So I’ve been doing iPhone dev for about 2 months straight now.  Just yesterday I sent my latest Galcon update to Apple.  This update includes multi-player wicked-awesomeness.  It will be available whenever Apple approves it.  I plan on doing a bug-fix update a week or so later to resolve any odds-and-ends that come up.  In the meantime, I’m trying to recover from my 2 months of solid coding.

The iPod has taken its toll on me.  I’m about five pounds heavier and I’ve lost any definition I pretended to have.  Time to get back into shape!  We’ll see how that goes.  I’m trying to reserve a few hours a day for “not sitting in a chair.”

In other news, I’m attending PAX’08 in a couple weeks.  Look for the guy in the Galcon t-shirt.  I’ll also be hanging out with the Garage Games and Brawndo folks a bit.

Hey, I’m trying to get Galcon-iphone to work for the color-blind population 🙂

Here’s the colors I’m thinking about using. If you are color-blind can you tell me if you can discern between the colors? If not, please tell me which numbered colors you are having difficulty with.

Thanks!

Well, I’m about 1/2 done with adding multi-players to Galcon-iphone.  I figured I’d stop for five minutes and note down some things I noticed during my porting experience.  Obviously, C and python are different, but here are a few of the ways I’ve FELT the difference.

• C doesn’t have garbage collection.  I’ve managed to avoid doing much manual GC by having everything in a single big struct that keeps the entire state.  The only place I use malloc/free is when I’m downloading web data.  So it hasn’t been a big deal for this project.
• Speaking of web data, C doesn’t have a built in urllib.  I wrote my own awful HTTP 1.0 page fetcher.  On the plus side, I was able to make it work *exactly* how I wanted it.  No threads, non-blocking 🙂
• Although not “built in” I found enet, which was a thin layer above UDP for networking.  I found this incredibly much easier to use than python sockets were.  (Yes, I could have used some other python lib, but I didn’t.)
• C is really fast.  Thankfully, since I originally dev’d Galcon in python, I was “forced” to get my algorithms pretty good to keep the speed reasonable.  By porting everything to C, I’ve now got amazing speed.  I think I could host 100+ servers on a single CPU easily.
• Managing strings in C is an ordeal.  It’s just not pretty, so I try to avoid doing much with them.
• OpenGL seems pretty painless in C.  I haven’t done any notable OpenGL stuff in python, so I can’t really compare the two.
• No exception handling makes me have to code things more carefully.  In python, I could parse an incoming networking packet, and just wrap it in a “try: (parse stuff) except: pass” block.  If something was bad about the packet, it would just move on.  In C, I have to check everything carefully so that I don’t create some kind of segfault by accident.
• In my case, serializing data is easy in C.  I can just save a structure to a file (or send it in a net packet) and load it back later.  In python this is much more complicated.  (Especially since Galcon-shareware isn’t pure-python.)
• By using C, I don’t have to deal with some awful FFI.  That is a HUGE time-saver.
• I must admit, I LOVE python’s indents.  But I also must admit, now that I’m back into C coding, I don’t miss them as much as I thought I would.
• I still dislike header files.  I wish C magically generated them or something instead of making me write them.
• I learned about writing tests in python.  I’m doing that in C for my networking code.  I run the tests as part of my build process, and it saves loads of time by catching all the bugs for me 🙂
• Automatic type checking is sort of nice.  Having the compiler tell me I didn’t do anything incredibly stupid is sort of nice.  (Although in some cases, it can get a bit annoying.)

Well, that’s about all I can think of for now.  Draw your own conclusions.

So .. not being in python-land I really didn’t feel like reinventing the networking-wheel this time.  So I grabbed enet for this project and it rocks.  I had no notable trouble (beyond normal laziness when it comes to reading documentation) getting it up and running.  And after I got it going nicely in my linux environment, it worked out-of-the-box for compiling to the iphone 🙂  Thanks to lack of endian issues, I didn’t have any trouble there either!  Here’s the screenie:

On my TODO list is:

• Add Settings (Sound effects on/off, favorite colors for MP game, user / password login for MP game)
• Add Server List (must figure out how to do HTTP requests from C with minimal strain)
• A bit more testing and some odds-n-ends

I hope to have it all done soonish!

On a development-side note, I implemented some automated testing of the network code.  This saves me from having to run over a dozen use-cases any time I mess with the client-server code.  So it’s saved me a bit of time, and given me that great “feels like it will work” feeling.

Hey, I’ve just finished porting Galcon to the iPhone and it’s now in the App Store!  You can read about it here!

I don’t *really* have anything super pythonic to say about the porting experience, other than .. I probably wouldn’t have bothered to do it if I hadn’t been hanging out at pycon and having people show me their iPhones and telling me how I should totally port Galcon to it.  So thanks to those people for getting me started!

The link above is where all the fun is, but just so this post isn’t all boring text, here’s a screenshot:

And if you want to know more about the porting experience, I’ve been blogging about it.

I managed to assemble a few backgrounds by grabbing some great photos from here.  I also did about 50 million little tweaks to the game, making it “almost done”.  (Meaning, there is probably quite a bit of even finer detail work yet, but not as much as their used to be.)

This version of Galcon introduces a new 3-way scenario.  This scenario the bots continuously choose which player to make a temporary alliance with.  They always attack the strongest player other than themselves.

I also created a new bot that has “redirect” capabilities.  I originally worked on doing a fairly complex one that I had done before, but found that it didn’t seem to work.  Probably because it was somewhat complex and I was doing something wrong.  I took a break and came up with a very simple variation on the fairly simple bot I use for the rest of the game.  It works great 🙂

