Fast Gear – Week 9

So this is the final week. I have been working on some different things throughout the week. I have tried to balance the sounds better. Mostly we have worked on getting the positions of the cars in-game. We can now differentiate the cars in the race and see who is first, seconds, third and fourth. This was supposed to be done earlier but we ran into some issues with the code and we have been trying to figure it out the past two weeks. We finally solved it and can now move on to how the positions will affect the game.

If the player is last we will set the cars to have a lower speed in order to make it so that the AI does not drive away from the player in order to make it feel more competitive. It was not a good feeling when you were last and there is no way you can catch up with the other cars. We also made it so that the AI will have a higher top speed if you are first. The purpose was to give the racing a more intense sense of racing, that you are never safe and if you crash it is not too late to win. This makes it much more friendly to new players but still keeps the difficulty for the players who have raced before.

Fast Gear – Week 8

This week I have been working on sounds for the game. I would have liked to start earlier than this but other “more” important things have come in the way. I say more important but in reality sounds are very, very important for a game. I added three different car sounds to our car, one idle, one for accelerating and one for when you have reached the maximum number of gears. Every time you go up a gear the same sound plays but with a different pitch so it gives a feeling of acceleration.

I have also added music since we aim for an intense feeling when you are playing. The music comes from an independent music producer that we contacted a couple of weeks ago to ask if we could use his music. Audience sound was also added along with minor ambience. The audience is cheering in the beginning and when you drive by them along the track, this gives an intense atmosphere which we were looking for. The ambient sounds right now is just in the harbor which you drive by one time each lap with calm ocean sounds.

All sounds are to give the right atmosphere that we are looking for. Intense and exhilarating. I want to add more sounds but that can result in a mess, where different sounds play all the time. It is a fine line I have to walk to balance the sounds with different volume and pitch.

Fast Gear – Week 7

In order to move the AI they have a force applied to their rigidbodies in the z-axis that pushes them forward. We use a property of the rigidbody called drag, which is how much air resistance the car will have when forces are applied to them. It is a scale from 0 to infinity where 0 is no resistance at all and infinity makes them unable to move. We are using drag to make the cars stick to the road better and the cars have their own value of drag so they have a different feel.

The problem this is causing is that they become so heavy when drag is applied and the player car can not push them out of the way. I tried removing the drag and give them each a physics material which is used to adjust friction between different objects. This was even worse and made the cars very slippery or too sticky, there were no in-between which is why I decided to go with the drag instead.

In order to make it seem like the player can push the other cars out of the way I made a script that checks if the AI has been hit by the car and then calculates the angle between the collision point and the player. We get the opposite Vector3 and normalize it and then add force in the direction of the impact. This will give the AI a nudge when it gets hit by the player. We will also implement so if the AI is directly behind the player they will slow down so they do not push you into a railing which can be very annoying.

Fast Gear – Week 6

This week I have been fixing some small hiccups that occur with the AI. For example when the frame drops I talked about in an earlier post appears and I have no idea why. Luckily this time it was relativelty simple to investigate and find the problem. In order to understand the problem you first have to understand the basics of the A* algorithm. A* searches among all the possible paths it can take to reach the destination and chooses the one with the smallest cost. f(n) = g(n) + h(n) is the equation where n is the last node on the path, g(n) is the cost from the start to n and h(n) is a heuristic that estimates the cost of the cheapest path from n to the goal. This might seem a bit confusing, because it is. The problem I had with this was when we swapped tracks to a new one. This made the waypoints which the algorithm is calculating towards move out of the track and onto the “ground”. I have it set so that the road costs nothing to travel on but the ground costs 1000. This makes it so it wont go over the ground since it costs too much. When the waypoints were outside the track it had to do a lot of calculations with very big numbers and that is why it caused a spike in memory.

