Cybersaurs Player Testing 1 Analysis and Reflection Part 1

Not too long ago we had our first play testing of Cybersaurs, and with that gave us a great opportunity to test the dynamics of our game and get a clearer look on how players react when thrown into these team based situations and how our game design worked on teaching the players how to play our game. Throughout this first blog I will be reflecting and analyzing the game and design chooses that didn’t work as intended and what became an issue throughout this first play test. Explaining what happened, what lead to this happening, what was the cause and possible solutions for the future.

Gunner Controls:

Gunner Rotation – it was evident that most people who played the
gunner role for the first time were completely confused in terms of controls and how to shoot. multiple players were seen just flicking the analogue stick in a direction and expecting the cannon to move, it did not. which lead to much confusion on how the gunner was expected to move the cannon. What lead to this was a lack of information given to the player though our instructions page as it only showed a controller with arrows pointing outwards on ether side of the right without any text or images for further instructions. Therefore, naturally, the player would assume the rotation would
be instant.

The main cause for this issue is a lack of any form of audio or visual
feedback to the player to help indicate that they are doing something. If a player moves a stick or presses a button there needs to be some form of instant feedback the player can use to determine that something is happening and a lack of it would only cause the player to think that nothing happens or they are not controlling it right and will proceed to use other controls to get try and get some form or response from the game. This is bad, you always want the players to have some form of pre-conceived notions on how to play before they actually get into the game itself, we decided to use a instructions screen but for this to be used effectively the information in it needed to be accurate.

Possible solutions to this issue would be to create and implement both audio and visual feedback the player receives instantly when attempting to rotate. This can be in the form or gears cranking to sound like the cannon is getting ready to move or an arrow pointing in the direction the cannon will move in and have it full up over the time of the delay. Along with this incorporating the word “HOLD  DOWN” into our instructions page would tell the player that the controls are not instant and would be delayed. However there was times that players didn’t use the instructions screen and went straight into the game itself. Other solutions to this are:

• Artifical loading screen to show all controls before moving into the game.
• Player Select Screen to allow what role each player wants before going in and displaying there respective controls.
• Having the controls on the game screen itself means that players would always have access to them and have an easier time figuring our what to do.

Gunner Shooting – the issue was that players would often just press or spam both the triggers or bumpers on the controller and not see or notice the charging bar underneath their teams health bar which caused much confusion on how the player was meant to fire the cannon.

There were multiple elements that lead to this happening, Firstly, our instructions page only had an image of two arrows pointing at both triggers on a controller but their placement was more on the central on both triggers leading people to think that the bumpers were needed. Secondly, there was no text to indicate the player needed to hold down the triggers in order to shoot and instead most people ether pressed once or spammed the triggers hoping something would happen. Lastly, the charging bar was just underneath the teams health bar and was a lot smaller in height. This meant it could be easier to miss and not notice as the gunners attention is focusing on the cannon itself and where they are aiming instead of on the their teams health.

Along with this the charge bar would fill up with a yellow bar, which was chosen by me. I though yellow would be a good colour as our early
mock-ups for our level had our UI off the level itself and on the background which would be space and therefore would contrast nicely of the black background and be easily visual. What actually happened was due to the lack of assets and a proper level design, we put a number of placeholder assets in to fill the gaps with lead the background to become a large orange, red
and brown landscape, like the surface of mars, and made it very hard for the players to see and distinguish the yellow charging bar.

Possible solution
s to this issue would be, firstly, add more information to the instructions screen, this could include having images on both triggers and the word “HOLD DOWN” to help tell the player they need to use both triggers instead of bumpers. Adding similar pictures onto the main game screen so the gunner can always see what buttons they need to press could also be useful as they will always have access to it. Secondly, moving the charging bar to somewhere where the gunner can see it much more clearly and not have to look away. An ideal spot would be having a charging bar on the cannon itself, this would give instant feedback to the gunner, and driver, without having to move their attention away from the game and gives a clear indication on how long it will take to fire the cannon so the driver and gunner could then coordinate when to move to get a perfect shot.

