Continuing

Saving in Unity!!

Including enemies!

Continuing where the last post ended. The version then lacked most of all was enemies, they where not included when saving. As such it is not an functioning system, but that will be mended.

There are three different enemies in the game and they have different properties that one might want to save, though there are some parts that they share such as position. This would result in a class for each type so they are easily separated and they have their own data. But to start off it would be easiest to start with one class and enemy so there is less to keep track off (less that can go wrong and less to debug) and there is only one type to search for when finding enemies.

A class similar to the characters data class was created but with an added position (the rest was added later, start small to see if it works). The enemies needed a bit more work and control to make sure that all was saved and loaded, and that it was the ones that had been saved that was being loaded. Enemies that had been killed was set as inactive so they could be activated again when the player re-spawned, those that where killed and the player managed to reach a save zone was deleted, since there was no need for them in the game after this point.

Besides adding a position the enemies current state was needed, position so that the enemies appear in the same spot as when the player reached the spawn point (important if the game should seem to return to that state). The enemies need to return to the state they had when saving so that they are not continuing to attack or chase the player, which is not desired. The state does not necessarily need to be saved, a function that resets the state and then letting the logic run its course and reach a conclusion of what it should be doing. The enemy could however be doing something important though unrelated to the player and if letting logic run its course a different conclusion could be reached, resulting in it doing something other than it did before. So using a variable to hold the information about a state seemed better.

What task to choose?

The character saving system changed, some parts needed to be added and more options was included. A switch that allows the designer to choose if the player should start with full health or the health value when saving, this would enable testing what works best for our game and/or later add it as a part difficulty level. Quite a simple part but very important, when trying to find what works best.

This is what was implemented for now, more might be implemented later. Some of the parts that is needed are, interact-able objects (so they are in the same state and place as before), same with events that was activated after saving they should not be active when re-spawning so the saving script should have some access to the event handler that is used so it knows what events have been activated and save it.

The saving system is not done until the rest of the game is done since until then it has to update the different parts so that all the needed data is saved and loaded, which will change as the game changes. There is also the balancing with what data actually needs to be saved to a file and what could be reset to a default value in the object, it tends to be useful to have a function that can reset some values.

Onwards

Saving in Unity!!

This is going to be easy, no problems at all! Right?

Surely it could be easy

Since I mentioned it in the last post I just had to continue with creating an saving function, it seemed like a very intriguing task especially since I had never done such a thing in Unity before and not really in any other kind of engine (self-made ones included). So making this would be a great step in the process of creating games, if one wants to make a life creating games understanding this is quite essential. Most game needs some way to keep track of its progress, be it a player and its stats or a story and the parts of its narrative, so having some sort of basic understanding of what is required to make it work would be very helpful. Yes lets gain some experience in this field.

OK, our game would eventually need a way to save progress across levels and containing stats, skills and choices (since it an rpg, interaction with npcs should be considered), though that is in the future  so lets focus at the current goal of the game. It is going one level in our demo version so making a system that saves your level progress seems a bit unnecessary, and though it would have been fun to make it will have to wait. For now it is going to be a saving system that utilises save-points across the level where if the player enters one it will save the players data and that of the  enemies, would look pretty weird if entities that can be interacted with is not saved, enemies that had not been killed yet are gone or suddenly chasing the player even though not inside a distance that would aggravate them.

So I decided to start of with copying the players data into another gameobject, that way I could simply switch between the two when loading and saving (copy from and to), this when a player entered a saving point, Ahh we need to make some saving points as well.

Hmm, a basic saving point in this case is just a hit box that the player can walk into, though it needs a gameobject so it can have a transform and have scripts attach to it, so that it can be moved around, have different rotations and scales as well as having a simple way to distinguish each area both in the editor and in scripts.

