My Pet Sandwich – Refining and Iteration

After our pitch we did a lot of small and major design changes and iterated on other based of feedback we received. This then leads us to the current iteration of our game and how we got there.

Firstly, we though that the player needed more things to do with there sandwich then just feeding it and making it bigger. This then lead to the idea of playing fetch/catch with your pet sandwich (which as an inspiration from Can Your Pet) where the player could pickup and throw a ball and the sandwich would move and bounce it back. We wanted these extra actions to allow the player to do more with their sandwich and help insensitive that feeling of it being your pet and that you were bonding/connecting with it.

This idea however did change along with the direction and influence of the sandwich as a pet. What I mean by this is that we felt we weren’t doing enough with idea of having a sentient sandwich and wanted to make the experience more about making the sandwich itself, having it react to what you do and giving more options to truly make your sandwich unique allowing the player to feel more connected to their sandwich as they are making it to suit them. We felt this was better then feeding and playing with a dog disguised as a sandwich.

On this note, we changed the playing catch/fetch option to toasting and tanning your sandwich. This was one of the most requested feedback’s we received and felt more in line with the experience of actually making a sandwich instead of throwing a ball at it. How toasting works is you drag your sandwich over to the grill and place it on it. Then, over a max time of 20 seconds,  every 5 seconds it says on the grill it will turn a darker shade (giving it a tan). Going the entire 20 seconds however will turn you sandwich completely black and burnt stopping you from using the grill again.

Following this idea, feeding your sandwich also was iterated on in two separate ways. The first, is giving the player the ability to give a drink to their sandwich by feeding it sauce. This will add a layer just like any other ingredient and helps give these extra options to the player to further customize their sandwich. The second, is the ability to pickup and throw food around and have your sandwich move over and eat it up wherever it landed. Originally we were going to use a pickup and drag system were the layers would only be added if the ingredients were directly over the sandwich and they would eat it. However we felt that the sandwich needed to move around more to help the depth of their sandwich show that we are taking care of it as it goes to eat the food we give it.

Next we wanted to give more meaning to the name of the sandwich and help show its uniqueness by added a recipe list to the game that is titled after the sandwich and will update (in real time) with the ingredients that are given to the sandwich.

Finally we had to look back at the ending of our game and see what we could do to help solidify the connection the player had between them and their sandwich. We were looking into a game called “Can Your Pet” which is a similar take care of a pet game but its ending involves the sudden and unexpected death of your pet. It followed a structure of setting up good and happy expectations from the start and continuing with them throughout most of the game before suddenly deceiving the player and killing off there pet that they took care of giving a feeling of grief and sadness as you don’t realize what you had until you lost it Allende. This is what we wanted to have in our game and to do that we use the idea of setting expectations from the start by.

Using though bubbles displayed above the sandwich to show what it wants. This can be for food, drink or tan and is meant to act as a small gating to help players get to the ending. Once the players has help the sandwich by giving it what it wants for the first time in each actions. It will then ask for a Knife, Upon clicking it will cause it to cut right though the sandwich in a very bloody and Gorey way. We want this to be that shock moment where things go wrong and expectations were deceived as you just brutally cut your sandwich in half, the thing you were caring and playing with for majority of the game.

Lastly the sandwich will want the player to eat it, Upon clicking the sandwich will cause it to slowly move closer and closer to the camera before camera tilling (to indicate opening the mouth) and the coming down (closing mouth) and then cut to black and displaying their recipe list. This is all to create that sense of grief and sadness and confusion to what happened to their sandwich and adding in the recipe list at the end helps show what they created and what they lost all at once giving a connection to both the sandwich that they made and the experience they went though.

That’s about all the iteration and changes we had made. Thanks for reading.

 

 

How we Brainstormed, Designed and Iterated a Game About a Sandwich

 

A couple of weeks back we were told to begin production of a game where the player must feel “Connected” and this is the processes we did in order to get to our current game “My Pet Sandwich”.

Firstly, like any good start to a project, we brainstormed the many ideas we had by throwing them at a wall, braking them down into their core components and see what we could use, design and iterate on. These ideas included:

• A black and white gangsta game where you have to listen to the stories and confessions of people and choose which one dies by shooting them.
• A narrative driven game where the player had to take care of a single flower that represented the relationship between two people and its various stages.
• A survival game where you had to take care of a mountaineer who broke both there legs on a mountain and you had to make sure they live.

These all have different ideas gave new an interesting method of getting the player connected, whether it was though the experience or the decision they had to make. However the one major, overarching, issue we had was that we were designing films instead of games and didn’t know how we could implement them into a more interactive experience. Then the idea of a decision based game appeared where you played as a person trying to make toast and had the worst day in their life. I would connect the player by making them feel sorry or the person involved and the other that were effected but it was a far as it got as we couldn’t think of a method for progression that would be suitable for five minutes.

That game however did give me an idea and I started asking people and team mates a question “How do you get someone connected to a piece of bread”. The general response was you make the bread, not a want, but a necessity and always keep it out of the players reach. This will drive them to want it even more and get a bigger satisfaction from it when they eventually do.

So how did we use this, Well we though, what if the player was chained down to the ground and had to eat a piece of bread that was in front of him. They couldn’t reach it and would need help. So what if we swapped it around and it was the bread that needed the players help to complete their task. The bread needs to open a door but it can’t because its a piece of bread and cannot do much. Why does the bread what the player? maybe the bread needs the player to survive or help get something done. What if the bread was your pet?

So now you can start to see how we got to our game idea and the idea of having a sentient sandwich for a pet was really funny to us. So what does the player do, what do you do with a pet. Firstly you would feed it but because its a sandwich would feeding it added more layers to your sandwich making it bigger, how many layers can your sandwich have, what are the different things you can feed it with, can you just use all the same thing to feed your sandwich with. What about if the bread had a face to actually look at the player, could we change it, what bread type would it be and can that be changed as well, what about naming it because its a pet. these were the ideas we had for our sandwich game in the early stages. From that we got the idea of having a sandwich customizer at the start of the game that would allow the player to choose a bread, eye and mouth type and name there sandwich what ever they wanted. All this allowed the player to get a scenes of uniqueness and ownership to there sandwich as it was theirs and they needed them.

