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.

I had some pretty good progress today 🙂  I got touch input implemented and tweaked pretty well for playing the game.  I also got in some crude orientation handling so that the numbers on the planets are readable from any normal orientation of the device.  I also added in a simple AI player, adjusted planet sizes, and added simple particle effects.

Next up: improved graphics, font, and sound effects.  I’m still pretty mystified by ObjC, but I’m getting by, I suppose.  It amazes me how much boilerplate junk is in languages that are not python 😉  Ah well, that’s life I guess.  On the practical side of things, I’m continuing to keep my SDL version of this working, so I can do work within my linux environment.  I’m glad I did all that work on tinypy, as I feel pretty comfortable in C now.

Well, getting it “running” on the phone after that was pretty easy. Although not everything went quite as planned … Here’s a really awful picture of my progress:

Stuff to deal with later this week:

• I’ve still got a long way to go in comprehending ObjectiveC .. So far, it’s all black magic to me, so I just guess until the compiler stops yelling at me.
• No input yet, so no game play .. that’ll come next 🙂 Should be fun! I don’t think that part will be too hard, Apple provides a number of tutorials on getting touch input, so hopefully that will be straightforward.
• It’s rotated the wrong way. I’ve got my game defined in a 480×320 box, but I guess the default view for the iphone is in the 320×480 direction. I’ll probably just switch my default setup to be in the 320×480 orientation. I might use gravity to determine which way the numbers on the planets are rendered.
• No anti-aliased lines .. Hmn .. I think I’ve enabled all the right stuff, but I guess I’ll have to read up on that. It would be a pity of Galcon wasn’t anti-aliased on the iphone.

Since I’m too lazy to switch my monitor cables back and forth to my mac, I VNC onto my mac mini for dev.  Which, since that’s kind of a pain, and the whole app compiling process is sort of slow .. well .. I figured I’d port my code to OpenGL in the safety and security of my normal linux environment first.  After I got it working using the normal OpenGL glBegin / glEnd stuff, I switched the code up to use the OpenGL ES style vertex buffers.  Here’s a screenshot:

Next up, see if it runs on my ipod …  For the easily disgusted, I should mention that I’m rendering the text using some old BIOS font using GL_POINTS.  That seemed less mentally taxing than trying to get textures working already.

I’m going to blog a bit about my experience porting Galcon to the iphone.  It’s not overly python related, so I won’t send all these posts to the python planets.  Maybe just a couple.  Anyway, if you’re interested, keep an eye on my blog.

There is a chance I’ll use tinypy in iGalcon, but I haven’t really decided on that yet.  There isn’t a large need for scripting at this point, but if one comes up, I might just do that.  To start, I’ve takened the main flocking engine in Galcon, re-factored it a bit, and built a 100% C / SDL mini version of Galcon at the res I will be rendering it on the iphone.  I decided to do this, so I could be sure that the core engine was working perfectly in C before I complicated the matter by trying to run it using the apple tools.

So far so good 🙂  It took me about 6 hours to get this mini version of Galcon up and running in SDL.  Most of the code I was able to grab from the original Galcon.  I did a small amount of reorganizing to make things cleaner.

One of the requirements for iphone development is for your app to be able to be closed and opened and have the app recover to its previous state.  At least, that’s the ideal.  I adjusted my C structures so that they include no pointers, only ID numbers, so I should be able to write the game state to a file and reload it and have everything back.  The full game state is around 32k, so I think that will work.

On the iphone side of things, it took me several hours to get all my certs set up so I could work with the dev environment.  I was able to build their example app this morning.  Here’s to hoping the rest goes smoothly 🙂

I’ve learned a lot about python by implementing tinypy. Today I was thinking over my re-work of classes, objects, and inheritance in tinypy (not in trunk yet). I noted how in tinypy, I will be able to change the class of an object via a function call (a-la lua):

class A: pass
class B: pass
x = A() # x is an instance of A
setmeta(x,B) # x is now an instance of B !!!

So I thought to myself, I wonder if python can do that. Well, it can, and as per usual, its solution is quite elegant:

class A: pass
class B: pass
x = A() # x is an instance of A
x.__class__ = B # x is now an instance of B !!!

So, lesson of the day — you can dynamically change the class of an object in bigpy. Which, actually, I’ve sometimes wanted to do, I just didn’t realize I *could* do it.