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.
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.
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’.