# GAME JAM: Squash and stretch: a 2.5D physics sandbox

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.

Here’s my first, not terribly convincing attempt:

https://youtu.be/ZLPpXCyrb2Y

I’ll share the code later.

I feel like I’ve already broken my own rules though, starting off with an animation, rather than actual gameplay…

Cool! Love the concept. It’s like Juice for physics

Here’s a link to the code.

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`)

### Day 2

(I’m a day behind)

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.

Here’s what I have so far:

The basic idea is you draw on the screen to create various shaped physics bodies. The goal is to guide the ball into the box.

Code to follow.

OK, the updated code is now in the Gist.

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…

Although, with the new JSON library, perhaps the file I/O needed for a level editor would be easier…

Very impressive

A couple of quick videos. I’ve added a notification system (and the beginnings of a narrative):

http://youtu.be/U7q65QU8bfU

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!

http://youtu.be/e2QYmMtlOzU

I’ll post the code and more discussion tomorrow

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)

Looking really good!

@yojimbo2000 I love the 2.5D style you have there, looks great.

@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.

http://youtu.be/skOEuUuyOqU

Gist updated.

I’m using the new JSON libraries for file io.
The scene manager/ state engine is now complete. I need to design more levels though.

no man, this is just awesome. respect

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):

http://youtu.be/jL82o5l0IfY

And here’s a video of the level editor:

Oops, quick hot fix!

interesting phisics sandbox

@yojimbo2000 fantastic achievement!
on my ipad the whole game is offset to the top left by 200,200 pixels…
Any idea what is happening?

@Jmv38 Do you have the iPad in landscape orientation when you first run the code?

I’ve found that it doesn’t launch correctly in portrait mode. Even though I have `supportedOrientations(LANDSCAPE_LEFT)` outside of `setup`.

i was in landscape_right

Maybe I should change it to landscape_any . Does it work OK if you launch landcape_left?