|01-11-2007, 06:58 AM||#1|
My non de plume...
Join Date: Dec 2004
Tutorial: Using a Game Design Document
This is nothing you have to do or follow adamantly. It was just a great idea that I realized to help create quality maps that don't need a ton of betas or revisions. I strongly recommend doing something like this, but it isn't required to make a map.
In game design, design documents are written up before any of the actual developing of the game occurs. There are three documents along with several reasons for creating each document. These are:
I'll be focusing on the Game Script for this tutorial, since that's the document that really matters to you as a mapper. The other documents are really just to get your idea sold to a publisher who will in turn fund your idea into a game. A normal game script for an entire game consists of about 50-200 pages. In some cases, as with some of the Final Fantasy games, the script has been as long as 1000 pages. However, since we're only dealing with a single map, the script should be at least 5 pages long, although it can go as high as you desire. Preparation time for this should last anywhere between a week and a month. Reserve the first 4/5ths of this time for thinking of what you're gonna write and the last fifth on actually writing the document. The thinking portion can include notes and the like, but these will be finalized and revised into the game script document in the end.
This document acts as a definite reference for everything that will be contained in the map. The primary advantage of this is that if you feel unsure of what you're doing or confused as to what to do next, you can refer back to your game script to look up whatever it is you need. Naturally, this requires a lot of thinking and fleshing out of ideas (which is why I reccomend so much time for thinking). The document contains creative, conceptual and functional aspects of the game. In traditional game scripts, technical design is not included but this our purposes, I think it would be acceptable. You should include what you want the general atmosphere of the map to be, being as detailed as possible with where you want things to go in what places, how you want paths to be set up, balancing between weapons, etc.
As a rule of thumb, with this document you should be able to "play" the map. That is, you should be able to either use the document to actually go through the level without the use of a computer; using your head, being able to play it on an elaborate board game or through some kind of table-top roleplaying game. This should give you some kind of idea of what to include in the document. I'm not saying you have to sit down and play it. You should only be able to theoretically play it with what you have in the document. Try not to confuse this content with what's already in your head. If ideas for your map are in your head, decide on the best alternative you have and then record it in your script.
Now I'll get to specifics in dealing with maps in Unreal. I'll be going in a slightly chronological order. This is my specific way of developing a map idea, as well as the map, but you should find your own style for this kind of thing. Don't try to conform to what is good for someone else. Starting out with the simplest of maps: DM, CTF, BR and DD, I'll be ammending sections pertaining to ONS and AS which can be more complicated. Firstly, I decide on the general ambience of the level. Do you want something in the jungle, city, inside a sewer, etc.? This needs to be decided so that you have a clear idea in mind for later on when you're picking textures and static meshes. From here, I would go on to get an idea of the general feel and flow of the map. In an indoor map, this means deciding where all the rooms are, what's in them and the paths that connect all the rooms. I completed this with success by using hand-drawn schematics. This isn't totally necessary and your drawings don't have to be to scale because you can always tweak them in the editor. If the map is outdoors, decide on any structures you'll include, the kind of skybox you'll need and how much the terrain will vary. A map like AS-Comet has a large amount of varying terrain while ONS-Frostbite uses terrain to seperate opposing forces and CTF-FacingWorldsClassic, which utilizes very simple terrain structure. Included in this is where you want static meshes and what kind of textures to use. Mind you, you don't have to memorize every static mesh to do this. Simple use "markers" where you would like certain things to go. Just write "crate" or "light fixture" wherever you need those things to go. The technical part of the can wait until you're in the editor.
After you have the general structure of the map laid out and perfected to a point where you're sure that's what you want, you're ready to move on. What I would reccomend next is setting up the lighting for the map. I do this room by room or area by area. Sometimes this is generally easy, especially for an outdoor map with the sunlight actor. In this situation, you have to worry about the large ambience of the outdoor setting as well as smaller ambiences within structures. Stormblade and I have a rule: the more lights, the better. As long as you don't use weird effects which can distort textures or too many coronas, which can be distracting to gameplay, you shouldn't have a problem with performance. One last thing on lighting: no one likes to see the default lighting and it even makes some veterans really annoyed. Try to match the color with your surroundings and use many smaller lights instead of a few big ones.
With lighting comes sound, which is a very important part of your map. Look at something like Stormblade's version of Ballx or DM-Conveyor. Just about anything makes a sound, including nothing. By now you probably think I'm insane, but bear with me. First of all, we have one of the most important sound pieces: ambient sound. I'm not really referring to the AmbientSound actor in UEd, but rather the sound that's heard at all times either within the entire level or within the zone of that level. For example, in an outdoor setting you could have crickets, birds, wind, whatever you feel is within your motif. In an indoor setting, there is a specific pack called IndoorAmbience that you could use for various effects. Just don't go with nothing. When you've got this down, its time to assign specific sounds to certain things, such as movers, static meshes or even textures. A good rule to go by is assign a sound to anything that moves. This compounds the effect of the movement and helps the player be more aware of his or her surroundings.
By now you should have documented how your map should feel and a general construct for which you can refer to in the future. Now comes the technical part. For all gametypes, you need weapons. The hard part is figuring out where to place each weapon for the most strategy. For example, DD, CTF and BR maps are mostly balanced, as are the weapons. However, different weapons in DM can appear in different places where those weapons would be advantageous. For example, a lightning gun being on a tower. Health goes along the same scruple. If you're going for a CTF or DD map, your map should already natively be balanced in some way. If this holds to be true, you shouldn't have a problem placing the flags/nodes/ball/goals. (Or at least markers to represent these things.) The technical aspects go further with things like triggers or pathing. Whatever you plan to do that require these type of actors or similar actors, you should record in your document.
For AS and ONS, this can be tricky. First, you have to make sure you know where you want your nodes to be and if the distance between them is balanced. Then again for AS, you have to have a balance between the weapons for both of the teams. Another rule of thumb says that the weapon power of the attackers is directly proportional to how easily the defenders can defend, that is, how effective their entrenchments are. For example, on AS-Damnation, the attackers already have rockets, flak and hitscan while the defenders have to search for the flak and sniper, since they're independent of the weapon lockers and also due to the fact that they are close to the objective and have an overhead advantage. For the AS objectives, you should be really concise. I reccomend having a list of the objectives with the optional objectives included (if applicable) and where these objectives would be as well as what kind of objectives they are. Be sure to also include what happens when an objective is completed.
That's all I really have for now. I'm trying not to write this out all at once but hopefully this will work out for someone out there. Like I said, you don't have to follow my advice to the letter, but having a predetermined plan of action before just diving into the map really helps when you aren't sure what to do next or you have a problem with re-working your ideas so the whole creation process takes longer then it really has to. That used to be a problem with me.
If you read through this, or even just skimmed it, thanks. I really appreciate it. Hope this helps.
It's insane this guy's taint!
|01-11-2007, 10:28 AM||#2|
Lord of Death
Join Date: Dec 2004
Location: South Carolina
We used to have to do something similar at the company I worked for when I was a developer. I personally think it it bullshit and a waste of time. Having notes and an idea before you start is useful, but excessive documentation is how you get caught in a Dilbert-workplace environment. You write and write and have meetings and discussions but nothing is ever accomplished.
Why make someone who is creative visually write out what they are doing. Design and development in general is not a "sit down and make X", it is X becomes Y becomes Z. It is an organic processes. Yes, you need some direction and information before you start, but not letting the bulk of the process happen naturally I think is a big mistake.
|01-11-2007, 05:29 PM||#3|
Join Date: Dec 2004
Location: Long Island, New York
Wow Arsenic, that was really informative and it brought my mind back to a time when I was heavily into creating RPGs and Sagas for StarCraft\Broodwar.
As for me, when it comes to UT, I begin with a "flash" vision, or a stream of sudden thoughts in my mind. This can occur at any time, regardless of where I am or what I'm doing. Creativity is only limited by the imagination. In any case, when this happens, I HAVE to either immediately start building the map in the UEd, even if its just a simple box and I start littering it with meshes (just a simple placeholder for my thoughts) or, I start jotting down as many things as I can on paper or a text file. I then sort through my notes (or the room) later on and try to make more sense of the madness. From there, I just let my imagination run and sometimes it all comes together real easily, as my Unwheel map "Omnipotents Motorsports" did. Then again, sometimes its more trial and error, and I suffer from setbacks and mapper's block... as with a few maps I still have unfinished after 2 years because... well, I still love the map in progress, but things just don't go as smoothly as I wish they would (ie: ONS-GameGrid-1, DM-)o(mas, etc).
Now, going back to my Starcraft days (man I miss that game). I remember heading up to New Hampshire for Thanksgiving. Now, take into consideration that here was a 39 year old guy whom basically never saw anything north of Long Island and for 7 hours I sat in the car scribbling away notes and drawing 1/2 assed sketches of portions of a map which only existed in my mind. I spent 3 hours in the hotel room one night continuing my stream of thoughts to paper. Then several more hours here and there before the trip was over... (need I mention that my GF at the time wasn't too happy about all this ) Once I was back home I started going over all my notes, cleaned them up via a word processor, the sketches were redrawn much cleaner and in color on new paper... and then I began creating my new world. A month or so later, my newest "Realm" was now fully playable. I'm extremely proud of that 1 map which takes a good 6-10 hours to complete in single player mode, and a minimum of 5 hours with 2 players. Unlike Starcraft where you could control up to 600 characters at once. In this 1 RPG map, you were you, 1 character. You either lived or died. You could however, hire a maximum of up to 5 other characters to help you along in your quest.
All along the way, I had already setup who would be who, what the different characters in StarCraft would represent (as NPCs and playable Upgradable characters), what the main goal of the quest would be, mini-quests which needed to be overcome to continue on, side adventures to gain more XP and wealth so you could get healed, buy retainers to help carry your treasure... I mean honestly, if I were to list everything about that one map and how it was played, the dialog which popped up on the screen, the amount of custom sounds, the way I completely reworked all the character stats, the custom points system to track your progress, the massive amount of triggers, 100s of enemy spawn locations, music triggers, etc, etc, I'd be writing 10 screens worth of info. What's cool is, when you play that map, you almost forget that its StarCraft. Mission accomplished.
Unfortunately, not 1 of my nearly 50 custom maps were ever seen by anyone outside of Marc and I. Perhaps I should reinstall the game, get all my maps together, go through them, and perfect them, and release them somewhere.
Now back to UT. I hope others do take the time to actually read what you wrote as it IS enlightening. You brought up several very important things which so many authors fall short at. These were....
- Preparation (if you haven't a clue what you want, why start?)
- Choosing a theme (pick 1 and stick with it!!!)
- Lighting (properly used)
- Sound fx (bringing the virtual world alive through use of sounds)
- Weapon balance (makes or breaks a map)
And honestly, there are so many other things we could add here that we'd keep people reading all night. "Particles" (emitters) being the toughest things that I hate trying to explain to people because they are so damned complicated that even in the vid tutorials, the guys were like "If we tried explaining even 1/2 of what there is to emitters\particles, we'd have to write a book". Reverse engineering these little bastards has been my hobby for 3 years now. And honestly, sometimes I still sit here thinking "How the hell did they create THAT effect?"
I don't know about anyone else here, but I'm really looking forward to getting my hands on the new UEd. I've been told there will be a STEEP learning curve (even StevenHorton of the UnWheel team is having problems with a cutdown version from some game he just picked up). Then again, we all start somewhere. Its just nice to know that at least these days, we have enough talent pooled together within these forums that no question rarely goes unanswered anymore.
Again, that was a wonderful post, Arsenic. Thanks for the kudos as well. You've been there for me for 2 years now as well, and you have helped me get through some sticky situations... so I throw kudos back at you, Bro.
|Thread||Thread Starter||Forum||Replies||Last Post|
|Simple Skin Tutorial||Anonymous[Lolz]||Unreal Tournament||0||01-23-2011 02:27 PM|
|Normal Mapping Tutorial||Big_Al_B||Mappers' Corner||2||02-25-2008 09:50 PM|
|Vehicle creation tutorial?||Solace||Games and Technology Workshop||42||08-21-2007 05:19 PM|
|Moving around in low-G ONS: a tutorial by N||_N_||Onslaught||16||08-20-2007 09:09 AM|
|A Skinning Tutorial||R.E.D.psk||Games and Technology Workshop||1||11-02-2005 04:45 PM|