I'm back. This time I want to post up a little about my exploration into building a prototype 'proof of concept' for my game I'm simply dubbing 'myCade' (Working title) for now.
Obviously there are other game play features involved, but that's the general gist of it. I have a fairly hefty document and design plan I sketched out that covers things in more detail that I may post up at a later date (once I see if there are any details I've left out, and test that things are actually working in terms of game play).
Of course, I also needed some generic graphics. As this is purely a proof of concept and not a final project, I don't need anything complex for testing... But also not too crappy looking either. I decided on 64x64 sprites so at least it looked decent on a high resolution screen. Four arcade machine graphics (representing machines that face left, right, up and down) and a single character. The character was actually drawn by my brother back in the 80's on a ZX Spectrum - he is also a pretty creative guy, so there were always cool ideas for other games from his artistic designs. I may drag him in at some stage and see what we can put together in the future for other games.
When I resized the characters, they did look a little less appealing in that the pixels didn't retain their clean shape, but I figured it does what it needs to at this early stage of testing. I can make prettier graphics later of course! :)
I first tried to code the movement of the characters to use an approach I'd tested in a simple Pacman-style game I wrote for fun a while back to help me learn how to use Pygame, My version of Pacman featured purely random motion of ghosts rather then the usual target-based system that the original used, but it worked and it was fun to play.
I used the same concept initially for my character movement in this game, using a constant linear direction movement and checking for exits in the arcade 'maze' that were opposite to the initial motion (if vertical, see if we could move horizontally and change if we needed to reach the goal).
This proved problematic. I found that I ran into some situations where characters would get locked into corners, or even walk out of the arcade and game window. I ran through my code, and while I could have eventually found where things failed I decided I was spending too much time with it. Plus there were issues that affected the feel of the game play, making the motion of the characters look a little 'misguided' and unintelligent...
Fyi - if you want to download the pacman game code, its included with some other retro code (old 1k ZX81 games recreated in Python). Click here for a direct link to the source code on my google drive, or click that previous link to watch me fumble my way through a presentation I gave on the retro gaming project I'd been doing.
The search algorithm I ended up using was a Breadth-first seach (or BFS for short). This is a fairly well documented algorithm, finds the shortest route (and gives our characters less of a random appearance when moving) and benefited from not requiring any use of recursion, making my code less of a mental strain on my brain cells (and at my age, I need to retain as many as possible - lol!)
Bonus is that bfs only takes 7 lines of Python code to implement - short, sweet and clean!
It may not be the fastest (I'll look at other options at a later date, such as A*, etc) but for this proof of concept, and the fact I'm working in a small map (once I converted the tiles to a graph structure, the amount of data became even smaller) it worked great with literally no visible impact on game speed.
Because the path is pre-calculated, the nice thing here is that I know a character reached the goal when the end of the path is met. I found I could take advantage of this path to easily control whether the character traveled onto a target, or could finish at the correct location one tile away (ie. say I wanted to make a character reach the arcade machine rather then land on top of it (ie. prevent it walking onto the machine graphic)).
The pacman-approach used a 'target tile reached' test, and calculating the direction the character was moving, the tile location and testing for the machine being in direct line takes more code and was not as clean a solution as simply ending at a path's second-to-last position.
So, at this stage I've got things moving in the arcade. This is perhaps the main thing needed in the game - getting the game characters moving and reaching their goal. With only a few simple tests and some data management needed to get the game up and running, I feel that this project may come together a lot quicker then expected (well, I hope so - but famous last words and don't count your chickens until they hatch as the sayings go!)
Until next update...
More about the game concept
The game centers around an arcade (hence the working title). Unlike my inspiration, this time the goal is not to stock up the machines with coins and collect them back, but instead let incoming characters play the games and stock the machines up with their hard-earned pocket money. As the player, you then collect the cash and store it in your safe. The goal here is to collect coins and move on to the next level (well, at a basic level) once you reach a certain amountObviously there are other game play features involved, but that's the general gist of it. I have a fairly hefty document and design plan I sketched out that covers things in more detail that I may post up at a later date (once I see if there are any details I've left out, and test that things are actually working in terms of game play).
Getting the ball rolling...
I figured I'd make a start on some coding... In the past, the best thing for motivation when writing code for a game is to at least see something happening... Even if its a bit at a time. This initial start was to purely get some characters running around an arcade to empty machines - or in this case, target points.
Of course, I also needed some generic graphics. As this is purely a proof of concept and not a final project, I don't need anything complex for testing... But also not too crappy looking either. I decided on 64x64 sprites so at least it looked decent on a high resolution screen. Four arcade machine graphics (representing machines that face left, right, up and down) and a single character. The character was actually drawn by my brother back in the 80's on a ZX Spectrum - he is also a pretty creative guy, so there were always cool ideas for other games from his artistic designs. I may drag him in at some stage and see what we can put together in the future for other games.
When I resized the characters, they did look a little less appealing in that the pixels didn't retain their clean shape, but I figured it does what it needs to at this early stage of testing. I can make prettier graphics later of course! :)
 |
