Does anyone have a reasonable idea about how the physics/mechanics work in Loco Roco? I had a look at Gish (which Loco Roco is accused of imitating) and discovered that the main character is just three solid circles, held together by some sort of elasticity. The blobby look is just superficial. But I couldn't see this with Loco Roco. It really looks and acts blobby.

I was thinking that perhaps Loco Rocos are just made up of lots of smaller solid circles, which wouldn't be so obvious.

Any ideas about the format of the game world?

It's a really interesting looking game. I wouldn't mind making an engine.

]]>I played the game couple of days ago and it was rather interesting. It's amazing what you can do with only two buttons* and simple idea (that is probably hard to implement).

*) Yes, I know about the one-button interface game competitions.

I was a bit too busy with the game so I couldn't analyze that well what was really going on. It looked as if the character was some kind of blob of solid circles moving around in a vector based world. Probably the soft parts of the world had some kind of simple bone hierarchy attached to them to make them soft.

I'm planning to make a platformer that borrows some ideas from Loco Roco too. Once I get AllegroGL and OL compiled I'll start toying around with some of the ideas I have.

]]>
The tilting world would be really easy to do in OpenGL / DirectX.

The physics.. I leave to Thomas Harte!

The blob physics are usually implemented by expressing the blob as a grid. The points in the grid are connected to the nearby ones by strings. Then it's just some simple [EDIT: spring] physics you'll need to play with.

]]>Yes -- I'd say it's probably a highly elastic 2D 'cloth' sim, rendered with a nice curve about the edge. It's like Fladimir said, except by "strings" I think he means "springs". If implementing, remember to pick a very stable physics model for the simulation so nothing explodes -- that, or just apply massive damping.

]]>Making your objects "blobby" and elastic is the simple part.

You just inter-connect the vertices using springs.

You'll need to use a good integrator to make the whole thing robust, or you can even cheat and use some math and a poor distance approximation to give your objects an elastic look and feel, while maintaining robustness.

Collisions are the hard part.

You'll have to implement a system that deals with concave polygons.

I have no idea what you are all talking about, but it sounds impressive.

]]>I'm with you on that one Mr Phipps. My guess at what they're saying:

If you play with your vertical string, it will spring and have an robust but elastic look and feel to the resulting blob?

Jeroen

]]>Hmm.. Slinkeys fall down?

]]>Edge collisions are implemented the same wat, no matter if the polygon is concaive...

Quote:

If you play with your vertical string, it will spring and have an robust but elastic look and feel to the resulting blob?

Here's a "screenshot" (dots are the vertices):

The "blob" without connecting springs: .------. / \ / \ . . \ / \ / .______. Showing the springs: (Imagine that all the lines are straight) .------. /|\ __,´/\ /,+´\ /| \ .-+--/ -+--. \ | / \,+´ / \| /,-´\| / .______.

In this "model", all the vertices are connected to every other one with springs. Then, if you move one of the points towards the center of the blob, the springs will cause a force agains the vertex, thus staring to accelerate it outwards. When the vertex starts moving further away from the center, the springs pull it back.

]]>Would you really need to connect every vertex to every other vertex? It sounds like there would be a lot of interactions to deal with. My guess would be that they're laid out in a grid or honeycomb fasion.

As for the tilting, that can be very easily done on the GBA. I don't know how the GBA would go at calculating the blobby stuff though. Perhaps I can make a poor-man's Loco Roco on the GBA.

I wonder if ODE could be used for this?

]]>Mr. Big said:

Collisions are the hard part.

Collision detection is probably the most extensive topic in game development. There are somany approaches and methods of doing it, and many and ways to cheat. Collision detection is sort of like an ongoing saga, and causes whoever is trying to explain how it might be implemented for a particular game to go off topic and ramble. There's a correct method, and many 'good enough' methods that are considerably faster.

The mathematically correct way of doing collision detection in any volume-based game (most 3D games and 2D games based on vectors instead of sprites) is to convert the temporal dimension into an extra spatial dimension and use this extra dimension to 'extrude' the shapes as they move for a length of one-timeslice. Then, you can do an n+1 dimensional volume interception test. If you are making linear approximations of your movement per frame (ie, you are not simulating the effect of various forces on mid-timeslice object-movements), then the movement of each vertex in the temporal dimension will be uniform, so this means that the shape-intersection math could be simplified somewhat because all new edges in that extra dimension will be unbroken straight lines who'se length in that new dimesntion is 1 (unless a collision takes place in that timeslice). Also, when you find the 'interception shape', you can find the vertex of that shape who'se point in the 'temporal direction' is the earliest, and that point will be the point of collision. This means you can easily find the exact time of collision, the positions and velocities of the colliding points, so you can react appropriately. Of course, you will have to have the objects react to the collision and take their new movements into account.

