2D Digging (E.G. Where's My Water?)

Hey guys,

I am curious - how would you go about creating a digging mechanic like seen in “Where’s My Water?”

Video Example:

A few issues:

Textures - how to get the background to show through where you dug.
Collision - getting collision to follow the edges of the dirt.
Optimization - Suitable for iOS.

I love challenges and now I have got my next one, currently I have tried a few different idea through my head such as using a plane and removing the vertices and also constructive solid geometry. Both methods seem to have some really big issues involved with them.

So what would the professional way of going about creating a 2D digging mechanic in Unity be?

i think they are using The marching squares algorithm. Search in google - marching squares or in wikipedia. I dont know how to make collisions for it but may be mesh collider will handle it. For performance issues i suggest you to use one solid mesh or if your world is very big split it into smaller peaces. And don’t rebuild the mesh every frame, rebuild it only when you change it (when you dig).

Looks like very simple polygonal texture erasing algorithm using a trivial perimeter calculation to determine where the water should flow.

Thanks Dee, marching squares is very interesting and Ill look into it some more.

Justin, if it is very trivial could you give me a little bit more direction of how to get it going in Unity.

Marching cubes is a very powerful algorithm but it is really overkill for this sort of problem. There are also other more suitable algorithms, similar to marching cubes, that are more memory efficient or use less compute power. A little light reading will give you some ideas in that direction should you want to tackle a completely 3D version of this sort of game.

I cannot speak to a solution that is particular to Unity because I have not done this type of game in Unity before. However, I have done this type of game before and it is a thoroughly generic problem that can be solved in any almost any engine relatively trivially.

This solution presumes that you are doing a game like Lemmings or Every Drop Counts or one of those “fire, water and sand” puzzle games that are presented primarily in a side-view, two-dimensional play style.

Maintain two bitmaps of equal size, or in Unity’s case, a 2D array of values and a separate texture. We will refer to these two bitmaps as the collision bitmap (or a 2D array in Unity) and the display bitmap (or a texture in Unity).

The display bitmap is what the player can see; it is the nice looking pretty version that is displayed on screen.

The companion collision bitmap is something that the player never sees but is actually the bitmap they interact with when they erase part of the screen or tell a Lemming to dig.

When the player wants to dig or erase part of the screen to permit the water to pass through, simply detect where the player is dragging their finger on the collision bitmap. Ensure that the area of the collision map the player is dragging their finger through can actually be erased or doesn’t have some special property such as they need to drag their finger across it twice or extra hard or some other game mechanic. Different values in the collision bitmap indicate different effects such as diggable, impenetrable, extra hard, can only be destroyed with explosives, etc. Let’s assume that your entire collision bitmap is diggable at this point. As the player drags their finger through the collision bitmap, the game will erase parts of this collision bitmap where the finger touches. The game will also erase parts of the display bitmap too in the exact same corresponding position.

Now for a game like Lemmings, we’re pretty much done at this point. When the Lemming needs to walk around the game mechanics can just check the collision bitmap for where the Lemming can walk or stop them if the ground is too steep or burn them if the ground (collision bitmap) is too hot, and so on.

In a game such Every Drop Counts, there is an extra step, and this is where we need to calculate a perimeter on the collision bitmap so that it makes the physics for making the water splash around utterly trivial. First, we run an edge detection algorithm on the collision bitmap which will give us a nice clean image of where the edges of the collision bitmap lay. Then we convert that edge bitmap in to one or more grouped polygons to give us some nice clean polygons to test our collisions against.

We can also use those polygons to draw lines directly on to the display bitmap to give us the nice hard edges in a different colour that you can clearly see in the game play video.

Okay, so at the end we have a display bitmap, looks pretty, shown to the user, with some areas cut out now. And we have a collision bitmap, meaningless numbers to a human but valuable to the game, again with some areas cut out. And we have some polygons to use in collision tests that permit us to run some simple physics for the splashing water. Now we run our physics algorithms such as PhysX or Box2D (recommended), the little particles of water splosh around inside the polygons, bouncing off walls and being contained all very simply.

For detecting edges and converting to polygons and lines, check out AForge, a pure .NET library. For performing tests against polygons, polygon intersections, calculating perimeters and all sorts of nice tricks, check out the Clipper project, another pure .NET library.

Another thought is that Every Drop Counts could well be using very simple polygon cutting code to do the removal of the pixels. This is an even more trivial solution than working at the pixel level. They may not have a collision map, they may be using polygonal exclusion regions to prevent cutting in areas not permitted.

Thanks Justin,

I have followed your advice, so far I have managed to get in the digging effect. Using a collision grid and texture as you suggested I am able to translate mouse positions into the collision grid and texture2D pixel array. I then set the color of the pixels which enables me to create the digging effect, in this case just setting the alpha of the pixels in the brush radius to zero.

I am now focusing on implementing the collision side.

Thanks again Justin for you advice and direction, although I wouldn’t call any of this trivial :wink: I understand the concepts easily enough, its just implementation in Unity which is giving me a headache.

Cheers!
Pip

Anything we can check out? Would love to see how you are getting on.

Just a side-note I thought you might find interesting - Where’s My Water was actually made in Unity =-)

