For the game-jam I thought I’d try my hand at a physics sandbox based game.
Box2D is a rigid-body system, so one of the things I’d like to work on is “fooling” the user into thinking that the bodies are in fact flexible, using animation. That’s the (tenuous?) link to the gamejam theme of “responsiveness” anyway, how our sense of how something feels can be affected by the way it is animated.
I thought I’d start with an attempt to squash and stretch a ball, depending on the normal of its collision, so that it feels like it’s made out of rubber. It’s harder than it sounds.
I’m going to render the physics objects in 3D. To make it easier to write the code for touching the 3D plane, there’s a nifty bit of code in the cameraMove function which makes such that the 3D projection lines up with the 2D plane.
There are 2 attempts to implement the bouncing animation. You can swap between them by changing the order of the tabs Ball and Ball2 (only the right-most tab will execute).
Ball2 (actually the first one I wrote) deforms the sphere in the vertex shader along its local x and y axis (I know, over-complicated much?). I tried to write some code that uses the modelMatrix of the rotated sphere to rotate the normal of the collision, but couldn’t get it to work that well.
It was only after I wrote this that I realised that the scale argument could take separate x, y, z arguments.
So, Ball uses scale to deform the sphere. It doesn’t take into account the rotation of the object (which looks quite odd if the object is spinning while it is still deforming). I think you could account for the rotation of the sphere by placing the scale command after the rotation (but then you’d again face the problem of having to rotate the normal of the collision into the model matrix view, which I couldn’t get to work in Ball2)
Right, time to add a mechanic. First, a disclaimer. This is not a terribly original mechanic. It’s perhaps most associated with Crayon Physics, and various other games on the AppStore, Finger Physics, Touch Physics, and at least one of which, 6 Dimensions was created in Codea. It’s such a great idea though, with so much potential, that I hope the creators (including our own @juaxix ) don’t mind me riffing with it. I think it’s one of the archetypal physics genres, and hopefully I can add an original twist.
Still under 1000 lines (and that’s with a superfluous version of the Ball class). I’m continuously amazed at the conciseness of Codea.
The absolute key Codea technique, IMO, is class inheritance. In this project, every object inherits from a Body superclass (handling all of the physics), and then a Mesh superclass (the 3D skin, with lighting etc). The structure looks a little complex at first. Each object passes 3 tables to the Body superclass: 1. the arguments for the physics.body command itself; 2. variables that are applied to the body; and 3. variables for the mesh. Keeping it modular in this way means that you can add complex objects with just a few extra lines. It really stops complex projects from spinning out of control.
I’m also really pleased with how the 3D skin on Box 2D has turned out. I was worried that I wouldn’t find any decent textures in the Codea built-in assets (I’ve decided not to use any extra assets, try to keep things simple), but actually the CargoBot assets have a number of textures that lend themselves well to 3D.
My biggest worry at this point is that sandbox-y games like this one really need lots of levels. Procedural level generation is not really an option. So I could be looking at writing a level editor, and therefore file I/O, which can be a headache when it comes to code portability. hmmmm…
And also levels, and a level editor. I don’t think the editor will be exposed to the end user (it uses the overlay for its controls etc), just for creating level packs. The new JSON api comes in handy for that!
I always think editors should be open to the end user. It really opens up the possibilities for content. For example, my latest game doesn’t include too many levels (~~50), but it has an editor and shareable levels which I think kind of evens it out.
Re saving, I usually just keep levels in a table of objects, which I turn into a string and save (saveText is cool now)
@Simeon thanks! @JakAttak Yeah I agree, and that’s something I might consider if I take this project further, but I’m not going to have time to get the editor ready for prime time within the time scale of the game jam.
Latest video! The temptation with physics sandbox titles is to throw every single conceivable physics object in. I’m just going to have a revolute joint as the only option. You can see it here with this catapult I made.
OK, the gist has been updated with the latest (final?) code. I don’t have different iPads to test it on though, so I won’t make any promises on how stable it is! Please let me know if you find a bug.
It ships with 12 levels and following @JakAttak 's suggestion, the level editor is now open to the user.
Level 3 is quite good fun, here’s a video (for some reason, the face ordering has become funky when I try to record the screen. It looks fine in the game though):