CTF_Round

Discussion in 'Map Factory' started by Krowbar, Aug 3, 2010.

  1. Krowbar

    Krowbar L1: Registered

    Messages:
    24
    Positive Ratings:
    0
    Hey guys!
    This is the very first TF2 map that I've worked on! :blush:

    "CTF Round" is a very, very small CTF map and is loosely based on a Jedi Knight II CTF map. However, I've been trying to make it different in ways that will make it work better for Team Fortress. This if my first public release but I've done a lot of lot of work on it already.

    The center of the map features a large circular pit that has two crossing bridges that allow access to either team's base. Each side has a main exit and a fairly vulnerable sniping area that can be accessed by high-jumping classes. Each team's intel is also in a large, circular pit that encourages pyro "poof"-ing :p

    The idea of the map is to have a fast, high-capture map with short respawn times and short intel-return time that only requires few players.

    More resources, such as real screenshots and further updates should be coming soon. If you have any constructive criticism, I'd LOVE to hear it. Right now I'm trying to get gameplay mechanics right before messing too much with the look. If you just want to say how much I suck and the textures look terrible... I already know. :facepalm: Dev textures are temporary. Don't waste you time telling me that.

    Thanks!
    -Krowbar

    PS If you haven't done this before, stick the file in "C:\Program Files (x86)\Steam\steamapps\<your name>\team fortress 2\tf\maps", then start TF2 and create a local game (using that map).

    EDIT: Added legit screenshots.
     
    Last edited: Aug 24, 2010
  2. Prestige

    aa Prestige im not gay anymore

    Messages:
    1,769
    Positive Ratings:
    1,517
    give us some pictures in game please.
     
  3. Omnomnick

    Omnomnick L6: Sharp Member

    Messages:
    335
    Positive Ratings:
    100
    Yeah, we need a lot more than a top down Hammer screenshot to convince people to download and actually play your map. Ingame screenshots please!
     
  4. Lancey

    aa Lancey Currently On: ?????

    Messages:
    3,076
    Positive Ratings:
    1,314
    You can take in-game pictures by binding a key to "jpeg". Whenever you press that key, you'll find your new screenshot in your team fortress 2/tf/screenshots/ folder.

    I also recommend typing the following commands before it:
    Code:
    sv_cheats 1
    cl_drawhud 0
    r_drawviewmodel 0
     
    • Thanks Thanks x 1
  5. Krowbar

    Krowbar L1: Registered

    Messages:
    24
    Positive Ratings:
    0
    Oh wow! I really didn't expect so many people to be interested in my map so soon! This wobsite really is active, ain't it?
    Anyway, I just uploaded some screenies as requested. The reason I didn't before is because I have a real crappy internet connection and wanted to do the total upload in pieces. ~_~ The Hammer pic was just temporary.
    Also, @Nerdboy, I already knew about the console options from someone else's map thread but I didn't know about the "jpeg" command. I was binding to "screenshot" then using Irfanview to convert (very nifty utility).
    I've linked some IRL friends and some web friends to this thread so hopefully I can get even more feedback.

    EDIT: Also, things I've learned... carve-ing a hollow cylinder from a cylinder is a TERRIBLE, TERRIBLE idea. Just for further reference for anyone who hasn't tried it... "this will all end in misery." A much better idea is to create a however-many sided cylinder and then place your rectangular solids / quadrangles all around the cylinder and delete the inner cylinder when you are done. If I had known that when I started... -_- Fixing map leaks was H***! Anyway, I may go back and replace all my semi- and full-circles with that technique once I have the rest of the feel of the map done.
     
    Last edited: Aug 3, 2010
  6. StickZer0

    aa StickZer0 💙💙💃💙💙

    Messages:
    664
    Positive Ratings:
    667
    Hehe, I remember this map from Jedi Knight II :p

    First thing I can see - it needs lighting (this tutorial should help).

    Second, so many deathpits may not really work in TF2, players don't like to feel cheated by falling off a thin platform to their death, especially if there wasn't an alternative path. Get this into gameday sometime once you've added lights :)
     
    • Thanks Thanks x 1
  7. Lancey

    aa Lancey Currently On: ?????

    Messages:
    3,076
    Positive Ratings:
    1,314
    Carving cylinders into anything is a terrible idea.
     
  8. Krowbar

    Krowbar L1: Registered

    Messages:
    24
    Positive Ratings:
    0
    @StickZer0 Hah! It's cool somebody recognized it! :p Also, I've been trying to toy around with different ways I could create alternate paths without destroying the whole "big open circle" idea. Secondly, yes, I know it needs lighting... it's still the first alpha so I was more concerned with closing map leaks and getting it to look presentable before getting lighting going. Thanks for the link, though. I'll check it out.

    @Nerdboy Yep... carving anything other than a square from a square just don't work well. This was something I learned the hard way. :D
     
  9. Lancey

    aa Lancey Currently On: ?????

    Messages:
    3,076
    Positive Ratings:
    1,314
    Carving blocks is also frowned upon. You should use the clip tool.
     
  10. Krowbar

    Krowbar L1: Registered

    Messages:
    24
    Positive Ratings:
    0
    @Nerdboy Woah! I never really was sure what the clip tool did but I was just messing around with it now and I really see the utility it has! One thing that makes me curious is why they even have the carve tool in there at all if any use of it seems to be "frowned upon." Is there ever a good use of it?
     
  11. Seba

    aa Seba DR. BIG FUCKER, PHD

    Messages:
    2,363
    Positive Ratings:
    2,365
    No, because it may create microbrushes that can break the compile. Also, it's bad.
     
  12. Krowbar

    Krowbar L1: Registered

    Messages:
    24
    Positive Ratings:
    0
    @Seba-079 Yeah, yeah... I've had first hand experience with microbrushes breaking my compile. Very annoying to fix. :-{

    @StickZer0 What if I changed the central circular area from a death pit into some other, more lengthy route to the other team's base? I could probably keep 1/4 the death pit in the center without it being too annoying ala KOTH_Nucleus.

    I'm staring to add lights but I was thinking of designing the cap rooms similar to the cylindrical, er, "computer" room in "Sam & Max 304: Beyond the Alley of the Dolls". If you've played the game, you'll know what I'm talking about.
    EDIT:
    To that end, I'm looking for a tutorial on how to add moving objects to a map in TF2. So far my searching on the dev site and on google has resulted in squat. Any recommendations?

    DOUBLE EDIT:
    I was also thinking that setting up camera/monitor systems would be really, really cool but the research that I've done leads me to believe that this is impossible to do in TF2 (altho it is possible in HL2). Anybody have resources that contradict this?
     
    Last edited: Aug 5, 2010
  13. StickZer0

    aa StickZer0 💙💙💃💙💙

    Messages:
    664
    Positive Ratings:
    667
    Good to hear you've started adding lights - you said you were concentrating on getting your map to look "presentable"; lights are very important for that, moreso than proper textures or props for the most part.

    I definitely agree with the idea of players being punished for falling off by having to take a longer (however, more sheltered) route either back to their base or into the enemies, similar to the sewers in 2fort.

    Moving objects don't work that well in TF2, especially when you consider that ALL lighting in TF2 is static so you won't get moving shadows, plus it can be confusing or annoying for gameplay. If the objects are going to directly affect combat, try reconsidering and thinking whether it will actually make the map more fun. If it's an indirect thing (such as a bridge that comes out after X caps, or maybe a door), then you should check up on func_doors. Also come in the Steam Group Chat if you have any problems.

    As for your cameras/monitors, this is impossible in TF2, sorry.
     
  14. Krowbar

    Krowbar L1: Registered

    Messages:
    24
    Positive Ratings:
    0
    The moving objects thing I was thinking as more of an aesthetic thing in the cap rooms. ie an object or inaccessible robot arm swinging around in slow circles, accessing the data banks. I completely agree that moving platforms in tf2 really do suck gameplay-wise. Will func_doors go in a circular pattern?
    Also, ALL lighting is static?? Are you sure? What's the whole point of dynamic props then? I thought those were calculated dynamically. :(
     
  15. StickZer0

    aa StickZer0 💙💙💃💙💙

    Messages:
    664
    Positive Ratings:
    667
    Ok, you got me there heh.

    Dynamic props are lit ingame, in realtime, and they cast cheap "dynamic" shadows on the floor in the same way a player model does. However, if you have a prop_dynamic in an outside area, when VRAD is run, it will cast a static, lightmap shadow on the floor. When ingame, you will see this shadow, plus the dynamic one. When the prop_dynamic moves however, the static realistic lightmap shadow will stay in place, but the cheap dynamic shadow will move accordingly. You can disable the static shadows though.

    Func_brushes, func_doors, and basically any brush entity will cast static lightmap shadows (unless you disable them) but they will not cast cheap dynamic shadows.

    As for the rotating robot arms, as long as they're not totally focused on and the area around them is lit in a clever way, people won't notice the lack of shadows from it (dynamic shadows don't cast very far). Func_doors won't rotate, but there is a brush entity that will. I'll get back to you on that when I remember what it is >.<
     
    • Thanks Thanks x 1
  16. Krowbar

    Krowbar L1: Registered

    Messages:
    24
    Positive Ratings:
    0
    Ho'kay! So, things are really going swimmingly except for a few exceptions. >_< (See bottom of post)

    I broke down and decided to replace the terribly UGLY central, carve'd circle with a series of quadrangle elements. I have to say, this looks, feels, and acts so much better!

    I replaced the primary death pit in the central room with a lower floor that currently has one set of stairways to come back to the central area (which will be mirrored on the other side).

    While I appreciate the advice on adding lights, the lights I added look very fake and awkward (and fairly substantially increase the compile time of the map). Any tuts on making GOOD looking lights and environment recommendations?

    I messed around with env_sound elements in blu cap room and started trying to make it look more intimidating.

    I managed to import a custom texture using pait.net, vtfedit, etc., then adding it to a map using PackBSP.

    **Right now my biggest problem is that I am always getting leak errors with the pointfile generating a line that goes straight through a brush. Before you ask, I checked... they are all brushes and no "func_??" or "prop_??" items. Any advice on that?
    Oh, I also learned that a "func_trigger" brush outside of the map will result in a leak error. Who would have thunk it?

    Once I get a fairly stable version of the map done (ie no more leak errors) then I will release it here with additional screenshots. Thanks for the help so far, guys!

    ** EDIT: Another problem that I've been having is that all my props have a purple grid overlaid on them in-game and look quite bad. I'm assuming this is related to the leak issues and will be resolved once I get that taken care of.
    Also, I tried adding two overlays proclaiming the "RED" and "BLU" bases but they don't seem to be appearing. Is this an issue that will be resolved after the leaks get fixed, too?
     
    Last edited: Aug 10, 2010
  17. Terr

    aa Terr Cranky Coder

    Messages:
    1,591
    Positive Ratings:
    405
    1. Make sure the brushes involved are not entities of any type. Make sure :ig: is turned off when you're looking at them or they'll appear to be non-entity brushes. (Since an entity can "group" brushes together.)

    2. Check that the leak isn't starting somewhere on the outside. If you don't see anything, then it could be a misplaced origin-point for a brush entity. You can turn on :helpers: and the currently-selected brush entity will show a blue dot (in 3d view) or a small circle-dot (2d view) for its origin. You can select-all brushes and see if anything shows up there.

    This is normal in TF2, and is a purely-visual issue you need to fix after each compile. The key phrase is "building cubemaps. (Basically, it means generating a lot of quick-and-dirty reflection pictures for shiny things to use.) The purple-checkerboard is the texture always shown as a placeholder when the real texture is missing.
     
    • Thanks Thanks x 1
    Last edited: Aug 10, 2010
  18. Krowbar

    Krowbar L1: Registered

    Messages:
    24
    Positive Ratings:
    0
    Thanks for the advice, Terr. I would have tried that yesterday but the power was out. :-/
    Anyway, I'm still having trouble with leaks that go through the map. Here an example of what it looks like in Hammer http://i197.photobucket.com/albums/aa149/russellchamp/TF2 Screenshots/leak_image_01.png

    Also, I should mention that I've been getting a lot of "FindPortalSide: Couldn't find a good match for which brush to assign to a portal near (x y z)" errors. Could that be related to the leak issue? A full compile/error log is available here: http://pastebin.com/dBxSbzUM

    EDIT: So I had an idea... would it be possible to just encompass your ENTIRE map in one HUUUGE box, call it a day, and never have problems with leaks any more? Would that work or is that infeasible, bad form, or frowned upon for some reason or another?
    EDIT EDIT: Yeeeeeaaaah... so that's really not working. The compiler is now stuck at "PortalFlow" and won't get past '4'. I'll let it go another couple minutes and see if it ever finishes.
    EDIT EDIT EDIT: Well, that didn't work. It just stuck there for quite a while, not progressing at all, staying unresponsive, and keeping my CPU up at 100% for an extended period of time. I had to force quit it and manually stop vvis.exe as well. Looks like that "easy fix" was not the best solution after all. >_<
     
    Last edited: Aug 11, 2010
  19. Terr

    aa Terr Cranky Coder

    Messages:
    1,591
    Positive Ratings:
    405
    • When checking for leaks, go to your vis-groups (the checkbox things on the right) and uncheck "Entities", "Tool Brushes" and "World Details". Also "Displacements" deeper down. This makes it so that you only see the walls/floors/etc. that actually matter when it comes to stopping leaks. (Remember to enable them again later, since they also affect what does or doesn't get compiled.)
    • The "huge box" approach is bad for optimization reasons.
    • If you need the "big box" approach temporarily, or to "quick compile" just a small part of the map for testing, use the cordon :)cordonenable: / :cordonedit:) tools instead. It basically says "Only compile stuff inside this area and automatically make a big box around it".
    • If you have a leak, don't bother continuing the compile steps, it generally takes forever and doesn't give you a useful product.
     
    • Thanks Thanks x 1
  20. Krowbar

    Krowbar L1: Registered

    Messages:
    24
    Positive Ratings:
    0
    Thanks, Terr. I tried messing around with the vis-groups before (and did again per your recommendation) but couldn't find any problems. However, after fiddling around with a few brushes further back in the point-file line, the issue took care of itself.
    I did get a general "Leaked" error and flew around and found that one of my floors had become a func_detail. Is there any way to simply "undo" this and make it back into a brush? Just deleting the name from the class won't fix it. :(

    EDIT: Also easy question, brushes with "nodraw" on the back side of them will still hold in leaks, right?
     
    Last edited: Aug 11, 2010