Portability Primer – Sticking to basic principles helps

I had a very interesting discussion yesterday. I want to summarize it below.

There is a fresh new group of developers who want to start making games. They have quite a decent (but various) programming experiences with different platforms, different project types and scale. All outside gaming of course. During my discussion I heard two very interesting questions, I’ve tried to answer then and will answer also here.

1) Which platform choose for casual indie games.

2) What if we choose wrong platform, how about portability?

Questions seem to be academic and I have a feeling, that I answered quite academically. As for first problem, I asked more questions to better understand it. I was curious what games is that group aiming at and for what audience in specific.

Answers I’ve heard were not clear which I understood as the group is rather looking for certain ideas, than have a complete vision of a certain title. Sounds like a pitfall, right? In further discussion we agreed that first goal is rather to better understand technologies and possibilities potential platforms can offer.

Fair enough. Knowing what you can do and binding it together with some assessment on who usually has such a platform and what games that player expects can help to work on realistic ideas and innovations that have better chance to work. It is good to know though, that it’s not real game development. Rather a technological training, which later can help to better discuss differences and potential on platforms like Facebook, iPhone, XBLA, XNA, PSN and Steam, just to mention a few different examples.

Answering to the second question: what if we choose wrong platform, how about portability?

In this case I believe that sticking to basic programming principles can help. Most programming platforms have for sure one thing in common -> objects and object oriented mechanisms. Syntax may vary and language specific elements can trick out porting efforts. Avoiding them should be part of that best practice, I think. Having objects on mind, in front I’d design abstraction layer with objects that share common elements. Any specific platform just should expose it in its implementation.

Simplified example: If I want to develop 2d sprite based scroller shooter, I need objects like screen that supports pixel-by-pixel redrawing, sprites, some routines for clipping, collision detection for sure. Those should have interfaces which are platform independent as much as possible. Then adding DX, GDI, Silverlight with WriteableBitmap, Xna support or whatever technology should become a task bound to platform but not breaking game features themselves.

This approach is implemented in Unity and Unreal Engine too.. what we see there is a common interface (even including WYSIWYG editors) and platform related implementation that we don’t care much designing game at its basic level.

Sounds very much obvious, yet question like this is really fantastic, because it reveals inexperienced developers or developers who have been bound to a single technology stack for long, if not forever. No big deal, good moment to start learning as many different technologies and languages as possible to push the perceptional horizon further.

From these obvious truths in answer, I suggested to these guys a task, challenge for the team of five as I heard.

I suggested them to develop some short game which isn’t time-consuming as for development. Let’s say it’s Tetris.

In this challenge each team member has to pick a technology and/or platform, different to the rest. When everybody finishes, then each developer should take somebodies else code and port it with the thought and structure of the original concept to another platform&technology.  Take C# or Flash port of Quake (originally in C) as good example of similar task.

When everybody finishes group should meet and discuss what was the biggest pain and if somebody failed, why?
Conclusions taken from that final discussion should help them to avoid practices that are potentially dangerous in such migration.

Interesting porting paths (to and back), I can recommend are:

  • Direct3d to OpenGL
  • Xna to DirectX
  • WPF Xaml+C# to Direct2D based 2d vector graphics and sprites
  • From HTML5+Canvas+Javascript to Silverlight and WritableBitmap

Even with Tetris complexity, above examples should be good to reveal some bad habits.


Leave a Reply