Creating a gameobject with a trigger collider and a script that is meant to communicate with the main saving script, when the player enters an area a callback function is called which is connected to the main script and it can decide what to do next, I wanted to simply copy the player information into another player object or empty object. This was not quite possible in the way I wanted since if setting another object to the current just makes it point to the same memory address (though in c# that is not really visible or controllable) so it is still connected to the player instance and will change with it which was not quite what I wanted, another alternative would be to have another instantiated player object and just copying the values that are needed, but if doing that I might as well get started with a real saving function that saves the data outside of the engine, in a text document (which allows one to avoid having an extra instantiated player and considering data involved it is a good thing).

Moving on to researching how to save in Unity a solution was eventually produced (seems to be a lot of ways to do it and a bit complicated). To save data in unity one has to use a class that is serializable, which makes it so that Unity can process the data of the class and transfer it to and from a file (a serializable, class or object could as such be saved as an asset), besides this each type of data used needs to be serializable (obviously, though a bit unclear which data types are since it says that vector3 and the like should be in unity5 but that does not seem to work for me) so all the basic types are available but others are not certain, but since one can do practically anything with the basic types that is alright (though would be simpler if it worked immediately with vector3 than writing your own version).

So I wrote a simple class containing what I wanted to save from the player character, hp, name,  and ID, any more is unnecessary at the moment since all other is data held by the prefab and current object that would still be the same and not something the file need to contain. The name and Id are just to check if the player is really the right one. When loaded the player will be put at the centre of the current spawn point, with its rotation, and in an idle mode so things like speed and rotation is not needed (in a system where one can save whenever one wants it is needed along with other variables).

This concludes the first part of the saving system, a couple of zones and some of the players data being saved is a working system though one that is incomplete. It will appear a bit weird if it is only the player that is re-spawned, there should be other options.

Building Tools

Week2

Building some simple tools to help the project along.

Perhaps not so simple.

Continuing with the enemies, bigger, stronger, better!!! Nah, just improved a bit.

Well more of everything  is needed to make this project ready for alpha testing, so work work. At the beginning of the week we had a meeting with some of our mentors to discuss how we are going develop the game, in general terms and some details. This in turn brought us to have several meetings of our own where we tried to define parts of the game as we envisioned them, with a lot of thought on what is actually doable within our time limit. A major part of the discussions where centred on the combat system, which since it is an action rpg has some major influence on the game.

The game features a combat system where Kei possess a gamepad which can turn into weapons, so she uses a control to control the outcome of the battle. For the demo/ggc version there is meant to be three kinds of weapons, ranged, heavy and normal melee, which a meant to be used to form combos.

A few examples of how the weapons might look, the amazing works of the artists in the team

One thing I have been interested in since I found out about it has been Unity’s editor scripting, to be able to change and create your own editor tools, plug-ins and windows. All this seemed really interesting and useful, though exactly what kind of editors should be made for our game? I have a few in mind and the first one that seemed really handy was a pattern script, or waypoint nodes (whatever one wants to call it), which allows the user to place nodes in the editor that are saved to a list. But what use is this? What could one possibly do with a list of positions?

Well the truth is that in an engine where much is about positions, world space and local, one can create and use such a list to anything you put your mind to.

I found some videos and other references to base my work on,  in this Unite 2013, advanced editor scripting video there are a lot of information but they cover a polyline that places nodes in editor mode  that one can use, the presenter says he uses it to create a mesh for prototyping instead of waiting for an artist to create one. He bases his script on another ones, this is an early altered version PolyLine Editor.

There is a class called Handles, there might be several of this type I do not know,  which is very useful when creating something you want to manipulate in the GUI window. It can have many shapes (spheres, cubes etc) to give one a visible object to manipulate (not a gameobject, just an object), with that comes the normal arrows and such that lets one move and manipulate any object in editor mode, in other words a handle which is what it is, lets you do this to objects though this time without the actual object.

So with this I created a list of positions that easily can be moved around in the editor, which allows one to change the pattern and test how it works quickly.

Pattern and enemy moving along it.

Continued.

 

This might seem easy in retrospect but it was not, Unity has a basic introduction to editor scripting though nothing that really covers this, so if one wants to find about handles for example the scripting api is the place to go. That is an amazing and extensive library of information so finding something that you did not know existed or the name of can be pure luck. Instead I was lucky to find a video covering that had some of the information I needed (well I say lucky but I was searching through a lot of information about waypoint nodes and creating lists of positions for a while). There was a passage in the video that covered creating a list of nodes. As explained before a list of positions can be used for a lot and the person in the video said he used it to create his own meshes to use for prototyping, instead of waiting for a 3d artist to make one. There are a lot more interesting information in the video which really makes one think about what is possible to create for the project and further ones skills and knowledge.

 

Some patrolling enemies, sometime in the future ours will have so they can see in an arc in front of them as well.

This was not everything I put effort into creating for the project this week, even though it might feel like it, some of the other things was the enemies and prototyping properties for them that is going to be needed. There will be at least one ranged type of enemy and as such it would be useful if they could fire some sort of projectile at command. A cube is created and given material and script, the script defines the properties for that cube, what direction to fly, speed, damage, lifespan etc. A projectile is created, so now all that is needed is a gun, right? Not quite but it is one step towards completion. The projectile needs a spawn point relative to the enemy and the weapon, the muzzle of the weapon seems appropriate,  to achieve this a simple weapon prototype is made (a cube block that is stretched so it becomes longer and more rifle like ) and a empty gameobject is placed as a child to this which position is at the end of the weapon. This empty gameobject is made the spawn point for the projectile so the enemy script tells the gun to fire a projectile and it instantiate a specified projectile prefab, so weapons can have a specific projectile but still work the same. A spawned  projectile last a specified time, the enemy specify how long though later it will be the weapon that specify such. Later this will probably be changed to use some kind of pooling system to avoid instantiating and destroying objects, since Unity does not seem to be well suited for such process.

Well this is it I guess, there are a lot of work done each week and will probably continue as such, so hopefully I will make a bit more frequent posts to avoid these long ones. Especially since they do not cover the work to such an extent as to be of much use for people reading (including myself) that have actually found there way to this blog.

Start Working On A New Project

Week 1

This is the week when we try to start working on the project.

Since the project was only in a concept stage we needed to define the game.

So a lot of time was spent on meetings to give the team a unified vision and an overview of the project. One of the first decisions was to use Unity (not Unreal), this was due to the the stability of the engine and that we programmers had a bit more experience with Unity (only one previous project though). Moving on, a lot of decisions where made for the gameplay, narrative and level. What type of enemies should we have and how to progress through the levels? What type of weapons and how do they work?

We made a foundation for the project that we will continue to build on and evolve the features involved, until we are satisfied with the game and the effect it has on the players.

Could This Be GameTown?

After decisions of what and how comes the task of producing a backlog, using scrum, and defining how to actually produce these ideas and what does the tasks involve. As a programmer I has to figure out what mechanics makes the game work as intended, there can be quite a lot of mechanics needed to make a feature work or there might be very few, it differs a lot. For example a spawn point system is a very basic one for games, but how do they work? Well probably a lot differently from game to game, but in our game? You need a physical world area that responds to the player entering and when this event occurs save the players data. And that is it right? NO! To make a functional saving system a lot more is required, there need to be several checks to see if the system should actually save the data and connection to player character so it knows that is really the player and to know when the character dies and at that moment focus the camera on spawn area and set the saved data to the character, there are quite a few ways to do this and knowing what method is most effective and useful is difficult. Just the fact of saving the data is something that  has to be adapted to ones own game, as of now there will only be one level to our game so there is not much point in having a system that saves the data outside the current game and allows the player to continue where they left of before they shut the game off.

Is This The Robot Ai We Are Looking For?

After finishing a draft for the backlog we continued to create the basics for the game, what basics? Such as player and enemy movement, trying out some basic  attacks for both player and enemy, the camera was definitely needed since we did not want the standard view but rather a isometric view. So we rushed headlong into development.

Perhaps These Are The Ones We Should Base Our Robots On.

My job during this project is going to be as a programmer, though since we are all designers in training there will probably be some of that to. What task I will work on during the project is not set in stone (or at all), but for this week we are all starting up the project and trying to get some prototypes working.

The basics would need to be created to be able to see if our vision could hold, would the core of our game function and keep a player interested in the game. So both of us programmers started on movement, me just to get some basic movement when testing other parts and to learn a bit how Unity’s navmesh works since I plan to use it to mainly navigate the enemies around the game though perhaps the player should use it to since it contains a lot of useful functions.

Well more about enemies! Enemies can come in many forms and shapes throughout games and we have several in min, though to have a well polished game for GGC we plan to have only one main type that can be altered into different states and modes. What better for such a plan but robots? Since they can come in such a variety of shapes and types, easily changed from one model with a colour or small alteration without seeming out off place (unlike humanoids which might clash with the narrative and setting if altering them to much). Robots that are remotely controlled by gamers or hackers throughout the Gametown, seemed to fit perfectly into our theme, but what kind of robots? We made ours sphere shaped with arms, so to attack the character they start spinning swinging their arms around in deadly arcs. A hazardous experience for the player, that needs to watch out while waiting for an opening when they are not spinning since Kei’s reach is not far enough with the starting weapon to get past their deadly attacks and strike at the core of their being.

So I took upon myself to try and actually implement these creatures that stand in Kei’s path through Gametown, so I start off with some placeholders cubes and cylinders to represent player and enemy. Then giving the enemy a way to find the player, well to make that easy to start of just giving it access to the players gameobject through the inspector. As such the enemy had a target with a position it could seek, the enemy updates it position each update moving towards the player. This was a start but more was needed such as all the data the enemy would need and making much of that easily changeable, for example having an detection area for the enemy that which radius could be changed easily with slider bar where you just drag the bars handle to the value you want. With these things in mind I continued the work to bring these creatures to life.

At the end of the week the enemies had taken form, they could detect the player within a radius then switching to an attacking state in which they move towards the player until reaching an optimal attacking range and as long as the player is within the maximal attack distance. This is so that the enemies do not have to move each time the player does, since if always trying to stay at the optimal distance they would have to move continuously. Instead the enemy has both min and max distance, the min so that there the player can be to close for the enemy to start an attack which is quite normal especially for ranged units which has a distance when the effectiveness of the ranged weapon is lessened. Besides this the enemies has an attack, just an animation of a sphere with cylinders for arms that spins around, if the arms connect with the player damage is given and eventually can defeat the player. The opposite is true as well with player attacking with a sword and giving damage.

Setting up the animation with those basics shapes gave an insight into the animation system of Unity, which is really extensive. But it was really fun to try and also programming what should be played and the conditions for it.

Well this was an interesting start of the project and an eventful week with lots of research and things to learn, lets hope all continues like this with a new wonder to learn around each corner.

A Bit How We Imagine The Setting With The Camera View And Town Lights.

 

A new Game Project

!!I!!

As spring comes along and warms people up, it is time to start on a new game project to fill the days with endless wonder.

But where to start?

What type of project should one choose?

What to do with it and on it?

For a start it will be school project and hopefully after that it continues to evolve into a full game with all feature that can be appropriate and allowing the player to experience the vision of the designers.  As it happens GGC (Gotland Game Conference) is drawing ever so closer and to cap it off a whole course is dedicated to make games to present at this event, people form groups to work on a concept of their own creation that they feel passionate about (hopefully).

Though the road towards the destination is a misty and treacherous one with many challenges and obstacles that must be overcome (hmm, almost seems like a game) . To start of  the teams own goal with the game should be achieved as well as pass alpha and beta requirements to be able to exhibit the game to people, well one wants to create  a game as good as possible tat people really will enjoy and have a lasting memory of.So what concept should I dedicate at least ten weeks to? Well there was so many good concept made by my fellow classmates and amazing people to work with, eventually I found one that really got my attention.

Kei, an 3d action rpg that is literally a social justice warrior game.  The game name is the same as the main character’s, which seems appropriate when the game is about Kei and her journey and experiences throughout the gaming world.

Concept Draft:

This is Kei, Kei likes games. All kinds of games actually, as do most of her friends. But Kei is not welcome in GameTown anymore. In fact, she quickly realizes that most of her friends are not welcome there anymore either. “That’s not fair!”, she says. “Games should be for everyone!” And so she embarks on her quest to reclaim GameTown and open its gates to everybody.

This is intended to be something more than just a game for fun. Kei will take you through a journey a lot of girls will recognize when they decide to be a part of the gaming society. The intention is not to represent everyone’s experience but rather to take some of these issues and gradually introduce them through an action rpg format like for example conveying the feeling of being unwelcome even if it’s not said directly through environmental and character shape design. It is still pretty culturally accepted that games would be a “guy’s thing” even though that is really ridiculous.

Along with this concept comes a great team to work with and what seems like great possibilities and many interesting  challenges along the way, what would a project be without challenges? And the fact that it is a serious game is going to be a great experience that feels really interesting.

Memory – the abundance of memory an Illusion

Memory a subject approached with caution.

Without fixing memory leaks your program will continue to use more and more memory. DANGER!

Sometimes you do not have a real choice though and have to approach it, unfortunately I had to approach the subj

ect and try and find all the memory leaks in a project I and five others are making. This is because the program needs to be optimized in this way and as an assignment we need to remove all the leaks.

Memory leaks are memory that is allocated but not deallocated, in other words you make space for something but never removes it, this is a real waste. If you start a game and it has memory leaks they will continue to grow, the rate and way differs from game to game, in our game the main leakage was in the gamestate and if you go back to the menu and then start anew the leakage will double, since the memory from before was not freed new memory still needed a place, therefore it increases. The same amount of memory was created but the old was still there (kinda like your normal storage, old things tend to stay there while still new things are put in). This will continue to build on it self until the program or computer crashes which makes it essential to fix.

In our project there was about 4000 and now there are none (according to the program, visual leak detector that tries to discover leaks in your program). This is quite a progress but an tiresome one and should not be necessary to this extent. The deallocating of memory should happen as soon as you allocated something, this however was not the case due to bad forethought  and not enough experience but now more of that has been gained. With experience this kind of memory leaks will hopefully not happen and you only have to look for other ones (since there will always be some leaks before you fix it). The memory leaks was small in bytes but it is still a lot in my opinion.

Most of the memory leaks were due to an object of an class was created and not destroyed. In this case it was objects  of the class animation mainly, its objective is to make an sprite move (rather to give the appearance of it) and it contains a pointer to an image and all the frames of the animations (frame a piece of the image or rather the texture and coordinates on it). The game contains many of these and as such there were many leaks. Well the thing to do was to delete them, though this needs to be done in the right place otherwise you will get errors or bugs, deleting removes the memory for that object. The animation variables in the entity (character, enemies etc) classes where deleted when the object was deleted.

To the left an animated sprite is deallocated. This is done through checking if the variable is pointing to a value/memory or if it is nullptr (NULL for pointers). If it has a value we need to deallocated it by deleting it, that deletes the memory but leaves the variables, as such we need to make it point to nullptr to indicate that it is empty. The same is done on the right though with different variables when the enemy class destructor is called.

Our code when creating it:

“According to the philosopher Ly Tin Weedle, chaos is found in greatest abundance wherever order is being sought. It always defeats order, because it is better organized. ”
– Terry Pratchett (Interesting Times)

Visual leak detector is just like most program, it takes time to get used to and understand. How does it work ? What does the results mean? Did I forgot to include something ? etc. The visual leak detector demands that you include many things to get it work in your (IDE) integrated development environment, library files and includes and a few more things needs to be done before you can use it, for more info  Visual Leak Detector. Overall it is much easier to get up and running compared to other programs, though a bit annoying to have to do for each project you want to use it on. The real difficult part is interpreting the result and understand how it works. Vld will scan the program at runtime and at closing calculate how much memory you used and how much was leaked. The leaked memory is “explained” in blocks where it says how much memory just that part took up and then it shows the user the object causing the leak, then it goes back though the call hierarchy as shown below:

Output from visual leak detector.

The marked line is when the object in question starts its constructor, the above lines go deeper following the process that creates the leakage (the process of actually allocating memory for the object). Bellow on the other hand the process goes the other way, just below is where in my code I initialize the object (object = new Object). The reason for the explanation being like this is because the part above the line are practically unnecessary since that type of code are hard to follow and in this case ain’t needed since it is about an object being allocated but not deallocated as such all one needs to do is find the object and delete it. It would make it easier to read, but if one is experienced this will let you see if is about the deallocating or something else about the object.

Since I am not experienced it took some time to understand the output and program but now I understand more but still have a long way to go in understanding visual leak detector. I also need to get into the habit of deallocating memory allocated, though with going through all of our project I have gotten a bit into the habit of doing so.

“Time passing”

“Time is like a drug. Too much of it kills you.”

-Terry Pratchett, Small Gods (1992).

Time seem to fly past like the wind or float by like the sea, rushing past like the storm or gently flowing like the breeze. One tries to grab it and take control of it but it is a futile effort since it will never be something one can do, control over time is nothing more than an illusion that will make it self known sooner or later. When the time is like the sea all one can do is let oneself float on the waves since if one tries to swim or struggle against the currents the sea turns into a wild thing trying to swallow you.

Time often seems to be insufficient or in to much abundance but nothing to spend it on.

Animations

Spritesheet containing some of the monsters for our game

Magic writer is a game concept me and a group of other people are developing.

In this you play as a magician that has a holiday on a tropical beach. Unfortunately he is interrupted by monster invading the beach. Ah no holiday this time. The magician is skilled in summoning magic. So he uses this to summon objects and throwing them with magic on the monsters. By doing this the monsters will be defeated and the oncoming tide halted. Summoning is done by typing in the word of the item displayed on the screen.

The game would look dull and lifeless without things moving, instead of sparling with life and movement. So all entity classes (character, enemy, objects etc) had to be remade, since they used an sf::sprite (part of an image), and not an animated sprite that changes frames automatically. We use sfml in this project and it has no built in animation class but its homepage links to github (an opensource site, were people post code either for programs or library like sfml ) and it just so happens that a person has written a class for animation and animated sprite and posted it there. So i took this class and started to get to work, and a lot of work it was.

Monster freeze animation, frames taken from the spritesheet and played in a certain order

First of transforming the classes so that they take in a animation, animated sprite in the beginning but changed due to this being unnecessary since it only take in one animation sprite and can not hold more. The animation class can only hold one animation per object, it takes in a specified number of frame and the texture (image loaded into the program), the frames specifies what part of the texture and size that should be used at the time. So with all of this almost in mind I started to reform the class after testing it in the game state, where I just made several animation objects and switched which one the animated sprite should use. Animation class had a std::vector that held an integer rect that contained all the frames of the animation, this was the starting point since I wanted to make the animation hold several animations I made a std::map hold a string and std::vector with intrects, the string to be able to locate the animation it containing the name of it and the vector as before.  A vector containing all the names as well so one could get access to them or easily compare them. And a integer variable to mark which animation is active.

Another one, monster dying

There would also have to be changes to the methods of the class so that instead of taking in an intrect a whole std::vector containing the intrects for a single animation. A  function for returning the animation names, as well as one for the active one so that one can check if the that is active is active or similar. Then a lot of more changes ha to be made to make the whole thing work. A set active animation had to be added and that takes in the name of the animation you want to change to and then has to search through the map and try to find it, if not found nothing happens, if found it changes to that and sets the active one to the position in the string vector of the name. Made some more changes.

Eventually remembered that the animated sprite uses a time variable for how long a frame should be active and it is the same for all the frames, so if one wants to be able to have a specific time for each frame I figured that the animation should take in a sf::time variable, changed though till making the intrect and time to a pair and placing them in the variable that you enter in the add frame function(method). This complicated things a bit but I finally managed to fix it, the animated sprite then takes in the pair when collecting a frame from the animations and puts the member time variable to the time from animation, this allows me top put a time in for example a text document and loading it into the program, where I can easily change it compared to if I always has to change it in the program. Minor changes where made to the animated sprite class compared to the animation class.

Overall this process went all right and I now have a functioning animation class in the game and felt it well worth the effort.

The changed classes:

AnimatedSprite,cpp AnimatedSprite Animation,cpp Animation

Power-ups

One of the real monsters in the game

Magic writer is a game concept me and a group of other people are developing.
In this you play as a magician that has a holiday on a tropical beach. Unfortunately he is interrupted by monster invading the beach. Ah no holiday this time.

The magician is skilled in summoning magic. So he uses this to summon objects and throwing them with magic on the monsters. By doing this the monsters will be defeated and the oncoming tide halted. Summoning is done by typing in the word of the item displayed on the screen.

In this game there are supposed to be at least three power-ups and some of them are connected to the items that you throw. First it is a freeze power-up that freezes every monster in the character’s field of view rendering them unable to move. The second power-up is called pierce and is supposed to go through all the monster in one lane and dealing damage to them. The third was supposed to be a power-up that makes the item thrown bounce on every enemy on the screen, it was however decided to make it into a power up that shoots at all monsters at once a multi shot.  At the moment it is changed to be lightning bolts that hit every enemy on the screen.

These power-ups needed to be implemented in the game and exits now though they are not complete, there needs to be more balancing as well as more graphical feedback when a power-up is activated.  The freeze for example needs to actually be seen freezing the water for the player to understand what happens, at the moment the monsters only stops moving like if the magician froze time for them (which would have been a great feature though it also would have needed more visual feedback for the player to understand what’s going on). So this needs to be fixed, the power.ups in them self works they are activated and do something but they need to look better.

I begun with creating a class for power-ups and a manager to handle them, this to more easily manipulate them since the class can contain all data belonging to them instead of like when doing a prototype and writing everything in main and everything is scattered around. Now we got a class with all data and functions, there are timers for cooldown and sprite to show the heads up display (HUD) version of the power-up that show when it is possible to activate and the cooldown. The timers are for how long the power-up should be active and for how long the cooldown, when activating the power-up it checks if it is active and if not activates, when activating it starts the timers at a certain number and then counts down until zero. When the first timer reaches zero the power-up stops having an effect in the game. When the power-up is activated the HUD version changes sprite to one that shows that you can not activate it.

Since no good lightning is implemented in the game this is an example of how it could be when the lightning strikes

Sketch of magician holding an item and planning on throwing them on some enemy. Power ups are the three round balls in the left corner and below are items that can be summoned

 

The power up manager handles the power-ups and lets the gamestate know that the power-up can be activated as well as when it is activated. It also creates lightning that hits each monster on the screen, for this it get the position of each active monster in a list as a parameter and uses a sprite and renderstate were it transforms the position of each strike. Renderstate lets one use one sprite and produce it on several different locations and can shape them differently, so I do not have to have several sprites taking up memory space. The bolts do damage when they hit and is implemented in the gamestate, it checks if the power-up is gets activated and then removes some of the enemies life, since the attack is instant it does not have to be at collision but rather when activated so there is not any risk of it happening more than once.

 

Why not add some Enemies

Magic writer is a game concept me and a group of other people are developing.

In this you play as a magician that has a holiday on a tropical beach. Unfortunately he is interrupted by monster invading the beach. Ah no holiday this time.

The magician is skilled in summoning magic. So he uses this to summon objects and throwing them with magic on the monsters. By doing this the monsters will be defeated and the oncoming tide halted. Summoning is done by typing in the word of the item displayed on the screen.

I have worked with getting the monsters into the game and making them do what we want them to do.

The monster are to move in five different lanes down towards the player. Their purpose to attack the beach and when reaching it the player loses a life. Monsters have a certain amount of life. The basic monster has ten hp, the speedy monster has one hp and our tank monster has five hp. Monsters have different weaknesses and if hit by an item with the same weakness property it takes more damages, normal damage is one. The basic monsters have a certain weakness throughout the game. The tank gets a random each time it spawn and the speedy has none since it dies on one hit.

The first thing to begin with was creating a class that inherit from entity and are for monsters. In entity there is an enumerator (basically a list of numbers with a name) that specifies entity type. So monsters are set to entity type ENTITY_MONSTER. At least at first since later we will have different types of monsters and if they have different types they can have the same class but different properties depending on the type. But I feel it is better with a type for the monsters in their own class and they are set to that when created and has a set of properties for each of those. Different hp and movement speed for example.

Enemy – the code class

The monsters have five lanes that they use, so I use a class that I created to hold positions in the game and when activating a monster setting it to one of these lanes. The position is above the screen and gets a one of the five lanes at random. The speed is set at an initialize speed and increases the speed with the time passed. This to let the speed be dependant of the time so the game becomes more difficult the longer you play.

The weakness and life part is not implemented yet, so the monsters dies after one hit.  The enemies will have to spawn less frequently when that is implemented to better balance the game.