I've recently been thinking about all the little things that can go wrong on a project and all the things that can be avoided early.
One developer I was talking to was telling me how they lost several days of production time just reorganizing the naming conventions of their files. Imagine being half way done with a project and realizing that you have to go back and rename EVERYTHING in the game? A nightmare.
So I thought of a few things to keep in mind when starting a game in regards to naming files and some other things...
1) Keep it to eight characters if possible.
I can't remember which programmer I worked with told me about this, but he said that any file larger than eight characters actually took up more memory. I don't know if I believe him, but I do know that several programs will only display the first 8 characters leaving you with a file that looks like this:
AirWorld...
AirWorld what? Air World War two? Air World Level five? Air World Enemy one? It could be anything.
2) Come up with an easy to understand shorthand for file names.
Make a consistent legend of abbreviations to name files. Air World could be "Air" or "AW" or even "A" - just make sure you don't create redundant named files. I found it's useful to name things phonetically. If you're not sure about how to name something, think of it like a personalized license plate. "Level Designer" becomes "LVLDSGNR".
Just don't get cute and name things using 8 for "ate" or something like that. Naming conventions are not a puzzle for the other team members to figure out. Otherwise your files will end up reading like the titles of Prince songs.
3) Group files accordingly.
OK, I'm guilty of this one. Having well organized files that separate various design assets is really important not only to you but to your co-workers. Generally organize files by stages of production (concept, pre-production, production) and/or by components of information (level maps, character, feedback) You should always ask yourself, "if I were to die tomorrow, would my team be able to find the results of my design work?"
This, of course, is even more important when creating assets to be used in game. Asset management software like Alien Brain, DevTrack, Perforce and Subversion can make or break your project's production. Pick the right one for you and make sure everyone uses it. And backup files often. (daily if not more!)
Speaking of files, there's one other area that gets neglected by teams during pre-production...
4) For God's sake, get those cheats working early!
Getting your cheat camera up and running early is one of the best things you can do for your production. Not only will it help you develop camera postitioning during grayboxing your levels, but also you can use it to help block out "puppet shows" for cinematics. It's extremely invaluable for creating videos and capture screens for marketing purposes. Remember, other people are going to eventually going to want these kinds of assets and they don't want to play through the entire game to get to that one cool spot in the level.
The same is true for player character cheats. Invulnerability, the ability to "fly" your character around, ammo adds, health adds, money adds, the ability to turn powers, weapons and abilities on and off are very important to get in as soon as possible. Not only does it make it easier for you to play and test your levels, but it allows you to show off your levels in the best possible light when your head of production or that guy from the press comes around.
Make sure your level cheats (the ones that take you from one world/level/location/checkpoint) to another is in early as well and MORE IMPORTANTLY easy to access. Don't make the player/tester have to enter the "Capcom code" just to bring up a level or feature. Make it as user friendly as possible. I know it's something that the final product will never see, but you will be living with this game for a year or two or three and getting around it easily will allow you the time to concentrate on the good stuff like design.
5) Make sure you communicate all of the above to everyone on the team.
It's easy to assume that everyone is keeping up with what you are doing, but make sure that this information is easy to find, easy to read and easy to understand. Just because you ARE writing "stereo instructions" doesn't mean it has to read like them.
Good luck!
Subscribe to:
Post Comments (Atom)
Posts
2 comments:
Come on readers, anyone disagree with this post?
Anyone have any good advice to add that I've missed?
Sound off!
I strongly agree with two of your points:
1) Get cheats up and running quickly. As you pointed out, this will allow people to test the game quickly and easily. Let's say you design a level and you accidentally make a certain jump too far to reach. Now, you want to check out the rest of the level (Perhaps to look for the same mistake in other areas), but if you don't have some sort of fly cheat (Or in-game level editor), you can't do it without quitting and reworking that part of the level.
2) Make sure to communicate the above points to the rest of your team. Communication is key when designing games. You need to let the rest of your team know what you're thinking, what has been done, and what you need. Also, if you're going to have some sort of naming convention as mentioned above, it would be a good idea to have some sort of "Naming Conventions" file to let other people know what the standards are.
Post a Comment