I have been putting of this blog for quite some time and i finally think i have all the words together that i can respond to the question, “where exactly do I see my career going?” Even though i am currently studying games programming i am still not entirely sure if that what ill focus on in the industry. The reasoning for me choosing the course is one of my life goals is to be able to create interesting small games, and i felt that programming was my weakness skill that i had. I have learnt a lot and after this course is complete i feel that i would want to join a small local indie company, such as The Binary Mill, Big Ant studios or Fire Monkeys. I would use the experience that they give me to help me understand if i would want to continue the path of a games programmer.
While working at a small company I probably would test my skills and create a few small games. Once i have gotta to a level that i was happy with i would aim higher, out of all the big AAA companies the one that i have always liked and has most my respect would be blizzard. I love the fact that they have created so many games from a large group of genres, all being quite successful or at least have they own unique twist. Out of all the blizzard games i have only played 4 those being, Overwatch, Hots, hearthstone and Diablo 3. I feel that if i could make it into this company i would learn so much.
So what would i be? Well unless experiences as a indie programmer changes my path i feel that i would apply for the role senior software engineer. After reading the description even though it sounds awfully tense as my current experience is no way near the level of intelligence needed. I feel that the idea of constantly changing roles from game play implementation, low level engine programming and interface development sounds like the perfect environment to learn a lot. This is the end goal and i have a long way to go though i have a lot of things i have to improve on to be able to acquire this role.
The requirements and my current status:
A minimum of 6 years’ experience in coding game play with at least one shipped online multiplayer title
This is one of my most obvious incomplete requirements as I wont know what a real experience feels like until i have started the path of a junior indie programmer. As for the other requirement i have created many single player games but i have yet to create a real multiplayer game, once i have the skills to do this successfully i will apply.
A minimum of 2 years’ experience with Unity (4.x or 5.x)
Even though i have worked with unity for a few years i feel like i still have only scratched the surface and have a lot to learn. If this requires two years then i will set a personally goal to greatly understand unity by 2018.
Proficient in C# and C++
C#: I have been using this language for a while now but again as i am new to programming i feel that i still have a lot to learn.
C++: I am very new to this language and still have a lot to learn. Next trimester i think we will be returning to this language and i feel i will learn a lot.
Enjoy solving challenging problems
It still takes me longer then i would like to problem solve but i feel this is just from lack of experience in the language and programming in general. I do enjoy challenging problems though as if i don’t know the solution it is new knowledge for me to learn.
Leadership potential or previous leadership experience
This needs improvement and even though i love working in groups, taking the role of the leader isn’t something i do often.
Passion for playing and making games (especially Blizzard games!)
I don’t think i have one problem with any of the blizzard games. I have put quite some time into Diable, hearthstone and i know that my life will be lost to Overwatch. As for making games, that is the main reason i got into programming as i’ve always wanted to create my visions but didn’t have the skills, so i have a major passion.
Strong programming skills and a proven ability to work with all departments to carry out the vision of the game
High comfort level working within (and adding to) an established code framework
Excellent verbal and written communications skills
These last three i’m going to group into one answer as i feel that these requirements are the most hazy. My programming is still poor, I haven’t had that many chances to work with established code frameworks yet and my communication still needs a lot of work. As for working with multiple departments at my current institute we are constantly grouped with other people ranging from designers, artist and audio students.
From Going through these requirements i see that i have a lot to improve. My skills will have to be greatly improved if i wish to get to the level where i could also be apart of the amazing company which is blizzard.
When analyzing hug a slug it was concluded that the whole level design of our game would have to be redesigned. At the moment the whole map is getting loaded, not only does this make the game laggier but also makes it harder to expand the map if we want to add more. Another issue is ever since we changed our game name to hug a slug, a sky level didn’t make much sense. Even with the old name our map didn’t make much sense. The first change will be that the game will be based around a forest environments, this will fit the theme more and make it easier for our artist to make reusable assets. For this pivot I have made three rough map ideas that give us a base line to work on.
Image 1 (Spawn)
This is where the player will spawn, it will have a huge tree in the middle where the rainbow generator will be located. Around the spawn will be mushrooms where the collected slugs will be stored. This level will branch out to three other areas although one of those areas (Level 2) which hasn’t been designed yet has a gate blocking the path, to unlock this level 1 must first be completed.
Image 2 (Hub)
This level will be located at the top of a tree it will have two branches that the player will be able to walk on, one will have a secret collectible and the other will have a secret path leading to level two. Hopefully this will teach the players that there will be secrets to explore in this game, prompting the player to explore more and look for the collectibles. The last thing in the hub will be the rainbow generator this is where you return the colour collected by the king slug one all of the colours have been returned the player wins.
Image 3 (Level 1)
This will be the first level where the player will understand the importance of hugging and how it interacts with the colour mechanic. The first the player will be experience when entering the level is a pack of sad faded slugs although the player can hug this slug to make them feel a bit better they won’t really react to the player’s presence. After making your way through a maze you will find a gate, a normal slug and a king slug. If you approach the king slime from the left path without going through his gate he will retreat to his house where the player won’t be able to chase him and will only come back out once the player leaves the area. To unlock the gate the player needs to hug the regular slug and use his colour to unlock the gate. This will give you a path to sneak up on the king slime and absorb his colour. Now with all the colour you could dream of the previously passive faded slugs will chase you trying to absorb your colour. You will have to explore the maze again to find a new path the escape.
In this blog i will be Analyzing my newest game Hug a slug, I will be talking about some of the mistakes that our group made, what we did alright at and what we can do to reduce these issues in the future. Like my Previous postmortems i will try and cover the most important things that went well and things that went poorly. As an added bonus i will quickly discuss a few extra events that happened during this postmortem.
While in group calls i was mainly thinking out loud discussing my ideas and if my partner liked it he would write it down.(Below is the only evidence i can show)
During the start of this project my partner was in charge of most of design because of this i had little connection with the game. To make me more involved we went through and heavily iterated the idea, this is why the game was different to what we presented.
We didn’t want to split up in the design faze we were going through each section of the HCD together to understand the idea better.
Note to self:
Documentation seems to always end up on these postmortems if you are reading this in the future go through each Recommendation section to understand the issues that caused your problems, i will also be summarizing each postmortem into one in the recommendation tab, so that you only have to read this recommendation to hopefully fix your issues in the future.
During the design faze it is important that each person knows clearly what they are working on but isn’t 100% necessary when writing documentation. Instead of writing the documentation as a group write it separately. Not only will this confirm if you both have the same idea but also might bring new ideas from miscommunication. After everyone has written there version combine it so that the paragraph that sounds the best is new main paragraph for that section in the documentation.
At the end of each week have a group call and go through every game play feature, each verb in your game and each noun. Do this without having the main HCD open, roughly write down every everything. Open up your HCD if anything is missing add it and if anything was missed it might be best if you just remove that feature as it wasn’t that important.
Get your Asshole friends to play your game. They know nothing and unlike your family will be honest and will tell you your issues.
Not talking enough talking with the collaborators meant that we needed to do audio ourselves.
Knowing that we really needed to work on our documentation meant that we didn’t give collaborators enough attention. Also at that early point in design we were iterating a bit and didn’t know fully what our game would sound like.
Not enough Communication.
The main issue here was that we weren’t active enough with our audio collaborators, we got carried away focusing on the design that we forgot to work on audio earlier. The only solution i can give for this problem is if you have other people helping you, design rough ideas for them to work on. Even if you don’t keep them or they change at least they will have a lot of time to work on them and if they can’t help you later at least you have something.
Although we did talk to our prob designers
What went right:
Even though we didn’t get any audio this meant that we got to design our own audio, i put this under a good category because i got to learn a few extra things and increased my audio making skills. I was in charge of 6 different sound effects and one background song. although our background song didn’t go through much editing i had to edit our sound effects a bit to allow for them to loop and be the right volume.
The place where i got all of my sounds was https://www.freesound.org/
The six sound effects i was in charge of were fire, leaves, wind, crystal insertion and two sound effects for the sounds the slugs would make.
Out of all of these sounds effects the one that took me the longest was fire, leaves and wind as these sounds needed to loop and be shortened. I also had too find the right sound for the style of game we were trying to create, that being a calm rpg environment. I didn’t want to create sounds that would overpower the background music but i still wanted them to have meaning. That being said a lot of the sounds that i ended up creating weren’t added to the game, as we never got to that point of design. I just really wanted to try and create my own sounds.
I will be focusing on the wind and leaves sound effect in this explanation. To create the sounds needed i used Audacity.
To find wind and leaves i used the keywords ‘Leaves’, ‘wind’, ‘rustle’ and ‘tree’. I created these sounds together in the same scene so that i could hear what they sounded like when played together. This was important as i wanted the wind to be playing at all times but as soon as the player entered the woods i wanted the leaves to start playing.
Here is an example of what my project looked like, at this point in development i was still choosing which leaf sound effect i wanted to use in the end i choose the bottom one as it was easier to edit and was more subtle.
Even though i didn’t edit the clips that much and they didn’t sound perfect i learned a lot of basic Technics to effect the sounds using the effect tab in audacity.
It would have been completed quicker and to a much better quality if we had some audio students helping although this taught me some basics and i feel that i could at least make place holder sounds in the future.
Partners In Rhyme – Fire
Mark DiAngelo – Wind
SpleenCast – leaves
gusgus26 – Crystal
Rocotilos – Angry
ecfike – Sigh
After going through and reading our questionnaire a few interesting points of information appeared the most shocking being the amount of people that wanted to play our game again. This small question told me that our game iteration at the start of the project wasn’t completely useless and although our game was over scoped and wasn’t completed i feel that we created a demo which at least showed the consumers where the game was going. The best part being the 25% of our testers answered the they wanted to get all the things. Even though not a single collectible was added to this demo.
I learnt a lot about how i work during this course. For some reason i don’t want to submit work that less 80% complete this means that if i work on something for a few hours but don’t complete it i will, not report that until it is at a more completed state the main problem being that most of my work can always be improved so i end up not submitting my hours until much later. I work better in larger groups or by myself although my third project was over scoped i feel that if we had one more person we could of gotten a lot more done.
A few weeks ago I had a chance to test out Overwatch in a beta weekend, but the excitement got to my head and I forget to analyze it from a designers view point. Although it would have been interesting to read a blog on my thoughts, i feel that this blog will go deeper as i understand a lot more. During the Analysis i will be discussing character design, as i feel that this is the most important part of the game and makes it very different from other shooters.
In this blog i will be analyzing 2 heroes although before i continue, if you haven’t heard of Overwatch i will quickly explain all of the basics. Overwatch is a team class focused first person shooters, where your objective is to either push a cart or capture control points. There are four main roles Defense, Offense, Tank and Support. Defense includes 6 heroes, Offense also includes 6, support has 4, Tank has 5, giving us a total of 21 different personalities to play with. The heroes i will be analyzing is Bastion a defense hero and Zarya a tank hero.
I will start will Zarya, she is the perfect example of learning curves that will be involved in overwatch, teaching players that it will be important to learn each character. I feel that the learning curve is quite basic and will know everything after playing this game for only 100 hours. I understand that this is intentionally designed to make the game feel welcoming and easy to pick up. Returning to Zarya she has an ability to put a shield on herself or others this shield makes her stronger if it is damaged. For a new player they might Damage the shield increasing her strength and effectiveness in battle. By doing this they will most likely lose the fight, and after doing this a few times they will learn. Although this could be seen as poor design, creating a character that depends on a lack of knowledge, other character have been created to make her stronger. By adding in characters that use turrets or long range projectiles, Zarya no longer becomes a useless tank instead she joining in on the game of rock paper scissors which is overwatch.
Bastion is a character that i believe was purposely designed to teach the players about this rock paper scissors game play. Although i see this design to be new, others could think of team fortress 2. Although there is some truth in this, tf2 doesn’t fully use the rock paper scissors build. Lets first image that you could have three teams, Red, Blue and Green. Green has a spy, Blue has a Engineer and Red has a pyro. From hearing these three names you would first assume that the spy would counter the engineer who would counter the pyro who would counter the spy, this isn’t true because of one small detail, load outs. Because in overwatch load outs don’t exist you know who you are facing as soon as you see the hero. This allows for stronger counters and a makes the game easier to learn. Returning to bastion this week I got to play the game with some friends this allowed me to see their views on overwatch. One hero i keep hearing was bastion and how he was overpowered. A lot of new players think this because of his insane damage output, later in the week we decided to all go bastion, and we lost. I feel that this experience taught them a lot of the counters to bastion and about the rock papper scissors system that exists in this game.
During the app design meetings we discussed that we wanted to add more to our app then just the tutorial. The plan for our app was to include a timer, we already knew that this would be the main component as they were needed every play session. After designing our app to have a timer we started to realized our game was made to easily implement dynamic sound and lights that would activate the the timer got to a certain number. Much later VR was added to our app this was added as it was an easy solution to a problem one of my collaborators was having.
The reasoning for us having video, images and text was to give the players the most information about how to play our game.
After our first app play test we came to the realized that our game is very confusing without someone teaching you how to play.
The main problem we encounter was not completing the images and videos on time. The last element was prompts which inform during the games. These were almost unavoidable as they would block both the timer and Virtual reality forcing the player to read it.
The timer was the main component, it was designed so it would clearly be seen while playing the game. To emphasize that the time was an important part of the app we added a loud clock sound effect, this would even over power any police sounds played.
The app’s timer was created this way to inform players that time was more important than the police.
Light & sounds
The design reasoning behind added lights was just to change the environment of the app when the police arrived. Another good reason for the lights is to clearly inform the deaf that the game has changed. The sounds were added for the same reasons as to why the lights were added. They would inform that the police are getting closer and sirens would play when the police arrived.
This was added to give the player another way to read the cards. It really suited the hackers theme as he was now in charge of knowing when the police would arrive and scanning hacker event cards.
During the development of three man job i worked a lot of on different areas to help complete the project. At the start the group worked on documentation and idea refinement. At the end we split off and worked on our own section, helping each other when needed. During the later weeks i worked heavily on the app and cards, improving and iterating the designs each time we did a play session. The main areas i feel i improved on was balancing, my communication and writing more effective scripts.
Card balancing was an important part of our project, it was required to be very optimized. The group started by designing 30 events. After our first play-test our group figured out two issues, we didn’t have enough event cards and the effects weren’t balanced. These issues made our game unplayable, we started balancing and adding new cards. I was given the task to balance the existing events, where everyone else would design more. Math was used to calculate basic probabilities, I then listed which cards were broken and how broken they were. Each event was balanced to be easier, starting with the lobby and working my way down to the police. Some events i completed changed as i wanted the effect to have some relevance to the flavor text. This would be an example of a 1st generation card: You’re on fire! No literally! – Everyone discard all of your red cards. Improvements were made so the events had a chances of a good thing happening. You’re on fire! No literally! – Everyone must draw a card, if red discard all of your red cards. This allowed for more interactivity and gave our game rewards and risk. For the final iteration I made the cards more direct, as players were confused as to who the cards were addressing. You’re on fire! – No literally! Everyone must draw a standard card, if YOUR card is red discard all of YOUR OWN red cards.
Usually I can be very antisocial and not get involved as much as i would like. That didn’t happen at all during this project, in fact i feel like my communication skills have improved dramatically. While designing this project many forms of communication was used. Email, Skype messaging, Skype calls and face-to-face meetings(This included going to a colleagues house and visiting SAE on a weekend). All of these events made me get involved in the project more, and add more ideas and suggestions to current problems.
During the project i was the lead programmer, another colleague helped during the start. I had to design and redesign a lot of elements to the app. The other members who were given the task to design the layout of the app weren’t clear, so i was constantly changing how the app worked. Although this was inefficient and ended with the app not complicity working(Videos needed to be uploaded). I learnt a lot of new ways to do things in unity because of the inefficiency, video being the biggest.
For this postmortem, four topics are going to be discuss. The Original plan was to have an even amount of bad and good events that happened. While analyzing, a realization occurred that not many things went as well as expected. Though even after finding over six bad topics and only one good topic. My project was still completed, with all the features i wanted to include. The topics that had the biggest negative impact on my project were: A poor project plan, My game was too confusing, and I didn’t communicate with my consultant enough. The only good thing that i did well, was sticking to a schedule.
Project Plan (BAD)
A lack of knowledge with MS Project meant that my schedule wasn’t completed.
Not enough time learning how to use the program, meant that i was missing valuable information that could of saved time.
A misunderstanding and poor scheduling. The original plan was to use Linda.com to learn how to use the program. On Tuesday i came to realize that you needed to be logged in at SAE to create an account. This meant that i had to use YouTube to learn the program, wasting a lot of time.
If a similar situation were to occur in the future, where i needed to learn a program but the learning source was unavailable, some solutions could be: Create a mock-up of your idea. An example, if you needed to learn Photoshop for a task use a program that you’re more familiar with first. Once you have gained access to the source of information(How to use Photoshop), redesign your idea. This method will save you time and will also allow you to learn more about the program.
Ways to prevent the whole situation from occurring in the first place could be: Work calendar! As soon as a new task is acquired, schedule it. This will give you plenty of time to react to your task.
Poor Design (BAD)
Not enough time spent on the design documentation left the players in a position where they didn’t understand how to play Commander Morse.
A lack of an instruction screen, meant that players were getting confused with the Morse & Stealth systems within the first minute of play. This confusion lead to boredom.
The games ‘do action’ key was right mouse button, because this was the case players would get confused. They would default to using the left mouse button first which activated the ‘change mode mini-game’. This lead to player being confused for the first 30 seconds of game play. The other confusing factor was that players weren’t sure why they were activating the alarms, causing the player to die repetitively. The main cause for most of these events happening was a lack of player friendly controls.
Whenever a game is created in the future i should, check with my family members if they understand how to play. If i can create controls that my mum would understand then i feel my games would be very easy to learn.
Always check if your documentation is understandable and has the same vision that you have. Try to update it as often as possible, returning to each documentation created once a week.
The main issue was that i would only responded when he initiated the email conversation, helping him with any issues.
Minimal communication between me and my consultant meant that we both were missing out on a lot of game improvements.
Shyness was keeping me from seeking advice from my consultant. I didn’t know my consultant at the start of this course. My bad communication skills made it hard for me to start a conversation.
Finding a solution was hard for me because i was looking for a solution for my communication skills, but that’s not the point of this postmortem. The solution to this problem is to set times for meetings. This way your not initiating the conversation, just showing up to talk like professions. It is very important that you communicate as it will always improve the outcome of whatever you’re creating.
Sticking to my schedule(GOOD)
All of the tasks were completed on time with everything that i wanted to add. Extra time meant I could add more to the game.
Throughout the whole project a rough schedule was being used which made completing tasks easier then it has been in the past.
I have used schedules in the past but the difference with this schedule was that i broke tasks down into small chunks. Another major difference was that i was ticking of tasks that i had completed. This gave a slight satisfaction when a task was completed, visually seeing my work shrink. This method of working really helped with my usual procrastination. I think a major cause of procrastination is that when a task is assigned, we see it as a massive wall that we have to climb. The truth is it can be chipped at, slowing lowering the total workload. Once it gets to a certain size all thoughts of procrastination leave our mind, as we can clearly see that it is easy to finish.(I’ll do a procrastination blog from my point of view in a later blog.)
A good way to stay on schedule is too put time into the development of your schedule. A schedule is an investment. You waste time writing up a documentation that is meant to make you manage your time. But by writing this documentation you’re technically wasting time you could be spending on your project, this is true but only from a short-term perspective. In the long run you are saving a lot more time. So let’s say you invest 30 minutes writing up a quick schedule. Sure you lost 30 minutes of time which you could of spent finished 1 task, but with this you now have list of all the major tasks. Now you know what you game fully consists of and if it is out of scope. That was ok but let’s take it one step further, this time you invest 5 hrs. This will allow you to have a clear idea of all the tasks. Instead of investing 30 minutes to an hour on just one task, now because they are smaller a task might take 5 minutes. With this investment you loss 5 hours, but you gain a bunch of small tasks. This makes the project feel easier and eliminating any procrastination from your project.
For this postmortem, three topics are going to be discuss. When i write these post postmortems i always try to include 4 main topics to talk about, although when thinking over my project all the events always lead back to three main topics. The topics that were the core of this project were: Good meetings, consistent iteration and poor documentation. When analyzing my previous postmortem and comparing it, I can clearly see that i have improved. More positive topics meant i took a different approach when thinking how i write my recommendations. I want to dissect them so that i can understand what went right and try and use this for the future.
A consistent amount of team meeting each week allowed the group to easily iterate, discuss ideas, check-up on completed work and fix problems.
Each week we would would come in about 1 to 2 hours before class and have a face-to-face meeting. We would have 1 to 4 Skype meetings each week. If we weren’t in a meeting we would be casually discussing topics over Skype using text. We had two Skype groups one for game designers and one for the whole group this included the artists.
Skype was a very productive way for our group to have meetings, everyone already had it installed and owned a microphone. At the beginning i missed a few meeting as they were very early in the morning. But it eventually changed to happen mid-day which was a lot better for the group.
To have consistent meeting it is very important that you use a program that everyone has and is easy to use. If everyone in your group has a microphone it is probably better if you use a program that allows for voice chat as a lot more can be discussed by word. It is also a good idea to have face-to-face meetings before class. Everyone is already going to be there showing up an hour early to discuss and work in person, helps both the project and your group’s understanding of each other.
Team didn’t spend a huge amount of time into documentation. We rarely updated all the documents. This meant if we wanted to do work it was better to have a meeting to understand what we were making instead of looking at the documentation.
Documentation happened a lot at the start but as the project continued less work was put into it. This is because we wanted to spend more time on the project, which is a trap i fall into often.
The documents did not have clear version control. This information could be found on the document itself thanks to google’s recent changes tab. Though a lack of clear documentation on this information meant it was hard to tell what had been updated, and what hasn’t been added. This caused updating the document to be a pain to change.
Update the documents as you work on the project, this way everything is getting added straight away although sometimes you forget or miss something. Make sure that you make a version control section down the bottom with dates, the name of who updated it and information about what has been added. This way you can put a version number at the top of the document to keep track of how many times it’s been updated and how recent.
The team changed the idea for the game and mechanics used a lot to try and optimism the game’s performance and meet the brief.
The game was constantly being changed, i don’t think there was a week that went by where we did not change at least 5 elements of the game.
Good communication and constant meeting meant we could discuss new ideas for the game almost daily.
To Iterate a lot don’t stop when the game is finished and done. Keep adding more to the game, changing and balancing weak parts of the game. Improving and expanding on strong key parts of you game, to fully send the message you want your game to say. The last thing i recommend is if you are in a group, communicate as much as possible. Everyone has different ideas and views, use this to your advantage. Make sure to at least have two group meeting a week.