Simple maze game tutorial?

Has anyone done a simple maze game, maybe even a tutorial? I'm looking for something I can wrap my head around that would look like one screen of the original Zelda.

1. Grid based movement

2. 32x32 sprites

3. collision detection with walls

4. collision detection with enemy

5. alert message

Everyone seems to be designing platform games, but I've always wanted to do a tile-based game like early Zelda or Ultima. Any help appreciated. Thanks!

you can start with that

gridMovement.capx

you can start with that

http://dl.dropbox.com/u/23551572/C2/gridMovement.capx

This is a great example to start with ! We can just refer and use the concept in our games! Thanks Yann! <img src="smileys/smiley4.gif" border="0" align="middle">

you can start with that

http://dl.dropbox.com/u/23551572/C2/gridMovement.capx

This is very helpful, but also puzzling. It looks like movement is a 360 degree vector with angles. Also it looks like the movement is not in fixed jumps, and sometimes I overshoot a corner when moving.

I'm trying to wrap my head around this. Most of my game programming was on 8-bit machines with rows and columns! This is rocket science!

Anyway, thanks for this sample and I'll keep digging a bit more. If this was music software, I'd think this was a tracker! <img src="smileys/smiley36.gif" border="0" align="middle">

Bob Thulfram

What do you mean by overshoot a corner when moving? You overlap a wall? If you do I'd like to see a screenshot 'cause in my mind that's pretty unlikely.

Also what do you mean by "360 degree vector with angles" ?

This example works by first moving a detector in the direction given by th input key. The cos and sin gives the proper direction to multiply by the length of the cell. (event 5)

And if the detector doesn't overlap a wall, the move is checked we can initiate it(event 6 does the opposite)

The move itself works by adding a little bit each tick. dt ensure that this little bit is always proportionnal to the time between two frame, thus making it frame rate independant (event7)

The only problem is that it's not a whole number. But we have to stop the movement after 32 px exactly, so once I cross the number I just substract the difference to get 32px exactly (event8)

Bob Thulfram

What do you mean by overshoot a corner when moving? You overlap a wall? If you do I'd like to see a screenshot 'cause in my mind that's pretty unlikely.

Also what do you mean by "360 degree vector with angles" ?

Sorry for not being clear. What I'm trying to say is that when I press an arrow key, I want the red square to move 32 pixels and then stop, wait, and then see if the same arrow key is still being pressed. I want to do this so I move square by square, and make it easy to change direction while keeping on the grid. I've noticed that if I hold down the key too long, the red square can overshoot the right or left turn I wanted to make. Maybe it is just a subtle timing issue.

I'll think about it a bit more and play with the code. I want to emphasize that this is really helpful code and should be the first part of a tutorial on how to make maze games (I haven't found one yet).

What also fascinates me is that a sprite isn't constricted to move in one of 8 directions. But I guess the grid restricts me to one of four directions, right.

Again, thanks, Yann, and I'm very grateful you took the time to share a code sample that illuminates the unique way that Construct works.

Oh you mean something like that?

gridMovement.capx

Oh you mean something like that?

http://dl.dropbox.com/u/23551572/C2/gridMovement.capx

E-X-A-C-T-L-Y!!!

Perfect, thank you, hooray!