How we could be test the connection between the sandwich and the player? We though that having a choice at the end of the game where you could choose whether to eat your sandwich or not would be a good method of testing the players connection to their sandwich. Were eating it would show they didn’t have a connection and not eating it would show that they did. Once we had this premise we decided to run it by Steve (one of our lectures) and his current class though a mini pitch to get there opinions on the idea. They liked it and pointed out a lot of holes in our game idea to patch up like, does eating the sandwich really show no connection and our game lives and dies by its animations along with other iteration ideas like playing with your sandwich and toasting your sandwich.

And this is how we got our base concept for My Pet Sandwich.

ScrewTape Studios Talk : My Thoughts

Today I went and listened to a “What I Really Do” talk by ScrewTape Studios, Featuring Anthony Wood and Megan Summers, and as a novice game developer who will eventually be plunged out into this industry I found it very interesting to hear there thoughts on the current indie market along with what goes into running a indie company with there daily and weekly work lives.

So what did I learn, Firstly, that the indie market is over-saturated with a bunch of shit, but anyone who is or going to work in this industry could tell you that. More specifically its probably better not to try and declare yourself as a indie studio or make indie game because you have to fight against all the other indie games on steam and other sites in order to get noticed by anyone.

Listening to their daily and weekly work schedules was also fairly interesting as it gave me an idea on how the structure of this company works and what it takes to work in the indie scene (spoiler, a lot of time and dedication to a project that may or many not have a payoff in the end). But what really stuck with me was, the idea that you need to not just be enthusiastic about games but being enthusiastic about making games instead. This is honesty something I hadn’t really thought of until this point and it makes a lot of scene, now that I think about it, as companies don’t care if you are really into games but are more interested in how enthusiastic and ready you are too actually going though the many stages of making a game and stay motivated.

When allying for jobs, this can be shown in a number of different ways:

• As a programmer – Show games, features, tools and other code related things that you have made or updated, that isn’t a final project for study that you worked on. Doing side projects and things in your off time helps show you are enthusiastic about making games as you are taking the time out of your day to get better and learn new things.
• Learning different coding languages would show that you are more flexible and can work with different engines and languages.
• Learn about different professions within game development like art and audio as, especially within indie studios, you would need to where a lot of hats in order to get work done and not just code as often things will go wrong and you will need to do some knowledge in each of these profession in order to get it solved on your own.

How this has influenced my career plan?

Firstly, do more side projects. These don’t necessarily need to be games themselves but just a combination of new things and mechanics that I’ve learnt and I can demonstrate to other people to prove it.

Secondly, the more important one, its given me a better understanding of the different roles there are between Indie and AAA. Where AAA is more you are focused and dedicated to one specific form and issue for programming and Indie is more open where you need to be able to do different things at different times due to. With this in mind, I’ve thought more on what direction I want to take my self after I leave uni.

This direction tends to fall more within the Indie side of the games industry. Why, I like the idea of wearing multiple hats while I work, learning about the different profession within a studio and see how they work, and have a bit more flex-ability in what I work in, in terms of programming, instead of specializing and focusing on one specific form of games programming.

So whats my updated plan? Well the dream would be an internship at a Brisbane indie studio like Half-Brick or ScrewTape themselves but to get there will require some work. Current methods of getting there include:

• Doing multiple projects help show I am enthusiastic about making games and show off my different skills and knowledge as a programmer.
• Applying for QA testing also seems like a good method of getting your foot into a studio as you would be able to learn more about the structure of the company and how the programmer, animators and audio work to make that game.

Thanks for reading my blog 🙂

Cybersaurs – My Experience with Audio and Animation

During the development of Cybersaurs I delved into the realms of audio and animation for a short time in order to try and learn a bit about each profession and get some suitable assets in for the final build.There was two main assets I worked on, The movement animation for our Cybersaur and the Gunner firing sound.

Concept

For the movement animation,  It would be used as the main visual feedback for the driver to show that they where actually controlling the Cybersaur instead of the sprite sliding around. It didn’t need to have many frames as any change will help the show this and just had to be a t-rex moving its legs forward.

In terms of the Shooting Sound, it acts as the audio feedback for when gunners shoot a bullet. It needed to sound like, as if a large amount of energy was just released all together and last about 0.5 – 1 second long. With a load starting point and quickly dulls down. (this last sentence tells you just how much of audio I really know).

Design

The main design for the animation came from one of our animators who took various mock-ups of old designs and placeholders we had and found movement examples of T-Rex’s online to get the initial idea. The animation was going to be the Cybersaur progressively moving each leg forward and back will moving its tail to show a bit more life to the sprite. It was also going to be four frames long, we choose this as four allowed us to make a relatively smooth transition between both legs.

In terms of the firing sound effect, I wasn’t sure how I go about designing it except from search laser sound effect example in Google to get a base idea of how the effect should start, loud and relatively high pitched, sounds like the energy is full, and quickly dulls out becoming much deeper, its all released.

Plan

In terms of the movement animation, I planned on receiving each individual frame from our animator and then use Unity’s inbuild Animation setup and Animator in order to construct the animation and set up the movement conditions for it to play using the movement velocity of the Cybersaur.

In terms of the firing sound effect sound effect, I planned on using www.bfxr.net  to make the effect as I could afford to wait the download and learn how to use other major sound and audio programs in time.

Iteration 

In terms of the movement animation, I learnt that you could just move and png files into the Unity Animator itself and then arange in what order you wanted it to be and change the frames per second the make it faster or lower. Doing this I lined the four frames in order and changes the FPS to 10, this showed each frame consistently and reset the frame without any added pause time and that’s what I wanted.

