Well, one thing is for certain I am grateful to be posting this and not something about giving up or moving on. Let me explain.
The whole hindsight thing.
I chose javascript for many reasons. I also chose v8 because it is extremely easy to integrate. It really is. It is also really fast, and easy to build on other platforms.
See when I started building the technology behind this game, my intention was not to get onto as many platforms as possible, at least not with the core codebase. I built the UI system in such a way that i can connect multiple 'viewers' to see that state of the game I am making. That means a native iPhone app, or a web based php system, all of them have the exact same access to become clients of the game, with little or no porting of the core code. The game mainly runs online, so a connection would be required anyway. Your client is actually hosted on a dedicated server, and your 'viewer' will show you what the client is doing.
As time progressed I found myself really enjoying the base technology, and more so enjoying using javascript to make games. I also ended up moving towards a normal usable 2D engine for other people to use (and quite a few are). I added tilemaps, physics, sprite systems, animations etc. What I realised then is some sort of potential for the cross platform factor to become far more of a reality. Port the code to the platforms as native code, and all my games can be portable (as well as anyone else who wanted to use the technology). I had assumed ( about 9 months after i had started ) that v8 was portable to the platforms I was porting to at the time. Mac? Easy. Linux? Easy. Android? Already there. iPhone? Compiled for arm, success!
What I did when building the iPhone version of Lab2D was something monumentally dumb though -
Make sure you do not test ported code on the simulator and be satisfied.
Why V8 engine does not run on iDevices at all.
This is something that took a while to find the REAL reason. Some complained about the SDK Agreements, not really an issue if you are not downloading the scripts. Some complained about the lack of ARM support but of course V8 grew on that pretty quickly for Android.
iOS has a restriction that basically makes V8 not work. Here is a list of the things V8 can and cannot do on iPhone.
CAN - Compile against device SDK's (4.1 in this case).
CAN - Run on the device, the arm code and v8 code works as expected (note, this is just the V8 code)
CANNOT - Execute any javascript via the JIT compiler.
Why is that? Some said the ARM JIT of V8 emits the wrong kind of assembly for ARM processors and uses a simulator of sorts on android? No, that is not the reason.
The reason is - Writable memory cannot be flagged as executable on iOS.
This is simple to understand. A JIT will compile code into memory, and execute it there. This, cannot happen on the iOS platform. Seeing as V8 is, just a JIT compiler, it makes sense why Invoke/Execute crashes on device and not on the simulator.
And then came GameMonkey
At first I thought I had lost out. I was really blown away at what a stupid mistake I had made by not testing earlier. Secondly, the other problem I realised is that V8 does not compile or run on PowerPC Architecture ( there is a port, but not usable yet ). PowerPC powers XBox360, PS3, Wii. That means the chances of me using V8 on those are so slim its not even funny. It also means that MIPS was not there yet either (think PSP).
The options I had included rewriting the entire engine in another scripting language. Rebinding the core engine to scripts can take half a day, but rewriting all of the game engine script code will take some time. And a lot of it relies on the language features to get things done efficiently, meaning a lot more code than I had in JS. It also meant losing the whole purpose of why i wanted to use javascript etc etc. I looked around, I have used many scripting engines before none of which I would choose for this, but I was linked to GameMonkey by the awesome Dylan Cuthbert from Q-Games. While there was a certain trade off, I was more interested in it because of its JS like syntax and other cool features. I started experimenting with the scripting engine and tweaking the VM here and there. What I did notice is that i could actually add the features of JS that I need to the GameMonkey engine, and continue forward with a language that was definitely portable ( as gamemonkey can be seen on all major consoles and platforms ). Instead of porting everything fully, I kept digging around for more possibilities. Most obviously, I would be looking for a javascript engine that was portable that I could use to add support for on the platforms that need it.
And then came SpiderMonkey
Now that I added some support for game monkey, I only added what was needed to test portablity and viability of using the engine. What came next was seeing someone else had used spidermonkey on iPhone before. I also noticed that the post was made in 2008. A long time for an engine to progress. And to be honest, there was no real competition with spider monkey and game monkey in terms of performance. Spider monkey was dog slow not that long ago. Luckily, they have made progress in leaps and bounds with performance and I didn't want to prematurely optimise anything without knowing if it was slow as an embedded engine. So, i grabbed the spidermonkey source code, I made a new static library project and I built the code using a hybrid of their make files and XCode. I hooked up the output library file into a test empty OpenGLES example , and I copy pasted the getting started tutorial into the main.mm file. 2 minutes later, I deployed to device and had spidermonkey functioning 100% on iPhone. On device this time. This was a huge sigh of relief. I can still move forward as planned, without losing much pace except for adding bindings for spider monkey to the core (only about 60 bindings total it seems).
And then there was the engine code
Obviously, I realised that i need to be testing far more if I plan to support other hardware and platforms. I need libraries and code that will definitely work on specialised hardware. I can't afford to spend more time on something I might not be able to use somewhere. It sucks. And If i plan to be using this code on consoles it needs a lot of refactoring for efficiency. When I started the engine code It was more than a year ago now, slowly over that time I had learnt far more about V8, about C++ and C practices, I had started moving to use C based libraries intentionally as they are the most portable and compatible and easily built, I started removing code that was legacy and tidying up all the weird experiments that I had coded in and around the engine code ( like a UV map editor in the UI system! ). I also learnt far more about writing efficient code, only after the code worked in the first place. The whole get it done, get it working, get it faster, get it clean was working wonders in terms of productivity with the little time I had to give the engine, but it added some ugly code along the way.
Inbetween all this, I have read a huge amount on the topic of portable code, portable games and understanding the architectures of consoles, mobile platforms and game engines. If you haven't - be sure to get http://www.gameenginebook.com and also check out http://www.altdevblogaday.org . Both of these links are incredibly helpful when looking to write console or portable code in general. Especially efficient code, memory management and those things that PC doesn't hate on so much.
And then there was a refactor
This weekend I started a pretty large scale change over the entire core codebase. Switching out libraries for proven portable ones, adding a scripting interface that allows multiple scripting engines to exist at the same time, wrapping more of the engine in spidermonkey and gamemonkey, moving away from code with known bad allocation patterns and starting to add custom memory allocation systems in the places where it would count. Portability for me always meant Windows, Linux, Mac for the most part. Now that there is more of a usable toolset here the value of having this available to independent developers on other consoles and platforms is obvious. Plus, it teaches me immense amounts about writing time critical code in an efficient manner.
And then there is a conclusion
iOS - spider monkey (javascript)
Windows, Mac, Linux, Android - V8 (javascript)
PS2, PS3, PSP, XBox360, Wii - GameMonkey
My plan is to move game monkey language closer to JS in all the ways possible, so that less porting between gm and js files will occur, but since I have yet to even test the engine code on any of these platforms ( due to the cost of obtaining a developer kit ) but until then, it is not much concern. Until then the focus will be on getting the engine embedded in browsers, and onto android in full. That is still a lot of options, and still all using javascript. When I do get onto those platforms with testing, and performance tweaking it might mean something different...
But overall, this side project hobby engine is actually so much fun. It is fun to face these challenges, fun to write and learn more about portable programming practices and most importantly - it is really fun to work with the engine to make my own games (which really, was the intention overall).
For now, the engine is of course still usable, still looking for testers, and the source will be available as soon as the refactor is complete. The code will most likely be hosted publically on github along with all the games and engine side code, there is nothing really magical going on there!
More soon.
