JSON Is Driving My New Game

I’ve begun work on a game idea that’s been bouncing off the inside wall of my brain for a couple of years now. I’m (obviously) convinced it’s going to be the greatest thing that’s ever been achieved by any being so I won’t go into any gameplay details until I actually have something to show of it. There’s going to be a lot of systemsy stuff in it, so I’ve implemented an entity/component system (or ECS) in Haxe. This enables me to write my code in terms of Entities, Components and Systems. My Entities are (more or less) a collection of Components. My Systems register interest with combinations of Components so that they can be notified when a relevant Entity becomes active and can then manipulate is as appropriate. For example my TouchSystem is interested in Entities that have a TouchableComponent and a SpriteComponent (so they know how big the touchable area for the entity is).
One interesting outcome of this approach is it keeps the data very separate from the functionality – Components are just dumb data holders, while the Systems provide the functionality, based on Component composition. I had a plan about how I could leverage this…

I’ve used Unity quite a bit, both professionally and for-funsies, and really appreciate its editor. It gives you the ability to build entities out of components with a drag and drop interface, the effects of which can be seen before you very eyes over in the live-updating 3D views. While I have no intention of writing a full editor for my game I wanted to achieve some degree of development, beyond just level editing, without having to touch the code. I’m using OpenFLTiled to allow me to import Tiled maps into my game. Tiled also lets you add arbitrary string to string key-value data to the map and its objects. My plan was this: store the types of components, and their initial data, right there in the map.
I implemented a step in the loading of the level that will iterate through the objects in the map and get hold of all the data they store. For each object I spawn an entity. For each key-value pair I use the key as a string representation of a type of component (literally its class name). The value is interpreted as a JSON array, and I get back a bunch of values. Haxe has extensive reflection support, so I instantiate the component based on its class name, and pass the deserialised JSON array along to the constructor to build the component just from data stored in the Tiled map. In the map’s data (as opposed to the objects in it) I specify a list of Systems to instantiate for this map (so we could turn off the Physics system for specific maps, for example). So now we can build unique combinations of Components right in Tiled. This is the main advantage ECS has over OO: we don’t have to extend anything to add functionality – it’s all based on run time composition. We can then specify which Systems we want to exist, save it and run the game. Once I have a good library of Components and Systems implemented I can see this leading to a very Unity-like(-a-bit), editor driven workflow for Super Secret Game X.

On Posting

I often think about writing more on this here internet, but quickly dismiss the idea, thinking that what’s on my mind is trivial and obvious and of use to no one. Lately I’ve been considering the type of people who would actually read any of the content I’m ever likely to post and my opinion has changed: if you’re reading this you might find stuff I’m implementing in my projects new, interesting or at least vaguely applicable. It doesn’t have to be ground breaking and it might just inspire someone to try a different approach to their development.
With that in mind I’m going to endeavour to post more, starting with the thing that will follow shortly!

Dirty Haxe

I’m working on my first ever Haxe project and I am loving it. Haxe is a free, open source, object-oriented, cross platform, multi-target, ActionScript-like language and compiler. From one project you can generate:

  • a compiled SWF, with support for a bunch of Flash versions
  • JavaScript
  • PHP
  • C#, for targeting Windows,Windows Phone, Xbox or anything Mono supports
  • Java, for targeting Android or anything that runs the JVM
  • C++, for targeting basically anything else

Apart from SWF these will all provide source code which can then be built in an environment of your choosing.

What about making games?

For me, the real magic comes with the OpenFL library – an open source, cross platform implementation of the Flash standard library. This gives you access to a complete, well documented node based view hierarchy that can target basically anything. From the same project, using a different build argument, OpenFL can build to run in browser using HTML5 or Flash; natively on Windows, Mac and Linux desktop; on mobile, with support for iOS, Android and BlackBerry. This means you can hedge your bets when targeting browser: don’t want to worry about flakey HTML5 support? Provide it as an option, but also build a SWF for everybody else. There’s always going to be discrepancy between hardware and screen resolutions available on different mobile devices, but that doesn’t mean you need different code. Build support for different resolutions into your game and target standard hardware features and your game can run on anything.

The language

So it can build a game to run on your toaster, but how is it to actually use? Well, for a start it has a compiler, so you know ahead of execution that your local variable is being used without being assigned. It’s strictly typed, so that same compiler can catch you assigning a String to an Int. It also makes good use of type inference so you still don’t have to be too verbose with assignment. It supports generics for some sweet strictly-typed containers. It supports anonymous functions and function objects for super-convenient callbacks. It’s got a thorough standard library with support for sockets, web requests, XML parsing, functional-style set manipulation and a bunch more. The standard library support varies depending on what’s actually available on different platforms, but that’s all covered in the API docs. I haven’t had to touch too much of it for the project I’ve been working on, but the hash map implementation has served me well. Compile times are an oft-quoted boon of Haxe, and from my limited experience it seems great. My MacBook Air generates the JS target for my simple puzzle games in 2-3 seconds.

I’ve struggled a little bit with debugging but that’s mainly a result of targeting HTML5. The JavaScript debugger in Firefox is great but you’re debugging a single monolithic JS file which is a different representation of your Haxe code, and then figuring out what that actually translates to. I’ll have to explore further if there’s a way to debug something closer to the actual game code I wrote, ideally the Haxe code itself. Declarations are ECMAScript style, name:Type (e.g. var x:Int), which I find a little off-putting as I spend most of my time in C-like languages, but I can cope!