Next came to  actually playing the animation on demand, I first trying playing it though code using, Animator.Play(MovementAnimation); However this didn’t work, In hindsight it was cause by the script no actually knowing what the Animator was as I just assumed it did. I then got one of my teammate to help explain the conditions part of the Animator and though that I could set up a Movement Velocity condition where if it was greater then 0 it would play. What made’s this condition interesting is the Velocity is determined if something is being moved and not though input so pushing a Cyerbsaur around that wasn’t controlled would actually play the animation which was very interesting.

In terms of the firing sound effect sound effect, I started cycling though the random selection of sound until I found a nice base sound to work off. I then started to change the pitch and low-pass filters of the sound to help make it dull out quicker but still keep a high starting pitch. I then spent the next 30 minutes listening to slight variants of the same sound until I got one that I liked and fit what we needed.

Polish 

In terms of the movement animation, When testing it in game we learnt that the hips of the Cybersaur movement a little to much, as if it was throwing its rib-cage from side to side whenever it moved making the cannon stand out as a non-moving object. This resulted in us making small tweaks to the sprites themselve’s though Unity changing the width to make it less noticeable.

In terms of the firing sound effect, I did some slight compression changes to it in unity to keep it short in timing so it match up nicer to the firing of a bullet.

Cybersaurs Final Build Postmortem

What went Right?

Aesthetic Design – The look and feel of our game was by far one of the best aspects about it. Though closer communication and working with out artists and animators, making sure they had the proper information so they could then deliver the assets we needed. It ended up really working out and helped set the scene for this game and give that look and feeling of falling though outer space, on a flaming asteroid, while trying to kill each other on cybernetic dinosaurs.

When choosing which theme to go off (tanks on battlefield or cyber-dinosaurs in space), we needed to ask ourselves:

1. What would be more difficult to accomplish?
2. What is more appalling to use?

For both, the answer was cyber-dinosaurs in space by everyone in the team. These specific questions were ask because the more difficult something is to complete, more mistakes we will be make, more issue arrive and more we would learn from them and how to solve them in the future. Choosing something that’s more appealing to us also keeps everyone interested and motivated to keep going.

How this worked out was, like I said in the beginning, we started working more closely to the animators involved with the project. Actually having a team meeting with them on campus, and Skype, so we could ask questions on why nothing was being done and how to solve it. This then lead us to creating both an animation brief and asset list, with some help from the animators, for them to work off. This in return allowed us monitor and make sure the assets our animators were making were what we wanted and followed the style and structure of our game.

How I plan to do this in the future, create an asset list and animation brief as early into our development cycle as possible and ask the animators involved whether the information presented is actually relevant. The biggest issue this time was we left it way to late and all the information from our current documentation didn’t help someone trying to figure our the dimensions of our players, relative the the asteroid. Along with this a team gantt chart or trello would also be useful in managing who is doing what.

Driver Role –  The driver is meant to control all the mobility of their team within the game and their main focus is running and dodging around level away from enemy fire. With this in mind, I believe the driver role was a success.

We designed the driver to be always trying to move out of the way and get the a safer location. However dispute how useful they are, in terms of mobility, they are also completely vulnerable and have no main method of defending themselves except from running. This is were cooperation between them and the gunner comes into play as the driver needs to gunner for protection and to hit the enemy team. So now movement for the driver becomes more of what is more useful for my gunner.

How this worked is we, first, made both the driver movement and rotation speed relatively fast (cross the map = 6 seconds) and (full 360 spin = 5 seconds). We did this because it allowed the driver to cover more ground and allows the driver to get into better positions for the gunner instead of being backup into a corner and the game turning into a camping match.  Secondly we stopped the driver from influencing the gunner cannon rotation whenever they rotated themselves. This was done to prevent the gunner from simply relying on the driver from aiming and removed any form of cooperation and teamwork in our game.

How I plan to do this in the future, when it comes to roles like this, making sure that no one role is dominating or influencing all of them. This looses any form of cooperation in the game as one player could do all the work and other does nothing and feels no needed.

Gunner Role – The gunner is meant to control all the damage of their team within the game and their main focus is predicting, aiming, timing and shooting the enemy ether directly or though an awesome trick shot. With this in mind, I believe the gunner was a success.

We designed the gunner to be always trying to hit the enemy though various means, ether directly at the enemy or bounce of walls and rocks. However dispute how useful they are dealing damage to the enemy. They are completely stationary and have no way of moving out of the way of enemy fire. This is were cooperation between them and there driver comes in as the gunners needs to driver for positioning and moving out of the way of the enemy.

How this works is, firstly, we made the gunners rotation independent from the driver so they are forced to rotate the cannon themselves and no rely on the driver. Secondly, their rotation is now instant instead of a slight delay. We changes this as the gunner is meant to be challenging not difficult were they have to constantly predict, aim and time when they are going to shoot to hit the enemy, which is challenging. Applying a delay to the actual rotation will removes these aspects as the gunner will always be steps behind the enemy driver, which is difficult, and therefore becomes more efficient to just spam shots.

Thirdly, we applied a delay to shooting the cannon in the form of a charge. We did this because, unlike rotation, this further enforces the necessity of timing when the gunner is going to shoot and working with the driver in order to make sure that every shot counts, we also moved the charging bar away from the top of the screen to on the actually cannon design itself. We did this because the gunners attention is always focused on the cannon and where they are aiming so this allows for large visual feedback with out bring the gunners attention away. Lastly, we applied a laser sight to the gunner, we did that as it makes it easier for the gunner to see exactly where the bullet is going to go and therefore be able to more easily set up a and predict trick shots on the enemy.

How I plan to do this in the future, Don’t apply a delay to something that requires a lot accuracy in order to do right. Always keep in mind whether if we want something that is Challenging or Difficult and tailor it towards it.