On the iphone specific front, I keep having to deal with gravity every step of the way.  I’ve added several other status items on the screen which I always orient with gravity.  These items are in the corners of the screen, so I have to temporarily place large planets in those corners during the level generation to ensure that none of the final planets end up obscured by a status icon.

I’m not sure if I’ll have it done in time for “launch day” but I hope to be pretty close 🙂

Hmn .. I know I spent some time on Galcon today .. Here’s a screenshot to prove it:

Ah yes .. that was it.  I’ve got menu transitions working very nicely now.  This menu appears when you come back to Galcon after using another application.  You’ll also notice that I’ve got the menu “gravity sensitive” along with the numbers.

There are a few iphone points I haven’t figured out yet.  One is when you suspend the device with the “power button” and then start the device back up.  I haven’t found much clear documentation on if my app will get any indication of those events happening.  Secondly, when I start the game, the SoundEngine class provided by Apple turns off any currently playing music.  But when I double tap “Home” and start the tunes back up, the tunes turn off my sound effects.  I’m not sure if that’s quite what I want, but I guess that’s sort of a minor point anyways.

All in all, the main thing I’ve got left now is making the difficulty levels and various missions.  Should be fun!

The good news: I’ve got the basic layout of my main menu decided on. It isn’t really functional yet, but here it is:

I’ve also got the game transitioning between several states and prompts now. I haven’t coded in the difficulty levels or the various missions quite yet, will be doing that soon. I’ve also got it saving and restoring game state when you quit the game and start it up again. (That way, if you get a phone call you can resume your game exactly where you left off after talking …)

Here’s the trouble: I can’t figure out how to write and read files on the iphone. I want to do this with C code:

void gc_engine_save(gc_game *g) {
FILE *f;
int ver = GC_VERSION;
f = fopen(“igalcon.sav”,”wb”);
fwrite(&ver,sizeof(int),1,f);
fwrite(g,sizeof(gc_game),1,f);
fclose(f);
}

And be able to load it later, etc .. However, the iphone gives me a EXC_BAD_ACCESS error .. I guess because I can’t just write to just anywhere. What would be nice is if I knew what path to write to, however my brain has found the API reference a bit huge for a noob to the whole Apple way of doing things.

Rumors I’ve heard are “save your stuff to the Documents folder” or “no no, save it to the Library” or “no, you have to save it under $some_folder/Galcon/” or “it’s best to save your settings via some NSSettings …blah blah” . I’m sure I could get it working one of those ways, I just want to know *which* one I should use. And maybe a link to an example. Basically, what I want to do is in my ObjC code is construct a base path, send it to my C code and be able to do something like char fname[256]; sprintf(fname,”%s/igalcon.sav”,base_path); And then carry on with what I was trying to do ..

And .. if everything I’ve just said sounds like a really bad idea, I’d be thrilled for some guidance on this point 🙂 In the meantime, I think I’ll get some more bots working and whatnot. I’m trying to decide if I should use tinypy or not for some of the code, but at present, I’m leaning towards just coding up my bots / missions in C code for the iphone.

P.S. while you’re at it, if someone can explain what the purpose of these methods of UIApplicationDelegate and how to make them happen on my ipod touch, I’d really appreciate it.

Responding to a Change in Active Status

* – applicationWillResignActive:  optional method
* – applicationDidBecomeActive:  optional method

The ever slightly changing screenshot – demonstrating multi-touch (I’m selecting the two green planets, and I’m about to send a fleet to the red planet):

I also optimized the OpenGL code quite a bit, so it’s all fast .. except for the fonts, which I can still do a bit of work on yet.  But it goes full speed with any number of ships and explosion particles on screen now 🙂

I also implemented multi-touch support in the game, which was a bit of a challenge.  See, usually when I make games, I’m only thinking about a single mouse pointer or whatever.  So, err, imagine now that you’ve got unlimited mouse pointers trying to play Galcon together at the same time.  And then imagine that you’ve got no sure way of knowing what clicks are coming from which mouse.  (The iphone docs are sketchy on this point, they say that the UITouch object will remain the same throughout the life of a touch, but then go on to say that you better not save a pointer to it.)  I might have misunderstood something entirely about that bit, but whatever.

As it turns out, it was easier to deal with MT if I just handled the events as they came and didn’t try to keep track of what touch was connected to which finger.  After a lot of messing about, and fixing a bunch of bugs in my own code, I’m now able to handle multi-touch events!  Yay!

Anyway, for those of you with exceptionally small fingers, Galcon now supports game play for people with up to 32 fingers!  As for me, I’m doing pretty good if I can coordinate two or three at once.

Today I worked on making it all shiny.  As per usual, I had trouble figuring out OpenGL.  I suppose I’ll get it one of these days …

Anyway, some notable differences between normal OpenGL and OpenGL ES are: OpenGL uses arrays for everything, instead of letting you do the whole glBegin() glEnd() bit.  It also only supports a subset of normal OpenGL features – for example, it doesn’t support quads, only triangles.

Thankfully, by following the ES spec, I was able to write my code correctly under linux before I got it going on the iphone.  Getting the iphone part to work was pretty easy, though I’m slowly grasping some of the ObjC concepts as I go, since I had to do a few lines of ObjC code to load the images, etc this time.

The iphone SDK comes with a swell simulator.  Since my last pic of the “live” iphone was awful, here’s a more attractive simulation of what it looks like on the iphone:

Next up, gotta make those fonts look good.  Add the good ol’ Galcon sound effects.  Gotta improve some of my OpenGL commands so they are a bit more optimized.  Then I’ve got to decide on what sort of packaging (levels, ranks, bots, menus, etc) I want for the final version.