The problem with using n-dimensional collision detection instead of n+1 dimensional collision detection is that if an object is travelling too fast, it crosses the other object in a single time-slice, so using a plain n dimensional volume interception would miss the collision. However, for collisions with fixed objects, you could divide the world into sectors and see if the object passes from one sector to the next in the time of one timeslice (again, if all intra-timeslice movement is straight, just seeing if part of the object is on the other side of the secror at the end of the timeslice will be sufficient), and if the sector-boundry is collidable at the point of crossing, then a collision has taken place. Another advantage of dividing the world into sectors is that you can use these sectors to reduce the total number of collision tests that are to take place (if an object is not in a sector, there is no need to test for collisions with objects in that sector). One way of dividing the world into sectors is to use Binary space partitioning.

Another approach is to approximate all collidable objects to circles (or spheres in 3D space). That way, testing to see if two circles intercept is reduced to seeing if the absolute distance between the two circles is less than the sum of the radii of the two circles. There is an interesting way of doing this when taking motion into account. Given a period between two times where all forces acting on the objects are known, you can use the Equations of motion to predict the positions of the the two centre-points at any given time. Given a set of two objects, you can combine their motion equations into a single equation that returns the distance between the object at any given time (the distance eqation). You can use that distance equasion to find out where the first point in time is where the distance becomes less than the sum of the two radii (if there is one). Like the n+1 dimensional method I mentioned earlier, you can obtain the exact time and position of the collision this way.

In Loco Roco, one way of using the above method would be to approximate all the nodes (or points in the grid) to circles, and use the circualr collision detection mechanism. As others have previously said, the nodes could be connected by strings, or surrounded by bags, so it's probably best only to predict collisions for each individual frame (timeslice) using the above method. And as I've said, this is just an approximation, but who knows, there's a chance it might just be good enough. But one of the things about collision detection is that you should try out many different methods and see which one gives you the best speed/realism comporomise. Thankfully, collision detection is one of the tasks gradually being relegated to physics-accelerator-hardware.

As for the game itself, it's a pity the PSP does not have any motion-detection or tilt-sensing mechanism.

AE.

]]>Quote:

As for the game itself, it's a pity the PSP does not have any motion-detection or tilt-sensing mechanism.

But people tilt it while playing anyway!

]]>Yeah, a tilt sensor would be nice. You could even play a race game by using the PSP as the wheel!

]]>Or glue it to your head and play a Rock'n Roll Head Banging game.

]]>Quote:

Or glue it to your head and play a Rock'n Roll Head Banging game.

Don't be silly. They'd market a $25.00 Velcro-strap extension.

]]>Fladimir's idea probably works. Have a look at sodaplay. You can build Fladimir's hexagon there, as a static figure. But to render it, you could use bezier splines. The vertices would be the starting and ending points of the bezier segments. The control points can easily be calculated.

You could use the hexagon for collision detection and don't mind that it is not 100% pixel perfect collision detection. Just improve all 2D graphics, adding shades and parallax scrolling and the world will be more real. The simpler graphics, the more we deman perfectness in collisions.

[edit /]

I started to think about the sodaplay type structure. Here's what I came up with. Hope this thread is still read.

{"name":"590253","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/e\/3eb8c75718ec2a2c6671cbe779f25547.png","w":383,"h":380,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/e\/3eb8c75718ec2a2c6671cbe779f25547"}

I got 6 vertices, a - f. Then I got 9 springs connecting the vertices. Each spring is in rest when the six vertices are defined (their coordinates). Gravity affects each vertex. And the springs affect each vertex. If a vertex moves towards another ertex and there's a connecting spring, a repelling force will affect both vertices.

In each loop, all forces that affect one vertex are combined to a single force for that vertex. In next turn all vertices are moved according to the total force on each vertex. Because gravity, each vertex tends to fall, but the springs might prevent them from falling. And of course the green ground prevents every vertex from falling further.

When rendering, all vertices get these bezier control points. In the image, vertex a has two control points. They form a straight line through a. The line should be parallel to the spring from f to b (not because the spring itself, but because vertices b and f). And the length from one control point to the other could be a third of the length from f to b.

In the image, gravity would make c, d and e fall down. The spring fc would of course make c turn to the right. a would fall down and f would be pushed into the ameeba. But in the long run, the ameeba would roll downhill.

There could be springs from a to b, from b to c and so on. But leaving them out makes the ameeba more flexible.

]]>