93
\$\begingroup\$

In my latest game I'm making, you can slice a 2D object arbitrarily, demonstrated in this gif:

enter image description here

You can continuously cut it into hundreds or thousands of pieces. This doesn't create a lot of lag, because they're always in a sleeping physics state, but there's a problem when you cause them to move.

I'm not really sure how to deal with making it so there's not so much rubble from cutting something apart. I don't really want to delete them after a certain amount of time; I don't like how, if you go back to something you cut up after a while, it randomly disappeared.

How can I clean up excessive player-created rubble?

\$\endgroup\$
6
  • 17
    \$\begingroup\$ It's not really clear from your question what you actually want. You say you want to "clean up the rubble", but at the same time you say you don't want rubble to disappear after a while. \$\endgroup\$
    – Philipp
    Jun 26, 2017 at 10:41
  • 10
    \$\begingroup\$ Tiny & Big would destroy the smaller pieces. Pretty sure the larger pieces stayed around for the level, but I don't fully remember it. Here's an example: youtu.be/236ly0ApPqg?t=177 \$\endgroup\$
    – TyCobb
    Jun 26, 2017 at 19:44
  • 2
    \$\begingroup\$ Stuff that's out of range can be removed and replaced when you come back to it. \$\endgroup\$ Jun 27, 2017 at 3:33
  • 3
    \$\begingroup\$ Just my little opinion, but set a minimum object size to be effected by the cut action. If it's hard to single out the piece you're cutting, then you can't cut it. (Just aside, nice game dynamics, this one's definitely got legs!) \$\endgroup\$
    – AJFaraday
    Jun 27, 2017 at 15:05
  • 12
    \$\begingroup\$ I'd like to state I take no credit for making the cutting mechanic since it's a free asset I found on github. Been using the example it gives you for an idea on how to use it to cut objects. (player was coded by me and so will everything else in the game. \$\endgroup\$ Jun 27, 2017 at 18:02

3 Answers 3

72
\$\begingroup\$

First of all, that game mechanic looks like it could be super fun, so congrats on thinking of it! Here are two simple solutions that could be used independently or together to solve this particular issue:

Remove Very Small Pieces

There isn't much of a point to keeping around tiny pieces of collision that really won't impede the player or have any real effect on the environment. Calculating the extra collision logic simply isn't worth it, so either remove these pieces or remove collision on them.

Limit Player Cuts

Having unlimited cuts could potentially make a lot of your puzzles really simple if you can just slice every impeding object into a pile of mush. Give the player only a few cuts to play with (or make it slowly recharge over time) and you'll likely find that it makes your puzzles more challenging in addition to eliminating the pains of dealing with collision on a thousand fragments.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Think I'll do the first one since I'm not planning to make any kind of puzzle game. \$\endgroup\$ Jun 26, 2017 at 18:31
  • 37
    \$\begingroup\$ Micheal Bay it up when the small pieces disappear too. That's not a log, it's sawdust. Or exploding sawdust. why not?! \$\endgroup\$
    – corsiKa
    Jun 27, 2017 at 2:44
  • 26
    \$\begingroup\$ @corsiKa If you add some flaming effects to the cutting motion, your could make the cuts leave scorch marks on the contact points, with a certain width. If the object is so small that it is fully "scorched", it could burst in flames and burn away in a few moments. \$\endgroup\$
    – T. Sar
    Jun 27, 2017 at 22:10
155
\$\begingroup\$

Figure out your bottleneck

A few hundred moving objects should not be a problem. However, a few hundred colliding objects might be. It will take some testing, yet I believe the bottleneck you have are the collision.

By the way, about how many objects are we talking? What is the platform? A hundred objects for a mobile game is not the same as a hundred for a web game or a hundred objects for a desktop game.

Test the same game but with collisions between the cut objects disabled, and see if you get it to lag on similar amounts of objects. If that is the case, it means that the sheer amount of objects is the cause of trouble; otherwise, the collisions are the problem.

This will inform your decision on what you will do to improve performance. Not all of the ideas below will apply, and you will need testing anyway.


I will not talk about optimizing for a large ammount of objects far from the player, as the trouble seems to come when interacting with the objects.

there's a problem when you cause them to move.

If the problem happens when interacting with the objects, it is unclear how removing not visible objects will solve it... yet, I'll assume it might help.

I'll just say that if objects far from the player are a problem, you could start by having smaller levels, or look into dividing the game in chunks that you can load and offload depending on where the player is going.


Out of bounds

I believe that when it comes to cleaning up rubble, the first thing to have is to remove objects that are out of bounds. For example, the piece that fell to a pit. If there is no way the player should be able to get there to see it, there is no reason to keep it around.

I will come back to this.


Make it more realistic (part 1)

When you cut wood with a saw, axe or similar tool, there will be lost material (to sawdust, shavings, etc). Even if you cut with a laser, the laser will burn some wood. In addition, for thing that are not wood there will usually be deformation around the cut, crumbling, etc.

What I am saying is that the cut is not perfect, and some material will be lost. You can model that in your game. That magic cutting red thingy has thickness. Remove that thickness from the objects (add particle effects if you feel too guilty).

This means that you will not be able to cut anything that is smaller than that thickness, in fact, attempting to do it will remove it from the game. That is good! It means that there is an upper bound the amount of rubble that there will be, and there is mechanically sound way to clean it up in game.


Change gears for small objects

This will work better if collisions are the problem.

Once an object is too small, the details of the different angles it has is less relevant. You could change to a less accurate collision mechanic. For example, you could use circle colliders.

You may treat even smaller objects without collision among themselves; only consider collision between them and agent objects (such as the player’s avatar or AI controlled characters).

Finally, very small objects could just turn into dust (particle effects).


Make it more realistic (part 2)

This will work better if collisions are the problem.

Material deforms and breaks under pressure. If you end up with long objects with very little thickness, break them down into smaller objects so they can take advantage of the solution above.

We can pretend that it had too little thickness that it crumbles and breaks when you hit it.


Merge objects

This will work better if the number of objects are the problem.

A common trick that many games use to deal with large amounts of drop that might hurt performance is to bundle drops together.

You could try something similar for small objects that are nearby each other. Have them become a single object. However, I do not mean to stick the pieces together. I mean to create a single object to handle their physics; you can still represent the individual pieces that made up the object, perhaps using techniques akin to particle effects.


Make it more realistic (part 3)

Have you heard of wind? There is wind in the real world.

Use wind to push small objects away.

I know it can sound counter intuitive, because it means small objects do not get to rest, at least not right away. Read below before you make your judgement.

You can use wind to push away small object before – or as soon as – they start to pile up. Which will work better if you are using optimizations for small objects (such are combining them or removing collisions among them).

Furthermore, if you can use wind to push items to pits or otherwise out of bounds, you can use as an excuse to remove the items. I told you I was going to go back to that. Even if you don’t, it can serve as an excuse to remove small objects that are too far away from the player, just pretend wind got rid of them while the player wasn’t looking.

You can remove some objects while the player is not looking, you have my blessing.

In addition to that, you now have an excuse to add wind, which you can add wind as part of other mechanics or obstacles of the game. You could even add into the narrative the spirit of wind that tries to keep things clean, if you are so inclined.

Note: You do not necessarily have to trigger wind when there is rubble to clean (although that would work), you probably can have wind happen at random intervals.


Beavers!

Some annoying beaver comes along and steal your wood!

Now you have an enemy type!

In addition, of course, they remove wood while you were not looking. You can even design it so you return to see one beaver running away with a piece of wood where used to be a pile. That would make for a memorable moment, will explain why the wood disappeared and will solve some of the performance problems you face, all at once.


It is all tradeoffs

There are limitations of the platform or the tools you have chosen, even the time and budget you have to develop the game is a limitation. You cannot make a perfect simulation of reality, yet. Nobody can.

Every developer works within the limitations that their target platform and the tools they had at the time imposed on them, and the best games had to do tradeoffs to make the game fun and engaging... even if that means less realism, in fact, often times they are fun and engaging because they are not realistic.

Let creativity come from those limitations.

Although, you can also make your game more realistic, by picking the parts of reality that are convenient for your development. Consider that sometimes removing objects that are away from the player is the part of the cost of making a fun game.

\$\endgroup\$
2
  • 36
    \$\begingroup\$ This post is the definitive answer to the problem of rubble overflow. You have provided an exhaustive summary of techniques, while also clearly showcasing the need for being creative and picking solutions that work for your circumstances, while also showing how mechanics and narrative can flow together. I just wanted to say that I have trouble expressing how I am impressed. \$\endgroup\$
    – Dragomok
    Jun 26, 2017 at 14:42
  • 12
    \$\begingroup\$ Attempting to cut an object smaller than the beam width need not cause the object to disappear altogether but might instead yield one smaller object. What's important is that the number of objects can only be increased if the cut object exceeds the beam width. \$\endgroup\$
    – supercat
    Jun 26, 2017 at 15:15
1
\$\begingroup\$

The world is discrete. You can't render an object smaller than a pixel, so don't allow such objects to exist. (This is similar to some of the realism points made by Theraot.)

Indeed, you might get this for free: the player specifies their cut line as essentially a discretized line on the screen. The effect of the cut is to divide every object into the sub-objects consisting, respectively, of the pixels on or below that line, and the pixels strictly above it. A one-pixel object can't possibly be both above and below the line, so it can't be cut by this algorithm.

If cutting all the cuttables into individual pixels would still leave you with too many objects to track, a larger minimum size might still work.

Or just don't worry about it. If the player is prepared to spend a long time cutting objects into dust, they're obviously not in a hurry so they can deal with the lag they caused. ;-)

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .