Archive for the ‘Mobile Games’ Category

More IPhone fun

Friday, February 6th, 2009

After getting things working on the IPhone I’ve been messing around with a series of further technologies on there.  I had to re-work my assert code as it only worked on a singe thread (oops).  In the end I discovered the way to do this is using Objective C’s selector messaging and then I can run a message on the main, event handling thread.  This reminds me of how in the Java/Eclipse SWT you can add blocks of code to be run later in the same messaging thread.  It’s very cool anyway and makes multi threading headaches appear to disappear somewhat.  I’m starting to really enjoy Objective C as there is a lot of expressive power.  How optimally some of these things compile I don’t know.

After fixing up assert for multi-threads I added in touch and tilt/accelerometer support.  At the moment my game engine simply polls for different input states so I’ve mapped these to the polling kind of architecture.  I’m wondering how best to do this for gesture control though.  I think it’s be nice to be able to define a gesture in some kind of ‘gesture description language’ and then just poll for that gesture having been completed as a single input.  This makes it easy to map inputs across platforms.

For example the Plane Game it would be nice on a PC to be able to drop a bomb by pressing b.  On IPhone though the same could be accomplished by a downward stroke on the touchscreen.  This would mean the underlying game code would be the same – the input library (and it’s configuration file) can handle all the mapping.

I should be producing another version of the Plane Game pretty soon with some advanced features. I’m working towards producing an IPhone version at some point. Also it’s been brought to my attention that the current windows version required the GNUWin32 dll’s for zlib, png and jpeg support. The new version will do away with those requirements.

With that in mind I’ve done some more COLLADA work, I can now import properly regardless of the up axis and once pulled in I’m indexing and then post transform vertex cache optimizing and vertex memory location optimizing my meshes. I soon hope to be able to save out a mesh imported from COLLADA and load it into the game to replace some of my sprites. It will be a nice stepping stone for the library!

Optimal code and Netbeans

Saturday, August 2nd, 2008

So I coded up visibility for my game.  It turned out to be a pretty simple task. As I think my approach is slightly novel I’ve documented it for anyone interested, feel free to comment! Hopefully it’s pretty optimal.

The next thing on my list was some really basic AI, I got a creature to be able to follow me around, I added a simple item class and a weapon class and made it possible to fight. All of which works nicely up to the point of dying – a the moment you can just carry on!

I then worked on some interface for the phones so you could open your inventory. A small learning process but not particularly daunting. The major drawback I can see of my chosen target platform (midp 1.0) is that if you create a list menu with implicit selection there is no way to know when the selected item changes. Which means you can’t create ‘soft button’ menu’s that vary on say the item type in your inventory list, instead you have to create a submenu based on selection. No big deal and I think something fixed in midp 2.0. If someone does know how to do this, please let me know.

Finally I decided that I should refactor my code. Originally the whole thing was based around simply using the mipd TileLayers to specify what things are where. However I wanted all of my game code to be orthogonal to the underlying display SDK it was running on – who knows I might port it to an applet or a standard Java game some time. So I went about building a Level class that represented the game world. In the process of doing this I discovered some interesting things about writing Java. If you create an array in a class as follows

int array[] = { 1, 2, 3, 4, 5, 6, 7, .... };

then that uses up a lot of memory as it has to produce byte code to load each value into each array slot. Then when it’s running you also need the space for the array itself. So it turns out if you want to create a large grid with tile indexes for each element you’re much better off saving out a data file and loading it up when you need it. Especially in the case of the code produced by the Netbeans game designer which just uses this array to initialize a tile layer – once that’s done the original array if effectively finished with and could be removed from memory. So as far as I can see the code the Netbeans game designer produces is almost as bad as it possibly could be when thinking about targeting a mobile device with a small amount of available memory… way to go!

Also of course rather than ints, in my case we’d be better off with bytes or shorts if I end up drawing more than 255 tiles (the zero index is reserved for an empty tile).

