Hi,
After giving up with Codea I reinstalled it again and am now trying to create a very basic game.
I want to create a maze with simple walls (lines) but I want sprites to collide with the maze walls.
How is this possible and do I have to create the maze by drawing line after line with coordinates or can I import an image of the maze I made in photoshop and use that?
Thanks, i’ve tried searching for that but not found it yet.
I’ll keep looking.
There are several ways you could do this. Three are:
@Ignatz made an excellent tool which finds the outline of an image and makes it into a polygon body, so that way you MAY be able to use an image of a maze with this, but I’m not sure how sophisticated this tool is with big images and complex images. The other way to do this is to create a image the size of the screen using parameters WIDTH and HEIGHT and set the vertices to this, this means you won’t have to use any scaling.
Thank you West, some good ideas there.
I particularly like the tiles idea, although I think that’s beyond my meagre skills at this moment.
It’s important you start of small and try to do stuff within your capabilities and build up otherwise you’ll likely get frustrated. Recognise that even getting simple programs up and running is way beyond the capabilities of most people with an iPad.
Planning is incredibly important as well. Have a clear idea in your head and try to break it down into smaller chunks to make them easier to tackle.
So for a very simple maze game you could start with drawing the maze on the screen. In this case lets store the information in an array (if you don’t know what an array is - look it up then try some simple examples of storing and retrieving information from within an array). To keep it simple lets start with a 5 by 5 array and store a number in each position. The number will tell us what tile is in that position, so lets say a 1 will contain a wall tile and 0 won’t (and therefore be the path). Planning ahead we could use the onscreen position of of our sprite to convert to the relevant location in the map array and check what tile is at that position - this will give us our collision detection.
OK to break it down into tasks
1)Define a 5 by 5 array in setup and fill with 1’s and 0’s to represent your map tiles
2)in the draw function add a loop which checks each location in the array in turn and displays a sprite on the screen at an appropriate position corresponding to the position in the array being examined.
To do this, you will need understanding of 3 concepts
1)arrays
2)loops
3)displaying sprites
Have a go and let us know how you get on
@Mene - my code to draw an outline round an object won’t work for a maze.
You can do it a couple of different ways. Both involve using an internal memory map to figure out where you can walk.
Here, you store your position on the map and compare it with a 2D table which has the walls stored, eg walls are 1’s and empty corridor is 0.
You can then store this table as part of the code. For an example of this, see the forum thread on RPGGenerator. That project uses tables which are included with the code.
Dynamic
Or, if you want a more dynamic map, you can draw your own map in a paint program, load it into Codea, and read it pixel by pixel, creating a table in memory with 0’s and 1’s.
The advantage of this approach is the walls don’t have to be in straight lines, you can have circular caves, etc.
In draw, you would figure out where you want to move to, then check your internal memory map. If that pixel is a 1 (wall), you can’t go there.
Thank you both.
I think the hard coded one is the way to go, I think I can understand how to store the data and draw it (will try it now) I dont understand how to use that with collision detection, maybe a few forum searches will help me with that.
@Mene - with collision detection, the simplest way is to divide your map into squares, eg 10 pixels per square, and when you move, you move from one square to another. Then your memory map will have a number for each square, and if you try to move to a square and its number is (say) 1, then you have collided with a wall.
I’m trying to do the basic code for a very small test maze right now.
What I ideally want is a maze with a sprite placed in a random outer position and gravity causes the sprite to drop to the bottom and the player has to rotate the ipad to cause change the direction of gravity so the sprite drops. it would be a timed game and it ends when you get to the center of the maze. Thats the plan anyway.
Sounds like a fun game!
This might be easiest using physics EDGE objects for each straight line in the Mae, then the collisions would be done for you.
If you need help designing a maze, I have an algorithm for you, also an algorithm to solve a maze.
Does ‘physics EDGE’ draw the line for you or do you have to double up on each wall, first defining the physics then again to actually draw it?
I think any algorithm would be over my head right now, I’m just trying to see if the basic game idea will work. (well, actually more like ‘am I capable of doing it’ lol)
I’ve done a few lines with EDGE to set the collision and Line to draw the maze but I cannot seem to understand how to make my sprite actually detect the collision with the wall.
Have tried searching the forums for sprite collision but I can’t seem to find the info I need.
Sorry to keep posting but I’ve been playing with this and seem to have collision working but my sprite’s y direction isn’t working right. Keeps flying off screen downwards and I don’t know why.
-- Maze Test
function setup()
displayMode(FULLSCREEN)
physics.body(EDGE,vec2(100,100),vec2(100,700)) --left test wall
physics.body(EDGE,vec2(100,700),vec2(700,700))
player=physics.body(CIRCLE,40)
player.x=WIDTH/2
player.y=HEIGHT/2
player.restitution=0.5
end
function draw()
background(40, 40, 50)
physics.body(EDGE,vec2(100,100),vec2(100,700)) --left wall
fill(0, 51, 255, 255)
strokeWidth(5)
line (100,100,100,700)
line (100,700,700,700)
player.x=player.x+Gravity.x*10
player.y=player.y+Gravity.y*10
sprite("Planet Cute:Star",player.x,player.y)
end
Here is a simple example. e1 is the edge, and c1 is the circle. The edge and circle do the collision detection. The sprite overlays the circle and gives the impression that the sprite is doing the collision. You can uncomment the ellipse command and comment the sprite command to see what’s happening with the collision. Instead of using EDGE, you could use POLYGON to draw the edges of the maze.
function setup()
e1=physics.body(EDGE,vec2(100,100),vec2(400,100))
c1=physics.body(CIRCLE,40)
c1.x=300
c1.y=600
c1.restitution=1
end
function draw()
background(40, 40, 50)
stroke(255)
strokeWidth(2)
noFill()
line(100,100,400,100)
--ellipse(c1.x,c1.y,80)
sprite("Planet Cute:Character Boy",c1.x,c1.y)
end
Here’s your code
EDIT: more corrections made
-- Maze Test
function setup()
displayMode(FULLSCREEN)
e1=physics.body(EDGE,vec2(100,100),vec2(100,700)) --left test wall
e2=physics.body(EDGE,vec2(100,100),vec2(700,100))
player=physics.body(CIRCLE,40)
player.x=WIDTH/2
player.y=HEIGHT
player.restitution=0.5
player.sleepingAllowed=false
end
function draw()
background(40, 40, 50)
fill(0, 51, 255, 255)
strokeWidth(5)
line (100,100,100,700)
line (100,100,700,100)
sprite("Planet Cute:Star",player.x,player.y)
end
@Mene - what I might do is this
Set up a 2D table with one cell for each square in your map grid.
Store 2 numbers in each cell, to tell Codea if the top and left of the cell are walls or not. (I’ll explain why just the top and left below). You could use 0=not wall(corridor) and 1=wall. You could combine the numbers in a kind of code, eg a value of 4 would mean top and left are walls, 2 means top is a wall, 1 means left is a wall, and 0 means neither are walls. All that combining does is make it easier to store all the information you need in one number.
Then loop through your table from top left to bottom right and look at each cell in turn. Every time you find a wall, create a physics EDGE that runs from one side of the cell to the other. You have to calculate the pixel values for the start and end of the wall.
When you get to the last row, always make the bottom side a wall. Similarly, for the last column, always make the right side a wall.
The reason for only looking at top and left is that if you do this and loop through all cells, you will actually end up looking at the bottom and right as well (because for example, the bottom of cell 1,1 is the top of cell 1,2, and the right of cell 1,1 is the left of cell 2,1. So as you work through the table, you will fill in all the walls. The only walls that won’t get done by this are the last row and column, so you need to do those specially.
If instead you stored all four wall values in each cell, and drew them all, then you would end up drawing all of them twice. This approach means you only ever look at each cell edge once, so you avoid doubling up on your walls.
Thank you dave!
Thank you Ignatz, sorry but even after reading that three times its so far over my head its in orbit. My fault, not yours. Even though I understand it in theory, knowing how to code it is a different thing.
I am currently stumped by a problem
If I try to use the tilting of the ipad to control the y axis on my sprite like player=player+gravity.y*10
Then it works fine but collision detection doesn’t work.
But if I try to use player.y=player.y+gravity10 then collision detection with my lines works fine BUT the sprites y axis plummets as it falls off the screen. Tilting doesnt affect it, yet the x axis works perfectly when I use player.x=player.x+gravity10.
Am I doing it wrong or is this a bug with codea and the y axis?