Why You Should Not Use Solids, and What To Do Instead

It seems almost everyone is using "solid" when they first start out, and end up posting questions asking why some aspect of their game isn't working the way it should.

It is indeed common among many developers' early games, and the reason is generally because it handles collision events for you moderately well when you don't have a lot of complicated platformer action going on (and because Prof Overmars' examples generally use it). However, though many developers use it, they generally don't know how it actually works and therefore usually run into problems with their platformers' (or even maze games') mechanics that they can't solve.

Solid, in case you don't already know, is controlled by the little checkbox in the object properties next to visible (you can, however, control it through code by using the variable solid) Go to one of your objects which is solid, double click it, find the solid checkbox, and uncheck it now. Why should you do this? Because of wizardry.

(no, not really...)

So you want to know how solid really works? Well, it's pretty simple actually. When actions or code is placed in a collision event for a solid object, the two objects cannot overlap. So if you have non-solid objPlayer, and solid objBlock, and you add a collision event in objPlayer for objBlock, then whenever objPlayer bumps into objBlock via "actual" motion (think hspeed and vspeed) it will be kicked back to the last hopefully non-colliding position. Same thing with the block; if it happened to be moving and the player was stationary, the block still could not move "into" the player.

Now you may be wondering why I said, "hopefully" above. Well, if your object is moving and hits a solid object, it will be moved out of it. However, if the object starts there or gets placed overlapping the solid object, suddenly, it can't move at all. And it's not really your fault (aside from using solid) because you didn't tell GM to do this; you just told GM to make the wall solid.

Actually, that is the very reason why you should get rid of it. Because you aren't in control. What if at one point you want the object to go through walls? No good with solid; as long as there's any action in the collision event, the solid object will be un-passable. What if you have certain walls that the player can go through after collecting a certain powerup (think super mario 64 after getting the invisibility cap)? You *could* turn off solid for those walls in particular when the player has the powerup, but that turns off their solidity for every other object as well. In addition to that, moving solid walls can also cause problems.

If you turn solid off like good boys and girls, all you have to do to keep a functional game is to program the collisions yourself. Take the more difficult path and collect the treasure at the end. When working without solid, you can include conditionals, etc. in your collisions, without the omnipresent don't-touch-the-wall-ever-or-you-could-get-stuck-mwahaha stuff. For a top-down maze game, you might use this code in the step event of the player:

Code:


if (OkToHitWalls)
{
  if (place_meeting(x+hspeed,y,objBlock1)) hspeed=0;
  if (place_meeting(x,y+vspeed,objBlock1)) vspeed=0;
}


Notice this copies a collision event exactly (better, in fact, because it checks horizontally and vertically separately), but we didn't have to use solid or a collision event at all. This also allows us to choose exactly when to execute collision events, but that'll be more useful as you get into more complicated projects.

One last thing that I feel I should mention. You can't use the function place_free() when you aren't using solid objects. Note, if you use actions, place_free() is equivalent to this one:

If a position is collision free

This is a small price to pay, as I will demonstrate, but I want to get it out there now that place_free()/the above action only returns true when there's a collision with a solid object. If you never use solid, place_free() never returns true.

Anyways, the way to get around this small roadblock is by using place_meeting(), as I did in the code above. Action form:

If there is an object at a position

Anyways, place_meeting(), or the action shown above, is an alternate form of place_free() in that it also requires you to tell it the object to check for collisions with. But that means, if you have 15 different wall objects you have to use this function 15 different times, right? Right?!

Um, no. When have I ever steered you down such an annoying path? In fact, with a little creativity, you only have to use it once. The way you do this, is to make a new object, and call it objBlockParent.

You guessed it, this object will in fact be a dummy object with no code of its own, only to be used as the parent object of all block objects. Okay, maybe you didn't guess that...or maybe you did. I don't know.

Once you've done that, you just plug that new object into place_meeting() as the final (third) argument (or into the action next to "object:") and it checks for all objects which have objBlockParent as their parent. That is, a single function/action checks every single block object. Yay. The code example above could replace e.g. objBlock1 with objBlockParent and work in just this way.


You've just written your very own custom, functional wall collision code, and now you don't have to worry that solid will mess you up later. Now that you have turned off solid, you can even make things like one-way platforms. I can't possibly know how far you are in your current project, so it may or may not be feasible to go through and revamp your current wall collision engine to stop using solid. But be sure to remember this for future games.

With any luck, this article will reduce the amount of solid-related problems that developers had. It's very difficult to explain to users and convince them of why they need to turn off solid when it means they usually have to revamp their entire mechanics base; reading this, developers will hopefully start not using solid from the beginning of their game.

-Written By gmXpert2000 on the GMC forums. Slightly edited by js1210 to fit the format of this forum and make a little more sense.

In short, only use solids with ground and wall objects.

In short...don't use solids!

woh,thats long

I haven't used solids in a long time

i use solids bareley

i use to use them all the time! or at least i did when i was still makeing games

The reason people use solid when they start is cus THE **** TUTORIAL TELLS THEM TO!

You didn't read the thing did you?
He just said the examples were BAD!

sorry, example is not equal to tutorial in my brain

Then what do you do with walls and stuff that should be solids? You'll have to script everything for every object.
Never use moving solids.
Make solids do nothing.

There's a reason..
If you used a sprite that had bits sticking out every where (flames from an exhaust, spikes, clothing, etc.), they have a good chance of getting caught inside a solid when you move right next to it!

So you use a mask or bounding box.

duuuuuuuuuuuuuuh I did not know that....
How do you set them up, it would be quiet useful.