Overall the gunners controls were the biggest issue with our first play test, due to a lack or miss interpretation of the information we had gave the players.

How we Brainstormed, Designed and Pitch a Game in 3 Hours

Last week me and my team, Team Dinosty, had three hours to take our game ideas, throw them at a wall, see what stuck, design a game around what stuck and pitch to a full room of people, its was an interesting experience.

Concept

Before we began, we needed to figure out what type of game we wanted to make. We started by throwing all our ideas onto a wall and seeing what we liked about each of them. More specificity we were looking for aspects and mechanics that can be used or changed to create an interesting experience and how we could we could change the dynamic of it to fit two players. This would often involve looking at a relatively simple single player task and trying to incorporate a second player in a way that makes scene and adds to the game rather then hinder it. This means splitting the process of that task between the two players or coming up with a new mechanic that the second player would need to do. Ideas we came up with include:

• Gold Collecting – One player is in control of a mine cart, they ride around a circular mine area trying to pick-up gold pieces on the ground while staying out of the way of falling rocks and explosives. The other player is on foot trying to use dynamite to extract gold from ore veins and push that ore into their teams mine cart while also trying to hinder to the other team.
• Tank Game – One player controls the movement of a large tank where as the other player is controlling the main guns and cannon of the tank other using similar tank controls. Which ever teams destroys the enemies tank first wins.

We ended up going with the tank game as it fitted more with what we wanted to do and what was specified in the brief. We choose it because, we felt at the time, it encouraged more teamwork and communication between both players on the team. This would lead to strategies being formed and timing a positioning would play a major part of winning. However there was more to this as we have learned, Due to how polar opposite each players responsibilities are, one trying to move the tank into a position where they cant be shot and the other trying to aim and wait for the perfect time to shoot. This causes friction within the team right from the start and it will be interesting to see how this friction influences the game-play.

Planning and Design

Now that we have had our core game concept and ideas we needed to flesh it out and design it into an actual game. We started with influences, WoT and Tank Tank were the two main influences we had when designing this game.  Tank Tank for the top down 2D style and bouncing bullets and WoT for the aiming, timing and position aspects. We choose 2D – Top Down as it was the easiest way for use to show each player on a single screen and therefore can easily build around that perspective. We wanted bouncy bullets as it added an extra dynamic to the game where the player can use the terrain and walls around them to kill the enemy and finally we decided on a semi-large circular map as we couldn’t use a square or rectangular map and it could cause some interesting strategies and rebounds for bullets.

After that we have the controls, we wanted to do a version of tank controls but for a hand held controller, in this case its using both analogue sticks. we decided on this as we wanted the player to be more engaged with what they were doing and having the player use both analogue sticks to perform an action fits this nicely. We wanted the same controls for both as when both players swap positions they would still have a decent understanding of what they need to do and wont be completely stuck when the game starts.  Lastly our designer encouraged us that that we should change the premise of the game to make it more over the top and and strange which I was all for as stranger premises tend to get more attention due to their unusualness. So from tanks we decided to make the premise Cyborg Dinosaurs with Laser Cannons Fighting each other on a Floating Asteroid.

Pitching and Presenting

Now that we had our game, we had to pitch it to an entire room of audio, animation and games students and facility members. By this point we had roughly 15 minutes before be pitched so we didn’t have time to write a script or practice so we decided to write down each of the key points about our game. This involved the Premise, Controls, Bouncy Bullets, Map and other general pitch information like target audience and market. We then just took turns talking about each aspect of our game, looking at the sheet to tell use wants next. The pitch itself could have gone better by:

• Talking more about the experience you will have rather then how you would make the experience by talking about the controls for too long.
• Timing it a bit better as we ran out of time and couldn’t talk about certain topics like target markets and audience along with other game play features.

Overall its was a great experience as I learnt a lot about designing games with other people in a short amount of time and that will help me in the future when im sure to have to do something similar again.

Azmodan Pitch / Presentation Reflection

Like most games before their made, they need to be pitched first and that’s no exception for my game Azmodan. Overall I believe I did great and this was further supported when reviewing over the footage of my pitch later on. I didn’t stutter any words or lines nor say, “Ummm” or “Ahhh” nor needed to look at my notes for guidance as I had practised and memorized my pitch  a few times over.

