greetz to the community!
here comz my tiny question, might be easy for thee:
In a fantastic pac-man-ish (or Wizard of Wor-ish ? :)) 2D terrain would my sprites like to move smoothly among and along walls. Still easy to imagine, yea? But the code for it is not so sudden to come into my mind. (dont waste time on possible causes now :D )
The walls and the moving sprites are of all the same rectangle size.
-should the sprites get a neighbouring pixel /or check for sprite collision/ from all 4 directions to determine which is the free path?
-should the entire level be placed in an array to check for fine ways?
-should I give up game programming 4ever? :(
btw. using python, pygame and a sleepy, lazy operator ... zzzzz..zzz
2D "pathfinding" at prehistoric levels
I ended up using an array to store the individual tiles I wanted to make up the maze. The path that you could move (if I remember right) had a value of 0 and walls had some other values. I ended up having the wall tiles (8*8) drawn half the size of a tile so that when the maze is drawn it looks like you have two tiles worth of clear space to move. I think I checked collisions against the array but kept track of x,y co-ordinates as well. The rest was a matter of tweaking positions so that the sprites appeared centered and moved at the rate that I wanted them to.
Whatever way ends up working for you and builds up your skills is the correct way. Just have at it, learn what works and what doesn't, and refine it as you go.
Whatever way ends up working for you and builds up your skills is the correct way. Just have at it, learn what works and what doesn't, and refine it as you go.
If your using equally sized tiles to create an isometric (flat-ish) world and you want to have an easy place to start off making a game use an array to manage the world. It is not massively flexible but pacman is not coo complex for such an approach. I did something very similar to build my first game bomberman!. The best part about using an array is the ease with which you can draw the world using two for loop.
I cant find a screenshot of how I did things :( but to make up for it here is some psuedocode, well I say pseudo code its snippets of visual basic 6 :p
I can't garuntee its flawlessly written because I wrote it when I was 13 so apologise for spelling mistakes.
The basic premise is that you create a two dimensional array of positions and then cycle through the array changing the values of the arrays cells in order to define what is where in the world. The beauty of it is in rendering becuase everything is the same size theres a neat trick you can use!
This is not something to copy and paste obviously but just shows you that you can tamper with the grid all you like before you start. Here is the sweet part, take notice of the value "GridSize" (belowin the drawing pesudo code) that can be the size of your sprites. If you make it the size of your sprites then do another for loop and multiply the position of the image with the number of times you have gone through both loops (making up x and y values) you can create a square or rectangular grid. You can use different integer values in the array to make different textures be drawn onto your grid.
Then you can use If statements to test if a player can move in a direction, because the outside layer is always made impassible (I used the integer value of 2 to represent a solid block) you can bypass the worry of having an exception because you had to test if the player could move down beyond the scope of the array. Obviously you can draw goodies and ghosts over the sprites making the terrain (I used a sperate array for goodies back in the day but a linked list is definetely the most efficient method you could try). If your new to programming games its a great place to start!
Make sure you store your players seperate from the grids values, you can draw them overlaying it afterward. If you make them part of the grid then you can't smooth over the animation when they jump between cells and you also have the trouble that you cant have them move over varying tiles with different terrain!
P.S. Apologise for my example code using such an old language I hope you can understand it! (the key thing to grasp is the arrays and use of for loops to draw) :p
I cant find a screenshot of how I did things :( but to make up for it here is some psuedocode, well I say pseudo code its snippets of visual basic 6 :p
I can't garuntee its flawlessly written because I wrote it when I was 13 so apologise for spelling mistakes.
The basic premise is that you create a two dimensional array of positions and then cycle through the array changing the values of the arrays cells in order to define what is where in the world. The beauty of it is in rendering becuase everything is the same size theres a neat trick you can use!
Private Sub Level1()'Set level WallsReDim LevelWalls(1 To 19, 1 To 19) As Byte'Set Level Walls horizontal edgesFor SetWalls1 = 1 To 19 LevelWalls(SetWalls1, 1) = 2Next SetWalls1For SetWalls2 = 1 To 19 LevelWalls(SetWalls2, 19) = 2Next SetWalls2'Set level Walls Vertical edgesFor SetWalls3 = 1 To 19 LevelWalls(1, SetWalls3) = 2Next SetWalls3For SetWalls4 = 1 To 19 LevelWalls(19, SetWalls4) = 2Next SetWalls4'GametypeGameType = "TeamGame"'Set Levels Personal Features ----------------------------------------------Dim XSetIncWall As ByteDim YSetIncWall As ByteDim TerrainSetup1 As ByteDim TerrainSetup2 As ByteDim TerrainSetup3 As ByteDim TerrainSetup4 As ByteDim ProbabilityOfBrick As Byte'Randomly sets up bricksYSetIncWall = 2'You dont need to modify the edges because you always make them an impassible block using a loop.For TerrainSetup1 = 2 To 18 XSetIncWall = 2 For TerrainSetup2 = 2 To 18 Randomize ProbabilityOfBrick = Rand(1, 5) If ProbabilityOfBrick = "1" Or ProbabilityOfBrick = "2" Or ProbabilityOfBrick = "3" Or ProbabilityOfBrick = "4" Then LevelWalls(XSetIncWall, YSetIncWall) = 1 End If XSetIncWall = XSetIncWall + 1 Next TerrainSetup2 YSetIncWall = YSetIncWall + 1Next TerrainSetup1'Sets up LevelBlocksYSetIncWall = 3For TerrainSetup3 = 1 To 8 XSetIncWall = 3 For TerrainSetup4 = 1 To 8 LevelWalls(XSetIncWall, YSetIncWall) = 2 XSetIncWall = XSetIncWall + 2 Next TerrainSetup4 YSetIncWall = YSetIncWall + 2Next TerrainSetup3'Clears player locations/Defaults of blocks ----------------------------------------------LevelWalls(2, 2) = 0LevelWalls(2, 3) = 0LevelWalls(3, 2) = 0LevelWalls(18, 18) = 0LevelWalls(18, 17) = 0LevelWalls(17, 18) = 0LevelWalls(2, 18) = 0LevelWalls(2, 17) = 0LevelWalls(3, 18) = 0LevelWalls(18, 2) = 0LevelWalls(17, 2) = 0LevelWalls(18, 3) = 0'Create Player StartsPerson(1).X_Pos = 2Person(1).Y_Pos = 2Person(1).PlayerColour = "RedBomberSprite"Person(2).X_Pos = 18Person(2).Y_Pos = 18Person(2).PlayerColour = "BlueBomberSprite"Person(3).X_Pos = 2Person(3).Y_Pos = 18Person(3).PlayerColour = "GreenBomberSprite"Person(4).X_Pos = 18Person(4).Y_Pos = 2Person(4).PlayerColour = "YellowBomberSprite"'Set Players Exhistance/Prepare Motion Function for a player (Makes them optional)PlayerControlsEnable 1PlayerControlsEnable 2PlayerControlsEnable 3PlayerControlsEnable 4End Sub
This is not something to copy and paste obviously but just shows you that you can tamper with the grid all you like before you start. Here is the sweet part, take notice of the value "GridSize" (belowin the drawing pesudo code) that can be the size of your sprites. If you make it the size of your sprites then do another for loop and multiply the position of the image with the number of times you have gone through both loops (making up x and y values) you can create a square or rectangular grid. You can use different integer values in the array to make different textures be drawn onto your grid.
Private Sub RenderFloorArray()'Pointers for All Arrays RefreshingXIncrement = 1YIncrement = 1'LoopsDim XWallDisplay As IntegerDim YWallDisplay As Integer'DrawAllRectanglesFor XWallDisplay = 1 To 19 YIncrement = 1 For YWallDisplay = 1 To 19 Select Case LevelWalls(XIncrement, YIncrement) Case 0 DrawTexture FloorSprite, (XIncrement * GridSize), (YIncrement * GridSize) Case 2 DrawTexture BlockSprite, (XIncrement * GridSize), (YIncrement * GridSize) End Select YIncrement = YIncrement + 1 Next YWallDisplayXIncrement = XIncrement + 1Next XWallDisplayEnd Sub
Then you can use If statements to test if a player can move in a direction, because the outside layer is always made impassible (I used the integer value of 2 to represent a solid block) you can bypass the worry of having an exception because you had to test if the player could move down beyond the scope of the array. Obviously you can draw goodies and ghosts over the sprites making the terrain (I used a sperate array for goodies back in the day but a linked list is definetely the most efficient method you could try). If your new to programming games its a great place to start!
Make sure you store your players seperate from the grids values, you can draw them overlaying it afterward. If you make them part of the grid then you can't smooth over the animation when they jump between cells and you also have the trouble that you cant have them move over varying tiles with different terrain!
P.S. Apologise for my example code using such an old language I hope you can understand it! (the key thing to grasp is the arrays and use of for loops to draw) :p
Megathanx Monsieur Kseh and EnlightenedOne
for the useful info, and thorough codes & explanations. Will take the time to understand it fully and implement it as first game. (but I will be away from this forums for some restful holiday)
Really it seems, tile based design makes movements/collision handling much easier in an array. As if the screen actions could be realised in ASCII-mode :)
Would dare to think ahead:
what if one would like pixel-based movement in a maze, where walls are just lines (thus not equal sized to sprites).
-How should AI sprites move among lines? Getting screen pixels and checking for a WALLCOLOR could come into my mind.
-But what if the walls have textures (ie of several colors)?
for the useful info, and thorough codes & explanations. Will take the time to understand it fully and implement it as first game. (but I will be away from this forums for some restful holiday)
Really it seems, tile based design makes movements/collision handling much easier in an array. As if the screen actions could be realised in ASCII-mode :)
Would dare to think ahead:
what if one would like pixel-based movement in a maze, where walls are just lines (thus not equal sized to sprites).
-How should AI sprites move among lines? Getting screen pixels and checking for a WALLCOLOR could come into my mind.
-But what if the walls have textures (ie of several colors)?
I shall answer those questions as best as I can.
There are many ways to solve collision issues the important thing to recognise is the scope you need collisions to happen on, I would say it was beyond the depth of the first game you builds needs but there are things to look up.
One other thing to take note of is that per pixel collisions are almost never the way to go its a brute force means of solving a problem that can be handled more elegantly without a great reduction in precision and if you do it right none. If your using python and no specific API to draw to the screen then the odds are you may stress the CPU doing all the calculations for collisions this way.
The two things I would recommend you search for instead of per pixel collisions are Axis Aligned Bounding Boxes (AABB as its commonly known) where you use the size of a box surrounding even a detailed object to calculate if two objects overlap, the beauty of this one is if you expand the size of the AABB you can use the detection of an overlap to make two objects be tested more precisely (such as for a per pixel collision or any other algorithms you use together).
The most common solution to making a 2D and or 3D world have collisions (I am studying the 3D version now) is Seperating Axis Theorum (SAT as it is more commonly known). With this you can create a series of lines that map the shape of a sprites edges and you can use these to detect collisions through a means of testing for a gap between the two objects for lack of a shorter description :p
Usually collisions represent a tradeoff, where bruteforce means cost you cpu cycles and elegant means cost you time and provide limitations, I always find the more elegant solutions are the way to go. The limitation of SAT is that all objects you test for collisions between must be convex in shape any concave areas will be treated as collisions without using an expansion on the algorithm, there are several beyond my scope here.
You would test for if the edges have any colour that is not your background colour. If you have a background made up of lots of colours then you could draw the two sprites with relative co-ordinates to each other offscreen. You can have a default colour for a background offscreen so you can detect an overlap, however there is probably a faster route than that to take.
Ordinarily unless you have alpha in your images you use one colour value out of the r,g,b spectrum (usually a strong pink) to represent a transparent pixel this is why alot of sprites you can search for on google will have a funny coloured background to them, that is the colour you cannot see in the game, implementing this depends on your API.
The best way to do AI if your using random sizes of walls is too create a group of nodes with links between them and attach a weighting to the link between every node. Then you can decide the AI wants to go toward one node from whatever node they are at and they can follow a linear path there without passing any lines(the destination can be updated based on the players distance to a node. To implement that I would recommend you research "Dijkstra's" algorithm its a fast efficient and more importantly simple (after you stare the code for afew hours ;p) algorithm once you wrap your head around it you will love it. An alternative method is A* path finding although I believe that one is harder to implement as I have never implemented it I can't go into depth on it.
No, start simple and build up your knowledge and skill. I recommend if you want to make games as a hobby start learning OpenGL or DirectX so you can build up toward 3D and beyond. If your not feeling confident enough to ignore the stop signs along the way and keep trying to make a game then you wont get far, so goodluck!
Quote:
what if one would like pixel-based movement in a maze, where walls are just lines (thus not equal sized to sprites).
There are many ways to solve collision issues the important thing to recognise is the scope you need collisions to happen on, I would say it was beyond the depth of the first game you builds needs but there are things to look up.
One other thing to take note of is that per pixel collisions are almost never the way to go its a brute force means of solving a problem that can be handled more elegantly without a great reduction in precision and if you do it right none. If your using python and no specific API to draw to the screen then the odds are you may stress the CPU doing all the calculations for collisions this way.
The two things I would recommend you search for instead of per pixel collisions are Axis Aligned Bounding Boxes (AABB as its commonly known) where you use the size of a box surrounding even a detailed object to calculate if two objects overlap, the beauty of this one is if you expand the size of the AABB you can use the detection of an overlap to make two objects be tested more precisely (such as for a per pixel collision or any other algorithms you use together).
The most common solution to making a 2D and or 3D world have collisions (I am studying the 3D version now) is Seperating Axis Theorum (SAT as it is more commonly known). With this you can create a series of lines that map the shape of a sprites edges and you can use these to detect collisions through a means of testing for a gap between the two objects for lack of a shorter description :p
Usually collisions represent a tradeoff, where bruteforce means cost you cpu cycles and elegant means cost you time and provide limitations, I always find the more elegant solutions are the way to go. The limitation of SAT is that all objects you test for collisions between must be convex in shape any concave areas will be treated as collisions without using an expansion on the algorithm, there are several beyond my scope here.
Quote:
Getting screen pixels and checking for a WALLCOLOR could come into my mind.
-But what if the walls have textures (ie of several colors)?
You would test for if the edges have any colour that is not your background colour. If you have a background made up of lots of colours then you could draw the two sprites with relative co-ordinates to each other offscreen. You can have a default colour for a background offscreen so you can detect an overlap, however there is probably a faster route than that to take.
Ordinarily unless you have alpha in your images you use one colour value out of the r,g,b spectrum (usually a strong pink) to represent a transparent pixel this is why alot of sprites you can search for on google will have a funny coloured background to them, that is the colour you cannot see in the game, implementing this depends on your API.
Quote:
How should AI sprites move among lines?
The best way to do AI if your using random sizes of walls is too create a group of nodes with links between them and attach a weighting to the link between every node. Then you can decide the AI wants to go toward one node from whatever node they are at and they can follow a linear path there without passing any lines(the destination can be updated based on the players distance to a node. To implement that I would recommend you research "Dijkstra's" algorithm its a fast efficient and more importantly simple (after you stare the code for afew hours ;p) algorithm once you wrap your head around it you will love it. An alternative method is A* path finding although I believe that one is harder to implement as I have never implemented it I can't go into depth on it.
Quote:
should I give up game programming 4ever? :(
No, start simple and build up your knowledge and skill. I recommend if you want to make games as a hobby start learning OpenGL or DirectX so you can build up toward 3D and beyond. If your not feeling confident enough to ignore the stop signs along the way and keep trying to make a game then you wont get far, so goodluck!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement