# Getting It Done vs Solid Software Design?

With barely enough time at our hands to complete the games we craft, how can you strike a good balance between solid software architecture and making good progress to get it all done?

My personal challenge: How about being effective today and long-term thinking at the same time? Plus, while you're doing it you may just as well want to learn new things on the way instead of resorting to the same repetitive patterns you've been using those past 5 years?

The less experience you have, the more time you waste with up-front design. Making good designs is something that you will learn by doing it and then seeing/evaluating how it turns out. Some decisions have far reaching but obscure implications. After some games you will probably be able to make the initial design pretty solid and it will pay off to invest some more time to this stage.

My motto: get things done in the first place, but use you common sense to detect what components are more critical than others and designs those pretty well, within your time limit. For example, if AI is critical to your game, make sure that you can easily extend/change it later on. Or, if you're going to write a component that you will use in every game, design it for reusability. Track your time and don't go wild on designing. Set a design-deadline and after that, start hacking everything in to get your release-deadline. But make sure you note what points need refactoring/redesigning afterwards and calculate in some time before you start on the next game to improve those things, so that they don't get to bite you back!

A good advice: if you have to choose between two options, don't linger too long over details. Most often, there is no "good" or "bad". In some situations, A will be better, in some, B will be, and overall, the difference between both may not always be worth the time.

There is a lot of experience to gain in designing software or games, so make sure you spend some of your time on research (e.g. reading a book on design, reading about others experience, talking with fellow programmers about your designs, etc...).

• +1, good advice. Don't let yourself be caught by the infamous Analysis Paralysis as this get's you nowhere. Whereas refactoring is a mighty tool to straighten out past flaws, so don't be afraid to make mistakes. – Michael Klement Aug 18 '10 at 10:07
• Ahh. Analysis Paralysis. My biggest enemy! I should build a game where Analysis Paralysis gets served as the End-Boss. I best start by designing the game-architecture first... Noooo! Joking aside: Great answer and good comment! – bummzack Aug 18 '10 at 12:15

People are terrible at predicting the future. This is especially true for games, where requirements can change on a daily basis.

There's a principle called YAGNI, aka "You Aren't Gonna Need It", which basically says that you shouldn't implement something until you know you're going to need it.

I've seen so many systems get bogged down with architectural rigidity that didn't actually use any of it since the features people thought they were going to need never got around to being used.

My personal philosophy is Do the Simplest Thing That Could Possibly Work. That being said, there's a difference between Getting It Done and Hacking Shit Together. Writing code with a purpose shouldn't imply doing things that generate "code smell" like making everything public, of having blob classes that do everything, or any of those dozens of other things that signify "bad" code.

This evaluates to true in my mindset today:

• Pragmatism over Ideology
• (1) Make it work (2) then make it right - game over if you forget step 2
• Release it!
• Too much up-front design will be a waste of time
• TDD and Clean Code leads to more simple, more stable software designs
• Can you elaborate on doing test-driven development in a game setting? Aside from some basic logic, I've never found highly interactive programs to be very well-suited for this kind of thing. Also, you are linking to the disambiguation page ;) – drxzcl Aug 18 '10 at 8:09
• @Ranieri If you draw a line between the parts that interface with the graphics hardware and user input, testing is straightforward. – Jonathan Fischoff Aug 18 '10 at 8:26
• @Ranier Thanks, fixed the link. I agree that coming up with tests first for interactive simulations or client-server games can be tricky. In addition to your unit tests you might probably want to have some higher level functionality tests and possibly playback sessions which run at certain intervals. In any case, thinking about the tests first is likely to pay off in many scenarios. Find some interesting views in gamedev.stackexchange.com/questions/1905/… – jmp97 Aug 18 '10 at 9:38

I'm friend of software rapid prototyping. Especially during game development. It's good for quick learning , testing and useing things. For close to hardware programming or complicated algorithms is the best method for me.

Theory();
RapidPrototype();
bool bOk = false;
while(!bOk)
{
Testing();
LotOfFixing();
PlayingWith();
bOk= AnalysingResults();
}
FinalFastAndNiceDataStructuresAndCode();


My version of Rapid Prototype has to have proper prototype crust:

• Max friendly input interface to configure directives and setup variables or data.
• Stable exceptions and errors handling.
• Online like debuger function but on level what you need to.
• Max friendly output interface for showing or capturing results on all posible and necessary ways.

• You can improve RapidPrototype crust during whole development.
• You can see and setup your code in many ways.
• You can focus only to theory and problem what You need to solve.
• You can fast develop any new parts of project and try it with the rest of final things.
• You can deliver new things for useing in content filling more quickly and finalize it later.(Especially in sandbox case)
• You can easily describe and show priciples or solutions to anybody else. Online.
• Funcional and transparent prototype is the best source of information for final code(anybody else can do it).

If You do it well You Can have real debug/learn version of your product on the end.
We are using it in our project and we are happy with it.

• This is pretty good advice, although I would recommend a time or some other kind of resource bound on the loop, after which you just exit(0) and try another prototype. – user744 Aug 18 '10 at 16:57
• @Joe Wreschnig - Time plans can be included in AnalysingResults() , but I think that You can use RapidPrototype for a while and finish it later or put it to the plans. Better then got stuck on it forever :). In RapidPrototype You can simulate functionality too. It's prety useful in many ways. – samboush Aug 18 '10 at 17:57

Have a look at agile software development. Although it is not a silver bullet, it aims to do both (get it done and have solid software design).

• I don't think there is any development methodology that doesn't claim to "get it done and have a solid software designer". – user744 Aug 18 '10 at 12:27
• @Joe I think many "heavyweight" methodologies tend to prefer CYA over solid software. Indeed, much of my non-agile experience tends to be "it doesn't need to be right, it needs to be right now," whereas "agile" aims to say "it needs to be right now, but do everything that you can to make stuff right as you go along." – dash-tom-bang Aug 19 '10 at 21:13
• I would argue that agile development has very little influence on whether the code is solid or not. The essence of agile is to spend all your development time on only stuff that matters. The code can still be a mess upon delivery, because code quality (or lack of technical debt) is rarely a measurement of success in a delivery. – Magnus Wolffelt Aug 1 '11 at 15:23