Lets start with speaking, as I mentioned earlier I’m proud of the lack of stutter or or confusion when I spoke. This is something I constantly strive to do whenever
I do public speaking as it means I feel more confident and the message is received more clearly. My methods on doing this involve, practising what to say until I have memorized it completely, doing this  means I know exactly what to say and it helps give me confidence when speaking it in public as I’m not reliant of my notes for the information along with allows me to pace my words and sentences correctly so they don’t sound to fast or to slow.

Another small factor would be my breathing, its hard to talk if you are out of breath and I tend to take a few deep breaths prior to speaking as it helps stop a few of the nerves. In terms of complains:

• I could have spoken a little but louder as though the video I seemed a little hard to hear.

In terms of my body language, I kept and straight posture throughout the time I was speaking my pitch and I only used my hands when performing simple gestures or pointing to something on the board. Why I control my body language like this is that it allows me to illiterate or point things out when needed along with give me more confidence as im not worried about what I might be doing with my arms or hands. Controlling body language takes time however as it something that you must be constantly aware of it when public speaking and though practising. A complaint however would be that:

• my body language completely changes after I finished my pitch with a slanted posture and crossed arms which, in my opinion isn’t all that impressive nor professional and ill need to look into it for the next pitch.

I was glad to see that most people enjoyed my pitch and liked my game idea as shown though the feedback and how most questions were about way of tweaking or improving the game. This told me that the information I used was well received and that people understood the game and what I wanted to do. This would have been added my the pictures and illustration I used to help convey the mechanic or feature. Some complaints would be that:

• I didn’t use my entire three minutes and instead missed out on adding additional information to help give an even better idea on my game how it works.

Overall I believe I did a great job with my pitch in proper speaking, good body language and a well made slides that help explain a particular mechanic or feature but could do better in how softly I speak,  Add more to the pitch based on my time limit to get the most out of it and could be a little more specific when answering questions.

However the same cannot be said about my game presentation that happened a week after that. Unfortunately due to my lack of preparation or planning into the presentation and all me effort going into the play testing of my game I didn’t have, in my opinion, a suitable presentation that correctly outlined all the tweaks and changes that I had made in my game since the pitch.

Unfortunately everything that I believed I did right in my pitch I didn’t do in my presentation.

Three Different Game Concepts for Project 2

Local Multiplayer Game

2v2 Teams

One player’s actions are instant and the other’s are delayed

Idea 1 –   2D, Top Down, Sniper / Maze Game – A game where two players on each team run around a large circular map trying to grab and hold onto a flag, by running over it. Holding the flag gives points and who has the most points at the end wins. The other team player’s are using super powered, high tech rifles from a distance. These players are tasked with helping or hindering there other teammate by shooting shit. Due to the power of the rifles however they are on a delay of 3 seconds before firing after the trigger is pressed, this gives room for prediction, strategy and positioning to play major factors in winning the game. Along with this are power ups that can be pickup by both the runners and the snipers:

• Speed Boost – Runners can pick this up and gain a temporary speed boost that allows them to close or gain distance based on your current position. Snipers can pick it up for a delay reduction for a short period of time from 3 seconds to 1.5-2 seconds long.
• Inversion – This causes everyone’s controls, but the who picked it up, to become inverted for a short period of time. Beware this effect does happen to your teammate.

The style and theme can change quite easily though the planning state to match anything we want from gritty realism or super colorful.

Idea 2 – 2D, Top Down, Mine Cart Game – One player on team is controlling a Mine cart were the other is on there own. The player controlling the cart has to move the cart around and pickup gold ore, the cart uses force and torgue, movement starts slow and builds up over time, This is were the delay comes in. The other player has to expose and push gold into the cart, they can do this by finding an ore piece and pushing it along, the level and ore are bouncy, or to expose more ore they can use dynamite, once dropped it has a 2 second timer before blowing up. dynamite is dropped on the players location. If a cart smashes into a wall or rock or get hit by dynamite will have there gold exposed to everyone to grab. Games played are on a time limit and who has most gold at the end will win.

