Author : Drew Sikora
Page : << Previous 3 Next >>
many people like to read long, boring documents that tell them exactly what they have to do. Most people just like to go out, do it, and be done with it. I for one know plenty of people who either hate to read or complain that they fall asleep while reading. This line of thinking will endanger both the project and your well-written design spec.
To avoid the spec will have to be broken down so that it is accessible by related sections and topics. The best way to do this is by putting spec on the company intranet with search and sorting options. You could also go a step further and categorize the various sections by department and restrict access to areas that do not need to be seen by all team members. Doing this allows everyone to be able to read what they need to know, and not clutter up their heads with irrelevant information.
If a team member is angered by the fact that he does not have access to all information, he should be reminded of his role in the project. The more unneeded information a person had, the harder it will be to stay focused on his own task at hand and therefore decrease productivity.
Real-Time Development Part I - Dealing with Emergence
This is just a small mini-series that will cover aspects of the development cycle where problems may arise and have to be solved right then and there. In Part I, we will discuss the power of emergence. If you can’t remember what emergence is and how it contributes to a game, go back to Part 2 of the series and read the section Rules and Emergence.
So what’s the big deal? Can emergence really trip you up? Yes. Emergence does have the potential to stop development in its tracks, but that event is quite rare. How does emergence do it? Well, when a new game feature pops up out of nowhere, it brings up a decision - keep it or lose it?
Sometimes you may have no choice. If you take out the new feature, you may disable other features. If you change a rule, you may also affect other features and create more new features. Pretty annoying huh?
Other times the feature may not be too important to the game, and you can drop it without affecting anything else. This is good. However, just dropping a feature isn’t as simple as it sounds. If your project does not have a malleable structure, removing a feature can cost money. A lot of it. This is why some games may have a few weird "bugs" that just don’t seem right.
In the end it comes down to the choice of both the Designer and the Project Manager. If the new feature fits in and can be used, it should be kept. If the new feature interferes with the gameplay, it should be dropped or somehow hidden, no matter what the cost. If the feature does not quite belong and can be easily removed, it should. The amount of emergence you have to deal with is directly related to how well the game is designed.
Real-Time Development Part II - Feature Creep Ain’t Dead Yet
Time for another flashback to Part 2 - The Design. Feature creep is probably the most annoying part of creating a game. The urge to add feature after feature is just too much for most people. I know I was once that way. I would imagine a game with huge worlds, beautiful graphics, voice control, massively online, human-like AI, and everything in between. Of course, everybody thinks like this, and one day I’m sure we could do it. But not today.
As the game is developed there may come times where you will be hit with a sudden idea on how to improve it. You’ll say, "Gee, this is so much better than what I had before!" Sounds great right? Not really. If you start thinking like this you will lose the big picture. You must remember that a game is a whole, and that everything affects each other. If you were to spontaneously change something without taking the time to research its effects, the entire project could go down in flames. This is where feature creep is most dangerous. It was annoying in the Idea stage, irritating in the Design stage, hiding in the Document stage, and malevolent in the Development stage.
It’s up to the Project Manager to reign in the Game Designer when he gets too excited over a new idea. This is because the Project Manager is the one who has his hands on the money, while the Game Designer does not. A Game Designer may not think about the cost of researching a design change because the idea is just to good to be true. The Project Manager, however, should realize that pausing development to decide whether to change this feature will cost money, and should try to deter the Designer in any way possible if the team decides not to change anything.
The thing to remember about feature creep is that it’s hard to detect in all its forms, chrome and eye-candy. The thing never to forget about feature creep is to shrug it off as something that won’t be an issue for your project. This is just stupid. No matter what, feature creep will always find a way to cre- I mean, *opens up thesaurus* sneak into your project.
Real-Time Development Part III - Adding/Removing Features
This is sort of a culmination of all the add/remove topics discussed so far. Basically, we have decided that adding and removing features is expensive. This is true. The further along in development, the more expensive the cost to change things around. This should definitely be taken into consideration. Hard data shows that a change can cost up to 50 times more towards the end of a project than at the beginning. This may seem like common sense, but you’d be surprised how many people don’t think about it.
Removing features is a tough process, in terms of both time and attachment. Features may have to be dropped for many reasons, including meeting deadlines, lack of money, and lack of effort (or loss of productivity). When removing features, you must decide what overall impact it will have on the game. If you are removing a key feature of the game, it must be replaced with something akin to what’s being taken out. If this is not possible, then the project must be scrapped so that money is not wasted on a financial black hole.
Adding features can also be tough, since you must recognize the fact that adding a feature could cost money and turn out to be chrome or eye-candy. Features must be thoroughly analyzed to determine how they will aid the gameplay before they can be included in the project. If the feature does not help out the gameplay, it should not be included, simple as that. This decision should come from the entire team, so that no one person can rationalize the feature to be helpful, when it is not.
Of course, if time and money allow, adding features is always a good thing. Enhancing the graphics, using multiple UIs, sticking in a few more NPCs - these are all things that can be added as an after thought, but never during production.
Polishing the Finished Product
After everything is said and done, there still come the Proving Grounds. All the while through development your team of testers should have been trying to break every build handed to them. Some people may like to save money by calling in the testing team late in the development, but this doesn’t justify the financial benefit. As soon as you have a build of the game playable, it goes to the testers. Programmers can test their own creations, sure, but that takes time away from coding new program segments and modules. A testing team is not just there to proof the game; it’s there to take a load of the programmer’s shoulders.
Before you decide that a game is ready to be sent out to the publisher, you must be assured that the game runs smoothly. This post-production should be quick and dirty. If a problem is found, it should be fixed as quickly as possible. Post-production time is usually cramped due to past project delays and shortcomings. Also known as "Crunch Time", post-production is very, very stressful.
The deal with crunch time is that you have x amount of days or weeks to either finish the project or polish it. Ideally, the project should be finished and you should be spending all your time trying to break it on every system configuration you can think of. The amount of time you have to carry out post-production work is based on how well the project was architectured, managed, and scheduled. So you see, we’ve come in a full circle. What you decide at the very beginning will, of course, affect the way everything ends.
The Misuse
Page : << Previous 3 Next >>