Level Design – Our level design needed to incorporate many ideas that would both enforce cooperation between the driver and gunner but also allow both roles to play effective. The level also needed elements that would dynamically change how the level is precised by both roles and give plenty of opportunities for expected and unexpected success and failures. With this is mind, I believe our level design was a success.

How this worked is we, first, made sure that the driver wasn’t restricted by space and that there as plenty of room in order for them to move around. We did this by spacing all the objects away from the center and only have one major object there, to prevent both gunners from shooting each other the second they spawn and gives time to plan out there attack, and scattering the rest away near the edges and at choke points. This gives the driver lots of rotation and dodging room without worrying what they will hit or how vulnerable they will be if they tried. Secondly, We needed objects for the gunner to trick shot bullets off, though testing we came up with these:

• Four, solid, 45 degree angled walls near the rounded edges of the asteroid. These don’t move and act as a good starting point to trick shoot off as they are, though there design, easy to see where the bullet is going to go and, thanks to there arrangement, can circle around the map allowing for unexpected hits and dynamics between the bullet and the other “movable” objects on the level.

• Various shaped, movable rocks throughout the level, distributed nearly evenly across both sides. These rocks can be pushed by both the driver and gunner and can bounce bullets. Due to these rocks are constantly moving, it is constantly dynamically shifting the level design itself and with that changing the priorities of both the driver and gunner and what they are going to do next.

• Lastly, the meteor system was a way of incorporating level based elements off the intended level itself (asteroid). It worked by spawning large rocks that would move done on ether side of the screen at different times. We did this because it allows for new “outside the box” thinking when it comes to trick shots and for unexpected success and failures to accrue, which is what we want.

How I plan to do this in the future, a major help was defiantly the constant iterating we did with our level and seeing positives and negatives of each, breaking them down and seeing what could be made of them in a new iteration for the level and how could we use them in order ways (e.g. Meteor system – Movable rocks on the level itself).

 

What went Wrong?

The Concept of “Teamwork” – Dispute how we might have put these different systems in and how we designed our game. One of the biggest aspects about it was meant to be it focus on teamwork between the driver and gunner. Unfortunately this didn’t turnout the way we wanted it.

What happened was, teams weren’t winning based of there skill and cooperation with each other but more of waiting and to see who gets killed by friendly fire first. It was evident that gunners liked to simply spam shoots towards the enemy without taking into consideration there own position or the spots around them and in doing so added an extra level of risk to the driver as now they had to look out for there own gunners shots as well. However with drivers, it was evident that they just wanted to run around the map, pushing all the rocks and charging the enemy directly, This is fine but it doesn’t show any form of cooperation between both the driver and the gunner.

Why did this happen, well one of the main issues was there was no real reward or incentive from the start for both the gunner and the driver to work together. The only thing we were using to try an get both roles to work together was to try beat the enemy team but this then lead both roles to do completely different things independent to each other’s goals. Another issue was the gunner constantly spamming shoots around the map, which lead to most of their teams deaths, without penalty or someway to incentive them to stop.

How do I plan on doing this right in the future, there needs to me more incentives for both roles to work together, in terms of the gunner, adding an ammo system with slow recharging shots could have been a potential fix as, if the gunner is limited in their shots then it could cause them to be more patient and timing there shots and cooperating with their driver to get into a position to make every shots count. A score system could also be used and points can be allocated based on tricks shots, this could work as the more effective trick shots can only happen if the driver understands where they need to go and what rocks need to be moved.

Visual Feedback – This relates to only one piece of visual feedback but it caused quite a lot of confusion. I’m talking about when ether you hit or get hit by a bullet and what happens, in short nothing which caused a lot of confusion about why a team died without any notification or reason.

Why did this happen, Originally I was planning on incorporating a large visual explosion whenever the bullet hit a Cybersaur, however due to how late we were into development and me having no real knowledge on how a particle system works. I was unable to get it implemented in time and not having any form of suitable placeholder just caused me to leave it empty.

How do I plan on doing it right in the future, Firstly, would be to plan ahead on all the different visual and audio feedback we will need for the game and finding suitable placeholders for each just to use to use as backups encase something like this happens again. Next would be planning time into learning asking peers and facility members on how do I implement a particle system and setting up with the correct conditions, Getting some outside help would have been useful and possibly could have lead some form of feedback being placed in instead of nothing.

 

My Own Performance?

In terms of my own performance, I felt like I contributed a lot to our team in both the coding and design aspects for our game. As team leader my management of each member of the team and keeping track of what everyone was up too could have been better, especially for the animators and audio people involved as I never used a gantt chart or trello and only relied on word or mouth to see how everyone is doing (which was a terrible idea). I managed to get most of my tasks down on time however issues started when the I was unable to catch on those old tasks in time which left a lot of undone stuff at some major points during our development.

What happened was, I didn’t understand what was really needed in order to properly manage a team. I relied to heavily on word or mouth and Skype messages in order to get my information from my team and didn’t properly set up team meetings.

How I plan on doing this right in the future, Firstly, definitely setup a team gantt chart will a task breakdown with everyone apart of the team on it. This will help manage where all the tasks are at over the development cycle, secondly would be to set up a trello for the team as well to manage everyone’s tasks on a much more day-by-day level and see what has gotten done then.

Overall the project was a success but like every other project there can always be improvements. For us, these improvements would include thinking of new ways to make both the roles work together instead of more independently and manage what everyone is doing more closely so things can get done on time.

 

 

 

Cybersaurs Visual Assets – My Contributions to Level Design

My contributions towards our level design came in the form our early conecpts and design work which then acted as our base framework for all future iteration. Along with this, discussion and implementation of future iterations of  “obstetrical” (walls, rocks, meteor system).

Concept

During the start of development we change the theme of our game around from tanks on a destroyed battlefield to the current cyber dinosaurs on an asteroid in space. We did this as the new theme seemed more appealing to us as developers, with new possibilities for mechanic, dynamics and would appeal to the other people who would come and play it, we were right.