Idea 3 – 2D, Top-Down, Tank Game – Two players are needed to work together to control a malfunctioning tank. One player controls the movement of the tank using similar tank controls and due to it malfunctioning it has a small delay when trying to move. The other player is trying to control the main and side guns of the tank. using similar controls the player must continuously re-rotate the main cannon of the tank as it is always slowly rotating in one direction. This player can also fire the main and side guns, Main deals a large amount of damage and has a recharge. Side can constantly fire dealing very small amounts of damage. the level is a destroyed city will walls and rubble for cover and fire team to destroy the enemy tank is the winner.

Game Analysis – Bees Need Friends Too

Throughout this game analysis of Bee’s Need Friends Too, I will be discussing the games mechanics in how they work along with how they teach the player how to play the game. Along with this will be discussion on how the game is currently talking about the games style, tone and over all experience.

Firstly, BNFT is a single player, 2D, arcade game where you play as two bees wondering around a field, trying to collect pollen. This premiss is simple and easy to understand and provides a nice base for the player to work on. The major mechanic of the game however is that the closer the bees are to each other, the more flowers that spawn meaning more pollen to collect meaning more score for the player and when they touch the player looses score. This is an interesting mechanic as it adds a layer of challenge to the game, keeping them as close together as possible without touching, while giving a good reward for players who do it properly, more score.

How this is shown though game play is the use of multi-coloured flowers. While separated the player is only able to see red flowers scattered around, however then closer the player then starts to see more colour of flower appear like yellow and green. This is a small indicator that the player that both bees are close enough and the player can pick-up more flowers. Another small feature about this mechanic is picking up flowers, slightly pushes the bees based on the direction they were pick-up. This forces the player to constantly make small shifts to the bees to make sure they don’t collide adding to the overall experience instead of simply moving them around with no resistance.

The issue with this mechanic however comes in with its implementation. There is nothing that indicates or signals to the player that you need to move both bees together to get the benefit nor how close they need to be before it starts. This would be a major issue for new players as they wouldn’t know that this mechanic even
existed. Aside from this, whenever the bees move to far apart they disappear and yellow line indicates the distance between both bees. This was slightly confusing when I first saw this and im nor sure why it is there.

In terms of movement, the controls were fast and responsive with the subtle ramp and decline of acceleration when you begin and stop moving. This help give the feeling of controlling two actual bee’s, perhaps not to the most realistic degree but, it still give that effect.

Scoring also play a major role as the main reward given in this game. Collecting flowers grants score and colliding both bees causes score to be lost. This is a very basic set-up as there isn’t must the player can do to manipulate or do that’s different or interesting for more score however it still works. How the player is shown this though game-play however is once the both bees collide they turn red. This is a simple but effective visual queue that something bad has happened as red is usually accosted with something has gone wrong, In this case it is score deduction.

The issue with this is that the score is located in the top left hand side of the screen and all the player’s attentions is focused at the centre. Meaning that the player, at first glance, won’t really understand what was the negative effect of both bees colliding and therefore not really bother about that mechanic until they realise.

In regards to the games style and tone, the theme of this game is very colourful and cute with major use of bright and happy colours, yellows and greens, and cutesy assets and models, wide eye bees and multi coloured flowers. This along with its great music gives the game and very calm and relaxing tone. This then translates to the experience itself as while playing I never felt rushed or worried as the each of these visual and audio queues allowed me to relax while playing the game.

Over all BNFT 2D, top-down bee game that utilizes a proximity mechanic and gives a calm and relaxing experience despite issues with its implementation and visual queues.

What I Want to be When I Grow Up

Ever since I played my first game, Mario Sunshine on the Nintendo Game Cube, I knew that making games, experiences and entrainment was what I wanted to do with my life and that hasn’t stopped now. This mind set and way of thinking has been with me ever since I was young and has persisted with me throughout most of my life and with it allowed me to make a number of important educational decisions.