This week I have also been working on a FOV(Field Of View) for the AI. It creates a circle around the object and then you can change how big the FOV is going to be. If another object is in that FOV it will sense it and I can then tell it to do something. We have not yet figured out exactly what we want the FOV to do as of yet and I imagine that I will be working on that the next week aswell.

Field of view example.

Fast Gear – Week 5

As I mentioned in my previous post I have been working on the waypoints and the AI practically throughout the week. I have made some progress and the frame drops does not seem to be noticeable. The problem was that for 21ms the pathfinding for the units allocated 18MB memory but now I have reduced that to only 8.9MB which is a notable difference.

The problem seemed to be the threading which you can implement so you can have different calculations parallel with one another without interference if I understand it correctly. Since I have not done something like this before in a project it caused an issue. But the threading is now gone and the frame drops are considerably lower.

I also changed some things with the target. Instead of the different AI’s using the same target I assigned them their own. It is now a list of different target locations that check if the assigned AI has collided with them and in that case it moves to the next index in the list. I did this incase one AI came to a waypoint faster than the others. There was a small jerk in the other AI as the may have been in the middle of a turn or colliding with something, now they can take their time with the track without relying on each others targets.

Next week I am going to be working on making my own controller/physics for the car instead of using the prebuilt, which has helped during the prototyping and alpha but it is a lot of code which we do not know much about making it hard to troubleshoot.

Fast Gear – Week 4

Up until this point and probably for a couple of more weeks my focus have been on doing the AI(Artificial Intelligence) for our game. The AI is not that complicated as of right now. It has a road which it follows using A* which an algorithm for calculating the fastest way to the goal. The area surrounding the road is not made out of the same material so it has a higher value, meaning it costs more to drive on it. This makes it so the AI will try to keep itself on the road as much as it can. I have also added physics to it so that it looks more realistic when it drives around the track. Also if the AI does get outside the road I made it so it has a bit more drag which makes it go slower until it gets back on the road.

During the playtest we had this week we understood that the AI needs more testing against players who are not used to playing racing games. It was fairly easy to keep up with and beat the AI for us but for the ones playtesting it was very hard, they hardly ever saw it after the start.

For the upcoming weeks my focus will be on optimizing the AI. There is currently a spike in memory usage when it is calculating its new route which causes the frames to drop down to around 30 for half a second. Right now I am not sure what is causing it so this is a priority for me and the group.

What you see in this picture is the A* algorithm. The red and white squares are cars and the black dots are waypoints which it tries to follow as best it can. The white lines are displaying when they should turn.

Hello and welcome

Welcome to my blog about game design and programming. This blog is an assignment in my course, Big Game Project. The goal is to have a finished game in approximately 2 months. During this process I will write in this blog and talk about my design decisions and programming.

We are seven people who will be working on Fast Gear. My role in this is lead programmer, which means I will oversee the work of the other programmers, coordinate our efforts and set a code standard.

So you might be wondering what our game is about? The short answer is that it is a singleplayer vs ai racing game. It is not only what you do on the track that matters, you will also be judged by the ai off track during press conferences. Depending on your actions they will behave differently towards you.

Vecka 8 – Tutorial

Hej! Sista blogginlägget för denna kurs och detta inlägg kommer att handla om hur jag tänkte och gick till väga när jag gjorde en tutorial för vårt spel. Vårt spel är inte särskilt svårt, kan vara för att jag har spelat det så många gånger nu så det har blivit lätt men från de olika speltesten som har varit så har jag fått känslan av att spelet är svårt att förstå i början. En av anledningarna till att spelet är svårt är för att det går så snabbt när man kommer in i spelet, det är många fiender och objekt som kommer mot spelaren och när man inte har spelat det innan så kan det leda till att man får lite panik och trycker på de knappar man tror ska göra det man vill. Innan så fanns endast ett val som hette “Controls” som låg inne i “Options”, det låg där eftersom det var tänkt att man skulle kunna välja vilka knappar man ville använda till vad, men det blev aldrig så.

