Week 6, Pause Function

This weeks topic might be a simple and boring one since it’s only about the pause function of our game. However, I figured there might be some solutions to how things were done that might be a tad interesting so bare with me for a bit.

A pause function is probably not necessary in such a small game like ours but it’s mainly there to not force the player to die if in need of a unplanned toilet break or just need time to rest and regain some focus. This is how I solved it.
The update function in our game state class which you could say takes care of the in-game-loop is quite slimmed down and basically just calls for all our game’s different managers. This allowed me to easily implement a boolean check before running the mentioned updates.
If this pause bool was FALSE: run the updates.
If the pause bool was TRUE: don’t run the updates and instead present the pause menu on top of the game area. The pause menu only covered a smaller part of the game screen so I also added a grey rectangle with low opacity to give a greater sense of that the game play was actually inactive.
The buttons for the pause menu was created with the help of a struct that held a text for the button and an integer to serve as the button index. Each button was created in a loop which looped through a set amount of times for as many buttons that was needed and added to a vector array. At the moment we only needed two buttons (a Continue and a Quit button) which may have made the loop a bit unnecessary but it will make the implementation of further buttons easier in the future.
Maybe I also should mention that these buttons wouldn’t be clickable with the mouse but only accessed with a keyboard. An integer in the game state class was compared to the index in of the respective buttons as the user pressed the up and down arrows and adjusted the color of the current matching value to show which button that was selected. It would then perform the assigned task to the specific value when the activate button was pressed which in this case would be the return key.
See, this wasn’t that boring at all, was it?
Thanks for reading!

week 5, Loading screen

As our game has grown larger and larger asset wise over the weeks I guess it’s not that surprising that there might be a great amount of data that needs to be loaded for the game to start. This could of course have been handled differently than we did but we chose to load every game texture as the game starts, in comparison to load everything as it is needed. This is also a viable way to do it as the game only has one level and is rather small. If the game would have had multiple levels I guess we should at least have loaded only the needed textures and sounds for the current level that was playing.
The reason for a loading screen was because of some of the textures (e.g. the level background textures) was too large. This made the game freeze as the player pressed “Play” in the start menu and he would have to wait for about 10 seconds for the game to actually start. We figured that if you got to see the process of assets being loaded this wouldn’t give the player a reason to reach for the exit button in the top right corner too quickly.

Anyways, between the menu scene and the game scene we added our new loading scene. Before this we also added a texture cache class which would store all the needed textures for the game with a load- and a get texture function. The loading screen does the actual loading call for each texture to the cache class which may later be used in the game. It also loads in every sound needed through the sound manager which stores them for later use.

Once the loading screen is displayed on the screen we wanted, as mentioned, something for the user to visually see assets being loaded and as for now this is represented by two growing bars in the middle of the screen. One for textures and one for sounds. To make these grow we added two integers to the loading scene which we added a value to in between each loaded item. This might most definitively be changed to a more fitting way to represent process and growth which are more relatable to the game.

To make this feature work we used something called multi threading. (Be gentle with me from now on since my experience on this matter is below beginner level.) Anyhow, multi threading allowed us to do the loading process separately form the main process. Why? Because else we would have needed to call the draw function in between each loaded item as well as the integer additions. Now the main process only needed to keep track of those integers, scale the bars sprites accordingly and of course draw them to the window surface while the other thread loaded in the assets to its handlers.

Code Review of Team 4

The first smart thing that got me was the clean start of the player class’ update function. Specifically the way of dividing the different states into their own functions which would be called by the value of an enumerator.
I also like the way that the player class seems to have control of the player dependent objects creation such as the harpoon, the golden harpoon and fish food. This is most likely how I, myself would’ve done it to keep track on what the player class can “access”, but I know many who would like to divide up most of this class into smaller ones. Dividing up the code into separate classes would probably make it more readable if you wanted to (for example) change something specifically related to the harpoon.
What you could’ve done differently, I guess, is have some sort of player manager class which would serve as the glue for each player related component keeping the player class at a minimum of only specific player related data. Even the controls could be in a separate class as well as the states. This would perhaps also prevent people from working on the same files making merging a tad less complicated.
However, to me, this would be an easier solution since my own programming skills are yet a bit limited and your way would give me a better overview of the player and it’s related classes, plus it seems fairly well organized.
Some comments would help making the code easier to get in to, if not for other team members, for an outsider like

Week 4, Natural Disaster: Tsunami

With a game concept like Datepocalypse, where a big pile of chaos should serve as one of the main flavors of the game, some of the hardships comes in the form natural disasters and this week I’ve been working on one that we call the Tsunami. As other games may give the player a screen sweeper, to clear all enemies from the play area, this game has this “enemy” which basically does the same thing but at the same time might be dangerous for the player as well. Plus, the player have no control over it’s activation.

As mentioned the tsunami functions as a type of enemy and is created and spawned in a similar way as other obstacles through the wave manager but has some key differences. It has a huge rectangular hit box that covers the entire game area from left to right and a height of about the same as a player avatar. This because if the player gets hit by the tsunami it will get past the player without continuously doing damage to the avatar for the entire tsunami duration but only on first impact. This could of course be done with a smaller height but for now with the tsunami’s current speed this felt like a simple solution to avoid the player avatar being missed and not affected at all. However, the player can protect both his avatars from taking damage by connecting the them thus activating the player shield. The actual sprite for the wave is however about the size of two game screens. As the wave is so huge and would completely cover the avatars we made it slightly transparent so that the player wouldn’t lose track of their positions.
A really big wave should affect every object it touches in some way, that’s why it also kills / pushes all still active normal enemies off the screen as well, which makes it similar to a screen sweeper. The enemies won’t actually try to avoid being hit but this is a necessity for the player which might not be so easy since the wave moves much faster than other obstacles. That’s why we added a second animation for the tsunami consisted of big, red, flashing warning triangles in the top of the screen to signal the incoming of something big and dangerous which played a few seconds before the actual wave would enter. We figured the triangles wouldn’t be enough so we also added a loud warning sound similar to the one used in real warnings for tsunamis, earthquakes or war to amplify that it might be a good idea to prepare the player shield.

There are still some bugs with the tsunami such as the collision between itself and the player where sometimes it would get stuck on the avatars pressing them continuously downwards and in the end hold them pressed against the bottom of the screen but this could be fixed by moving either the avatar past the wave hit box on impact or temporarily deactivate either of the collision bodies (preferably the avatar’s bodies to avoid enemies slipping through the wave as well).