Beta Testers Wanted for GNU/Linux buggy combat simulator game.

So... I've done a lot of work to port my game Six Wheels and a Gun from Android to ASM.JS javascript in a browser. Just when everything was working, and only networking was left, I found out that Javascript cannot do UDP communication. This means that online play in a browser is not going to work. TCP is too high latency and too slow for running a distributed physics simulation.

I don't want my porting effort go to waste, so I made a derivative port to the 64 bit linux platform. (The Javascript version is built on SDL1.2 and the linux version on SDL2.) Everything works just fine as far as I can tell, and I am preparing a release on the itch.io portal. Before I release it, I could use some testing and feedback. Grab a copy of the game here: swaag-1.5-linux64.tar.gz or swaag-1.5-linux32.tar.gz

No installation necessary, just run ./swaag on the command line. It is dynamically linked and requires libSDL2 to be installed on your machine. (apt-get install libsdl2-2.0 on Ubuntu 13.10) In case of problems, please send me the console output.

Rendering flags for online users.

So I've ported my Buggy Bang! Bang! game to Android, and released it under the name Six Wheels and a Gun or SWAAG for short. While doing this port I wrote a multiplayer networking system from scratch, including the lobby server. When doing online multiplayer, I thought it would be nice to render flags for the players based on the country associated with the IP number. I've open sourced this piece of technology as ip2ensign which is available at GitHub.

2013: another successful year for The Little Crane.

I have proclaimed the year 2012 as The Year of the Crane. And 2013 was another smash hit year. A legion of people (a touch under 5M) downloaded the free version of The Little Crane That Could in 2013.

	2013	2012	2011
iOS	3199K	3454K	1550K
Android	1579K	1656K	-
Mac	53K	81K	-
OUYA	15K	-	-
Kindle	95K	-	-
Rasp Pi	6K	-	-

Even though the game is now available for Windows and Ubuntu, they do not show up as those download counts round down to 0K.

These marvellous figures mean that the grand total for the lifetime free downloads of The Little Crane That Could is now a whopping 11.7 million. Thank you gamers! I look forward to bringing you The Little Crane That Could II in 2014/2015.

Game Lobby

I am porting my game Buggy Bang! Bang! to Android. The leaderboard/matchmaking in Android has no NDK support and looks complicated. So I think I will need to roll my own online game lobby. I've written a leaderboard service before, in Python, for some of my earliest iOS games. It worked pretty well, except for the unreliable web hosting I have, causing outages of the leaderboards. Writing a lobby should not be much more difficult than a leaderboard service. I will write down my thoughts in this weblog.

• I think this can be done based on UDP, to avoid managing connections.
• When a client wants to setup an online game, it could send a datagram with its gamer tag and IP to the lobby server.
• The lobby server can then respond when a second client sends a similar datagram, and create a match up between the two.
• It would send the IP and tag name of each to the other, so that from then on, the match can be played peer to peer.
• I would still need unique gamer tags. Where to get this? Use google plus account names?
• Alternatively, I could have the server assign unique IDs for the first time a client connects, and cache the ID in the client for use with subsequent sessions. Then I could just skip the gamer tag altogether and make the ID user-facing. If the ID increments from 1, it may become a form of pride, like low digit slashdot user IDs.
• What about NAT?

Emscripten

Could I possibly get The Little Crane That Could to run in a browser window? If a modest Raspberry Pi can run it, why not a 'lowly' browser?

Inspired by a blog posting from Dirk Krause over at web3dblog, I decided to look into this. And my weapon of choice: emscripten, because I grow fonder of the C programming language each year, and have no appetite for Javascript. Hurdle number one is the outdated build instructions on linux that I found here. So in this blog posting I will document the attempt to emscripten my game.

• Instead of building llvm/clang from source, I simply install those from the ubuntu repository using 'apt-get install clang-3.2'.
• It turned out that emcc cannot find llvm-link on my system. This is because ubuntu installs it as llvm-link-3.2 so this needs fixing.
• Like clang and llvm, node.js can also be obtained from Ubuntu's repository using the 'apt-get install nodejs' command.
• With those modifications, the compiler seems to work just fine.

  $ nodejs a.out.js
  hello, world!
  

• To target ASM.JS you can use this command line:

  $ ./emcc -O1 -s ASM_JS=1 tests/hello_world.c

• There is an emar archiver tool, but combining bytecode objects into an archive gives unresolved symbols when I link against this archive. fixed by using -L. flag.
• You can put files onto a virtual file system using the --embed-file compiler flag. I've not yet figured out how to successfully use dlopen() though.

Lastly, these slides on an emscripten talk are very interesting.

OpenDE and Bullet

I would like my simulation of tracked vehicles to be faster, so it could possible run on mobile hardware. Currently, you need a modern desktop to do it, at the bare minimum my mid 2011 MacBook Air is even struggling. The 1.7 GHz Intel Core i5 struggles to run the physics simulation when a lot of dirt is active. Additionally, the integrated graphics HD 3000 struggles to render it at full screen resolution.

OpenDE lacks support for SIMD processing. However, there is another physics library, Bullet, which is streamlined for things like Neon, Cell SPU, multithreading, etc. And there is even an OpenCL version. Here I try to summarize the implications of a potential switch:

✪ Bullet builds out of box for all platforms with minimal dependencies. The dependencies it has, come included.
✪ Bullet supports cylinders, capsule, boxes, meshes: all the shapes I use with OpenDE.
✪ Bullet supports (even though it is missing from the manual) the OpenDE style hinge2 joint, crucial for my vehicle simulations.
✪ Bullet uses OpenDE's ERP (Error Reduction Parameter) and CFM (Constraint Force Mixing).
✪ Bullet comes with SIMD implementations, so should be faster in theory. It's probably still AoS though, and not SoA.
☹ Bullet has a C++ API, not a C API.
☹ Bullet lacks the concept of collision spaces to quickly ignore collisions within spaces.
☹ Bullet advices against differences in mass. OpenDE does this too, but at least I know OpenDE handles it well. You can never create a realistic vehicle simulation if your wheels have weigh the same as the chassis, no matter what you do.
☹ The bulk of my game development comes down to endless tuning of the physics parameters. Switching physics library means retuning pretty much everything.

I am still on the fence about this, and will probably hold off on a port. Maybe it would be better to use it in case I start a project from scratch.

UPDATE

Here is How Wolfire switched from OpenDE to Bullet. Also, Bullet3 seems yet to be released, and its development branch seems to still lack the C-API unfortunately.

UPDATE

I switched! Colliding and solving are both multi-threaded, which is great. Unlike ODE, Bullet does proper collision detection on convex-versus-convex. Something that tripped me up: Bullet's transformation matrices have the axes stored as columns, not as rows which I am used to.

Making a mess

I call this composition "Making a mess." It takes a bit of manoeuvring, but after 15 minutes of playing in the sand, the landscape looks considerably changed.

But the sad news is, I am still having a hard time finding a game play design for it. I've got this incredibly advanced simulation technology, but that does not make a game in its self. Should I just hide some treasure in the mud, and have the player dig it up? Maybe with a "warmer" "colder" hint system? Do I create a fancier version of the "Yukon Gold" level in The Little Crane That Could? I don't know at this moment.

Then there is the problem of hardware platform. Mobile is far too underpowered to do this. Even my second generation Mac Book Air is struggling to get fluid frame rates. So PC then? Well, steam greenlighting is not working out for me. And Amazon's app store keeps rejecting my PC build of Little Crane v1. Should I shelf it for a few years, and release it for iOS9 when cpu performance has increased another order of magnitude?