This is because I have a clear goal in mind for what I want to be, Game’s Programmer, I understand what isn’t exactly clear as there are many different types of game programmers, like AI, Game play, Engine, Software, etc, but due to programming becoming such a passion and hobby for me over the last couple of years I don’t want to restrict myself to one specificity until I’ve had experience in each of these fields but if I had to pick I would like to be involved with the Game play and help create the mechanics of a game.

There has been a number of steps I’ve taken to get this far and there are many more to come. For starters, in terms of programming that started during high school where we would code in visual basic and create small projects from scratch. As an avid fan of RPG’s I decided for my final project to make a small, four level JRPG with a tradition turn based combat system and items, talk about over scoping. I finished it though and even if it was held together by threads, it was a great experience and what originally made me want to become a programmer.

Moving on from high school I went and did a, Diploma of Interactive Digital Media at GCIT. It was short but I learn the basic of HTML and Photoshop along with Presenting and some documentation skills that I still use today. Finally, now im doing a Bachelor of Game Development and SAE Quntm learning how to properly design and develop game and experiences for people to enjoy.

After this I plan on trying to find a job or intern ship at nearby studios, like Lightmare and HalfBrick as a games programmer and bring my new found knowledge to with me to start helping make games. With this I hope to gain experience working in this field and eventually I would want work for some major AAA developers like Blizzard, Bethesda, EPIC, etc, but that is a long way away.

Other possibilities in the future that could happen, solo work and try to develop my own games. The advantages of this are:

• I get to make what ever I wanted or felt like
• Work on my own times and schedules.

The disadvantages however:

• Based on time and scheduling, the scope could cause a major issue with being to big for a solo person.
• No group experience is gained unless hired from outside sources.

More possibilities include working with friends and people I know, I’ve met many people would want to work in this industry just like me and getting together with these people could allow us to make some great things. Advantages:

• More people means more work that gets done, larger scope, and different perspectives and talents

Disadvantages:

• Timing and scheduling could be an issue as the people would most likely work at different times and cause a lack of work.

Aside from that there inst much else I can think of at the time. Thanks for ready this blog about what I want to become and the small steps Ill take to get there.

Azmodan Self Assessment

Over the past week, working on my game, I noticed that there were a number of improvements to my work ethic and time management which allowed me to become more productive and get most of the my game’s functionality done on schedule. However despite all the improvements, my time management is still not were I would like it to be, in terms of timing and pushing my self to do it, which did lead to less work being done at certain points and on top of that I was also easily distracted by friends and games which caused the same effect.

In terms of my strengths thought out the project, my decision making and problem solving skill were much better in comparison to previous projects. Since I had free rein over this entire project, besides the aspects of the brief, I was able to get really creative with the systems I could make and how to build them, A good example of this is the Spell Creation and Firing System using OnTriggerEnter2D. Whenever issue came up I was able to quickly solve and come up with a solution or work around to the issue that was in more ways better the last, an example would be replacing the pickup system of “if” and “else” statements to public functions that can be called anywhere.

In terms of my weaknesses throughout the project, as I mentioned previously, my time management was better and I was able to push my self everyday to work on it but the amount of time I worked on it varies day to day. Ideally I would like 2.5 to 3 hours a day as it would be the most efficient set up for me, but throughout the week, sometimes I would easily do 3 or more hours and some would only be 1.5 which isn’t what I want. Solutions im putting into practice are changing my personal work schedule to suit my current class times better and my personal life, aside from that is to keep pushing myself to do more and more work each time.

The other major weakness was I got easily distracted throughout the week ether though wanting to play games and talking to my friends over steam and Skype. This was an issue as I didn’t complete as much work as I would have liked in that time and therefore had to do more in the closing days. Solutions I have come up with are keeping steam and Skype, along with any other games related thing, closed until I’ve finished working and just to keep pushing my self not to get distracted.

Things I need to work on, my Time management, Improving that would allow me to become even more productive with my work and therefore get discover and solve new issue even faster. Force myself to constantly keep working until its done. Reschedule my personal work timetable to suit my current classes and personal life and do more research on new way and methods on creating various systems for future projects.

