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.
Showing posts with label game. Show all posts
Showing posts with label game. Show all posts
Sunday, 27 April 2014
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.
Saturday, 22 March 2014
How should a game work? (Brainstorming)
There's not really a whole lot of stuff out there (if there is, I can't find it) about how to put together a game. Unfortunately this post isn't so informative. It's a brainstorming post where I try to plan how I should go about designing something. That means that you shouldn't expect to find too many pearls of wisdom in this post. This is me trying to figure something out, not me offering a brilliant solution.
At the heart of it the game is just an endless loop that says:
1. Handle user input
2. Process AI
3. Update game values
4. Draw graphics
The loops vary and can be more or less sophisticated depending on how you decide to make it. I'm not going to talk about this loop beyond what I've said already because someone else a lot more knowledgeable about the topic has already made a great write-up about it. I already have my own crude game loop figured out. At the moment I'm more concerned about how best to organise what happens inside point #4. I'll give the other steps a brief mention, however.
#2 AI
The AI is an entirely different problem that I'll cover in the future. At the moment I have simpler things to consider. If you take all the complexities aside and think about what the AI step should actually do, it's just a whole heap of calculations to determine the positions of units and what they're doing.
#3 Update game values
This is also something I've decided to leave for the future because I haven't thought about it enough in detail yet. Basically this is just the part where we determine if units are still doing something. This step might even be merged into the AI step because they'er related. An example of this is soldiers shooting a building. If the soldiers are still in range to shoot at the building then the building needs to be losing health, for example.
#4 Draw graphics
Anyone can draw some graphics. The difficulty comes with figuring out what to draw. Some kind of system is needed that keeps track of all the sprites in the game and draws them when needed. This system needs to:
a) Unit & Building sprites list
The best way I can think of to draw all the sprites is to add them to a big list of sprites to draw. If a player makes a new soldier, this soldier sprite is appended to the list and subsequently drawn. If this soldier dies, then he needs to turn into a corpse sprite for a while before disappearing entirely (or I could leave him there as a permanent stain upon the battlefield, which is also cool). In any case, the very first thing #3 should do is draw everything in this list and figure out a good way to add & remove sprites from this list. This list shouldn't be a simple array, but something more intelligent like a vector/dictionary.
There should also be another list that will be drawn after the list I just described, and this is the effects list. So explosions, fire, smoke, rain and whatever else should be drawn here.
b) Draw from the perspective of the player
In an RTS game this means that the player can only see his own units, and also see whatever is in the light of sight of the player's units. I think the easiest approach to this is to go for the fog of war type of thing where everything is drawn and then a layer of fog goes over the top, shrouding everything that shouldn't be visible from sight. This gives me then the simplicity of being able to draw everything onto the map, then selectively reveal parts of the map to the player instead of selectively drawing only based upon what a player should be able to see.
At the heart of it the game is just an endless loop that says:
1. Handle user input
2. Process AI
3. Update game values
4. Draw graphics
The loops vary and can be more or less sophisticated depending on how you decide to make it. I'm not going to talk about this loop beyond what I've said already because someone else a lot more knowledgeable about the topic has already made a great write-up about it. I already have my own crude game loop figured out. At the moment I'm more concerned about how best to organise what happens inside point #4. I'll give the other steps a brief mention, however.
#2 AI
The AI is an entirely different problem that I'll cover in the future. At the moment I have simpler things to consider. If you take all the complexities aside and think about what the AI step should actually do, it's just a whole heap of calculations to determine the positions of units and what they're doing.
#3 Update game values
This is also something I've decided to leave for the future because I haven't thought about it enough in detail yet. Basically this is just the part where we determine if units are still doing something. This step might even be merged into the AI step because they'er related. An example of this is soldiers shooting a building. If the soldiers are still in range to shoot at the building then the building needs to be losing health, for example.
#4 Draw graphics
Anyone can draw some graphics. The difficulty comes with figuring out what to draw. Some kind of system is needed that keeps track of all the sprites in the game and draws them when needed. This system needs to:
a) Unit & Building sprites list
The best way I can think of to draw all the sprites is to add them to a big list of sprites to draw. If a player makes a new soldier, this soldier sprite is appended to the list and subsequently drawn. If this soldier dies, then he needs to turn into a corpse sprite for a while before disappearing entirely (or I could leave him there as a permanent stain upon the battlefield, which is also cool). In any case, the very first thing #3 should do is draw everything in this list and figure out a good way to add & remove sprites from this list. This list shouldn't be a simple array, but something more intelligent like a vector/dictionary.
There should also be another list that will be drawn after the list I just described, and this is the effects list. So explosions, fire, smoke, rain and whatever else should be drawn here.
b) Draw from the perspective of the player
In an RTS game this means that the player can only see his own units, and also see whatever is in the light of sight of the player's units. I think the easiest approach to this is to go for the fog of war type of thing where everything is drawn and then a layer of fog goes over the top, shrouding everything that shouldn't be visible from sight. This gives me then the simplicity of being able to draw everything onto the map, then selectively reveal parts of the map to the player instead of selectively drawing only based upon what a player should be able to see.
There's two styles of fog. The first is to have a completely black map which you have to explore thoroughly or else you see nothing. The second is to have a grayed out view of the entire map, but you can still see features of the map - just none of the units or buildings. The former was much more common in older games like Warcraft 2, Starcraft, Age of Empires and C&C: Tiberian Sun. The latter is basically the 'status quo' of all modern RTS games and features in basically everything. I haven't seen the old style fog of war in years.
The question is, which should I use? It'd make more sense to go with the latter in some ways because of the modern setting of the game. It seems quite silly that a space-fighting force couldn't do a simple radar scan of the map to determine its terrain features before landing. Although not at all related to the fog of war, one game had a very cool feature, in my opinion, that is deserving of a special mention. In C&C: Tiberian Sun the minimap was actually disabled until you built a radar structure. This means that you could only have a minimap if your radar structure was functioning. I might go with this idea and put it in my game because it actually makes a lot of sense and is quite a cool idea.
Concluding #4
That should be enough planning for me to get started on the next part of my little game project: The sprite list and the fog of war.
Subscribe to:
Posts (Atom)