A very good set of guidelines, indeed. I just want to stress out one thing (clearly stated in the post, but whatever): you'll HAVE to make changes during the development. Design for later changes and implemet taking into account that your code must not only be interpreted by the compiler, but also be easy to understand by HUMANS. This topic might be worth of its own post, though.
Of course changes will always happen. So you have to design code for changes and flexibility. But it's also very useful, expecially in for us rendering guys, to at least TRY to minimize those. You really can't develop features blindly. You have to gather as exact as possible information on the requirements and gather experience and confidence on the methods you're going to implement. That does not mean that stuff can't change later on, but at least for the big features you should gain confidence in what you're going to do. And the easiest way to do that, for big and risky tasks, is to go through prototypes. Art guys can prototype the requirements by gathering visual references and do test renderers (do they need 1 or 10 lights? they can prototype that requirement directly in 3dsMax or Maya or whatever). Code guys should prototype the most risky things (100000 instances at 60fps? let's try if it's something that we can reasonably come near to in 2 weeks. It goes at 10fps? Then maybe the feature should be investigated more...)
Shouldn't this be OBVIOUS? In my experience, it is not.
This post maybe should e printed and posted on every wall in our company :D
February 25, 2008 at 2:28 PM
Game development is hard. Design is, by its nature, continously subject to changes. Competition is very high. The required investments also. You work on the bleeding edge of the technology. You need to have skills in many different fields. Many times missing deadlines is not an option, or it's very expensive and you have to deliver an high quality product as well in order to be able to compete.
It's really hard enough. You don't want to add on top of that a bad development process. You have to do the things in the best possible way, to manage to get everything working. And sometimes the temptation of avoiding good practices is high, due to the pressure you have expecially towards the end of a project. Some other times your company/game/product simply does not start in the right way. And then everything will be messy and a waste of time/money.
Change is not avoidable. You have to be prepared for it. You really want to identify probles as soon as possilbe. Plan every major feature. Gather requirements. Gather references. Plan possible implementations. Try to identify risks. Make fuzzy time estimates. Refine those estimate until you're confident enough about them. If you don't have enough information to be confident about your fetaure plan, stop and GATHER IT. Make early prototypes. Don't blindly try to do something and hope that everything turns out right. It WON'T.AGAIN: Don't do things blindly. Gather information. Make prototypes. This is not related to programming only. In example, you want to strive for a given lighting in your game. You're not sure about some quantities like the number of light sources, light types, shadow casting direction, shadow casting object, shadow receiving objects, etc... Then do a prototype with some test renderings directly in your 3d authoring application. Prototype possible solutions, see if it's reasonable to expect that your assumptions are right. Investigate about how many areas a feature will impact. Allocate your technical budgets for each major feature early (i.e. CPU time, GPU time, memory etc).Don't enter production if the planning phase is not done. You will have enough changes to deal with anyway. Don't start the real product if you've not investigated and planned all the major new features. Prototype everything that has an high risk. Be incremental. Work in small iterations. THINK. Develop. Test. Refine/refactor.Always test. Test as soon as it's possible. Run batch tests. Make a working game as soon as it's possible. Do early QA tests on every newly implemented game feature. Gather information.First priority is to have something working. You can't break the work flow. Spend extra time to make sure that your feature is working. Don't rush.And, more day-to-day coding related: Strive for code quality. Do reviews. Use linting tools. Adhere to good coding standards. Refactor.Design for change. Design for flexibility. Try to have as few interdependencies as possible. Try to be always able to trash a given code and rewrite it. It will happen. It SHOULD happen, as code WILL rot, no piece of code is immortal. This is expecially true in games, with fast moving technology and always changing requirements/scenarios. Keep the documentation updated. Run a internal WIKI. It has to be EASY to write the documentation. Documentation tasks should be allocated for any new major technological component. Comment your code. Comment your HACKS, you will do them at the end of the project, but at least you should comment them so you can remove them later.Before starting a new project on an old code base, clean the code base. KILL any dead code. Kill last minute hacks. Search for old "todo" items. Try to do the right thing. Don't cheat too much. Cheats are hard to maintain. Think about your tools. Tools are hard. Tools are the key of productivity and are the main mean of interaction between the coding and graphics department. If you can't affod to do many in house tools, find a way to leverage on existing technologies and be minimal. Don't build huge tools that you can't affod to refine and maintain. A bad tool WILL kill a good feature.If there are some items on that list that you were NOT doing during game development, then probably you're doing the wrong thing (or I wrote something stupid). If you do the wrong thing you will end up loosing money. If you loose too much money, your project will fail.
"You CAN'T afford doing things in the wrong way."
4 Comments -
Great post, thanks.
February 23, 2008 at 12:38 AM
A very good set of guidelines, indeed. I just want to stress out one thing (clearly stated in the post, but whatever): you'll HAVE to make changes during the development. Design for later changes and implemet taking into account that your code must not only be interpreted by the compiler, but also be easy to understand by HUMANS. This topic might be worth of its own post, though.
February 25, 2008 at 11:51 AM
Of course changes will always happen. So you have to design code for changes and flexibility. But it's also very useful, expecially in for us rendering guys, to at least TRY to minimize those. You really can't develop features blindly. You have to gather as exact as possible information on the requirements and gather experience and confidence on the methods you're going to implement. That does not mean that stuff can't change later on, but at least for the big features you should gain confidence in what you're going to do. And the easiest way to do that, for big and risky tasks, is to go through prototypes. Art guys can prototype the requirements by gathering visual references and do test renderers (do they need 1 or 10 lights? they can prototype that requirement directly in 3dsMax or Maya or whatever). Code guys should prototype the most risky things (100000 instances at 60fps? let's try if it's something that we can reasonably come near to in 2 weeks. It goes at 10fps? Then maybe the feature should be investigated more...)
Shouldn't this be OBVIOUS?
In my experience, it is not.
February 25, 2008 at 1:47 PM
This post maybe should e printed and posted on every wall in our company :D
February 25, 2008 at 2:28 PM