Så denna vecka har jag skapat en ny textrad som lyder “How to play” genom att deklarera en array med sf::Text som heter howto och som innehåller 3 element. Dessa skapar jag sedan i meny klassens “Enter” funktion och sätter att howto[0] skall visas i den första menyn som kommer på skärmen. Jag deklarerar även vilken storlek, font samt vilka färg de element som finns skall ha innan de ritas ut i “Draw” funktionen.

I “Update” funktionen så skapar jag en sf::IntRect för varje element i arrayn. En sf::IntRect behöver veta vart det övre vänstra hörnet är och sedan hur bred och hög den skall vara. Som exempel så skapar jag en sf::IntRect som heter m_pHowTo och sätter in det första elementet från howto som heter “How to play” och har en plats i den första menyn som visas(dessa variabler deklarerades tidigare i “Enter”). Så nu finns det en text och en osynlig ruta runtom texten. Nästa steg är att ge rutan några egenskaper!

Programmet kollar hela tiden vilket värde “selectedMenu” har. Den första menyn som visas har värdet 0, går man till exempel in på “Options” så ändras värdet till 2 och så vidare. Så programmet kollar om en sf::IntRect innehåller muspekaren genom att man skriver rektangelnsNamn.contains(musensPositionIBilden) och är muspekaren i rektangeln så byter texten färg och programmet kollar även ifall man trycker på musen inom rektangeln. Trycker man på rektangeln m_pHowTo så ändras “selectedMenu” till 1.

“Draw” funktionen håller också koll på vad “selectedMenu” har för värde, har den värdet 0 så ritar den ut den första menyn. När värdet ändras i “Update” och blir 1 så kommer “Draw” rita ut det som är deklarerat i if (selectedMenu == 1). För att kunna rita ut alla element i arrayn så gör jag en for loop. Den säger for (int i = 0; i < 2; i++) draw(howto[i]), vilket leder till att den kommer rita ut allt i arrayn tills i inte längre är mindre än två det vill säga att den kommer rita ut de tre element som deklarerades tidigare.

Väl inne i “How to play” så kan man trycka på “Previous” och “Next” för att bläddra mellan bilderna. Detta görs på liknande sätt som med “selectedMenu” men istället för att byta till en annan meny så byter den bilderna. Nu saknas bilderna för tutorialen men de kommer in idag och jag tror att det kommer hjälpa de som testar spelet att förstå grunden.

Vecka 7 – Fler Menyer

Ännu en vecka går mot sitt slut och projektet blir mer komplett för varje dag som går. Denna vecka har jag haft mitt fokus på menyer. Jag har gjorde startmenyn för några veckor sedan men för er som inte har läst det eller vet hur jag valde att gå till väga så tänkte jag förklara det.

Kortfattat så börjar jag med att skapa en rad text som visas på skärmen, genom att ladda in en textfil med fonten och sedan sätta ut den text på en position. När jag har skapat alla rader text som jag vill ska visas så skapar jag en fyrkant runt dem. Den fyrkanten kollar sedan om musen är i den rutan och ifall den är det så ändras textens färg till svart för att visa att den är markerad och tar man ut mus pekaren ur rutan så går den tillbaka till sin ursprungliga färg, vit. Trycker man i rutan så går man vidare, antingen till själva spelet eller till en annan del av menyn.

Den menyn som jag gjorde denna vecka var en paus meny. I GameState’s Update funktion så uppdateras hela spelet. Genom att lägga in en rad som säger while (!IsPaused) och sedan säga att den ska uppdatera alla objekt i spelet som behövs för att det ska hända något när den deklarationen är sann. Genom att göra detta så kollar spelet om det är pausat för den uppdaterar endast om IsPaused är false. Så när spelaren trycker på escape så pausas spelet och inget uppdateras.

