Simplicity Oriented Programming

After few years on Warsztat (a Polish gamedev site) I’ve noticed an interesting phenomenon. Every now and then there are Compos (programming competitions) organized in two different flavours. Some compos are single-run events that last only few hours, others are long-term (several days/weeks). And as an extra catch, the former are usually restricted to basic APIs (SDL, OpenGL etc) while the latter are free-for-all (all sorts of engines, UDK/Unity allowed).

Now, results are somewhat shocking. Much more people participate in short compos than the long ones. But the best part is that quality of games created is just the same, no matter if the games was made in 2 hours or 4 weeks. Why?

  1. Well, creating game in 4 weeks doesn’t usually mean neither 672 nor 224 working hours. In extreme cases 4 week compo is just a 2-hours compo, with 2 hours located at the very end of 4 weeks.
  2. A lot of game value is an idea. Fact: you won’t come up with better idea in 4 weeks than in 10 minutes.
  3. Development process for 2-hours game is very dense. And most of the time is spent on improving core features (because there are no others).
  4. On the other hand, in long-term projects people start to focus on insignificant features. The moment you start improving abstract communication between task pools, adding GUI widgets so that you can make a built-in MP3 player or making splash screen data-oriented, your project is screwed to hell.

And this is probably the most important lesson to remember. If you need to do something very quick, code will be horrific, but also short, simple and fixable. With no time constraints, code will get new levels of complication, features and bugs. Time spent on maintaining won’t justify the result.

In 4 weeks, you can make several iterations of speed-coding, each time improving core features of the game. If you start with future proofness in mind, writing code and fixing bugs will consume most of the time. Sure, in 4 weeks you can make a ton of assets/levels, but how good are they is core gameplay is not good enough?

Finally, one solid C(++) tip: when adding new features, start with the smallest of available guns:

  1. Global function — if you need to display score, don’t hesitate to add void DisplayScore() somewhere. If your game is single-player, store score as a global variable. See? You have just saved 10 minutes of writing getters, setters and designing communication between modules. If your game is multi-player then you will need to store and display scores per-player. But there is no reason to be able to display arbitrary score of arbitrary player if your game is not yet multiplayer. Believe me, you’ll have bigger problems than displaying score with that.
  2. If your functions share common code or require helper functions, group them somewhere, possibly in separate file. Remember about static functions and variables — contrary to “OO” static, file static is about visibility. But it’s cool, because you can have a file for all font-related operations and store internal data in static global variable. Helper functions can be static, and public ones go to one shared header (if you write simple code, compilation time is never your enemy).
  3. Promote functions to classes only when it’s relevant and useful. Remember, classes means objects, objects mean relations and relations means complexity. Is your gameplay so cool that you have time for code complexity?
  4. Any design patterns or other exotic stuff is the last resort if none of above is good enough. Personally? Never got there.

(from #altdevblogaday)

Feedback

5 thoughts on “Simplicity Oriented Programming

  1. Sindisil | 16.07.2011 19:40

    Fine advice, applicable to more than just game programming.

    If only more developers thought this way.

    It’s important to develop a good intuition for when it’s appropriate to move up the scale of abstraction, or back down for that matter.

  2. Wu Feng | 18.07.2011 03:29

    Do you have the example for VB soft? The C++ soft might be interesting for some people but the VB soft is used by the main business works.

  3. Quooston | 18.07.2011 08:17

    This is my language.

    I wish they actually taught this at university, instead of convincing people that abstraction is everything and patterns should be everywhere. But hey, I guess that’s what experience is supposed to teach… only that 99% of the time it doesn’t, because every dev out there wants to be a damn hero and prove how effing smart he/she is. Drives me insane.

    Wonderful advice. Spam the world this stuff and you would have done us all a favour.

  4. mihu | 03.08.2011 16:22

    Under influence of many discussions on warsztat forum, that said more or less the same as you, I’ve been following these advices for some time yet, and I’m happy with results. Less time spent writing and “inventing solutions”, more time actually developing features.

  5. Bzouchir | 04.08.2011 04:09

    Great observation! and all so true.
    The only reason people try to use design patterns and proper (whatever proper means) object oriented code, is for re-usability.

    But I read somewhere that writing reusable code takes 80% more time!
    and guess what, you hardly ever re-use it! there’s always tweaking and pulling its guts out for each scenario to work.

    If we could just bundle “Simplicity Oriented Programing” + “Product Driven Development”, I wonder what we’d get!?

    nice one Dabrowski!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>