Conclusion

I use Unity extensively, both at work and at home, and it’s perfect for making cross-platform 3D games, making heavy use of the concept of scenes. I’ve made a few 2D games in Unity and it always feels like I’m fighting against it, shoehorning 2D elements into a 3D workflow. Haxe with OpenFL seems like a great code-centric alternative to Unity – you get all the benefits of write-once, deploy anywhere, plus the whole Flash standard library to drive your game’s sprites. I’ll definitely be using it for any small 2D games I make in the near future. Also having the option of targeting Flash is a nice bonus few other cross platform solutions still support!

Project Structure

Spare-time game development for me is primarily a learning exercise. If I get a game out the other end then that’s great, but I’m more interested in what I learn along the way. I’ve been reading through old entries on Noel Llopis (co-creator of Amazing Alex/Casey’s Contraptions)’s blog, Games From Within and was inspired by his comments on unit testing and TDD and thought I’d try out TDD in my own project. The interface for some of my low level code had gotten pretty nasty so I thought I’d throw it all out and start again. This is a strange luxury of personal projects, and the reason I never end up finishing anything. I guess I’ll leave shipping games to my day job. This also presented a perfect opportunity to really familiarise myself with Xcode I recently bought a MacBook Air and until now my experience with Xcode has primarily been a process of getting a project to compile for iOS and never changing anything ever again. Integrating projects to run unit tests after a compile which would interrupt the build process would allow me to explore some of the more advanced features of the IDE.

My Xcode workspace currently takes this shape:

Project structure diagram

Actual, unedited screenshot of my project structure!

  • Engine – non-game-specific, re-usable code. This is where all my entity/component base classes live, along with some re-usable components and subsystems
    • EngineTests – unit tests for the engine code
  • GameLib – game code library. This is where all the game-specific code goes
    • GameLibTests – unit tests for the game code
  • Cocos2dx – the cross platform graphics framework I’m using
  • UnitTest++ – unit testing framework
  • GLM – GLSL-like C++ library for vectors/matrices/etc
  • Game launcher – the platform-specific entry point for the game. Used to make a window, set up the render context, etc

All of these projects except the launcher and the test projects compile to a shared library to keep everything nice and modular – the tests projects use the same .a file as the game launcher itself.
This is all currently building a Mac binary, but switching over to iOS or Android should just be a matter of adding a new target for the appropriate platform and changing a couple of its settings for the most-part everything will just work. There’s no game yet but that’ll come in time!

Update: Just to potentially make this post useful to someone, I thought I’d share something that I had to wrestle with briefly trying to set this all up. In Xcode, if you run your unit tests as a pre-build phase of your Scheme, the return code will be ignored and it won’t count as a build error, so any unit tests which fail will do so silently. I have a Target for my game setup which has a Run Script build phase on it, which is just the path to the Product produced by unit test project, and the Scheme is setup to build the game and the unit tests. This way the build will show errors if any unit tests fail.

Events Are Operational

I have implemented my proposal outlined in the previous post and all it’s working great. There’s a base TriggerComponent class which holds a pointer to its action. PositionTriggerComponent extends TriggerComponent, and PositionTriggerSubSystem checks for objects occupying PositionTriggerComponent-Entities’ tiles and sets the triggered flag on their Actions. Finally, classes inheriting from ActionSubsystem decide how to handle their actions being triggered. This is working for a simple DebugActionComponent/SubSystem but the idea should apply to anything else. Getting closer to being able to make a game.

Hello, The Internet

I'm currently developing a personal-project mobile game using Cocos2d-x, a cross platform port of the Cocos2d-iOS framework. I got as far as having a few graphical layers moving sprites on the screen when I got tired of 2d-x's weird Objective-C–shoehorned–into–C++ style, which encourages the use of static factory functions to create objects, when C++ already has constructors. I had also been reading a lot about Entity/Component (EC) systems for game development – a methodology that allows for game objects to be built up from collections of reusable components, and, relevantly, forces logic to be separated from display code. I thought this would be a great opportunity to implement my own EC system, as it would keep the nasty Object-C style code very localised and wouldn't spread to any parts of the game logic.

This went really well – after writing and refining the EC framework, then coding some fundamental components and subsystems (such as SpriteRenderable and Position components and SpriteRenderer subsystem), I had a character I could set the world position of, and the SpriteRenderer subsystem would set the Cocos sprite's position accordingly. I went on to write the relevant components and subsystems to get the character moving around a tile base map, using the Cocos touch interface and all was good.

Then I hit a problem. The game I'm developing needs a trigger system. An entity (e.g. a button) needs to trigger an action (e.g. a door opening). This requires the subsystem to track entities with Button components (the trigger) and entities with Position components (the entity that will cause the button to trigger) and consider them independently:

for each Entity with Button and Position: b
    for each Entity with Position: p
        if b.pos == p.pos
            b.button.triggerAction()

..which my current system doesn't support, so I'll have to add the concept of or and and operators to the class that defines the types a subsystem is interested in. I'll check back in when that's implemented and hopefully I'll have a nice, flexible event triggering system.