Hi!

I just came up with a (still very raw) idea for a small game. Or better: A raw concept about which I'd like to think a bit longer, and see if it can work out for some sort of game, but before I go on with this, I would appreciate some thoughts on how I could (or should) do this.

The basic idea is, that the player gets to control a "goo ball", which basically can only do one thing: Get stiffer and looser, so that it may become an almost rigid ball, or a watery splat. (Going rigid fast could make the ball jump for example, or when falling, becoming more watery in the right moment could prevent you from rebounding - but become too incoherent, and you splatter. As I said, raw ideas, still figuring out if that can make a fun thingy.)
Combined with surfaces with different friction (think lotus leaf vs. a carpet), there might be fun ways to make a neat small game from it.

My problem is that I can't really decide what technique would be best to make this goo ball. My initial ideas were a) a particle system, where the goo particles are held together with more or less force, or b) a mesh with spring dynamics. The latter could make it a bit difficult to handle "death", which means disintegration of the goo ball because of falling from too high, or being too loose on a high friction surface. Also, since I haven't done much with physics so far, I can't picture how difficult it might be to apply friction on either technique. (My feeling says, that a spring mesh would be easier in that department.)

Can anyone point me into a good direction?

Many thanks in advance,
Medium9

There's not many basic concepts that are unthought of today, and I wasn't really shooting for originality here. Being original nowadays is pretty much as hard (or depending on luck) as a major, rule changing scientific discovery I fear.

But yes, this is more or less what I had in mind, just taken to 3D, and maybe more like a racer than a platformer, or a bit in between these two. Looking first hand at Gish may help me shaping this out more however, thanks!

If you're using a spring-based system, you could probably measure the stress put on the springs and "kill" the player when that stress reaches a certain amount.

My problem with this approach was more related to visualizing it. With particles, splattering into pieces would be comparably easy (at least as long as you're not rigid enough to produce more of a shatter than splatter...). Tearing apart a coherent model to form multiple "drops" at least sounds a good bit more troublesome.

Another thing to consider crossed my mind: I need to keep the volume of the ball roughly the same in any state. Does any technique make this possible to handle fast enough?

Hi there,

In my opinion, don't try to make something "original". Don't hesitate stealing concepts from other games, what counts is that the end product is good.

I've been working on a similar game concept, except that the blob also can take on a number of shapes, thus camouflaging itself. For instance, it could harden into the shape (and color / texture) of a rock, plant, or any other odd object as a way of avoiding enemies. Also, I have actually developed a physics simulation algorithm capable of doing this.

I have tried out several methods for making goo-balls or blobs. If you want your protagonist to be able to splatter out and divide into several droplets, a particle based fluid method is definitely the way to go. Actually some wok was done on making Gish 2 using this concept, but apparently the project has been abandoned.

If you rather want a soft, deformable body, some sort of spring based method is preferrable over the particle based system. This is what I use for most of my simulations. Keeping an appox. constant volume is fairly easy in both methods.

If you're interested I could post some of my program examples for you to "get inspied by" :-)

cheers,
Mike

That is a most generous offer! And I'd be more than thankful for some bits to look at, as to how I might just even begin. This is thought as a private learning project, and I finally want to exceed "static meshes bounce off of static walls" stuff. I've done my fair share of mathy software, but only few games. With a tip into the rough direction, I (hope I) should be able to stand on my own more or less.
And the camouflaging is a quite awesome idea. I was more going for a sort of "puzzle racer", where the surroundings themselves pose a threat, and you need to go from start to goal - possibly against other blobs via network, but that would be something for later :).

A deathmatch mode for network would also be awesome. Rigid blue goo speeds into watery red goo, red splatters, blue gets a frag. ...yes, I think I want to carry the basic idea further.

Here's one for starters:

http://www.gamedev.net/community/forums/topic.asp?topic_id=579582

I finally got to read your thread and the papers linked in there - apologies for the long wait until my reply.

I've got to say: Wow! Your demo looks very promising! I had to realize however, that I probably need to take a few steps before jumping to "3D goo ball", since this will be the first time for me to work on the internals of a spring based system, hence I don't really know much at all here. Fully comprehending what you did there will take it's time, but it seems it could be well worth it.

One question arose while reading: It's all 2D - can you foresee any major problems with taking this up one dimension? Or could I build on that more or less straight forward, but with one component more per vector?

Either way, again many thanks! That little project seems to potentially grace me with some very interesting spare time in the near future :)

Hi Medium9,

I totally forgot to post links for my other examples! These are relatively simple and include well commented source code. In the header files you'll find some links for papers describing the theory. Should get you going in no time :-)
As for nudging it up one dimension, yes that is definitely doable, since the model is spring based. In the resource section somewhere on gamedev there's a code sample on how to do 3d volume calculation for this kind of thing.

Example 1
Example 2
Example 3
Example 4

Cheers,
Mike