In the game The Summoning the players are playing on a terrain made in Unity. The CharacterControllers in Unity can handle slopes upwards, but can’t do it downwards. This is the reason to why we need to create boxes on the map, so the players can’t walk out from it.
Firstly we created a object with a collider and gave it a layer which is called ”WorldBoxes”. Now we can decide what can pass trough the boxes changing the physics in the project. Then the boxes gets extended and are placed at the edges of the player area. The placing process starts with placing a block at an edge. Then the box gets scaled and rotated so it covers a large linear area. Lastly the box is rotated and placed, so it merges with the previous box and won’t create any strange edges which players can get stuck in. Now the players can walk on the map while not walking away from the game area or get stuck in any edges.
This method was also how we solved the problem with the demon being able to place buildings every where. Instead of having the hitboxes small and tiny we made them wide so they could cover large areas. These hitboxes would also get their separate layer to seperate them from the other boxes. Now when any of the players are Raycasting they will iognore this layer. This is just so that the building preview will not be floating in the sky and instead be on the ground where the player is aiming. The colliders of the previews will collide with the boxes now when a player is trying to place a building in these areas.
In the game The Summoning there will be a Demon player and a Human player, which will play against eachother. The Demon are able to spawn units and build buildings which can be commanded. To make this fair, the units will need to have something which indicates the HP, which is why a HP bar has been created.
The HP bars work in the same way as the normal HP bar for the Human, which means that they are Images on a canvas which can be filled. They will however hang above the units in the game, and not be static in the HUD. To do this we use the camera function WorldToScreenPoint, which is a camera function that returns the the position of a object in the world to where it is on the screen. By adding some extra space you can make the HP bar to hover above the units. This method have thou showed some complications, as the HP bar does not scale when you zoom in, and they seems to render above other HUD elements as well as trough the game objects in the game. The scaling has been worked on a little, as the bars scales up when zooming in, which makes it easier to see. But the bar is still to big and covers a lot of space on the screen. This will hopefully be worked on later, as it is a very little time left to work on this.
In the last blogpost I wrote about cleaning the Demon class and creating a FSM to make it easier to implement new states. Now I have been able to harvest what I sow. Now the Demon player can sling objects against the Human player to inflict damage. As a start I made a prototype on the sling in one of our offline test scenes beffore the implementation to the real game. This was mostly so that I wouldn’t need to bother with network stuff and other things which could have an impact.
At the beginning I created a new prefab and added a RigidBody and two BoxColliders to it. The RigidBody is for the movement of the object and also for the physics. Now the prefab will have a more realistic movement when the player slings it away and will be able to bounce of the walls. One of the BoxColliders are for the object to collide with objects so it doesn’t fall of the map. The other collider is set to ”as trigger” so it will be able to recieve signals from the mouse as well as the objects it collides with. Now when the object got these properties I can use the OnMouseDown function, which is called when an user clicks on an ”as trigger” collider. The object will then wait until the mouse button has been released beffore it starts to calculate the distance between itself and the mouse position, and then set a velocity equal to that distance.
When the prototype was done and worked, as it was itended to do, I started to create a new state for the Demon which is called Sling. The Sling state is called when the Demon player has clicked on a special type of rock, which got the previous script on it. The state calculates the distance between the mouse and the rock when the mouse button has been relaesed and then sends a speed to the script on the rock. It also checks, every frame, the distance between the mouse and the rock and then stretch an image inbetween the two to show how long the distance is. The picture bellow is when you drag the rock. The only problem with the Sling mechanic is that the rocks will disappear when you sling them to hard. The reason is as with the Human from one of the previous blogs: RigidBodies ignore collision physics when the velocity is too high.
This weeks’ blog will not be about the Human character, as the previous ones were, but will instead be about the Demon class. The Demon class was not as well planned and structured as other parts of the project. The reasson has been that no one has taken it as their field of work, which has made it into a class where codes got dumped into. I took the responsibility to clean it as the other members are busy with other code parts in the projects and it was really necessary to clean it. The class had about 1000 rows of codes and an update function with 400 rows, which made it very hard to work with anything that was related to the Demon character.
To start this of I created a new class which got would get called from the original Demon class, which was a simple FSM (Finite State Mashine). A FSM is a way of keeping track of states and limiting users/ mashines from doing things which they should not be able to do. This can be a player who should not be able to walk and sleep at the same time, so the player got one state for each of these actions and only one of them is getting updated by the FSM. Each state is a class which is getting a property from the same interface as the others, which makes it easier for the FSM to work. By creating a FSM for the Demon we are able to have more control over the player and it will be easier to create new actions for the Demon. Every state got a StateChanger class in them which is deciding in what state which should be the next one, it also got got other variables which can be necesary to remember when switching states like selected units or what building is going to be spawned.
After the base for the SFM was done I started to sort all the things, in the Demon class, into different state classes. All building related things got into a building class and all unit commanding stuff got into commanding class. Now everything is nice and tidy in the Demon class, as it only got 100 rows of code in total while having an update function on 3 rows. There has also come up some nasty bugs from this, like some things not showing up or working. This will however be fixed next week before the Pre-beta Testing. The problem is that the code, which was in the Demon class before the cleaning, were not only written by me. This means that I don’t really know what everything needs to work correctly. So next week will be some talk between me and the other programmers so they can explain what is missing (as they should probably know better than me). Bellow is just a quick painted image of how the system looks like when looking on the classes.
This week have been a real blast. Last Friday we had the pre-alpha gametest and we got some feedback on the game. It were both which they told us through the survey and what we noticed when we watched them playing. Most of the was about speed and cameras, which most people felt it was okeyish (as it needed small fixes), but some others were about gameplay and stuff. People seemed like they didn’t know what they should do, objective and controls, as there was no feedback for these things. Most of these things will be much clearer when we have got most of the mechanics and art into the game, but we will keep some of these feedback in mind to the beta.
In the last blog post I wrote alot about the Human character and this week will be no different. In the pre-alpha game test we got the bug where the Human could bug through the walls and buildings by running into them while nuking that poor little left mouse button. Players also thought attacking was more convenient than walking/running as they moved faster and could glitch through walls while doing so. This had to be fixed ,to the alpha, of course and it was. Firstly the attack state got a cool down to about 0.5 secounds as well as an movement nerf. Secondly two other attack states were added to the Human character. These attacks does not have any dash motions and are an attack combo. So the player will do an attack combo when spamming the attack button now. Thirdly and lastly the movement system on the character got changed. The Human character was moved by Unitys transform in the beginning, just because it was easy to do it like that. This is very inconvenient as transform just teleports the object without taking physics into consern. This was first changed to adding velocity to a Rigidbody, which also created some problems. The Human character would now not glitch through the buildings, which was great. What was not so great was that we will be using a terrain instead of building a map from our own objects. The terrain is very thin, which makes it very easy for a Rigidbody to glitch through when they have a high velocity. Rigidbodies seems also to not care that much about gravity, as the Human character could climb 180 degrees walls like some kind of Spiderman. This could perhaps have been becasue of the terrain not having any sharp edges where it rose to a mountain wall. This was however fixed by replacing the Rigidbody with a Character Controller component and using its Move function. Now the Human character moves smoth and doesn’t glitch through any objects or climbs any walls.
From last week the Human character also got some extra components: some sound effects, a model and some animations. This is some great improvements, as last friday the Human character was only a cube with a plank as a sword. It just needs the rest of the animations and sound effects, a little bit of balancing in movement and such, some HUD elements and maybe some more states then the Human character is done. This will be great as we will be able to do propper game tests to balance and improve the gameplay. The picture bellow is an ingame screenshot of the Human character in the spawning area. It is a little hard to see the character now, but it will be easier when the textures are added and the sahder has been modified.
Our game ”The Summoning” are an asymetric game where two players are battling eachother. One of the players plays as the Demon Lord whom is trying to kill the Human with an army of minions. The Human player has to stay alive while keep going forward to the Demon Lords’ castle/lair (work is still in progress on this area) and summon the Demon Lord. When summoned the Demon Lord is risking to die by the Humans’ hands.
As mentioned above, the Human player is fighting against the Demon player whom got an army of minions while the Human is playing alone. The Human player will need some help or great power, to make this a fair fight. As starters the Human player will have the ”regular rpg” set of skills, which are: walking, attacking, rolling, blocking and some special attack. These are very common mechanics, which are often seen in these kind of games, but they will work for now as we go in to alpha. As of now the Human can do all of the things above, except for the special attack (it’s still in discussion on how it should work), but they are still in an iterate state. Sadly they can’t be iterated yet as we still need the Demon part of the game to see how it will work together. Even so I can already see some things which will need some changes later on, as they are too powerfull or making other mechanics less relevant. For example the Human character moves fatser when attacking, because the attack does a little dash forward, than while running. By fixing the cooldown a little on the attack and also change the movement speed then it will become better. This will however be a little less priority as we need build more than polishing.
The picture above is a picture on the Human character. The purple cube is representing the Human player, and the plank bellow is the sword. When attacking the sword position itself infront of the player and then goes back to its original position. Hopefully there will come a model to the Human character and the sword soon, but this will probably be our placeholder until the beta. The graphical artists have said that it will be a samurai model, which will be very intresting to see (as a fan of samurais). Tomorrow the pre-alpha testing will be held, and we will hopefully get some great feedback on the Human character.
Denna veckas spännande artefakt har varit regnbågsasteroiden. Regnbågsasteroiden är en asteroid som är regnbågsfärgad och kommer att skapas slumpmässigt på nivån. När spelaren skjuter sönder den så kommer den att röja bort alla fiender (utom bossen), de andra asteroiderna, fiendernas skott och spelarens skott. Medan detta händer så kommer en chockvåg skickas ut ifrån regnbågsasteroiden för att symbolisera att den fungerar som en ‘screen clear’.
Jag började med att skapa en klass för regnbågsasteroiden som är baserad på den vanliga asteroidklassen. Anledningen till att jag använde den vanliga asteroidklassen som en mall för regnbågsasteroidens klass är för att de båda kommer att fungera nästan likadant, förutom att asteroiden förstörs bara medan regnbågsasteroiden kommer att rensa skärmen på motståndare. Det enda som har ändrats är att regnbågsasteroiden har nu en bool som tittar om asteroiden har blivit aktiverad (träffad av spelarens skott) samt en funktion som returnerar boolen. Samt så har ‘kill’ funktionen ändrats så att den sätter aktiv boolen till sann första gången som den blir kallad och sätter liv boolen till falsk den andra gången som den blir träffad. Liv boolen är till för att våran ‘AsteroidManager’ ska hålla koll på vilka objekt som ska förstöras och finns i nästan alla våra entiteter. Och inne i ‘AsteroidManager’ så skapas ett regnbågsasteroids objekt samt två animationsobjekt, en för regnbågsasteroiden och en för chockvågen som skapas när regnbågsasteroiden sprängs. Anledningen till att animationerna är i ‘AsteroidManager’ är för att minska antalet kopplingar mellan klasser.
Regnbågsasteroid när den är hel. Vanlig asteroid till höger om den.
I uppdateringsfunktionen i ‘AsteroidManager’ så skapas det en ny regnbågsasteroid slumpmässigt, så länge som de inte finns en levande regnbågsasteroid för tillfället. När en regnbågsasteroid skapas så får den en slumpmässig position samt en slumpmässig hastighet, vilket gör att spelaren kommer inte kunna veta vart ifrån regnbågsasteroiden kommer att komma. Regnbågsasteroiden uppdateras beroende på vilket stadium den befinner sig i, vilka är: Levande och inte träffad, levande och träffad samt död och träffad. När regnbågsasteroiden är levande och inte träffad så åker den på skärmen från en kant till en annan tills den är utanför skärmen, precis som de vanliga asteroiderna. Om regnbågsasteroiden är levande och träffad så slutar den att åka runt samt så ritas explosions animationen ut, istället för regnbågsasteroiden, medan den skalas upp till femti gånger så stor storlek samt så ändras en ‘clear’ bool till sant. När animationen har blivit femti gånger större så ändras regnbågsasteroiden från levande till död, vilket gör att regnbågsasteroiden förstörs och alla värden som ändrades när den blev träffad ändras tillbaka till sina ursprungliga värden.
Bild på explosions animationen.
När ‘clear’ boolen är sann i ‘AsteroidManager’ så kallar ‘GameState’ på alla ‘clear’ funktioner som finns i de managers som ska ta bort objekt ifrån skärmen. Genom att göra så här så slipper man att koppla ‘AsteroidManager’ till de övriga managerna, men skapar en funktion för just detta enda mål i ‘AsteroidManager’.
Denna vecka har jag för det mesta jobbat på små saker, vilket gör att detta inlägg kommer att handla om det mest intressanta som jag har gjort denna vecka, vilket är att kunna pausa spelet. Anledningen till att jag har gjort paus funktionen är för att vårat spel är väldigt intensivt och snabbt, vilket gör att spelare kanske vill ta en paus efter ett tag. Det kan också vara att spelaren behöver lämna datorn i ett par minuter på grund av toa paus eller andra viktiga anledningar. Och om spelaren måste då klara av nivån eller dö för att kunna lämna datorn så kommer hen troligtvis inte bli glad.
Jag började med att skapa en Paus klass. Denna klass är väldigt tom och innehåller endast en sf::sprite. Klassen innehåller en uppdatering funktion samt en ritningsfunktion. Just nu så gör uppdateringsfunktionen inget, men jag skapade den utifall om vi nån gång i framtiden kommer att lägga till några funktioner eller andra saker som ska uppdateras. Ritningsfunktionen ritar bara ut bilden på skärmen. Vi valde att göra en separat klass för paus då vi ville ha saker separerade ifrån varandra och ha saker självständiga.
Inne i våran ‘GameState’ klass skapar vi ett Paus objekt samt en bool och en float. Boolen är till för att hålla koll på om spelet är pausat eller inte och floaten håller koll på vilken knapp som har blivit tryckt (Detta återkommer jag om längre fram i texten). Så nu sätts allt i uppdateringsfunktionen i ‘GameState’, förutom biten som ser till att uppdateringsfunktionen returnerar sant till våran ‘StateManager’, in i en if-sats som håller koll på om spelet är pausad eller inte. Medan i ritningsfunktionen så skapas det en if-sats som håller koll på om spelet är pausat, men den innehåller endast ritningsfunktionen till Paus funktionen samt de knappar som dyker upp i paus menyn. Detta leder till att skärmen kommer att visa upp spelet med paus menyn ovanför, vilket ger skärmen lite mer färg och mer rolig att titta på istället för en svart bakgrund.
Hur det ser ut när spelet är pausat.
Och som det nämndes tidigare så har vi knappar i paus menyn och en float som håller koll på vilken knapp som har blivit tryckt. Dessa är dock skapade just nu i ‘GameState’, men kommer att sättas in i paus klassen senare efter andra viktigare saker. Detta kommer att göra så att paus klassen uppdateringsfunktion kommer returnera en bool som är sann om en knapp har blivit tryckt, samt så kommer en funktion som returnerar vilken knapp som har blivit tryckt att läggas in. Men detta kommer att fixas senare när tid finns, så knapparna kommer att finnas i ‘GameState’ tills dess.
Jag har tittat på grupp 10:s spelar klass för att leta efter vad som kan göras för att minska de antal bindningar som klassen har. Efter en kort analys så kan jag med säkerhet säga att den behöver inte ta in xSystem som en parameter i sin konstruktor. Man kan se att xSystem innehåller åtta värden, men klasen använder endast två av dem. Klassen skulle kunna använda flera av dem, men använder sig av andra saker istället (t.ex. finns det en keyboard pekare i xSystem, men klassen använder fortfarande sf::Keyboard funktioner vid inmatning istället).
Som klassen ser ut nu så skulle konstruktorn endast behöva ta in en SoundManager samt en SpriteManager pekare för att klassen skulle behöva fungera. ScreenWidth och ScreenHeight som finns i xSystem, fast används inte, skulle kunna bli placerade i en h fil som t.ex. ‘stdfax.h’ eller någon annan h fil som innehåller viktiga nummer som kan användas överallt i programmet. Sedan skulle SoundManagern också kunna bli borttagen ifrån spelarklassen, då den ska inte behöva hålla koll på vilket ljud som spelas upp. Det är bättre att spela upp ljudet i t.ex. en EntityManager eller något liknande, då jag förmodar att andra Entiteter i spelet kommer också att spela upp ett ljud när de tar skada.
Sedan längre ner i koden så har vi funktionen CreateSprite. Den behöver för det första inte ta emot xSystem, då det redan finns en m_xSystem i klassen som tilldelas ett värde ifrån en parameter i konstruktorn. Jag tycker också att grupp tio skulle ha gjort en PlayerState klass istället för att ha så många if-satser. Genom att ha en PlayerState klass så skulle de kunna undvika att ta in harpunen in i spelar klassen och istället bara ändra state till ‘HarpoonThrow’, för att byta till kastnings animationen.
Övrig Synpunkt:
Inkludera inte alla h filer i stdfax.h, som sedan blir inkluderat överallt. Det är inte bra eller fint.
Denna vecka har jag arbetat med vårt highscore system. Vad jag har gjort är att visa upp för spelaren de topp fem spelarnas poäng och namn. Detta har då gjorts med hjälp utav en textfil.
Textfilen
Jag började det hela med att skapa en textfil som innehåller namn samt poäng. Denna fil är då tänkt att innehålla all data som är för highscore. Så först har vi en Highscore state klass som spelaren kommer till om hen vill se de fem bästa spelarna som har spelat spelet. I dess Enter funktion öppnar den en text fil och börjar läsa den. I en loop börjas det att läsas poäng samt namn, som läggs in i en varsin lista för respektive datatyp. Efter att all data har blivit läst ifrån textfilen så stängs den, och programmet går till uppdatering samt ritnings funktionerna. I uppdaterings funktionen händer det inget mycket, den väntar bara på att spelaren trycker på mellanslagsknappen för att komma till Menu state. Det är dock i ritningsfunktionen som det mesta händer i. Att skriva ut namnen är inget svårt, medans att skriva ut poängen är lite svårare, detta på grund av att poängen är floats medan namnen är av datatypen string. Det är så att när vi skriver ut täcken på skärmen så använder vi oss utav sfml:s klass Text, och den tar bara emot char eller strings. Så för att kunna mata ut våra poäng så måste vi göra om dem ifrån floats till strings utan att byta ut siffrorna till andra tecken. Detta görs genom att skicka in poängen först till en stringstream och sedan använda funktionen ‘str’ innan dem blir strings.
Highscore
Något som jag fick problem med var att de sista poängen som skrevs ut blev väldigt höga. Detta var på grund av att alla poäng hade lagts på varandra, vill säga att den med högst poäng hade 1000 poäng och tvåan hade 1000900 fast hen skulle egentligen bara ha 900 poäng. Detta var för att stringstreamen krånglade, och det fixades genom att skapa den inne i loopen som ritar ut poängen istället för att skapa den utanför. Detta leder till att den skapas varje gång loopen loopas igenom, vilket innebär att den kan omöjligt veta de andra poängen. Det fanns ett annat sätt som dem berättade på webbsidan www.stackoverflow.com som går ut på att man använder funktionen ‘str’ och skriver in i parentesen std::string(). Jag vet dock ej om detta fungerar, då jag använde den nuvarande lösningen innan jag fick reda på den lösning, men lämnar den till de som läser utifall om våran lösning inte kan hjälpa dem.
Persson Programmering 