News Mar 20: R.U.B.E v1.7 released. Instanciable objects!
Feb 21: Added RUBE sample loader for Cocos2d-X v3.4.
Feb 17: Funny Fists released in iOS App store and Google Play store. (YouTube video)
2014
May 25: R.U.B.E v1.6 released. Samplers!
May 12: "On-the-fly" resource updating for Cocos2d-x
Apr 22: New blog post: Inverted pendulum control
Apr 7: On-screen logging class for Cocos2d-x
Mar 22: Downhill Supreme 2 released for iOS and Android
Jan 2: YouTube video: Making soft-body wheels in RUBE
2013
Oct 6: Check out Supplyfront RTS, my 7dRTS entry continued.
Sep 26: R.U.B.E v1.5 released. Customizable item labels, snap-to-grid, export filtering, full-text help search.
Sep 18: Added RUBE sample loader for Cocos2d-X.
Sep 16: Updated RUBE sample loader for Cocos2d v2.
Aug 12: RUBE loader for Nape by Zeh Fernando
Aug 7: Added RUBE sample loader for SFML.
Jul 30: Try my MiniLD 7dRTS entry.
Jul 24: Added physics-driven particles tutorial.
Jul 20: New blog post: rendering solid ground (as in Downhill Supreme)
Jul 18: R.U.B.E v1.4 released. Command-line interface for batch jobs, hotkeys for scripts, better script management.
May 22: Downhill Supreme is out now! (iOS)
Apr 2: R.U.B.E v1.3 released. Collision bitplane editing, Cocos2d-iphone loader, usability improvements.
Mar 11: R.U.B.E v1.2 released. Now supports weld, friction, motor joints and automatic image reloading.
Mar 10: RUBE loader for libGDX by Tim Scott
Jan 28: New blog post: a functional combustion engine!
Jan 22: New blog post: wind tunnel
Jan 20: Added explosions tutorial.
Jan 16: Added buoyancy tutorial.
Jan 16: AndEngine sample project to load RUBE scene by Bart Hirst
Jan 14: R.U.B.E v1.1 released, now supports custom properties.
Jan 1: All basic tutorials are now available in Chinese at ohcoder.com Huge thankyou to @OhCoder!
2012
Dec 23: Discussion forums have been set up
Dec 4: R.U.B.E v1.0 is ready !
Dec 2: YouTube video: Box2D pendulum clock
Nov 26: New blog post: rocket platform thingy
Nov 25: Video of R.U.B.E scenes in Chipmunk.
Nov 23: A sample project to load R.U.B.E scenes into Chipmunk physics! Details here.
Nov 14: An XCode sample project to load R.U.B.E scenes on iOS is now available. Details here.
Nov 11: A Java version of b2dJson is now available, based on JBox2D.
Nov 6: A Javascript version of b2dJson based on box2dweb is now available. Demo here!
Nov 2: The full specification of the JSON format used by b2dJson can be found here: b2dJson file structure
Oct 28: YouTube video: 2-minute ragdoll in R.U.B.E Box2D editor
Sep 29: YouTube video: R.U.B.E Box2D editor usage example
Created: November 21 2011

Game progress


What's happening recently... I added tutorial topics covering trajectory prediction and 'sticky projectiles', which also looks at a way to model an arrow in flight. And mayobutter's conveyor-belt idea made it into Box2D proper, so the conveyor belts topic has been made simpler. Next will probably be one-way walls/platforms.

I have been working on the boxing game a little here and there, at this rate it's not likely to be done until next February I'm guessing :) Here are some screenshots of the fight scene, this will give you an idea of how it will look. The big TV screen at the back is used before and after the fight as the menu screen. So while you are choosing your fighter character the 3D scene is already loaded and you are actually looking at the arena screen, but the camera is perfectly positioned so that you can't tell this until it pulls out and swoops down to the ring. Then after the fight the camera swoops back so that the arena screen once again perfectly fills the device screen. Quite neat if I say so myself... and I do. Boxing2D Actually most of the work done since my last blog post is not related to the screenshots above. If you were thinking that the heads of the fighters look too big, this is because you will be able to put photos onto them, either from the device's photo album or by taking a photo with the camera. You can set up three photos, normal face, ouch face and K.O. face for when you lose. Being able to beat on your friends should be fun. So the menu screens for setting these up is where most of the work has been going lately.


The fluid simulation has not been touched for a while. I came to realise that the loss of area that occurs in a collison needs to be corrected much more before continuing to the next time step. Currently I am first joining the drops together, then looking at the area that needs to be made up and pushing the surface outwards at places with high pressure, which is a good start but those new locations can still be intersecting so the area is not fully accounted for in just one iteration. I think something like Box2D's position iterations setting would be needed to do this say 10 times or until a stable point was reached.

The other thing I realised was that two colliding drops should not simply have their surfaces joined, because this discards information about the pressure in the overlapping portion. The overlapping portion should first be used to come up with a new border line between the two drops as if they were immiscible, and their area loss should be corrected individually before allowing them to become one drop. This has a couple of nice advantages: firstly the density of each liquid can be taken into account when defining the new border between them by allowing the denser one to take a larger portion of the overlapped region. Secondly, if you know where their border is, just don't merge them and you automatically can simulate for example oil and water.

The drawbacks are that the collision tests are more complex. Previously I had a linear time method which just ran around the edge of each drop looking for overlapping lines, and there was a simple algorithm to know how to cut them and which pieces to discard. If no surface sections can be discarded this won't work. There are other things to think about when rigid bodies come into the picture too... Since the new way of dealing with drop/drop collision is similar to how I was thinking to deal drop/rigid collisions. I still think there might be a way to keep everything handled in a 'unified' manner, but until I can figure it out I will probably not be coding any more just yet.


What I have been doing instead is checking out SFML and Angelscript. For some reason I had been thinking the ML in SFML stood for markup language so I had not bothered to even google it - silly me. Boy was I pleasantly surprised. With Angelscript too - how did I miss that one! I have used the Spidermonkey Javascript engine for a little scripting in the past and was thinking to use that again, but I never really found a way to fit it into the 'brains' of game entities satisfactorily, and I'm not a big fan of the un-typed nature of it (quietly letting you run something that will blow up in your face later), and being able to develop in Angelscript and then drop it (mostly) straight into C++ is a huge win too. I'm sold.

So I'm getting accustomed to these new (to me) tools lately. I was pleased to see how easily an SFML window fits into a Qt widget - this means that it could be used for the editor, and then detached to run on its own as a game using mostly the same code. Angelscript I am intending to use obviously as the 'brain' for AI, as well as probably for settings files to tweak values while running. Eventually it would be good if the editor had some scriptable features too.