Monday, 14 November 2011


I have spent quite a lot of time on my other product (KitBase) this week. I have realised again that working on database applications is generally easier than games and progress is more easily achieved. I'm not saying that the technical skills are necessarily harder (although they are different) but that achieving 'goodness' and predicting outcomes consistently is much more challenging.

I think that the differences are largely down to the weighting of:
  • Objectivity vs Subjectivity
  • Plumbing vs Sculpting or Crafting
  • Design and Realisation vs Experimentation
(There are probably many more of these but the above spring to mind).

To elaborate:

Subjectivity vs Objectivity
Games are extremely subjective. A game that is loved by one crowd may be hated massively by another. Business applications can usually be made to fit many different users without alienating half of them due to the more objective nature. Trying to make everyone happy during gamedev tends to result in a mess that nobody likes, either that or two games in one. Either way, a stupendous amount of hours can be burnt up trying to make a game 'liked' only to upset the original lovers of the game.

Plumbing vs Sculpting or Crafting
Business applications are generally built by fixing together various technologies (plumbing) to fit with the business requirements (databases, form systems etc). Rarely are entire systems built from scratch. Games on the other hand tend to be created by building (or buying in) some base functionality then continuously refining and chipping away until you end up with a good, playable, (hopefully marketable) game. Not easy - particularly the last part in my case (see Gravity Core on the right).

Design and Realisation vs Experimentation
Again, business applications are largely built in a methodical manner - even when built using Agile methods. Sometimes functionality may not work out and is scrapped but generally the design is built piece by piece until a required level of functionality is reached. The next phase of the application can usually be visualised by a designer then realised pretty accurately. Quite often with games, the end result is quite different to your original vision as some key features may not work as you envisaged or rebalancing may yield a very different gameplay experience. Huge amounts of time can be spent tweaking, refining and reworking the design with no obvious finish line.

Clearly all software is elements of all of these things but the emphasis is in different directions for games and 'serious' software.

Now that progress has been made on the other project, I'll burn some hours on gamedev next week.

1 comment:

Eddie W said...

I suspect what you've just discovered is that application development is 90% science (the code) and 10% art (the UI), where game development is 10% science, and 90% art. It's not that either skillset is easier than the other, just that they are very different!

App development is often about knowledge, about following rules, about picking up tools/libraries that exist and fitting them together in a way that means you don't reinvent a basic FTP transfer or encryption. The best app engineers tend to be those who remember, research, and base things on established patterns that work.

Game development on the flip side, is about trying to entertain, bamboozle, and outwit a human being - once you have the basic engine with graphics and physics, you have to ask awkward things like "How do I measure how fun it is?" There's no such thing as a 3rd party library for that :)