Seriously? wow then it even more awesome.

If you don’t mind me asking, how do you know this? :slight_smile:

In Unity?? For real ballz?

I had a discussion in another game engine forum about this exact game, in amazement I was as the games physics. The consensus on that board was that the engine in Where’s My Water, is so intricate that it had to be a custom buil engine. Since it is a Disney game I thought that was totally feasible. Any proof to your statement? Very encouraging tho.

I don’t know if the game was made in Unity or not, there is nothing in the game that would indicate that it was or was not. I could open up the file and take a look at the executable headers. It’s very easy to determine a game made in Unity on iOS.

That said, there is nothing in the game that indicates it is so intricate that it could not be easily whipped up in Unity. I know that Disney Mobile has Unity, but I do not know if they used it for this title. Wouldn’t be hard too find out, drop a line to some of the people at Disney Mobile that worked on the game and ask them.

You are easily impressed.

People are easily confused and make laughable statements at times. Maybe if they had been talking about the early GameMaker engine I would agree.

Not sure.

You are not so impressed by the physics AND the incorporation of the illusion of water/fluid? The little things, beyond the lack of any noticeable drop in frame rate no matter how much water is in scene: the visual refraction of light thru the fluid + the thinning of water drops relative to speed. All in all I think it is a brilliant little game.

I am not dying to know if it was built in Unity but if it were confirmed, that would be cool.

I would not expect anything less from a AAA professional development team with a full life-cycle budget that is probably somewhere North of $3M**.

** And that’s a pretty low estimate.

Hey mate,

I did manage to get something working, a bit rough though. I’ll post it up when I get a chance. I ended up getting thrown on to a very large project with little development time, so I havent been able to continue with it.

Wow. Any accurate guesstimation of the amount of people that would involve?

The Behind The Scenes video on YouTube showed at least a half-dozen team members, and that would have just been the immediate people involved.

Let’s say they took 6 months to create the game, but probably took 8. It was probably in pre-development for a good three months or more before anything was done. That probably involved a part-time producer and full-time game designer to create the pitch and design documents and get it green lit, which probably involved the discussion through at least a dozen meetings about financial projections, budget compilations, marketing and so forth.

There was probably at least one or two full-time QA staff through the entire life-cycle of the project, and then Disney’s own internal QA team and then any external QA. You can bet that Disney nursed that thing through the App Store every step of the way too.

Engineering, art, production, management, quality assurance, localization, advertising, marketing, branding, support, updates, bug fixes, release management. This doesn’t even include any kind of media buy. Don’t forget all of the cost-center ancillary activities too. Infrastructure, office, HR, administration, maintenance, internal support - when your computer hard drive dies, you nip down to the Fry’s Electronics or Best Buy and pick up a new drive for $100, when a programmer’s drive at BigCorp dies, the cost of the replacement hardware is incidental to the cost of procurement, installation, recovery, not to mention the opportunity cost of a programmer with a dead machine and the possibly lost work.

How much do you think it cost to produce a Behind the Scenes video for the game? I’ll wager more than the budget on most indie titles posted on this forum. Probably around $15K or $25K in amortized equipment cost, filming, editing, production, marketing, updating, opportunity cost, etc. Let’s say Disney did the behind the scenes video on a shoestring budget using an external contractor who brought their own skills, equipment and software with them. How much? If we are being generous, and the external contractor was allowed to do exactly what was needed and never had to talk to a manager or producer or be interrupted and do a re-take, they probably shot an afternoon or two of video, edited it together in a few days, handed it off to someone at Disney, we might get lucky and get out the door with the final video, sans any Disney involvement in posting it on YouTube and the management and promotion of that, for about $2,000.

I would say, at least, 30,000 to 40,000 man-hours of labour to get that thing out the door in the state it is in.

Until you’ve done this stuff, and sat down and run the numbers, you just don’t realise how much production can cost.

A certain cartoon video game title in summer of 2007 aimed at kids for PSP, DS, XBOX360 and PC had a team of about 60 direct staff and a budget of $30M that also took advantage of the $300M in advertising for the film tie-in at the time. Our goal (which we hit) was to get the game on the shelves two days before the film was released. Miss that day and we sink.

Wow.
All I can say is wow.

Thanks Justin.

1 Like

Ok, so I tweeted Tim FitzRandolph, he is the senoir game designer for Disney Mobile and asked…

he responded with…

So there you have it folks.

Justin can’t you just use the approach here (http://unifycommunity.com/wiki/index.php?title=MarchingSquares) to create the perimeter collision mesh so you can leverage unity’s built in physics engine?

I’ve implemented the pixel based collision method you mentioned but my requires physics objects to react with the new surface. My only question with the marching squares script is how to translate the voxel data points they are using on the wiki script:

float[,] data = {{0,0,0,0,0,0},{0,1,1,1,1,0},{0,0,0,1,1,0},{0,0,0,0,1,0},{0,1,0,1,1,0},{0,1,1,0,1,0},{0,1,1,1,1,0},{0,0,0,0,0,0},};

to the 2d data that I’m maintaining in the updated collision array. Anybody else try this?