I had help from a friend who said that the following blocks would just "work". Since it didn't, he has no idea what is the problem. It's essentially a maze game with a random maze generator built in. The things i can't seem to figure out are movement controls, a stopwatch, and whenever i click start, the app locks up and closes right after. Plz help and thanks!
I should also include that I don't know how to do the following:
Make the maze have an entrance and an exit.
Make the sprite and exit image appear on the correct locations.
FROM_THE_SCREEN_TO_THE_RING_TO_THE_PEN_TO_THE_KING.aia (5.2 MB)
Here's the aia file if perhaps the problem is somewhere else.
Couldn't your friend who helped you tell about these?
He doesn't seem to know how to make those.
This is your first error, in the Game Screen.
The TinyDB Get has to be done in the Screen Initialize event, not in the global init.
(Corrected)
Look at your Canvas in the Game Screen, in the upper left corner.
Kinda small, huh? What would be a better Height and Width for it?
Also look at the two Sprites, their locations and their sizes.
Finally, look at
SInce your Canvas is so small, you are immediately colliding with the exit.
Okay, so i increased the size of the canvas, but as for the TinyDB error, it still manages to get a sprite from the first screen, so I'll count that as working. But now I'm stuck at making collision so that the player can't go through maze wall. and also starting positions for the player and the exit sprite.
I haven't figured out what your friend was thinking of for movement controls and boundaries in his code.
However, if I were to do a maze game on my own, I would think of the maze as a rectangular arrangement of cells in rows and columns, like a chess board or a spreadsheet, with each cell having a name that tells you its position, like A1 for the upper left corner of a spreadsheet.
To translate cell names to their positions on the Canvas, add 2 to the number of rows and to the number of columns, to leave room around the maze to see the outer walls and gates.
Then it's just some math to get the pixels (x,y) of each dell from the row and column numbers.
For mapping out interior walls, set up 4 dictionaries (left, right, up,down) with cell names (A1,B1,...) as keys and the names of the destinations you would arrive at if you attempted to travel one cell in that direction. So up('A1') = 'A1', because you can't go up from A1, but right('A1') = 'B1' if there is no wall between A1 and B1.
With this approach, you don't need any sprite collision event, just an if/then test if you reached the final cell.
The basic game play would be to control the player sprite with 4 buttons for the 4 directions, and update a global variable with the new cell destination after each move (in addition to moving the player sprite to the x,y of the new cell name.
No, i have nor coded this in blocks.