Så när IsPaused blir till true så skapas text som visas på skärmen och musik pausas. Rutor skapas på det sätt som jag förklarade innan och spelet kollar ifall spelaren har tryckt inom dessa rutor. Det som visas är “Paused”, “Resume” och “Exit”. Paused visas för att säga till spelaren att spelet är pausat och trycker man på resume så startar spelet från det stället som det stannade på och exit stänger av spelet.

En paus meny är inte en nödvändig sak att ha när spelet inte är så långvarit men vår grupp kom överens om att det var en sak som vi tyckte var bra att ha. Det ger spelaren en möjlighet att gå ifrån spelet utan att behöva oroa sig över att förlora, en sorts frihet att kunna välja när han eller hon vill spela och känna sig tvungen att dö med mening för att kunna avsluta spelet. Därför tyckte vi att det var ett bra tillägg till spelet.

Jag stötte inte på några direkta problem under denna process, mest för att jag gjorde en meny tidigare. Ett tips som jag kan ge är att se till så du inte kollar efter musens position på skärmen, utan i rutan där spelet visas.

Code Review on Group 15’s game “Geneva Lost”

This is a code review on group 15’s project “Geneva Lost”. In this report I am going to look into how their player class is implemented in their game and the types of connections it has with other classes. Simply put; what makes the player do stuff.

Their player needs a few things to make it work:
It inherits from a base class called GameObject.
A Entity class which is derived from GameObject.
It also needs a DrawManager which renders the players texture onto the screen.
A SpriteManager is needed to create a sprite from a sprite sheet.
And a CollisionHandler which in turn checks the collision between objects.

So the first thing I noticed in their project is that they are not using a player class, they are instead implementing everything that the player needs to function as it is suppose too in the GameState. So the problem now is that if they were thinking about changing anything that has to do with the player they have look through the entire code in GameState instead of only having to change things in a player class. This also makes a very long list of code if they implement a lot of different entities the same way because now, everything the player does is written in the GameState.

In the current state of this project they create a player from a sprite, they move the player in the update function and they draw the player in the draw function all in the GameState. This means that in the update function they have approximately 100 lines of code to move the player. If they were to add an enemy that another player could control in the same way, they would have 200 lines and so on. In my opinion the way they should have done this is by having a player class where they define how the player moves and so on because now the GameState is not just for the player, it is also where they create the background, declare the enemies health, declare the projectiles damage and how it moves.

They do have a enemy class however but no player class so I guess that makes it a bit easier, but still, a player class is needed in my opinion.

Let’s say that a bug appears and causes the player to move in a weird way or something along those lines. It would be a lot easier to go through a player class that handles all that and look for the error. Instead they have to look through code that may not have anything to do with the player just because it is in the same place.

Even though it may not be troubling now to change the players properties but imagine you had a project four times as big and that the player has a lot of new things it can do. That would make bug fixing a nightmare and if one thing changes a lot of other thing may change as well.

To make this easier I suggest you make a player class, like you made an enemy class and do everything that has to-do with the player there. Then you can add what it needs there instead of adding it in the GameState which is considered high or tight coupling, since if something goes wrong in the players code the game would most likely not compile.

A couple of hours before deadline, I decided to check in with their project and see how and what they were doing and I noticed something. They have now a player class! The player class however doesn’t do very much right now, but at least they have one and that is great! The player class in its current state has an Update function that handles the movement and attaches a camera to the player so it can follow the one that is playing and we can see what going on. They also move the player in this Update function, they tell it that certain buttons will move the player in a certain way. I like that they started this at least, its a solid ground to build upon. However, the GameStates Update function also tells the player how it moves, by binding the same keys to the same movement. I don’t know if this was done on purpose, I doubt it was though because it’s reduntant code. But as I said it seems like they know what they’re doing and that they are on the right track. The code is very easy to read and understand but if I want to find something specific, like what happens to the player if I pick up this power up, it is going to be slightly more difficult. And I have to say that I really like the way you have connected your other classes like the GameObject and Entity. The game at its current state looks and plays awesome, can’t wait to see the finished version, keep it up!