We knew from the start that we would use an asteroid, due to its circular/oval shape, which kept us within the restraints. It also lead way to creative “obstacle” design like:

• Curvy / Wavy walls – giving abstract angles for trick shooting.
• Small Chasms and Holes – act as a blocking and choke points.
• Possible Debris – scattered around to give more spots to trick shot and allows for added RNG shots to occur.

I used pictures on asteroids in space as inspiration for my base concept image.

Design

When we started to make our own custom level designed however, I started to stray away from the circular asteroid based level we set in our concept for more of a hexagon, rigid based approach with large, block walls and narrow passages. I did this because we wanted the player to try and perform as many awesome trick shots as they could without a super amount of effort, but in doing so limited the drivers move ability and space on the map so they couldn’t dodge and really only hide (which we didn’t want). I also couldn’t come up with a reliable early design to fit a circle/oval which was a contributing factor the the hexagon design.

These design’s did not work for our game for a number of reasons:

1. It doesn’t look of feel like an asteroid, the main premise of this game is to be fighting each other on an asteroid in space and having a blocky, hexagon map doesn’t give that feeling.
2. It restricts the driver, looking at these design’s there isn’t a lot of freedom for the driver in terms of mapping out where to go and how to avoid enemy fire. Instead the all paths are just narrow corridors that don’t really support rotation or evasive maneuvers.
3.  It supports hiding and camping, because of how restricted the drivers movement is on this map and how large the corresponding walls are. It gives the driver more incentive to just stand still and hide around one of the walls as they would be harder to hit and they can then set up large choke points for the enemy team. We didn’t want this as it would just boils down to a camping match where the first person to leave there cover losses.

However despite the poor design we did learn a number of important details that would be used in all future iterations.

1. A large center piece stops the players from instantly shooting each other without any time to reach and give players a little time at the start of a match to plan out what they are going to do.
2. The angels and walls in the map did allow for good trick shooting to happen as the angels allowed the predictability on where the shots would go making it easier for players to set up perfect shots.

Plan

We did end up using similar designs for some of our future testing but opened the middle and center areas so the driver had more room in order to run, turn and dodge while still having a large circular rock to prevent players from instantly shooting each other and other small walls scattered around the outside edges.

Placeholder

We used the above level design as our main placeholder design for our testing. We wanted to know if the driver could reliably move and dodge there way around the map and that the gunner had many opportunities to perform trick shots.

What we learnt:

1. Players didn’t understand what they where fighting on? there was no indication that they were on an asteroid and therefore didn’t get the premise.
2. Drivers did have quite a lot of freedom in this design as they could easily run and dodge there way around the map.
3. Gunners however didn’t couldn’t capabilities on the the bouncing bullets for trick shots as the only reliable wall was the center object. All the others did have much sense to where the bullets will go.

All these were taken in consideration for our future iteration.

Iteration 

There were many major iterations that happened over this games development. The first came when we were testing our new base image design, done by our animator and artist. 

With this I notices that our bullets could move off the intended level and into the outer space background. This lead to the idea of having walls and “obstacles” outside and off the level itself to give new, thinking outside the box, trick shot opportunities and potential RNG related success and failures. This was implemented in as the meteor system where different shaped rocks will fall from ether side of the level at different times, giving these opportunities. (Check out my meteor system blog for more information on how it works and how I implemented it).

The next major iteration happened soon after. Where though a mistake of another member placing rocks outside the level without know about the meteor system say how these rocks can move on the asteroid. This then lead to the idea of incorporating the meteor rocks into our asteroid level design as small movable objects. 

With these new found movable walls, this opened up many new play styles and dynamics within our game, due to the rocks constantly moving so does player priorities and position as they need to constantly look where everything is moving and base there next moves on how the level will be. Other potential dynamics its showed where:

• Using them as shields to try and protect yourself from fire.
• Using them as barricades to try and block in or of the enemy.
• Added projectile that can me moved towards the enemy as a way to counter their shot.

Nearing the end of our development the issue was brought up that we weren’t utilizing our five bounce mechanic on our bullets. This lead to my idea of incorporating solid, non-moving, 45 degree angel walls near each of the corners of the map.

These walls allows setting up predictable trick shots much easier as due to how they are positioned and displayed on screen makes it much easier to look at and understand where exactly the shot is going to go. This also gives new players, who done not what their doing, a solid starting point to begin shooting at. As the walls don’t move it helps keep a solid foundation for our level no matter how much the other rocks move around, keeps the level from just boiling down to a open field with anything of interest being pushed to the outside edges.

Polish 

Polish came in the form of our artist re designing the walls and center block to be pieces of metal debris and a lunar lander. From an aesthetics points of view, it helps brake up the samey looking brown colors across the level and makes it more visual appealing along with making the solid non-moving objects more distinct on the level. From a dynamics point of view, it adds new angels and possibilities for amazing trick shots because of how the rigid each of the pieces look (especially the lunar lander in the center).

and from that we have our finished level design for our game. As you can see I helped a lot in the early stages of concepting and designing the base level designs that we used later on for our finished product as well as implementing a number of our future level design iterations and features like the meteor system and movable rocks.

Cybersaurs Systems – Meteor System

One of the systems I did later on in our development was the meteor system. This is a similar system to a previous enemy spawning system I did for Azmodan but what makes this one different is that I expanded on old functions, incorporated new ones and had better code efficiency then he last.

Design

The design on the meteor system was to add level based elements likes walls and rocks and place them off the playable level itself (the big asteroid). These were meant to act as our moving objects throughout the game and allow the players more room and possibilities for trick shots and unexpected successes and failures, due to the bullet being able to leave the asteroid itself.

The other major reason was it helped fill up the outside edges of the screen, which were left empty with a scrolling background, to give a feeling that their was more to this level and tat you could think really outside the box. Along with random spawn timers and different shaped rocks/meteors, we could give a very natural flow to this system of rocks coming in at different times instead of a very structured approach of ‘rock spawns at this time every time with no variation’. which didn’t feel anywhere near as satisfying.

