So, I managed to submit a “python” app to the App Store — “Elephants!” Here’s a few crazy things I had to work out to get things going:

• I found that ObjC doesn’t care much for C++ objects that do their own reference counting.  To have a “Game” object at all, I had to use a pointer to my object instead of using my reference counting object.  It seems that during some of the “magic” of ObjC it copies objects without calling any of the C++ copying methods, so reference counting gets killed.
• I ported a basic subset of pygame to tinypyC++ and made it work under openGL.  I don’t have this available in my tinypyC++ repository because it takes a good deal of prep-work to use (isn’t out-of-the-box) so it wouldn’t be generally useful to anyone yet.
• I was able to get pause on call / resume working by saving the game state to a text file.  Since tab-separated files are so easy to create and parse in python this seemed to be the easiest route to getting the project done.
• I learned a ton about C++ templates.  I still haven’t even touched the tip of the iceberg, and I’m not sure I want to, but at least I’m getting the basics down and that seems to be enough for me to stumble through this project with.

You can check out my current progress at svn://www.imitationpickles.org/tinypy/branches/tinypy2 (in the tinypy/example folder you can check out a julia fractal demo.  It also includes a mini pygame module that depends on SDL not OpenGL, so it actually works out-of-the-box.)

Here are some things I’ve been adding this week in preparation for my next project:

