Hi!

My name is Andreas, and I'm a musician/writer/developer who really wants to make games but has struggled finishing anything because games are hard. I've just begun a new project about werewolves and road trips, and it's very early going, which seems a great opportunity to start a dev diary to kick my own ass. Difference this time from the past is knowing the scope, knowing how long things take to do, and also my livelihood isn't tied into it, which frees up a lot of time to think, learn and experiment. I expect this to be a 2-year project at least, though elements of it compartmentalise into individual projects in a nice way that I think should give me the required bursts of accomplishment.

In this first post, I'll go over the tools I have currently chosen to go with for my game:

1. Haxe/CPP. I adore Haxe (http://haxe.org), a bizarre frankenlanguage that takes a great deal of inspiration from languages as diverse as ActionScript, OCaml, python and a suite of bizarre french shit its designer, Nicolas Canasse, decided was neat (and for the most part he was right). It is a transpiling language with a ton of different targets, but instead of adopting a general xplat approach I'm committing entirely to its C++ target, because it lets me use Haxe in the way I find the most natural: As a paint roller that straddles the middle ground between scripting and native code, letting me broadly productive while still giving me the ability to do performance intensive things in C and C++. In the long term I would also like this game to be straightforward to port to consoles, so choosing a web-based or VM based technology just isn't a good option. I've elected Windows desktop as my primary platform, with MacOS as close a second as possible: My current dev setup bounces between a desktop pc and a mac laptop, so the leapfroggy way feature parity is achieved is very educational as well.

2. SDL2. My biggest hassle with learning C++ in the past was simply getting to a stage where I felt productive with interactive visuals. Out of the solutions I'm familiar with, SDL2 is the most straight forward xplat way of getting an OpenGL window up with input, and the Haxe linc bindings for SDL2 made this particular choice very easy.

3. OpenGL 3.2. I've not had the opportunity to write much OpenGL off of mobile platforms where I've been tethered to GLES2, so learning to write "proper" OpenGL is both complicated and extremely interesting. I get to piggyback on the competency of people like Ferris and Baggers and I also get to test my hypothesis that a hand written renderer has a certain je-ne-sais-quoi that adds character and "feel" to a game that off-the-shelf solutions do not. For Haxe, I'm forking the linc OpenGL bindings, which are for the most part ultra thin and inlined.

4. Un4seen BASS. Sound is obviously important, and the first option available to me was the linc OpenAL bindings for Haxe. However, I find OpenAL a pain in the ass, I have no needs for low level access, and I just wanted to get off the ground quickly. BASS is a wonderful, tiny C library that covers most of the bases I have, as well as supporting XM module playback, which I'm toying with the idea of basing my soundtrack around. I was weighing BASS vs FMOD, and while FMOD is more attractive featurewise, the simplicity of BASS tilted the scales in its favor. My linc-style Haxe bindings for BASS will evolve along with this game, and that project can be followed here.

5. Nape physics. This part is not truly decided yet. I think the kind of game I want to make has limited needs for accurate physics, and the majority of interactions between objects might just as easily be resolved with SAT-style separation vs naive euler integration. The parts of Nape, a Haxe physics library, that I really like, are actually tied to its geometric utility functions, like easy access to marching squares for things like destructible terrain. It also allows for kinematic bodies, meaning I can use whatever dumb physics model I cook up and slave Nape bodies to it and still get the information I need to resolve complex collisions. I think it is likely I'll use Nape for static collision geometry in the game world and kinematic bodies slaved to game entity transforms to detect and inform gameplay-impacting collision resolutions.

6. Verlet integration. Verlet integration kicks ass. It's simple enough for any fool to understand, blazingly fast, allows complex interactions between a very useful subset of constraints (very stiff springs, distances and points), and parallelises beautifully. I would like to use verlet stick constraints for most secondary motion in my game world, including door motion, trailers, ropes and chains and anything else that requires a tether. It would also be interesting to see, given how nicely verlets parallelise and are basically stateless, if performing all the verlet physics on the gpu wouldn't be a fun exercise in learning how to leverage transform feedback for giant particle systems.

7. CEGUI. A UI framework is a lot of work to do ground up, and CEGUI seems to strike the right balance of features for me: A good editor for laying out interfaces, good typography support, decent platform coverage and most importantly, it's an open source venture. There are no Haxe bindings for it though, so like BASS, I'll have to roll my own. A possible alternative is an immediate mode solution like IMGUI but the workload associated with writing the bindings makes

8. Bitbucket and Trello. Bitbucket has pretty nice Trello integration now, and I really like the Trello way of managing tasks. I'm not quite comfortable making the game open source at this juncture, simply because so much of it sucks and I want to have a window in which I can flail a bit before it seems to gain direction, so Bitbucket's support for free private repos inched out Github this round.

That's it for this update. Next week I hope to have made good progress on CEGUI bindings, at the very least to a point where I can print messages with a custom typeface and I can finally abandon endless amounts of logging at 60hz to know game state internals. Ciao!