Trial and Epic Fail

Ventures of an indie game developer

Python 3.4.2 for iOS

Was surprised to find that there was no Python 3 complete and ready to roll with iOS. I found project for Python 2.7 that hadn't been touched for a couple of years and managed to build that: https://github.com/highfestiva/python-embedded.

Now I have a basic editor, Python is running on the phone, the simulator is integrated. This is going better than expected. Time for fredagsmys.

Way forward

Trabant keeps kicking ass in Alpha version. Most things are settled and very stable on the PC platform. Simulator works on Mac, havn't bothered trying to build SciTE for Mac. Since Mr. Hodgson built a commercial version (worth $42 a piece) for the Mac app store, I suppose it might be hard. At best.

The iOS version will be based on CYRTextView for editing and Python (ported and running in a worker thread). Then the infrastructure: an output text window, a pinch of load/save/restore/launch/launch for external host and a little listener for copying of code (and a "Do you trust host X to create/update prototype Y.py? [Always],[Ok this time],[Block]"). That hopefully covers it, but only one thing is certain. It won't.

Spot the difference


I edited out the title so you couldn't tell them apart. E-mail me your guess ("left" or "right") and I'll personally deliver the millionth...th Swedish crown to the first person who gets it right. (I also may not, conditions may vary depending on gender, looks, distance from home and so forth. See fine print for details.)

minecraft.py is 35 lines of code, I must've looked at the total number of lines in the file last time. 1 import, 1 loop, 10 lines of initialization, 10 lines of movement, 4 lines of respawn code (if you fall off the edge of the planet) and 9 lines of building. Nothing obfuscated, no crammed oneliners, nothing like that. Isn't that impressive? Well, at least I'm impressed. One down, 6,999,999,999 to go.

Minecraft prototype

Wohoo, I built a Minecraft prototype just now, this morning, in 1.5 hours. I had to implement ray picking in the physics engine, but apart from that it was a breeze. Quake became 124 lines of code, but Minecraft only 47. It's not finished yet, I haven't implemented adding blocks (just removing). But dang Trabant rocks ass!

Quake prototype

It took me a few hours to implement a very basic prototype which resembles Quake in steering and feel. The prototype itself is 100 lines right now, but I'm going to add a brain dead bot as well. All the prototypes looks like über-crap though.

What I'm starting to wonder is if anyone will "get it". I had hoped the look would be something like Balsamiq's Mockups but for 3D games, but there is no sketchiness to my engine. It just feels like the worst and ugliest OpenGL tutorial from 1997:


If no-one else understands what this tool can do, it's not going to be as fun as I had anticipated. It will still be useful to me but it would be a really nice feeling to develop a tool for others. You know, and finally get some feedback!

Perhaps I could make a show-off screenshot to catch the attention of would-be customers? From a rendering perspective it's not very hard, but from a design perspective it's very hard for me. I seriously don't have it in me, I'm sad to admit. I would have loved to be artistic and it would have made my indie gamedev career a lot less pathetic.

Should I plagiarize Limbo? Lose the speckle rendering and the particles and there's really nothing to it as long as you dodge character animations+rigging+skinning. Which you do if you're just making a screenshot.


White background, linear white fog, ten meshes for the houses, drop the kid, Z-rotate the camera about the center of town. It doesn't make a selling point in the specs, but it might lure a couple of buyers in. The other stuff is the good part but it's ugliness repels to much so I won't feel to bad putting on some makeup.

IDE and portable code growth without portability layer

I took my first stumbling steps with SciTE. The code was straightforward and as far as I could tell the bulk of it was platform-specific. Which means the author has had to implement it twice and probably a third time for the Mac version. I jumped to a ton of hoops to avoid this in my game engine. I know that when something is implemented on a very portable code base you have five major benefits:
  • When it's implemented for another platform, it usually just works.
  • It usually behaves identically on all platforms, as behaviour is separate from system calls. This often surprises me as it's a bit strange at first to see your game run flawlessly on different hardware.
  • The easy problem areas are confined to platform-specific files. These problems are often trivial to fix, only seldom hard.
  • The hard problems are more often than not bugs that occurs on all platforms, but is usually overlooked on the development platform that for some reason or another is more forgiving.
  • In the long run it should be less work.
One obvious drawback is of course that the architecture in the platform-specifics becomes more complex, larger, harder to develop. And I assume it also becomes more boring to maintain in the long run, as it (base of an engine) is further from what you're actually trying to make (a game). The trade-off in time is, I'm guessing, advantageous if you want less total boredom.

If we look at the number of commits over time for SciTE we could either assume the project has become more relevant for Niel, or it takes more to maintain it:


(The contributions by others constitute only 1.1 % of the commits and I consider them neglectable.) My two-penn'orth: go for a portability layer if you're making something that is going to live more than three years.

Btw, this is what I did with SciTE in 5-6 hours: drop all other languages than Python, drop menus and menu alternatives for other languages, place all configuration files in a subfolder, default to a monospaced font, configure syntax highlighting similar to Notepad++, remove syntax check menu command, add buttons in toolbar for running and stopping, build as TrabantIDE.exe, replace program icon, ESC hides the output window, output log shows every time a game prototype is started. Most of this was made in two configuration files in minutes. Thanks again Mr. Neil Mega Awesomeness Hodgson!

Computer IDE it izzz

I looked at various options to base my desktop "TrabantIDE" on. It should basically do five things: load/save, syntax highlighted edit, run the code through the Python interpreter, display the simulation process (TrabantSim) in some good way, and finally log the output of the Python interpreter to some text pane. I wanted to avoid bloated for my sanity. Atom sure is fancy, but it's written in CoffeeScript/brower-ish. Node.js. tl;dr.

I finally settled on SciTE, which seems like a perfect fit as it had 4/5 features built-in! It seems very customizable (through some .properties files). All I need to do is to replace the icon, fiddle with the toolbar and add a tab for the simulator. And of course give huge credits where they're due: Neil Hodgson, thanks man! You rock! It's really rare to find a piece of software this well-written and without a ton of dependencies.


The only trouble so far was fetching the code as it was hosted on SourceForge (downloading snapshots is for n00b aiit?). I eventually installed a fork of git-remote-hg, pip2 and pymercurial on my Ubuntu machine. Thank you O Software God for package management. Ta-da - it just went through the compiler and now it's running! Tonight and tomorrow I rest, Friday it's time to get to work.

About the author

Min bilder
Gothenburg, Sweden