Plan

I planned this system to use four main spawn points across the level all located at the top of the screen, just above the camera, and used a script to find each of their transforms on start. 

On found, it would run a spawn timer, using Time.deltaTime, to acts as the delay between meteors. I wanted to regulate meteors with a long timer to keep them from becoming more of a hindrance then a help, on both players and the system.

After every timer the system then goes though two major functions, finding which spawn point to use and selecting which meteor shape to use. The first is spawn point, as I mentioned earlier there are four spawn points so I decided to use Random.Range in order to find which one would be used.

Due to us having multiple shaped meteors to use, I needed to incorporate more Random.Range into our game and have it choose between them. I used a series of “if” statements to determine what meteor was selected based on the number as it was a simplest form I could think of at the time.

Now that both the spawn point and meteor are selected I needed to instantiate them on the screen by creating a clone of the selected meteor prefab and spawning it on the selected spawn point as a GameObject.  

Finally it needed to move so I decided to use Rigidbody2D.Addforce but to do this I needed to access the clones Rigidbody2D  and apply it from there as it is a GameObject.

Iteration 

Now that the base script and functions were in I wanted to start adding different randomized spawn timers to make the system feel less static and structured. I used Random.Range at the start of the meteor system to get the initial spawn timer and had a function that would be called when ever it ended.  

One other major iteration was the implementation of a removal script as I forgot to add one in the initial setup. Since the meteors are constantly traveling downwards, following the rest of the scene, checking when they reached a certain Y distance would suffice.

Polish 

Lastly polish came in two forms, one being regulating what side got the next meteor and better code optimization. In terms of regulating the meteor, anyone who knows the term RNG would understand that is not always fair and this was the same for us. Having ten meteors in a row spawn on one side doesn’t accomplish what we want from this system (having new trick shot opportunists for BOTH players).

So I added a variable that would track what was the last spawn point chosen and though a set of “IF” statements would select the an opposing spawn point. 

The issue however with this code is that I will always spawn in two meteors at the exact same time on ether side. This is due to how “IF” statements work and the structure I used. Once it finds the if statement that’s TRUE, it last spawn point variable but because of that know the other “IF” statements become TRUE (due to it being checked every frame) as well and therefore spawn a meteor.

Too solved this I learnt SWITCHE statements (from my peers), what they could do and how to add them to our “IF” statements. SWITCHES allow you to compare a single variable against how many sets of data and variables you want, which is exactly what we needed. We set this up by having each IF statement have its own case and then break once its checked so it wouldn’t change. This then allowed the system to work as intended and now properly regulates meteors on ether side of the map. 

Overall this system turned out great. It was a large advancement from my previous attempt at a spawning system and though it I learnt about SWITCH statements and how use they can be when comparing variables together.

Cybersaurs Systems – Gunner

One of the biggest aspects of our Cybersaurs game, and what I did first, was the Gunner role with how it worked, what were the controls, how we were going to implement it and how we polished it over time and testing.

Design

The Gunner role was designed to be the main, and only, source of damage within Cybersaurs. With this in mind, we needed to make sure that the both, the controls provided a challenging experience where the player would find it difficult to aim nor utilize the trick shot mechanic easily on but then later learn to aim ahead, react to enemy fire and use the walls and rocks around them to hit the enemy. Along with this, the bullet needed to have a suitable speed and number of bounces in order for both, to feel threatening to the players and provide smart usage for the trick shot mechanic to be utilize to its complete potential.

We did this on a controller and was, initially, done though the use of tank controls and both triggers. This was issue during the start of development as I had never worked on controller mapping before. However, thanks to my peers and teammates telling me that unity came with an inbuilt input controller and you could set up input names though the input manager it became a very simple process of finding the input control and naming it so it can be used in a script but we did learn later on that using this was not a very good idea.

On of the core aspects of the Gunner role was its delay. All the actions of the Gunner needed to be delayed in some way and from that we broke down what actions that Gunner could do:

• Rotate
• Charge
• Shoot

We then choose our delay timer to be 1.5 seconds long for all aspects of the Gunner, except for firing. We choose this as we thought that having such a long delay would force the player to think and consider when it would be a good time to move and work as a team with their driver for smart position around walls and rocks and preemptively charge in order to get the first shot on the enemy. This ended up being a very bad idea.

Plan

Into the planning stage of how this system will work. I started with rotation and moving the cannon itself. This would involved checking the input value of each analogue stick in the controller for a value of ether 1(up) and -1 (down). Analogue sticks can have a float or double value in between these values however so an analogue threshold would need to set so when the stick was moved past a point (e.g. 0.5) it would change instantly to 1 or -1.

Once the values were found it would begin a timer, which acted as the delay, and when it ended the rotation would happen and the timer would be reset. 

We wanted the rotation speed of the Gunner to be far quicker then the driver to try and prevent the Gunner from forcing the driver to rotate the cannon for them and they just endlessly spam shoots until something dies. In this, we make the a full 360 rotation for the cannon take about 3.6 seconds where as it took 9 for the driver.

The charging bar needed to be visible to the player at all times and we did this originally though a UI element of a bar located underneath the health bar that would fill up using a slider and a layer mask to hide the excess and resetting once the bullet was spawned. 

Shooting is also a major component as it is the only way to deal damage to yourself and the enemy. This was done in a similar way to the sticks as we named the inputs (LeftTrigger, RightTrigger) and checked if they were being pressed down. If so then run the charge timer and when it is complete instantiate a clone of the bullet prefab then access its rigidbody2D and apply a force to it.

Finally the bullet itself needed to be sorted, as we wanted it to bounce around the map and off walls and rocks we attached a physics 2D material to the bullet prefab itself. We did it this way as it saves times and has the exact same effect if all the walls had the same material. We then removed its collision with the Cybersaurs themselves as whenever they would hit it would cause a force issue and make the Cybersaur spin uncontrollably and instead relied on a hitbox system to determine hit.

