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: October 31 2011

Drops 2D :)


After doing some experiments with the boxing game network speed over bluetooth etc and satisfying myself that it will run ok, I've decided to go ahead and make an app for the app store. Obviously this one will not be done in a week like the last two were, it's quite a bit more work.

I also became extremely distracted with another side-project, a 2D fluid simulation using just the surface of a fluid to simulate it. As the surface moves around the area will change, so the position of the surface points are adjusted to keep the area at the target size. This paper explains some of the ideas quite well: Fluid Animation with Explicit Surface Meshes.

The paper covers a method where the surface is affected by an underlying grid representing the movement of the fluid. I am experimenting with not using any grid at all, but simply surface that preserves its area. This method cannot simulate the incompressible nature of water so it's not really an accurate fluid dynamics thing, but it may just be good enough for use in games. Since there are no particles or grids, the processing time depends only on how many points the surface is made up of, and there is no problem with keeping small details. Drops2D On the down side, apart from the compression issue, fast moving surfaces can be problematic - small drops can tunnel through the surface of a larger drop in one time step. Something similar to Box2D's bullet body setting will be needed. I have a feeling the compression problem could be greatly improved if the time step were extremely small, so that each frame only had a small amount of compression to repair before the next frame occured - as it is now I am trying to handle cases where two drops can go from not touching, to being half-embedded in each other in one time step, but perhaps this is not realistic.

Anyway, the long term goal is to get this interacting with Box2D rigid bodies sometime. I have already used a bunch of code from Box2D which was very helpful to get this far already, in particular the dynamic tree has been awesome. These calculations involve tons of raycasts and it has been performing really well.



Uhm... so the boxing game, yeah. Work has been a bit slow on this front. I resurrected a lot of old code I had and managed to get a proper messaging system up and running, and loaded in 3D models made in blender. I also set up a system so a friend of mine who will be making the audio can upload his sounds to a webserver, and the app will load them from there at runtime. This lets him check out how things will be on the device anytime without me needing to get the files from him and build and distribute a new adhoc ipa.

As for synchronizing the physics, I'll be cheating on that. One device is the 'server' which receives touch inputs from the other device, runs the physics, and sends the entire Box2D world back to the other device every frame hahah... I can do this because the entire world is only 300 bytes or so in size. There is no synchronization of game 'turns' whatsoever, the two devices just send whatever they have available to send at any time.

I went with this method over the typical way I might have done this (which is to send the input only and simulate physics on both devices) mainly for simplicity, since there are no timing issues to think about, and for accuracy - the determinism problem will not matter because only one device is actually doing any physics. Another factor is that I will be writing the gamestate to disk as it is played, to create a replay file. This could also have been done much more economically by only recording the input, but I thought it would be neat to have a replay that could be rewound at will to watch the KO punch highlights or whatever, and the simplest way to do that was just to have the entire world state for any given frame available in the replay file.

Anyway here is the 'arena' so far, the fighters will be the two flat planes in the boxing ring. The game play itself will be entirely 2D but the camera will move around in the 3D scene a little before and after the fight. Boxing2D
Oh yeah, I also added a Box2D gotchas page and an advanced tutorial topic covering the 'fake surface velocity' idea that is quite useful for making conveyor belts. Enjoy!