V
Home Rules Plug-Ins Forums Donate


 
Page 1 of 3 123 LastLast
Results 1 to 10 of 25
  1. #1
    Community Regular
    Join Date
    Jul 2011
    Posts
    44

    [Guide] A Decently Sized Dodgeball Map Making Tutorial!

    TABLE OF CONTENTS:

    Chapter 1:
    - Envisioning Your Map
    - Building Your Map
    - Fiddling With Skyboxes
    - Working With the Dodgeball Spawner

    Chapter 2:
    - Correcting Errors
    - Optimizing Your Map

    Chapter 3:
    - Packing Your Map
    - Building Cubemaps
    - Learning Advanced Methods

    Chapter 4:
    - Feedback
    - Tools

  2. #2
    Community Regular
    Join Date
    Jul 2011
    Posts
    44

    Chapter 1; Part I.

    Envisioning Your Map:

    Coming up with an idea is one of the hardest things you will do while mapping. Ideally you'll want to create something completely new, something dodgeball players haven't seen before. In order to do this, you need one thing, and one thing only. Genuine Inspiration. It can come from anywhere, pondering in your bed, browsing the internet, even watching a tv show/movie! Wherever it comes from, when you find your inspiration, write down the ideas that inevitably flood your brain. It's important to note that not all ideas will be good, and that most you will later throw out, however it is the one you don't throw out, that will be the best map you've ever made.

    When you find that inspiration, and start fleshing out the design, one of the things that has to remain in mind is functionality. When we say functionality, we're talking about spawner locations (dodgeball spawner, and player spawns) as well as obstacles. You must always consider the relative position of the teams in relation to each other as well as to the dodgeball spawner. Place a spawner too close to the teams and you get unexpected slaughter, likewise with placing the spawner too high above the teams.

    It's a good idea to draw a rough sketch of the map before beginning to build it. At least with a rough sketch, you'll have a general idea of how things should laid out. Proper planning will enable you to avoid the "first map blues", where your first map gets boo'd off stage because it's unplayable.

    So, you've drawn up a good design, and you like it a lot. You're now ready to move on right? Nope. Draw it up again, the more you draw it, the more options you have, and the more you have to pick and choose from later on. These iterations also help you to think through your map a few times, and visualize the gameplay, before you even build your first brush. It's not necessary to flesh out your design multiple times, however it can be extremely beneficial.

    Once you have your map design planned out, there are some other things you need to think about. For example, if you plan on using custom textures, you should gather those ahead of time. It saves you from constantly stopping while building the map to go search for more textures. Likewise with custom models and sounds. Realize however, that getting these different custom files to work can be quite a pain if you do anything slightly wrong. Luckily, this guide is here for you.

  3. #3
    Community Regular
    Join Date
    Jul 2011
    Posts
    44

    Chapter 1; Part II

    Building Your Map:


    Of course, you must know the fundamentals of building your map, however, this guide is mainly for the fundamentals of dodgeball mapmaking. Although, many good tutorials are listed in the tools section for beginners to source sdk. I suggest you look into these if you are completely new, as these are the tutorials I read and watched when I was beginning.

    To start, we’ll be adding custom textures to source for use. The first thing you’ll need is obviously the texture to be, followed by a program called “VTFEdit”.

    1. Open VTFEdit and locate the file > import option. Browse until you find your texture.
    2. A screen will pop up asking you what various options you want. Leave it be and click OK.
    3. It will take a small amount of time for the image to appear in the program - more or less depending on the size of the picture file.
    4. Click the save button and navigate to your [username]/team fortress 2/ tf/ materials folder.
    5. Create a new folder, if you don’t already have one, named “My Textures”. (Or in a folder named after the map you’re using the texture for. Whichever one works for you.)
    6. Save the file as “Custom_” followed by whatever you wish to name the texture. This way, when you search for your own textures, all you need to type in the hammer filter is “custom” and you’ll see all of your own files.

    Here, I saved my new texture as “Custom_Grass01”.


    Now, the program has saved the VTF file for the texture to the folder, but we also need a VMT file. Luckily, the program makes that exceedingly simple.

    1. With the same window still open, click on Tools > Create VMT File
    2. When the Create VMT File window pops up, go to Options and locate the Surface1 scroll box.
    3. Locate a surface that matches yours. There are tons to choose from. Picking the surface type causes the texture to make a sound relating to the type of surface we picked when stepped on.
    4. Click “Create” and save it as the SAME name as your VTF file. It’s VERY IMPORTANT that they are the same.

    Since I have a grass texture, I obviously choose the surface prop “Grass”. Simple as that.


    Now that you’ve done all that, you have a custom texture in hammer! Obviously, you have to do this for each new texture. Don’t worry, though! The more you do it, the more familiar it will become!

    Here’s a look at my custom_grass01 in the hammer editor!


  4. #4
    Community Regular
    Join Date
    Jul 2011
    Posts
    44

    Chapter 1; Part III

    Building Your Map II:

    Another custom elements that can add a breath of life to maps are sounds. Sometimes the hammer editor just doesn’t have the right sounds for use, and this is where adding your own comes in handy. The process can be confusing, but let’s keep it simple!

    First, you obviously need a sound. I’ll be using a .WAV called “Croak”. It’s a sound I used for my map Skydeck which is a frog croaking. It’s a really short sound, but in reality, you could add entire songs to your map. Just remember that adding these files adds on to the size of the map, and no one wants to download a huge map!

    After finding your chosen sounds, (there’s a link to a website with a large collection of .wav’s in the tools section), we need to begin the process of getting it into source sdk! You’ll need the Audacity program only, unless you need to convert a file type other than .wav into a .wav type. (Again, tools section).

    1. Go to your [username]/ team fortress 2/ tf directory and make a folder called “sound” if you don’t already have one. Do not add an ‘s’ to make it sounds. Just name it “Sound”!
    a. Inside of the Sound folder, make a folder with your username or map name, or however you wish to categorize your custom sounds.

    2. Open Audacity. Click import under the file menu. Locate your sound and click OK. The program will prompt you to either copy or read the file. Copy the file and click OK.

    3. A long box will open up with the sound file’s information. You need to make sure three things are correct, or else hammer will not play them correctly.
    a. The Rate must be 44100Hz.
    b. The sound must be Mono.
    c. The Sample Format must be 16 bit.


    You can change these by click the small arrow by the sound’s name, as shown here:



    4. Now that you’re done with fixing the rate and everything else, you can export it to hammer! Save it to your folder you created earlier!

    Example: [username]/team fortress 2/ tf/ sound/ [username]

    5. Now, to actually use it in hammer, we need to use the correct entities! Open Hammer and figure out where you want the sound to be and place an entity named “Ambient_Generic”.

    6. Click the ‘Sound Name’ property and then browse. When the sound browser pops up, navigate to the ‘sound type’ scroll box and select ‘raw’.

    7. Filter the search with the name of your sound and bam! It’s in the map!



    Note, that you will need something like a trigger_multiple or the like to trigger the sound. It’s a fairly simple process that uses outputs to trigger the sound whenever you deem appropriate - such as a player dying, taking damage, or just general area sounds that play continuously.

  5. #5
    Community Regular
    Join Date
    Jul 2011
    Posts
    44

    Chapter 1; Part IV

    Fiddling With Skyboxes:

    As much as people may like to neglect their skybox, it’s not a wise thing to do. Don’t just paste a skybox texture on a hollow box and call it a day. That’s bad not only for the optimization of your map, but also for viewability of the rockets. If your skybox is too bright, it can cause the rockets to disappear into it, leading to frustration from many players.
    Placing other bright things into a 3D skybox can be a disaster too. Waterfalls, clouds, anything that emits any sort of bright white or similar look can be a strain on the eyes when looking for rockets. Adding HDR on top of these is even worse. Talk about a headache and eyestrain on the players!

    The best way to make a useable skybox, 2D or 3D, is to use darker skybox textures and models, as well as shadow controllers, fog controllers and light environments. Not only do these make the map more visually easy on the eyes, it makes them seem more realistic!

    Take a look at this sample map. All I did was add a skybox texture around the platform. Notice how no shadows cast, everything is harshly bright, and the sky would be incredibly hard to see rockets against!



    Let’s fix this little example! First, I’ll pick a different skybox texture. Bright blue just doesn’t work, especially when the red team gets rockets surrounded by a bright blue particle effect. So, for this little test map, I’ve picked the skybox texture sky_day01_09. It’s nice in that it’s a tad bit darker. The Valve Developer Community has a nifty page with a list of the default skyboxes in game. I happened to choose mine from there. So, I’ll use the information listed with the skybox to fix the brightness, shadows, etc.



    The red box is ideal sun angle. The yellow is ideal sun pitch. The green is ideal brightness. Finally, the blue box is ideal ambience. Now, to show you where these numbers go!

    First, place an entity in the level. Then, search for the “light_environment” entity in the class box. Hit apply. Now, plug in the numbers from the website using the guide. It’s pretty straightforward. The only slightly confusing one might be the Ideal Sun Angle. It goes in the Pitch Yaw Roll box in the light_environment editor. So, after plugging in all these numbers, here’s what we get:



    Now, that will make a drastic improvement to the map! It will look much better, however, we could still add a couple things to help. Adding entities like Shadow_Controllers and Fog_Controllers will help make shadows clearer and places that are far off appear faded. However, since this map is just a small test one, I won’t be adding fog to it. There are a multitude of good fog tutorials out there and one is even listed in the tools section!

    Here’s the little test map after making those changes and adding a shadow controller:




    It’s amazing how much a map can change from just a couple things, huh?

  6. #6
    Community Regular
    Join Date
    Jul 2011
    Posts
    44

    Chapter 1; Part V

    Working with the Dodgeball Spawner:

    There are a ton of variables you could use when working with the dodgeball spawner. I’m going to go over some very basic ones - enough to get you started with placing them in your maps. Maps such as Drunknuke, Relentless and Various use outputs to make different effects with the rockets and nukes. However, those are more advanced and as such, will not be covered here.

    Placing the spawner into the level is fairly easy. However, since this guide covers the Voogru mod, you need to obtain the FGD to place the spawner into the hammer editor. The newest FGD is obtained here: http://www.dawgpaw.com/files/voogru_db_sdk.zip - Unzip the file into the /sourcesdk directory and you’re good to go.

    Here is a look at the fa_dodgeball_spawner entity that you will need to place into your map:



    All the properties may seem a little confusing at first, but they’re not really. I’ll go over the more important properties.

    Name: You MUST name your dodgeball spawner. You’ll need to add another entity later that uses the db spawner’s name to enable and disable it at round start and end.
    Team: Whichever team you select in the box, the rocket will belong to that team. Thus, it will not attack that team, but anyone not on that team. I.e., red rockets will attack the blu team.
    Min & Max Dodgeballs: This is obvious, but it’s one of the things that changes from multi-rocket dodgeball to speed dodgeball. Usually speed dodgeball maps have very few or only one projectile in play at a time. In contrast, multi-rocket maps like burst have dozens in play at once.
    Dodgeball Damage: Another difference from speed to multi. Speed rockets should one hit kill players, while multi-rockets do significantly less damage. The 30 you see listed as default in the properties actually does about 90 damage. So, increase this number to at least 100 when you are mapping for speed!
    Airblast Multiplier: Leave it default if you’re mapping for multi. For speed, increase it. It may take a little tweaking to get it just right. Try setting it around 35 to begin with.
    Fatboy Chance: Simply the percentage of the time a nuke is spawned. Default is 25% of the time. Maps like Twinnuke have 100% nuke spawn, whereas other maps may have default settings or lower.


    Once you’ve tweaked these things, you’ve gotten some progress done, however, you’re still not all the way there. You’ll need two more entities to properly complete the dodgeball scenario.

    Place two entities into your map. Try and keep your entities organized based on what they control. The first is a tf_logic_arena and the second is a team_round_timer.

    Open the [b]tf_logic_arena entity’s object properties. Change the “Control Point Enable Time” to 0. Unless you’re using a control point, you don’t need this. Now, you’re done with this entity.

    Open the team_round_timer entity’s object properties. Remember how I said to name your dodgeball spawner? This is the entity you use it with.

    1. Click on the outputs tab and then hit the “add” button at the bottom of the menu. Follow these directions to properly enable the spawner at round start and end:
    a. My output named [OnRoundStart]
    b. Targets entities named [Dodgeball Spawner Name Here]
    c. Via this input [Enable]
    d. Click apply. Disregard the “delay” and “only once” options unless you want there to be a delay in the spawner firing.

    2. Now, we need to disable the spawner when a team wins so it doesn’t continue spawning useless projectiles.
    a. My output named [OnFinished]
    b. Targets entities named [Dodgeball Spawner Name Here]
    c. Via this input [Disable]
    d. Click apply.

    Now, your spawner is ready to go! And with that, we reach the end of chapter one of this guide!

    Here’s a look at how the property boxes should look when done correctly:


  7. #7
    Community Regular
    Join Date
    Jul 2011
    Posts
    44

    Chapter 2; Part I

    Correcting Errors:

    Everyone will reach a point in which either their map will not compile, compiles wrong, has a leak, etc. This part of the guide will show you ways to detect and correct some types of general, common errors.

    Generally, the best way to fix an error, when one is encountered, is to use this site: http://www.interlopers.net/errors. You paste your compile text into the box there and it scans the text for any errors. It will often tell you the coordinates of any errors encountered so you can plug those into hammer and go right to the source. From there, you can easily fix the offending prop or leak.



    The other option is to use the pointfile in hammer to locate leaks. It’s also a backup to using the interloper’s error check as sometimes the descriptions for errors can be rather confusing. Go to the toolbar in hammer, click map and then load pointfile. From there, it will pop up a window where you simply hit okay. It will then load a red line leading to a leak IF there is an error in your map. Otherwise, it will not load a pointfile at all.



    Sometimes errors have nothing to do with leaks at all. Vvis or Vrad will either crash or stop responding for seemingly no reason. However, there is a very good reason that the two .exe’s are either slow or not loading at all! Optimization! Which leads into the next part of chapter two!

  8. #8
    Community Regular
    Join Date
    Jul 2011
    Posts
    44

    Chapter 2; Part II

    Optimizing Your Map:

    As stated in the previous part of chapter two, optimization is a major factor when making maps. There are lots of different things you can do to make your map the most efficient it can be. We’ll cover this part in stages, starting with the biggest factor:

    The skybox should not be a big hollow big covering the entire level. That is just bad. It can lead to all sorts of lag and drawn out vvis/vrad headaches. The skybox is best when it is six brushes intersecting, but not overlapping. Each brush should have 5 sides that have the “No Draw” texture applied. The only side with the skybox tool texture should be the obvious one : the one that faces the level.
    The brushes should also be to the power of 2 - 1024 x 1024, 2056 x 2056, etc.Just don’t go crazy with something like 999 x 679 or 257 x 3163.



    Here is one wall of a sky box seen from the front and back. As you can see, every side is no-draw except the one that would be facing the interior of the map.

    No Draw everything the player cannot see. That is the second mission in our map optimization! Anything not seen by our little pyro players should not have to be rendered by the engine! It just puts unneeded strain on the engine that can lead to way slow rendering times. It’s really as simple as it sounds. If the brush has sides that the player can never see, then why have them rendered? The no draw texture allows transparency and it doesn’t force an engine render. Below is a great example from the map “Champion”. The map maker did a great job optimizing the map.



    Detail brushes reduce cost. Basically, anything that doesn’t block your vision of something should be a detail brush. Things like stairs, rails, trim, etc - all should be detail brushes.

    Find a brush you want to change into a detail brush. Double click on it and in the class box, search for func_detail. Simply hit apply and there you go! Only things like walls, floors, ceilings, etc should be world brushes. Everything else can be a detail brush. However, don’t change anything into a detail brush until your map is completely built. You can’t alter func_details after they’ve been changed!



    This entire row of stained glass windows and trim are “func_details”!

  9. #9
    Community Regular
    Join Date
    Jul 2011
    Posts
    44

    Chapter 3; Part I

    Packing Your Map:

    A relatively easy but extremely important part of your map going from zero to rotation hero! Whether or not you have custom textures, models, or sounds in your map, you need to pack it using a program such as Pakrat. (Look in the tools section!)

    Packing things like sounds and textures are really easy. Simply open pakrat,jar and select your map when the dialogue box pops up. Another box with a list of items will pop up. Hit “Auto” and another dialogue prompt will pop up. The text will indicate that it found files to add if you used custom textures or sounds. Click to add them. Now, save the newly combined list to your current map name. It will ask if it can overwrite it. Click yes. It will make a backup just in case.

    An example of the pakrat process:



    It is a very easy process. Packing models is a different story. However, those will be handled later on. For now, we’re off to cubemaps!

  10. #10
    Community Regular
    Join Date
    Jul 2011
    Posts
    44

    Chapter 3; Part II

    Building Cubemaps:

    Cubemaps may be THE number one thing people forget when making maps. They are absolutely necessary however. Whether or not you have glass or other reflective objects in your level, you still need one for each side of the map depending on the size. Players wearing vanity items such as glasses, medals, and other reflective hatwear will look odd if there is no cubemap. The reflective material will show a layer of pink and black instead of the glossy perfection it would have with a cubemap.

    So, why did I wait until this far to mention cubemaps? Well, oddly enough, team fortress 2 is a bit weird in that you have to manually build cubemaps in after the map is compiled while in game.

    Placing the cubemaps in the editor is as simple as placing an entity and changing the class to env_cubemap. Team Fortress 2 doesn’t have a default size, so change it to 32x32.



    Place the cubemap either [3] 16 unit blocks above the reflective surface that the cubemap needs to reflect on, or at height with a player model’s shoulders when using to reflect in the player spawn area.

    After you compile the map, go to Team Fortress 2 and start your own game using your map.


    1. After opening the game with your map, open the dev console.
    2. Type in Mat_specular 0. Wait a moment while it calculates.
    3. Type in buildcubemaps. It may take a moment while pictures flash up at the top of your screen.
    4. Disconnect. In console, type in: map “cp_dustbowl”. You must join a new map to clear that cache or else your built cubemaps won’t be saved.
    5. Disconnect.
    6. Reconnect to your map and enjoy the built cubemaps!


    Your map is now ready to get tested! Please note however, if you’re using HDR lighting, there are quite a few more steps to rendering the cubemaps properly.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
 

Copyright © 2001-2011 voogru.com. All Rights Reserved.
Voogru, the Voogru logo, are all trademarks or registered trademarks of voogru.com.
All content on this site is the property of Voogru, and unless otherwise specified, may not be reproduced without prior written consent.