game-editor.com

Update!

For collisions on sides of blocks, use this script:
Actor>Collision>left or right side>block>
int j=yvelocity;
PhysicalResponse(MOVE_EVENT_ACTOR_ONLY, USE_CALCULATED_MASS, 1, 1, 0, 1);
yvelocity=j;

The collision kills all motion then j returns the vertical motion. Its awesome!



Anything is possible. It's 99% there.

There are some rules to how you can draw your levels, between clones and tiles, and there are still a couple of minor glitches, but the player doesn't go thru platforms anymore, and he doesn't get shoved off the edge by a physical response.

You can download the GED file here:
viewtopic.php?f=6&t=5833

Note: You can drag the platforms (cloned ones, not tiled ones) with your mouse, to test arrangements, if you like.

And of course, DST just can't release anything without music!


The posts below explain how its done. Now you might think its too complicated, but ask yourself this: In 1984, when Super Mario Bros. first came out on the NES, do you think it was made by one guy? Do you think that guy was making his first or second game?

No. Mario was made by a highly paid team of computer experts, some of the best of their day, on par with anyone working for NASA or IBM. In comparison, what I'm doing here is very, very simple.

P.S. Don't be scared. This post is long but after i come back from work, i will post the GED file. You can simply build your game off that, if you don't want to learn how it all works.

pretty amazing I can't wait until you release the GED file

Ok here's how it works: A physical response pushes you up out of the platform if you land in it, like this:




The problem here is that if you land on the edge, away from it also happens to be at an angle, because it calculates from the center of the block. This will frustrate your player as he makes perfect landings but dies anyway.


The shape of your actor is also important. If the actor changes shape while moving, the physical response changes too. This not only confuses the program as to what to do, but if your view is following your player, it will make the screen shake badly, and give the player a headache. (like the old black and white gameboy used to do! It was very hard to see what was happening).

The shake is only a couple of pixels, but its enough to fry the graphics as the screen vibrates. It also causes massive problems with collision because the physical response goes haywire constantly trying to recalculate.


See the next post.

Another problem with physical response is that most people use it on ANY side of the block. This isn't good, because (as you've all seen from the advice people give) we usually set the player energy to 0 on hitting the block (so he won't bounce). But this also means that when a player hits the SIDE of a wall in midair, he 'sticks' to the wall, instead of falling down at normal gravity speed.



Now look at the purple box; this is the shape of my player. Because the leg hits inside the platform (horizontally), the platform shoves it straight back up, instead of to the side.

And the reason for the long legs, as you can see in the second frame, is as a player falls into the platform, we want to make sure that no part hits on the edge and causes him to bounce to the side. It is very unlikely that your player could be moving fast enough to make it past the 'legs' before the collision takes place.

Now the top and sides aren't a big deal, because when hitting the bottom of a platform, gravity is our friend.

And when hitting the sides of the platform, gravity doesn't really affect us. Now why is the top smaller than the bottom, you ask?

This makes sure that on Player>collision>top side of platform won't happen when walking toward a block. If it does, your player would be 'climbing' the blocks, which is not what Mario does. The player 'legs' must get small before the top of the block size. In addition, if you have the 'sticky' problem from the beginning of this post reply, AND you have the ability to collide with the top of a block while sticking to the side of it, CANJUMP is reenabled, which basically allows a player to jump up walls. This might be nice if you want a wall jump, but Mario doesn't wall jump. We probably don't want to either.

In the next post: I don't want my player to be a purple block!

What we'll do is have a player1 (who's a purple block). Player1 gets all collisions, keydown events, etc.
We have another player that i like to call VISUAL. Visual is a child of player1, so he goes wherever player one goes.
And VISUAL contains all the animations. Now we can simply use animation commands in player1 as normal, only instead of 'event actor' we say 'visual'.

However, i prefer to use a draw actor for visual that sets his animation based on whatever player1 is doing. This draw actor script can get complex, but at the same time it is simpler because ALL of the animation commands are in ONE script editor.

This makes it sooooo much easier to change things and hunt down errors.

But first, we need player1 to have good collisions!

Here is the script involved in my collision demo: its not really that complicated. It consists of four collisions, two draw actor events, three keydowns, and one keyup.

The first things to do for player 1 are to add variables to him. Do NOT use solid values in your events, and i'll show you why.

On player1>create actor i set a number of variables (global integers) for player1.

Code: Select all

canjump=0;
jump=16;
speed=4;
gravity=1;
canright=1;
canleft=1;