What I planned to after the project was completed, was update the game based on the play testing feedback, like the UI being in a bad spot and players not getting to see or use power ups. Aside from that is to keep learning.

Thank you for reading my Self Assessment on my Studio 1 Project 1.

Azmodan Spell Creation and Firing System Explained

One of the most interesting and unique parts about my game, Azmodan, is its spell creation and firing system and despite me originally thinking, and working on first, one of the hardest systems in my game,

it turned out to be one of the easiest to design and code. Throughout this blog I will be going over how I designed and coded this system along with other handy tips when trying to do something similar.

Firstly the player needs to be able to move both hands along the X axis in order to aim and lineup there spells. There were a number of different methods that can be used for this but the one I used was, Input.GetKeyDown. e.g.

if (Input.GetKeyDown(KeyCode.W)) 
{
    leftHand.Transform.translate (speed * Time.deltaTime, 0, 0)
}

The above code checks for when the “W” is pressed and when so moves the left hand along the X axis until the key is lifted. Using this method allows me to setup each individual movement keys for both hands and gives me more control over what happens when a movement key is pressed. Other potential systems that can be used are, Input.GetAxis(“Horizonatal”). e.g.

transform.Translate (Input.GetAxis (“Horizontal”) * speed * Time.deltaTime,0,0);

This method works the same and is even easier and simpler to write then the one above. However the issue with using this is, Input.GetAxis(“Horizontal”), takes into account both W,A,S,D and Arrow Keys without any separation so using this would cause both my hands to move at the same time in the same direction. But is useful when only working with a single avatar.

Secondly I decided on having a center point what would always be in between both of my hands. this is used as a way of judging how close and apart both hands are and gives an easier identification on when the hands are close enough. I started with
making a small GameObject, giving it a large box collider and turning it into a
trigger. This means that it cant interact with other physical objects unless told though code. I then worked on making a script that would all ways transform the position of the object to be in between both hands.

This involved getting the location of both hands. e.g.

Vector 3 leftHandPos = leftHand.transform.localPosition;
Vector 3 rightHandPos = rightHand.transform.localPosition;

Then using some basic maths to get the location in between both hands. e.g.

centerPoint.transform.position = 0.5f * (leftHandPos + lightHandPos);

Once the center point is moving in between both hands I could then change the size of the box collider to suit how close I wanted the hands to be before making a spell.

Thirdly are triggers and instantiating the spell, This involves setting up box collides on both hands and setting them to triggers. After that I decided that the easiest method to use would be OnTriggerEnter2D(Collider2D other) and OnTiggerExit2D(Collider2D other). These are condition functions that check if a 2D object has entered and exited the collider of another trigger.

Using these I was able to check if both hands have entered the collider of the center point or not. e.g.

void OnTiggereEnter2D(Collider2D other)
{
    if (other.gameObject == leftHand && rightHand)
    {
        beginProcess = true;
    }
}

Once the process begins I can then run a timer that , once finishes, instantiates at the location of the center point. e.g.

GameObject spellClone;
spellClone = Instantiate(fireBall, centerPointPos, Transform.rotation);

Finally once the spell is made I can then check if both hands have left the collider and, when so, access the rigidbody2D on the spell and add velocity. e.g.

bulletClone.velocity = transform.TransformDirection (Vector3.up * projectileSpeed);

And there we have it, This is the entire core system I used for the spell creation and fire system in my game Azmodan. There are other small changes that can be added like deletion and resetting but that is incredibly simple to do so there is no need to show how that done. Thanks for reading.

Azmodan Post Mortem

Throughout the past week I had worked on making my one week project, Azmodan the unhandy mage. A 2D, top-down, arcade shooter were you create and fire spells at in incoming horde of evil demon sheep. By the end I would consider it a great success and im very happy with how it turned out but getting there was a bit of a hassle. Not only did some things turn out completely fine, like the spell creation and casting system but some aspects when completely wrong, like the UI an spell pick-ups. Throughout this post Mortem I will be discussing what had happened though the development, why it happened and how it wont happen in the future.

What went Right?