• I’ve added “weak pointers” .. Since reference counting has the problem of cyclic references never getting collected, I had to do this for some use-cases.  In tinypyC++ weak pointers are just normal pointers, and if the object is collected, the pointer will be invalid, so be careful.  They are created by doing stuff like “x = ptr(GameData())”
• I’ve added more C style types.  I’ve got uint16, cstr, Array, etc.  This all makes it possible for me to have a different kind of object – a struct in tinypyC++.  The struct is meant to be a C oriented type that can be saved directly to disk.  In Elephants I serialized via saving CSV data.  In the future, if I keep all the game state in C struct type data, I can just use a single simple line like “open(‘data.txt’,'wb’).write(struct_dump(game_data)”
• I found that STL extensions include a “hash_map” which turns out to be about 2x as fast as the normal “map”.  I’m using that now.

I’m not entirely sure how useful this project is going to be for anyone else, or even for me for that matter.  But I think after my next game project I’ll have a much better feel for what the situation is.  TinypyC++ has some real tradeoffs in terms of being a bit of a hybrid of C++ and of python.  It doesn’t offer the full power of either language.  But I’m doing my best to capture a middle ground between them that will make my life easier.

I’ve spent the last week working on a tinypy to C++ converter.  It works!  See the screenshot to the right – I’ve managed to port a pygame game over to C++.

Here’s how (and some of the catches):

• I require type annotation of all the functions and methods.  ”def test(x:str)->str: return x”
• I do two passes on each file, the first pass to catch all the function types and class members, and the second pass to generate the code.
• I generate C++ code that has automagic reference counting.  So you have to code your script so it won’t have any cyclic references if you want garbage collected for you.

How is this different from shedskin (really cool project!)?

• Built-in reference counting, instead of using libgc.
• I require the user to type annotate everything.
• It only supports a subset of the tinypy subset of python.  Shedskin supports a much larger subset of python.

So what’s the point?

• Well, I learned a lot about STL and C++.
• I know it will produce iPhone friendly code, I’m pretty sure libgc isn’t iPhone friendly?  (At least, I haven’t found anything via a few searches…)
• Way less magic.  Since everything is annotated, there are no surprises.
• Implementing C++ modules is pretty easy – the code can be inlined within the python code and it just works.
• This will make it easier for me to develop C++ games.

Anyway, if you’re super brave, you can check out svn://www.imitationpickles.org/tinypy/branches/tinypy2 .. I don’t have the elephants example in there, but the pygame.py that I include gives you a pretty good example of a complex module.

I’m going to chat with the tinypy folks to see if we’ll merge this into the tinypy trunk or have it as a separate project.  I’m not quite sure what makes sense to everyone else  The nice bit about merging this in is that I could unify the test suites nicely.  And tinypy would still function as normal, just better tested, and with function annotation parsing supported.  All that said, I should make a tinypy module for tinypyC++ so that I can do some code evals!

So .. Yeah.  Check it out.  Realtime multi-player game .. in flash!

So on a more technical note .. The game involves quite a number of technologies!

• AS3 – of course – for the Flash client itself
• C++ – for the server
• PHP – for the web API and rankings system
• python – for the bots

If I did the project over, I’d probably do the server in python as well.  But all in all the project went pretty well.  After things were done, it only took me a morning to write up the python client.  There’s a very good chance I’ll release that code in a few weeks and let people try making bots for the game.

Anyway – have fun checking it out.  I’m a bit wiped out from wrapping all this up, so I’ll try and post some more interesting details later!

-Phil

Today marks the release of my first iPhone game release in five months.  It’s about time I got going on dev again.  I’ve been in the midst of many transitions in both of my businesses, so I decided to start out with something short-n-sweet.  The game is called Beast.

Beast is a re-make of an ancient MS-DOS game that I played ages ago (and I’ve re-made several times).  The original is here.  You may have followed my progress on twitter.  Here are some interesting “factoids” about the game dev.

The original game is pretty tough to play, if you have dosbox and have all the proper slow-down settings going, you’ll find it can be a challenge to surround the beasts and crush them with blocks.  The iPhone doesn’t have a D-Pad, so moving a character around the screen is a bit tricky.  I had to make several modifications to the original game so that it would work with the touch interface:

• You can move the player around the screen by pushing your finger around.  However I had to make the player unable to move diagonally as I found the resolution of your finger movement made it near impossible to play and quite jumpy if I allowed diagonals.
• You can touch any point on the screen and warp to that location.  The controls were still a bit tricky, so I had to add this feature so you could do quick movements to escape from a beast, or to attack it quickly.
• I disabled the beasts so they can’t move diagonally, made the super beasts spawn into only 4 instead of 8 normal beasts, and slowed down the beast movement by about 50%.  These changes were all required to make the game playable.

All these changes turned an impossible to play on the iPhone into a reasonably fun diversion.  I also added a notable element of speed into your score.  This gives the player a good bit of replay value, since even after they beat a level, they can try again and try and “master” a map they are playing.

Overall the main point of this whole exercise was to get myself back into iPhone dev.  Really last year when I worked on Galcon I threw myself violently into that project for 3-4 months and came out a bit burnt out.  I knew this time I needed to do a small scale project to get going again.

I’m pretty pleased with the results of this project.  For some more interesting factoids about the game project, check out my game blog announcement.

Excuse to post this to the python planets: I actually made a python version of this game a few years ago.  It contains some really bizarre pure python sound-synth for both the music and sound effects.  Check it out.  Not only all that, but the whole game is a single 18k python file!  I ported from this code for the iPhone version.  Again, another great example of python prototype -> C++ final product!

(Silly side-note, actually the python code was a port of some C++ code I made ages ago.  So this is a great example of C++ code that was ported to python and then later ported back to C++.  I won’t bother you with details about my even earlier Java and C versions of the game.)

I think I wrote an article a few months ago comparing C and python.  I’m doing some new iPhone games now, and this time I’m using C++.  I found not having classes was getting to be too painful for me, so I’m trying out C++.  Here are a few things I’ve observed:

(As a side note – I’m writing my games /almost/ the same way I’d write them in python.  So if you’ve seen my game code, I’m doing almost the same stuff, except in C++.)

• As usual, not having memory management is a bit of bother.  Fortunately, I’ve found there are only a few places where I actually need it.  The main thing I had to do was write some basic reference counting code for my state engine class.
• I’m using structs instead of classes, since I have no use for private variables or methods.
• Having separate .h and .cpp files is a drag.  But them’s the breaks .. It sure would be swell if C++ was a wee bit smarter about that.
• For my in-game objects, I just define a single struct that has all the possible variables I need.  This is pretty much how I did things in python anyways.  I’ve never been a big fan of using much inheritance.
• For writing my GUI classes, in python I was able to get lots of magic into them.  In C++ it isn’t so easy to get magic, so I’m doing without most of it.  It seems that most of the magic was gold-plating anyways.
• Having written all this code in python before, getting clean C++ code seems pretty natural.  I know what I WANT my code to look like, so I try to get my C++ to be as close as possible to that.