Monday, August 27, 2012

Writing a game for GNU and GNOME

Hello All,

I've decided that I'm going to write a game.  I've always wanted to do it. I've held off because the world is full of homebrew games that aren't very good, and I'm not sure I can do better.  But, whatever, let's see what happens when I try.  Programming is my golf, I guess.

But I know myself, and I know that when faced with the awesome ambiguity and limitlessness of "making a game", I'll get lost in the planning and never bring anything to execution.  I've always been the type of guy that loses the big picture by looking at details. So first, I need to set some limits, some serious restrictive boundaries on the problem so that I don't get lost in the weeds.

So the first consideration was what SDK was I going to write it in.  I looked at the various game SDKs, but, I wanted to do something to help the GNU + GNOME stack.  This is one of the problems with GNU and GNOME: it is still wicked hard to develop anything, especially coming from a work background of C# and .NET.  C# and .NET form a complete well-documented SDK.  There is no need to look outside of .NET for a solution.  Whenever I get back to EMACS + gcc + GNU + Linux + GNOME, the whole devel experience is much tougher, primarily because first you need to basically roll your own IDE and SDK.  You choose a bunch of libraries and integrate them with autotools glue.  In the integration of several libraries there is always varying quality and detail of the documentation.

This is where my productivity always gets derailed, this process of rolling your own SDK from the dozens of great libraries out there, and rolling your own IDE from the dozens of EMACS libraries out there.  What should I use?  What shold be in my own personal GNU IDE and SDK, exactly?

So I decided to let some one else make that decision.  I decided that I would only use the libraries listed at Gnome Developer Center in their Platform Overview, and I would only use API that was documented and languages that it supported.  I'm not going to add any other dependencies.

So this simplified the decision making trememdously.  For audio, there is only GStreamer, so I'll use that.  Its sample application plays Ogg audio, so I'll use that.  For graphics, I can use either Cairo or Clutter.  But I can't use Clutter, because my graphics card's free driver doesn't have any hardware acceleration, so OpenGL won't run.  Cairo will have to do.

Cairo is a 2D library, so my game will be in 2D.

Since I'm limiting myself to fully documented interfaces, my game will be in C.  It is the only language that spans the whole GNOME SDK stack and that has proper documentation.

Since I'm limiting myself to the GNOME stack, I guess I'm writing my own engine.  For inspiration on how to do that, I've been reading a lot on how the Game Boy Advance and Nintendo DS work.  There is a big homebrew Nintendo DS scene, and some great free developer tools to write Nintendo DS games, like DevkitPro.  So I started writing an engine inspired by the description of the 2D stack of the Nintendo DS hardware.  Not an emulator of course; an engine inspiried by a description of the workings of the DS's 2D stack.

What's great about the Nintendo DS as an inspiration is that it is very specific in how it works.  Objects are sprites.  Sprites are made of collections of 8x8 pixel tiles.  Sprites can only be specific sizes, 2x2 tiles (16x16 pixels) or 4x4 tiles (32x32 pixels).  Backgrounds are either maps of 8x8 pixel tiles or they are single bitmaps.  The screen size is small 256x192 pixels. There's a lot of structure there to keep me from getting off track.

I'm also setting myself some resource restrictions based on the Nintendo DS as well.  The memory footprint of the application will be under 4.6 MB. 4 MB for the in-memory application and the heap, plus another 0.6 MB specifically reserved for the video resource cache. The total disk space of the game executable and resources has to be 32 MB or less.

So along the way, I hope to learn and describe a few fun things
  • Setting up EMACS to be more like an IDE
  • Using Cairo to make a tile and sprite rendering engine
  • Using GIMP to draw some graphics
  • Generating audio with free tools
  • Playing game sound with GStreamer
And I hope to file lots of bugs and documentation clarifications

So, my very first task is to assemble some graphics into a resouce file and then implement my 600kb resource cache.

6 comments:

Ronan Houitte said...

nice idea !
I have always wanted to do it but I never had the courage to do it.

Do you want to do it or you own or you will accept some help ? (game design, software, story telling, translation etc.)

If so I would love to give you a hand.

I am a programmer and I am French. (and I have a pretty endless imagination)

Anonymous said...

Please take a look at this advice for game developers and upstreams in general:

http://www.freedesktop.org/wiki/Games/Upstream
http://wiki.debian.org/UpstreamGuide

Mike Gran said...

@Ronan-

Let me get the renderer and the keyboard input working. Maybe we can talk when the engine actually does something useful.

Mike Gran said...

@Anonymous,

This ain't my first ride in the free software rodeo, but, thanks for the advice.

Ronan Houitte said...

ok keep me inform.

Mike Gran said...

OK. I've actually set up a repo, a wiki, and some skeleton code for the engine at the
Project Burro Github.

I'm going to call the game engine "Project Burro".