This will probably be my last post for a few weeks. The week after next the school component of my German internship continues. I've been living in Germany now for about 13 months now, and while I can speak and understand enough German to get by it's still quite a challenge for me. Learning content intended for native German speakers in a German school when I'm someone who's just been learning German for about a year is taxing. Although this is certainly a great way to get better at speaking a foreign language, it unfortunately also means that I have too little time and energy to progress much with my gaming projects.
Anyway, back to the topic at hand: the Event Queue. Early on in my gaming efforts I noticed this need for some kind of queue. Especially when thinking about AI and keeping all the actions that the player and AI make in sync. Up until now I'd been messily getting by without this system but my Wanderer game has grown to the extent that I really do need to implement a queue system. The need for it is so paramount that it will be the next thing I do.
Now what this queue would do is allow me to do is queue up a bunch of actions to happen per game loop cycle. This means that instead of pressing the left arrow key and having the key handler call a method that moves the character west for me, the key event handler simply adds a movement order to the event queue. The event queue has units subscribed to it, and the event queue finds the right unit and informs it that it has been instructed to move. The main advantage of this for me now is that I then don't have to consider time when moving many different objects and characters. They will all move at the same rate because the event queue will ensure that they move at the same rate by only updating them once per game cycle. It also means that I can pause the game by issuing a hold on this queue for a specified time period or indefinitely.
There are more benefits to using queuing system but I've yet to realise and consider those. If you wish to read further I recommend this article. It explains the queue system but also much more. I would also suggest looking at an observer pattern. My understanding of a queue in a game is that it's an observer pattern that updates with every cycle of the game's loop.
After I've developed a prototype I'll write about it here to let you know if it was successful and I'll discuss more about it.
Sunday 27 April 2014
Friday 25 April 2014
The Wanderer - 2D Open World (prototype)
Three days ago I made a post about my plans on how to convert my 2D Wanderer game into an open world Wanderer. I'm writing here now to report that my plans have been successful, although there's still a few bugs left to iron out and I also need to optimise my functions so that there's less of a framerate drop when loading chunks.
I'm not convinced this is the best way to do it, but it's a first attempt and at least it works.
Anyway, here's how I did it. Of a much bigger world I establish a viewpoint into this world that's 1760x1760 pixels large. This is then divided into 9 sections arranged into a 3x3 grid:
123
456
789
The player is on chunk 5. If he moves onto one of the other chunks, then the chunks need to be rearranged. For example, if he's standing on 5 and moves to 6 then the following needs to happen:
Chunks 2 5 8 need to be moved back to chunks 1 4 7.
Chunks 3 6 9 need to be moved back to chunks 2 5 8.
Chunks 3 6 9 then need to be reloaded.
This creates an effect where if the player moves off chunk 5 then the world is rearranged so that he's again on chunk 5. Just like in this picture:
Here's some screenshots of my Wanderer in action. In this picture, he's just spawned at tile 64,64.
Now I turn the grid on, and the tile coordinates on, and walk east until I reach chunk 6 (which forces a shuffling and loading of chunks):
I'm not convinced this is the best way to do it, but it's a first attempt and at least it works.
Anyway, here's how I did it. Of a much bigger world I establish a viewpoint into this world that's 1760x1760 pixels large. This is then divided into 9 sections arranged into a 3x3 grid:
123
456
789
The player is on chunk 5. If he moves onto one of the other chunks, then the chunks need to be rearranged. For example, if he's standing on 5 and moves to 6 then the following needs to happen:
Chunks 2 5 8 need to be moved back to chunks 1 4 7.
Chunks 3 6 9 need to be moved back to chunks 2 5 8.
Chunks 3 6 9 then need to be reloaded.
This creates an effect where if the player moves off chunk 5 then the world is rearranged so that he's again on chunk 5. Just like in this picture:
Here's some screenshots of my Wanderer in action. In this picture, he's just spawned at tile 64,64.
Now I turn the grid on, and the tile coordinates on, and walk east until I reach chunk 6 (which forces a shuffling and loading of chunks):
Then I walk against east, until a new chunk is loaded.
Here's another shot at a different location with the chunks coloured.
Anyway, it's an ok first attempt at getting an open world to work, but I've got problems with framerate and glitches to overcome before I label it as a success.
Tuesday 22 April 2014
The Wanderer - 2D Open world (Brainstorming)
This week I put together a little game called "The Wanderer". It loads a map created with my map editor and you're given control over a beetle that can walk around on the map. At the moment he's confined to his little map, but what I want to do is expand this to be an open world wanderer. This is my article about my solution to this open world problem.
The open world idea presents new challenges for me, but I have a plan about how I can do it. I generated a rather giant map (65536 tiles). It's really only feasible to have about 4096 tiles loaded at one time, which equates to an image of 2048x2048 with a size 32 tile. Anything more and loading times begin to become longer, and an image size of 2048x2048 is larger than what can fit on an average monitor - providing ample space.
My challenge is that of the 65536 tiles in this giant map, I can only ever have 4096 tiles loaded at a time. As the player moves, tiles need to be dynamically loaded and unloaded to maintain this small drawn window of the large world. I'm going to refer to these 4096 tiles as a chunk.
To figure out which tiles need to load/unload, I have to first take the tile that the player is standing on, and then calculate all the tiles around the player that fall within perimeter, determined by this chunksize.
Solution
My solution is simple, but untested. I will implement it and then report whether it works or not, but in theory, it should work.
The solution is that we know the tile that the player is standing on, and we know the size of the chunk. Therefore, the top left and bottom right tiles in the chunk can be predicted like this:
The amount of tiles behind and before the player's tile: Difference = (chunksize - 1) / 2
Therefore:
Top left tile in chunk = PlayerTile - Difference
Bottom right tile in chunk = PlayerTile + Difference
With these values I can determine which tiles to load into the new chunk whenever a player moves to a new tile. I have a visual representation of this below (sorry about the MSPaint.exe style quality). In this example, the chunk size is 25. X represents the player's tile and the big red box represents the chunk.
In this next image, the player walks one tile to the right. You can see drawn the tiles that need to be unloaded, and the tiles that need to be loaded.
The open world idea presents new challenges for me, but I have a plan about how I can do it. I generated a rather giant map (65536 tiles). It's really only feasible to have about 4096 tiles loaded at one time, which equates to an image of 2048x2048 with a size 32 tile. Anything more and loading times begin to become longer, and an image size of 2048x2048 is larger than what can fit on an average monitor - providing ample space.
My challenge is that of the 65536 tiles in this giant map, I can only ever have 4096 tiles loaded at a time. As the player moves, tiles need to be dynamically loaded and unloaded to maintain this small drawn window of the large world. I'm going to refer to these 4096 tiles as a chunk.
To figure out which tiles need to load/unload, I have to first take the tile that the player is standing on, and then calculate all the tiles around the player that fall within perimeter, determined by this chunksize.
Solution
My solution is simple, but untested. I will implement it and then report whether it works or not, but in theory, it should work.
The solution is that we know the tile that the player is standing on, and we know the size of the chunk. Therefore, the top left and bottom right tiles in the chunk can be predicted like this:
The amount of tiles behind and before the player's tile: Difference = (chunksize - 1) / 2
Therefore:
Top left tile in chunk = PlayerTile - Difference
Bottom right tile in chunk = PlayerTile + Difference
With these values I can determine which tiles to load into the new chunk whenever a player moves to a new tile. I have a visual representation of this below (sorry about the MSPaint.exe style quality). In this example, the chunk size is 25. X represents the player's tile and the big red box represents the chunk.
Finally, based upon the player's tile and the chunksize, I learn can predict the indexes of the tiles to be loaded.
This is my open world strategy. It should work. If you have a better idea, please let me know in the comments.
Subscribe to:
Posts (Atom)