Iteration 

Iteration became a constant thing for the Gunner, due to constant issues and feedback coming in about the its different aspects. One of the first major iterations was changing the firing of the bullet to be instantly after the charge is complete. We though that releasing the shoot instantly would be against the “all actions are delayed” rule and never argued for it. We also thought that having it fire instantly would force more timing to and aim to go into the shots due to the Gunner not having exact control over when the shot fired.

Prior to our first play testing we also learnt that unity’s input controller doesn’t handle very well during a build and this wasn’t any different for us.  While in build the controls would be swapped between different controls to a point in which the game couldn’t be played. We decided that swapping the unity input controller to something more stable would be best (like InControl). We used a git repo called XboxInputController which tailored all the control input in the input manager to an Xbox controller and from that we could rename them to our current setup.

Rotation delay also became a major problem as well, we started to reduce the amount of delay on the rotation to 0.5 seconds long as a way to prevent the gunner from giving up and just allowing the driver to do all the rotation for them but this wasn’t enough. Gunner was suppose to be all about positioning, timing and accuracy and not of that was accomplish able with our delayed setup as actions like these need to be instant to have any meaningful effect on the current situation. To solve this we removed the delay on the Gunner rotation and argue that it was a bad game play decision that hinders the team working together and only forces the gunner to relay on their driver to do their job more efficiently.

Lastly we needed to move the cannon charging bar as it was to far away for the anyone to care and we didn’t to force players attentions away from the game in order to look at a bar. Solution to that was to incorporate the charge bar into the cannon itself so players attention wouldn’t have to move as they are already focusing on the cannon itself as well as where they are aiming so now it acts a great form of visual feedback to the player.

Polish 

In terms of polishing the system we decided that making the cannon and driver rotation independent as the driver could still influence the rotation and angel of the cannon as it was chided to it (wanted or not).
This was done by making the cannon rotate in the opposite direction, at the same speed, as the driver so it ends up in the same spot both forces are canceling each other out which then doesn’t effect the Gunners input as well. 

Lastly Visual and Audio feedback on the bullet itself was important as the players need to understand when something happened and unfortunately this didn’t go as planned. We had made audio effects for charging, firing, bouncing and hit but the charging sound was ear piercing and didn’t stop if you let go of the triggers so it was removed. In terms of visual feedback, I wanted to incorporate a participle explosion on hit to shot the player that they manage to get a hit or was hit themselves. Unfortunately due to a lack of time and knowledge I was unable to figure out how to setup a particle system in such a short time and couldn’t get it implemented which did lead to some confusion.

Overall the Gunner had many new development and issues as the project continued and even though it isn’t a perfect system it still came together nicely and works completely fine.

Cybersaurs Prototype 1 Post Mortem

Over the one week development time we used to make our first prototype of Cybersaurs : Dinosaurs in Space. We managed to get a lot of things right and a lot of things wrong, ranging from the design of certain features and mechanics to their implementation. However though these experiences we managed to learn just that bit more about how working in an actual team is like along with the advantages and issues that come with it.

Main things I want to focus on throughout this post-mortem are:

• What when right – How we designed and implemented aspects of our game that were successful
• What went wrong – How we designed and implemented aspects of our game that were not successful.
• Group management – In terms of how we managed our time and and the collaborators we had brought in.

What went Right?

Bouncy Bullets

---

As one of the core, and one of the most interesting, mechanics to our game, I am glad to say that the bouncy bullets system worked out great.

Whereas instead of being limited to the straight line shooting and a game of constant camping, bouncy bullets allowed all the walls, spaces and angels to provide new opportunities for the player to get the advantage and hit their target and we though this would be a great mechanic to add in our game.

We also though it was a great way to counter camping,  Due to the driver main focus of NOT GETTING HIT. Having them constantly move into the line of fire just to give their gunner a chance to hit the enemy would cause boring stalemates and one sided battles as the camping team would always have a distinct advantage. However add bouncy bullets into the scenario and now it forces both teams to keep moving due to all positions now being vulnerable from multiple angels giving stationary targets a distinct disadvantage.

We then learnt that many people actually liked having lots of bouncing bullets, ether from them or the enemy, flying everywhere as they desperately tried to escape and dodge them. However this leads into the a few issues we had with our implementation. Due to all the bullets having five lives each and all looking the same, the players didn’t have any clue which bullets were about to run out and which ones were not. This in return gives the driver very little information on their surrounding hazards and therefore cannot make proper movement decisions, on where they should move to and where they should avoid, and in the end play more defensively and hide.

Possible solutions to this would be starting the bullet off with a light, team based color and on each bounce turn it a darker shade until it completely destroyed.

But overall the bouncy bullets worked out great.

Driver

---

The driver I believed to be successful as it was easy to understand how the driver role worked and what you were meant to do. There are a number of reasons for this:

• Firstly, Instant feedback was great for the driver. Due to all the controls of the driver not being delayed, it made knowing what you were doing that easier as acceleration and rotation would happen instantly and therefore no external feedback was needed.
• Controls were easy to understand and use from both design and instructions screen. We originally used tank controls for our driver thinking it would be an interactive and challenging experience trying to manage both legs/treads while moving around the map and avoiding danger. However due to negative feedback we decided to change it to left stick controls forward/backward and right stick controls rotation. This still followed our original controls idea just made easier and less annoying to use.

The other major aspect of the driver that we focused on was its rotation speed. We wanted to make sure that the gunner wouldn’t rely on the driver for aiming, due to the cannon rotating with the driver as it is child-ed, and our attempted method was to make the rotation and arch of the driver very slow and wide, with a full 360 rotation taking about 9 seconds. To compensate for this however we increased the movement speed of the driver to allow them to cover more ground in a shorter time and allows for quicker positioning and dodging dispute the slow rotation.

What went Wrong?

Gunner

---