| Quick-n-dirty test sprites |
The game play field.
As you'd expect with games like this, the design centers around a tile-based map. The map contains clear areas for walking, and machines (which come in 4 orientations) that each character will stop at and play. The characters in the arcade enter and then travel to a target (one of the free machines). This initial test code uses random locations just to test the travel algorithms and make sure all the game characters would move as expected. After this is all working, the game code will make sure that a character will choose a free machine as its target.I first tried to code the movement of the characters to use an approach I'd tested in a simple Pacman-style game I wrote for fun a while back to help me learn how to use Pygame, My version of Pacman featured purely random motion of ghosts rather then the usual target-based system that the original used, but it worked and it was fun to play.
I used the same concept initially for my character movement in this game, using a constant linear direction movement and checking for exits in the arcade 'maze' that were opposite to the initial motion (if vertical, see if we could move horizontally and change if we needed to reach the goal).
This proved problematic. I found that I ran into some situations where characters would get locked into corners, or even walk out of the arcade and game window. I ran through my code, and while I could have eventually found where things failed I decided I was spending too much time with it. Plus there were issues that affected the feel of the game play, making the motion of the characters look a little 'misguided' and unintelligent...
Fyi - if you want to download the pacman game code, its included with some other retro code (old 1k ZX81 games recreated in Python). Click here for a direct link to the source code on my google drive, or click that previous link to watch me fumble my way through a presentation I gave on the retro gaming project I'd been doing.
What a load of BFS!
I instead opted for a path search system. The character would be given a target location to reach, and then would calculate its path as a sequence of directional movements. While the game loop ran, each tile the character entered would then check for the next direction to move and set the characters motion as expected.The search algorithm I ended up using was a Breadth-first seach (or BFS for short). This is a fairly well documented algorithm, finds the shortest route (and gives our characters less of a random appearance when moving) and benefited from not requiring any use of recursion, making my code less of a mental strain on my brain cells (and at my age, I need to retain as many as possible - lol!)
Bonus is that bfs only takes 7 lines of Python code to implement - short, sweet and clean!
It may not be the fastest (I'll look at other options at a later date, such as A*, etc) but for this proof of concept, and the fact I'm working in a small map (once I converted the tiles to a graph structure, the amount of data became even smaller) it worked great with literally no visible impact on game speed.
 |
| Arcade time! |
Because the path is pre-calculated, the nice thing here is that I know a character reached the goal when the end of the path is met. I found I could take advantage of this path to easily control whether the character traveled onto a target, or could finish at the correct location one tile away (ie. say I wanted to make a character reach the arcade machine rather then land on top of it (ie. prevent it walking onto the machine graphic)).
The pacman-approach used a 'target tile reached' test, and calculating the direction the character was moving, the tile location and testing for the machine being in direct line takes more code and was not as clean a solution as simply ending at a path's second-to-last position.
So, at this stage I've got things moving in the arcade. This is perhaps the main thing needed in the game - getting the game characters moving and reaching their goal. With only a few simple tests and some data management needed to get the game up and running, I feel that this project may come together a lot quicker then expected (well, I hope so - but famous last words and don't count your chickens until they hatch as the sayings go!)
Until next update...
Posts