Now on player>keydown>keyright we do this:(Repeat YES)

Code: Select all

x+=speed*canright;
canleft=1;

and on player>keydown>keyleft we do the opposite:

Code: Select all

x-=speed*canleft;
canright=1;

Now on player1>collision>left side of block: (Repeat YES)

Code: Select all

int j=yvelocity;
PhysicalResponse(MOVE_EVENT_ACTOR_ONLY, USE_CALCULATED_MASS, 1, 1, 0, 1);
yvelocity=j;

Now we used speed for a reason! what happens when you hold down the B button? Mario RUNS! so all we have to do to change his speed is to change the speed variable when the run key is held. We can also easily adjust his speed througout the game, for instance if he gets wings or is underwater.

Now for player1 gravity, its also very simple:
player1>draw actor:

Code: Select all

yvelocity+=gravity;

And on keydown (jumpkey):(Repeat NO)

Code: Select all

yvelocity-=jump*canjump;
canjump=0;

Now player 1 will take off, and canjump becoming 0 happens AFTER his yvelocity becomes -. This prevents him from moonwalking. On player 1>collision with top side of block, or ground: (Repeat YES)

Code: Select all

if (yvelocity>0){
PhysicalResponse(MOVE_EVENT_ACTOR_ONLY, USE_CALCULATED_MASS, 1, 1, 0, 1);
canjump=1;
}


This is good because it means player 1 will only have a response with the top of a block if he is moving downward. When moving upward nothing happens with the top of the block.

So notice too, we can easily change his jump amount whenever we want; Like when he gets boots or something. We can also change his gravity easily too, once again, in case he is underwater or in space.

Player 1>draw actor

Code: Select all

if (yvelocity<14){yvelocity+=gravity;} //limiting gravity helps avoid errors.


One final collision and we've got him moving pretty well;
player1>collision>bottom side of block (repeat NO)

Code: Select all

if (canjump==0){
yvelocity-=yvelocity;                }


Once again we've avoided using physical response; this is important because once again, we don't want him to stick to the block, and if he bounces off the block, the bounce can push him thru other objects, which is bad. We simply make him fall when hitting a block with his head.

So our collision is ALMOST perfect. Now we have other issues to deal with. First off, we can't touch the same block from two sides at once. We also don't want to touch more than two blocks at once. This would be bad, because we'll have conflicting commands. This sounds hard but its not hard at all.

IF you tile your actors, and you use the same tile for the floor as you do for the wall, and mario walks into a corner, he is touching both the top of the block and the side of the block at the same time. We need to avoid this.

So there are rules to how you can place your blocks, but the rules are very simple.

The rule is that walls must be a different clone than the floor. You can still tile your floor, but when you make the wall, you want to use a CLONE of the floor. A clone is, in this case considered a separate actor.

But the wall itself is tiled.

Each color here represents a different clone. They are tiled, but as you can see, our player cannot touch two sides of the same clone at once. He also cannot fall down the side and hit multiple clones on the way down. Both rules have been satisfied. Now when you're making breakable blocks, you can run into trouble on the vertical stacks; as he will, when he is halfway between two blocks, be touching two separate clones at once. While this works for a single block laying on the ground, or for stairs, it is not good for walls.

I'm still working on that one.

East and West
DST is the Best



+1 Point

This is very easy to understand thank you lots!
(+1 point)

A simple thing to avoid the player stick in midair when colliding with platform if you use physical response, add this code for player>collision event>bottom side of platform>script editor :

Code: Select all

yvelocity+=1;
//if your player DrawActor yvelocity is 1

this is good for newbie who dont understand DST code well.when you understand enough,you should use DST code

Bee-Ant wrote:A simple thing to avoid the player stick in midair when colliding with platform if you use physical response, add this code for player>collision event>bottom side of platform>script editor :

Code: Select all

yvelocity+=1;
//if your player DrawActor yvelocity is 1

this is good for newbie who dont understand DST code well.when you understand enough,you should use DST code

BLAH BLAH BLAH!!

When are u going to post the GED game

paperboy321 wrote:When are u going to post the GED game

huh what?

paperboy321 wrote:When are u going to post the GED game

until DST publishes the game data you'll have to follow the instructions above, I'm afraid.

Bad news folks! DST's account has been deleted, he himself cannot post anything as "DST" anymore...

how do you know?
can't makslane fix that?
where is he at the moment?
how long has this been?

(one question at a time )
well, DST, join theibverse then, your bro DXT has paid us a visit already ^^ (if he really exists XD)