Tuesday, December 31, 2013

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.

Sunday, December 29, 2013

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?

Monday, December 23, 2013

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.

Wednesday, November 27, 2013

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.

Wednesday, November 20, 2013

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?

Thursday, November 14, 2013

Lean Code

I guess my code is pretty lean.
$ find ~/apps/LittleCrane -name \*.cpp -exec wc -l {} \; | awk '{total = total + $1}END{print total}'
19653

Compared to these monstrous code bases. This would designate my game as a 'simple iPhone game app' according to their classification. Also, I do not believe their assessment of the code size of a modern car.

Sunday, October 20, 2013

First release of Little Crane for MS Windows.

I'm happy to announce my very first release of The Little Crane That Could for MS Windows. You can try the first 6 levels for free, in the Free-To-Try distribution. If you want to play all the 25 levels in the game, I urge you to vote in the green light campaign and tell all your friends.

In case you try this out, please drop a comment in this posting. I love to see feedback on it. In case of troubles, copy the console output and paste it into a comment please.

Requirements:
  • 64 bit Windows OS.
  • OpenGL capabable graphics card.
  • Support for GLSL (shading language) V1.1 or higher.

DOWNLOAD LINK
LCFREE-516.msi

README
The Little Crane That Could.
Free-To-Try release v5.16 for Win64.


KEYBOARD CONTROL:

CURSOR KEYS: Drive truck
Q/A:         ROTATE
W/S:         ELEVATE
E/D:         BEND
R/F:         EXTEND
T/G:         GRAPPLE

+/-:         ZOOM CAMERA
ESC:         RETURN TO MENU / QUIT


JOYSTICK CONTROL:

ONLY XBOX360 COMPATIBLE CONTROLLERS ARE SUPPORTED.
Tested with Logitech F310.

Support: http://thelittleengineerthatcould.blogspot.com/
gmail user: b.stolk