Firstly, The spell creation and firing system in Azmodan worked out completely as expected. The system, in short, involves the player moving two hands together, waiting for a spell to be created and parting the hands to fire it up screen. Originally I thought this was going to be one of the hardest things to code in my game, however thanks to the use of OnTriggerEnter2D(Collider2D other) and  OnTriggerExit2D(Collider2D other), used to check if a trigger has entered or exited the collider of anther object in a 2D space, made making this system a lot easier as all I needed to make was an empty GameObject and check whether both hands were within that GameObjects collider.

My enemy and pick-up spawning systems worked out great as expected. These were both systems that used a random number to select what enemy/pick-up to choose and what location to spawn them from. This system was fairly simple, using Random.Range(), to get the number and checking across a set of conditions. e.g

if (enemyRandNum == 1){
    Instantiate (enemy1, enemySpawn1.position, transform.rotation);
}

This system works for both my enemies and pick-ups spawns and was a simple and effective system to create.

Finally, my enemies and pick-ups themselves also worked out great as they provided an extra level of challenge, reward and decision making to the player. The other enemy types included, a Red demon sheep that moved twice as fast and a yellow demon sheep that took two hits to kill. This allows for enemy prioritization to happen when playing and save goes for the pick-ups. Which included, a frost ball that could go though multiple enemies and a lightning ball that would travel twice as fast. I’m happy with how each of the pick-ups turned out as it rewards players who play well along with teaching others the penalty of failing to correctly creating a spell as if both hands collide the player losses their current pick-up.

What went Wrong?

The system I originally used for the spell pick-ups, in terms of collecting the pick-up and using it, was incredibly faulty and didn’t work as intended. How this system worked was, once a pick-up was collected then it would run though a list of “if” and “else” statements and check which of these condition’s was true. The code:

if (frostBallPickup){
    currentPorjectile = frostBall;
    projectileSpeed = frostBallSpeed;
    proectileChargeTime = frostBallChargeTime;
    fireBallPickup = false;
    lightningBallPickup = false;
}else if (lightningBallPickup){
    currentPorjectile = lightningBall;
    projectileSpeed = lightningBallSpeed;
    proectileChargeTime = lightningBallChargeTime;
    fireBallPickup = false;
    frostBallPickup = false;
}

The issue with using this code is, firstly, “if” is meant to check for very simple conditions and “else” is meant for when the “if” condition doesn’t happen. This in relation to the above code works fine on paper, as you are only checking for one of two conditions to be true, however this leads into the second issue as both conditions are within the same scope, the first condition will always be checked first. How this is a problem, is when the player picks up a frostBall, it will change the values around and set lightningBallPickup to false. Then when the player picks up a lightningBall nothing will happen as it will check the frostBall condition first and determine that it still has a frostBall and keep lightningBallPickup set to false, therefore wont change.

How I resolved this and stop it happening in the future, is by changing the code to not use “if” and “else” to change the values. Instead I split both the changes into two separate public functions, so they can accessed anywhere, and when the player collects a specific pick-up it calls that specific functions. Code Example:

public void SwapToFrost(){
    projectile = frostBall;
    projectileSpeed = frostBallSpeed;
    resetTimer = frostBallChargeTime;
}

Designing and creating UI for a game is still something im completely set with and with was evident when originally creating both my game UI and other screens. The issues I had were that graphics and text would not stay as I placed them and the camera would cut off certain aspects of the UI. This was caused by my lack of use in the canvas and anchoring al UI elements down so they scale with the screen. Originally All I would do for graphics was bring the prefab onto the screen and aligning it where I wanted it to be. This doesn’t work as it will move when displayed in a build version.

How I resolved this situation an to prevent it in the future is to store everything in th canvas as ether text or an image. this would allow me to anchor all UI and screen elements down and allow them to move and scale with the screen size making it more effective and efficient.

Overall this project worked out great in the end and thanks to feedback from play testing I have made a number of minor changes to the game to make it more efficient in terms of it’s UI an pick-ups. I look forward to continue working on this game and in other games in the future and seeing how my experiences from this project can affect my coding and decision making in future projects.