One of the biggest issue, and biggest oversight, with our game was the gunner role. Due to them having a delay, we decided the rotation delay to be 0.5 seconds long (down from 1.5 seconds long). We did this because due to the accuracy and timing involved with the gunner, having such a long delay would cause aiming a preparing a shot to take too long and the gunner would end up having the driver itself rotate around for them and keep the cannon straight. This stops any form of unique strategies and cooperation from emerging and just dulls the game down. Having a 0.5 second delay allows for much faster reactions, positioning and timing to happen and stops the gunner from relaying so heavy on the driver for aiming.

The other major aspect to the gunner is their charging and shooting. Charging takes 1.5 seconds, we chose this because having a longer charge time forces the player to think more about timing and placement of the shot and where its going to go, further enforcing teamwork with the driver for positioning. Unfortunately for both aspects of the gunner role, they were hindered by the lack of instant visual or audio feedback to the player.

This caused many issues when it came to testing as gunners would often get confused on what was meant to happen and why they were not rotating or shooting.  There was no visual indication for how long it took before the cannon would start to rotate and the charging bar for the gunner was located underneath the team health bar and because the players attention in on the cannon and where they are aiming it was often missed and therefore served no purpose. The lack of proper instructions for the gunner on our instructions page didn’t help ether as it ended up being tailored more to the driver due to the lack of the word “HOLD DOWN” to indicate that the movements are not instant and would need to wait.

Possible solutions to this problem are, moving the charging bar onto the cannon itself so the gunner can clearly see how long it will take to charge and fire a shot along with indicating that they are doing something. Adding a colored ring to the cannon base that fades in or out in the direction the player wants to rotate to indict that delay before it starts to move. Another solution would be to remove the entire delay of the rotation itself and have the input instant as it would allows more accuracy to be placed in the shots.

Role Swapping

---

Our games swaps the roles of each player on the team after each round, we did this to allow both player to experience each role before the game is over and get a feel for how each role plays and how they interact with each other. Unfortunately due to the rush of trying to implement this we forgot to add any indication to the game or end round screen that their roles have been swapped which, needless to say, caused a lot of confusion to the people playing.

What was often happening though our testing was players got a feel for their controls on their current role and then when the sudden, unexpected, swap of roles and controls would cause to players to get confused on why what they were doing from the last round wasn’t working now and this lasted often around 30 seconds to 1 minute were someone would figure it out and tell the rest of the players what had happened.

How this can be solved is saying that there roles have been changed on our round end screen and displaying there new controls. Have a visual identifier on the game screen that tells each players role and respected controls or just allow them to choose which role they would like to do at the end of each round. Each of these allows the players involve to quickly understand what role they are about to move into and spot most of the confusion.

Collaborator Management

---

One of the more exiting aspect of this development was that fact we had other collaborators form other professions coming into help us, like Audio, Art and Animation. However due to how new and  different this was we weren’t prepared for what information and setup was needed in order for these collaborators to get the most information possible to and make the best possible work related to our game.

What ended up happening was us trying to use our HDD and GDD along with word of mouth as ways to help give ideas on what we wanted to be made whether it was music or models, this didn’t work. However even with access to our Google drive, Skype and other social network groups not many questions were ask during the early week of the development which lead us to believe that everything was fine. Skype meeting were normally setup over Skype itself and ether people could not make it or just were not there to help in the discussions, which is still our fault as we didn’t attempt to message this over other social networks we were using so it could easily be missed.

It wasn’t until very late into out development that we were told there wasn’t enough information they could use to get there work done. So for our first play testing we had to use placeholder assets.

The main cause was a lack of proper information to give our collaborators, this includes artist and audio briefs that explain the ascetic and tone of our game along with examples, Asset lists to outline all the models, sound effects and music tracks that would be needed and a proper communication and meeting schedule in which they can come and ask question along with discuss important factors of their work. The resulting factor to this was out collaborators didn’t know what they were meant to do and therefore were not able to get any work done.

if their is anything I can take away and learn from this early experience is to ask questions constantly and make sure that everyone you are working with understands exactly what they are meant.

My Own Performance

---

My own performance could have been better for a number of reasons. Firstly was due to a hardware issue of my computer dying and stopping me from doing any form of coding for the first couple of days. In this time I focused on trying to update our GDD to fit the current incarnation of our game. Once my PC problem was solved I only had about two days left in order to complete all my scheduled coding, which was setting up the gunner and all controls related to the gunner (Rotation, charging, shooting, bullet bounce).

 Time management was all a bit rushed due to that hardware issue but I did force myself to spend overtime in order to keep everything on a reasonable track, relative to the time frame, and get every code aspect of the game nearly complete on time for the backup build. Unfortunately with our backup build, we were not able to get a complete build of a game working and ready in time, these included:

• Not having our input for each player working as intended due to unity default input controller not being able to handle multiple controllers at once in a build.
• Our cannon wouldn’t stay connected to the driver, even though it was chided. We then learnt that the cannon had a rigid-body of its own so it would slide away when the driver began to move.
• No assets of any kind were available to us on that day, due to us not preparing placeholders in time and our collaborators not making anything due to lack of information.

In terms of coding, it was mostly simple as it only involved rotations, instantiating prefabs and adding force to said prefabs. The only issue I did come across was working with a controller. This was the first project I used a controller for and therefore didn’t know how to implement the control mapping into our game. Thanks to teammates however, they already setup some variables names related to the controller. This involved finding the specific input in the input controller in Unity, ie the left thumb stick and putting in an appropriate name (leftThumbStick).

Overall the first prototype of this project could have gone better if we keep communication with our collaborators up and gave more in-depth information on the style and look we wanted our game to have along with its audio and tone. Giving instant feedback to the player on what they were doing would also solve some of the confusion we had in our game, especially for the gunner. However we did learn that once players understood the controls and mechanics of our game that it turned out to be a fun and competitive experience and we plan on keeping this when we complete our final build.