I’m now thinking I’ll either

  1. write my own tool to draw tile layers (hmm perhaps integrate it with eclipse as at the moment I still prefer it over Netbeans).
  2. find another tool that’s a bit smarter.
  3. improve the Netbeans game designer.
  4. not worry about it as I’m planning on randomly generating most of my content.

At the moment I’m going with 4!

Next up I think I’m going to look at that random level design.

First steps at mobile game

Tuesday, July 22nd, 2008

So over the weekend I spent a few hours working on my first ever mobile game. I installed NetBeans, the latest Java SDK and the Java Mobile SDK. Then I fired up NetBeansand started to follow the mobile development tutorial. Very quickly though I got bored of that and started to work on my own game.

For now I’m going to use the game designer application and draw up a simple town level which I can move around. To get things moving quickly I’m using the tiles that came with the sample game so I can’t actually distribute any of my versions until I rewrite it all.

I’m working on a roguelike game. At the moment everything is tiled based and the game doesn’t run in real time – instead it’s turn based. As I want to play it (and might be the only player) I’m making it so that the levels for the dungeon are autogenerated, infact the whole inspiration comes from Moria and later variants like Angband.

I might regret this later as I think it would be very cool to make the game run in real time so be much more like the Diablo series. If I did this then I’m sure the combat system would be inspired from that used by Bioware in KOTOR and Jade Empire. Here the game is effectively turn based however you input or queue up a series of commands for your protagonist to follow as combat unfolds.

So far I’ve found Netbeans to be an OK environment, although I miss the familiarity of Eclipse when writing Java. Also there is something wrong with the auto completion – when I ask it to tell me the arguments for a function call they’re always listed as “type arg0, type arg1, type arg2…” rather than showing me the argument names. Which is a bit annoying but I’m guessing a result of using a non-stable version of Netbeans.

So where have I got to with the game development? I’ve built a primitive map and can move my character around it, collide with walls/creatures and have my view port updated so the character is kept within the centre of the screen. Next up I’ve decided to tackle visibility – what can the character see. There’s some interesting articles on this on a site I found all about roguelike development called RogueBasin. There’s even a link to a java library that implements some of these functions – sadly it heavily uses generics for lists and generics don’t work on the mobile Java run times as far as I can tell. Also I want to optimize maths where possible to be integer based as I think that’s what the hardware supports and I want to minimize memory usage. This should be interesting as normally doing games I have control over what memory I’m using and how but not in the same way with Java! It will force me to think at the algorithm level much more than at the machine level.

Mobile games

Saturday, July 19th, 2008

I’ve always been interested in mobile phone games. They make a great way to pass the time whilst stuck waiting for something with little else to do. A common occurrence here in the Philippines. So I decided that as a project I’d have a go at writing my own game for a mobile phone – for my own fun and education.

I recently bought a new mobile – A Nokia 3120 Classic which has a nice big screen. Sadly however it’s not a S60 device, only a S40. I have two options developing for this phone, I can write in Java or I can try my hand at embedded development. However I write C/C++ for a day job and as this is a personal project I feel the urge to try my hand at Java. Also it should work on pretty much any mobile phone that way too without a great deal of effort.

I’ve used Java from time to time. At university I taught myself Java by writing a snake game as an applet which I might try to dig out. Then my second year group project was also Java with a fair amount of JNI – a plugin system for a VR world their research department worked on which allowed you to edit your avatar. Also my third year project – which was a ‘rogue like’ game editor was in Java. Actually in my third year I ended up being a lab assistant for the first years as their teaching language had changed and not enough of the teaching staff knew Java. Then more recently I dabbled with the some bits and pieces in eclipse using the SWT.

The first thing to do is to choose an IDE. For the sake of education I’ve decided to try out net beans. I don’t know if this is a good idea as it’s something else new to learn but that is the point. I’m already familiar with Visual Studio for C/C++ and Eclipse for for both Java and C/C++. Now I’m going to try my hand at Netbeans. Besides they appear to have a nice easy to use integration for just what I want. Being adventurous I’ve decided to download the cutting edge version, 6.5M1 and we’ll see how it goes. I’m going to use this blog to keep a development diary of this project under the category Mobile Games.