Scratch

Lucario621 wrote:

Hmm...well could you have the detection like in Archknight's Adventure? Because there it was pretty good. Still not perfect, but it was better.

You don't understand... He's using array based detection in order to make the size of his SSBB game smaller. He isn't asking for a new kind of sensing, he is asking how to improve this one.

Btw, I don't have a clue Archmage 

Dan01 wrote:

Lucario621 wrote:

Hmm...well could you have the detection like in Archknight's Adventure? Because there it was pretty good. Still not perfect, but it was better.

You don't understand... He's using array based detection in order to make the size of his SSBB game smaller. He isn't asking for a new kind of sensing, he is asking how to improve this one.

Btw, I don't have a clue Archmage 

To me, I care more about quality than file size 

Lucario621 wrote:

Also, far as I know, nobody but you and S65 can understand this XD. Anyway It might have a smaller file size but the movement isn't as good and stuff......*barf*......the movement made me barf you sicko!

But also, I don't think its reasonable to have over 100 sprites in the end.

The movement can be changed, easily. What is important is the hit detection. This is how most game developers make their games, so doing things this way is far superior to using large drawn sprites.

Games that use this kind of tile based system:
-All 2d mario games
-All non 3D zelda games
-Heli attack 3
-All 2d final fantesy games
-pokemon games
the list goes on and on...

The movement is bad partly because of lag and partly because the number values involved in the movement need to be changed. But, using this is the ONLY way to make a perfect clone of a game like the original mario bros. There is no way to make an accurate clone using an art based method.

Last edited by archmage (2008-12-20 15:02:20)

The best tutorial on tile based games on the net is located @ http://www.tonypa.pri.ee/tbw/

It is in actionscript and it cannot be perfectly translated into scratch unfortunately.

Here is a tutorial of A* path finding.
http://www.policyalmanac.org/games/aStarTutorial.htm

However, I doubt that scratch could even run it quickly enough.

As for using tiles in scratch, there is a small tut by addzero on this thread.
http://scratch.mit.edu/forums/viewtopic.php?id=11632

It would be really ideal for a zelda type game.

Also I made a collision type thing. But if you see it I know what your going to say: it uses the sensor blocks. True. but what I did is Player 1 stamps the stage based on the list (like AddZero was talking about storing in lists) and then player one can move in the stage. 1 sprite to make the stage and move through the stage, and 4 sprites for sensors to tell if P1 is touching the walls. Different, but still nice.

http://scratch.mit.edu/projects/JSOlabs/358269 - the level editor for all the following projects

http://scratch.mit.edu/projects/JSOlabs/358270 - my first (kind of silly) attempt.

The movement is sluggish but you can't move through walls, floors, and ceilings 
For the movement it uses a "previous x" and "previous y"...

I made a new, way better one:

http://scratch.mit.edu/projects/JSOlabs/358371

It has x and y velocity and is lighter.

JSO wrote:

I made a third, probably the last one:

http://scratch.mit.edu/projects/JSOlabs/35965177

It's based upon .2 but I fixed some glitches. It works fine for me.
Archmage, do you mind if I turn this into a create-your-game project?

Do what you want to do. You should have to ask for my permission