The mobile market is quickly becoming one of the largest, and highest earning game markets out there. The most popular form of revenue on the mobile market doesn’t lie with app purchases, but with in-app purchases (IAP) which are made after the game is downloaded. These IAP’s range anywhere from 99c, all the way to hundreds of dollars. And what do these purchases give you? In game content that would otherwise be locked away permanently or would have to be worked hard for over weeks of playing. For adults, these purchases are usually thought out decisions, with the player knowing exactly what they are doing, and what they are receiving. But what about children? Children’s games are a huge market on mobile as mobile devices are so easily accessible to kids.

But what implications can IAP’s have on children? Studies conducted in Europe examined how IAP's can subconsiously effect a childs behaviour. The study suggests that children are vulnverable to prompts to make IAP's if there is no restrictions on purchases and they are able to recieve something faster. These types of purchases offer instant gratification and reward, for doing basically nothing but use real money. This can have a negative effect on a childs behaviour and cause negative backlash such as continously purchasing items without their parents knowing. The study also mentions that kids that play games with advertisments and IAP's can have their behaviour change subconsciously and in the long term can effect purchasing behaviours.

So what does this mean for game developers? When designing a game that is aimed at children, we should take certain steps to make sure that we aren't part of the problem. Simple steps such as making it known that our game has IAP's instead of hiding them could make a huge difference. Another way to help is by making IAP's purely cosmetic only, this eliminates the chance of kids buying something over and over again. When the upgrade is purely cosmetic, the need to purchase a powerup repeatadly is removed which takes away part of the problem, but doesn't completely remove it though.

Children are kids, and they don't always know the full extent of what they are doing. When it comes to IAP's in games, at the end of the day, they are playing a game. To them, they just want that new shiny item, or the new set of levels.

References

Effects of Mobile Phones on Children | Impact. (2017). Kids.ownfone.com.au. Retrieved 18 January 2017, from https://kids.ownfone.com.au/effects-of-mobile-phones-on-children#.WH9XFvl96Uk

When designing the difficulty levels for Steel Seal, our team used Comma Seperated Value’s or CSV’s to dictate what spawned and how often. Throughout the life of the game there were different versions of these values that dictated the spawning rates of each object. In this post, I will compare the original versions of the CSV files to the ones that shipped with the game, and explain the changes that I made to them.

Pictured below are two different versions of the CSV’s of difficulty 1. The first picture is the first version of this sheet, and the second is what was shipped with the final game. The first thing you probably notice is that the original has a lot more lines to it compared to the final. The original CSV had all the spawners on the lowest difficulty, even though some things weren't spawning at all. This was unnecessary memory usage which was removed in the final build. Another huge difference is the amount of enemies spawning, as well as what enemies were spawning. Originally, all enemies were spawning in difficulty 1, and the spawn rates were fast, which meant players were only lasting a couple of seconds per play through. After watching friends and peers play the game, they would get frustrated at how fast they were losing. We didn't want Steel Seal to be a frustrating game to play, so to improve this, I reduced the Sharks spawn time from 3-5 seconds, to 4-7 and the Orcas and Polar Bears being harder enemies, I pushed them back to a slightly higher difficulty.

Another piece of feedback I received from peers was that the amount of snacks spawning was very low. With them only spawning once every 4-7 seconds, there were large spaces in time where you wouldn't actually collect a snack. To improve this, I greatly increased the spawn rate to every 1-2 seconds. This meant there is almost always a snack on screen that the player can collect. The amount of snacks spawning was originally very low because I based it off of the player collecting every snack that spawned. This assumption didn't take into account the snacks that would be missed because of obstacles and enemies. This increase in snacks made it that a player could miss a snack, and not feel like they are missing out.

Difficulty 1 - First Pass

Difficulty 1 - Final

Unfortunately, I don't have an original version of the Difficulty 2, but I managed to recover a difficulty 3 original CSV.

The first image below is the first pass of the third difficulty, while the second image is the final version. In this difficulty, you can see that unlike difficulty one, there are a more spawning in the final version then there is in the first pass. This is because of how we made each play through feel different to the last. In the original sheet, each object had its own spawner, with varying times and chances of spawning, but the way it was set up, each play through was either very similar to the last, or felt like a completely different level. Because it wasn't a 100% chance that the shark and orca would spawn, you could go for 6-9 seconds without even seeing an enemy. Players said that it felt weird having the huge gap, and one even going as far as saying they thought they bugged the game out. To remedy this, I made the shark spawn 100% of the time between 3-5 seconds. I then increased the chance of the orca spawning to 50%, which doubled the chance of seeing one. The polar bear originally spawned between 20-30 seconds, which in some cases was longer then the entire difficulty, which meant he didn't spawn at all. We fixed this by making the ice spawn every 7 seconds, with an 80% chance of it having a polar bear on it. This added some needed variation to the ice caps in the game.

Another thing we recieved an overwhelming amount of feedback on was the spawn rates for powerups and snacks. Originally, it was programmed that as the difficulty rose, the amount of snacks was dropped and so was the amount of powerups. This would have been okay, but the amount of time it took for a powerup to spawn, stacked with the chance of it spawning, meant they saw nearly no play in the later levels. This was especially noticeable for the powerups. This is definately not what we wanted, so in the final version as difficulty increased the spawn time was dropped dramatically, but the chance of the spawning was kept around the same level. This meant you saw almost 3 times as many of some powerups.

Difficulty 3 - First Pass

Difficulty 3 - Final

In the early versions of the game, there were only 3 difficulty levels. Because there was only 3 difficulties, there was a dramatic change in spawn rates moving from one to the next, and because there were only 3 of them, the time the player was in a specific difficulty felt like a long time. To fix this, we added 2 more difficulty levels in. This smoothed out the difficulty curve and made the change a lot less obvious, as well as shortening the time on each difficulty, making the game feel less repetitive.

Over the 13 weeks of trimester, the CSV's changed dramatically. This was from the help and feedback of peers and team members, as well as my skills at balancing were improving throughout the trimester.

Analytics is define as a systematic computation analysis of data or statistics. Analytics can be used for many things and are a great way to determine different things, such as what kind of content the player is enjoying, how easy or hard a level is, and seeing what content is more popular than others and why. They can be used to map your users and determine what is working, and what isn't.

Steel Seal was intended to use analytics to tracks statistics such as how many play through's per session, average score, what IAP purchases people are making the most and how long a players average play session. All of these bits of information could have been useful in improving the gameplay experience, but due to over scope and lack of time, we couldn't get our analytics set up in time for launch. This data could have helped refine the gameplay and make it a better experience for the player. If we did use analytics, this is the type of data we would have collected and how we would have used it.

If we were able to note how many play through's per session, and how long an average session was, we could use that to determine whether or not the difficulty of the game was okay. If a players play session would only last a minute or two, and they had multiple play through's of the game, we could gather from this that the game may be too difficult in the early stages and could be frustrating to the player. If a player is getting frustrated with the game easily because it's too hard, this could cause them to uninstall the game, which means less active users. This also relates to the average score metric. If a lot of players scores were really high, it could indicate that the games difficulty ramps up too slowly, or if their scores were all very similar it could indicate that the game is fairly easy, but then suddenly gets really difficult without any ramping. This again could be frustrating for the player, and could cause them to uninstall or not play the game.

The information we could get from IAP data would have to do with future updates. If a large group of players own a certain skin, for example the Santa suit, we could create more holiday event skins, such as Easter and Halloween. This would help us identify customers and take the guessing game out of creating new content. Another bit of IAP data that is useful would be what power-up's people are using. If nobody is buying a certain type of power-up, we know it's either over priced, or not effective enough to be worth a purchase at all. We can use this data to balance out the abilities so that each power-up is a fair price and the player is getting a worthy product for their currency.

Unfortunately due to over scoping and just being really busy with the final release of the game, we couldn't incorporate analytics in the final product, but if some time in the future, that could be implemented, it could be used to make future content more appealing to players, and help balance the game.

This trimester, in the midst of all the production, we were given the task of creating two fake persona's that would help us keep the design decisions within our target market. When creating these persona's we had to give them generic motivations and life goals, as well as what they do and how many games they play. Some other information included was what sort of games they enjoyed and what they didn't like about some. Our two personas are below.

Throughout the project we referred back to our personas to make sure the design decisions we were making were relevant to our audience. Because of these persona's a few design decisions were made. The first decision was what art style we were going for. The audience we were aiming for was people who enjoyed bright and colourful games, with funny and consistent art style. Steel Seal stuck to this pretty closely, with a very consistent art style throughout the entire game.

Another decision that was made had to do with our reward system. Steel Seal offers free in game currency every so often after a play through. This keeps people coming back to collect their currency, and also gets them to play a game or two while they are there. This count down was originally 2 hours. This seemed quite short, so we consulted our personas to find out when they were playing the game, and how often should they receive free gifts. After brainstorming a regular day for our personas, a six hour timer was required. This was changed for a few reasons. Firstly, the gaps in between play sessions for both personas was anywhere between 3-6 hours. This was due to work or school. We also didn't want to make the time a 3 hour count down. This meant every single play through the persona would get a free gift. This would pretty much make our in-app purchases pointless, as they could earn the same amount of currency in 24 hours. So we settled on 6 hours, which is approximately a free gift every 2-3 play sessions, depending on the persona.

Another feature added that was because of the personas was the social media integration. Both personas mentioned that linking games to social media and sharing photos of their high scores to friends was something they did a lot, so we integrated social media sharing. At the end of a game, when it is game over, the game takes a screenshot that you can then share to a social media of your choice, whether its Facebook, Twitter or Instagram.

Both personas also shared frustrations with pay to download games. This, and also due to our market research, is why Steel Seal is a free to play game with in-app purchases. The IAP model suited both our personas and market plan well. Overall, the introduction of personas to our project cleared up confusion with what our target market wanted. It also helped us make design decisions based on our audience and kept the game interesting to the people we wanted it too.

A lot of different factors come into play when designing a video game. Some choices you make may have social and economical implications that need to be addressed before you release your game. Steel Seal had a few of these decisions that were reflected in the shop and another large ethical decision was made in the art style.

The first decision was the art style. This was probably the easiest decision to make, but also could have had the biggest implications if ignored. Steel Seal uses a vector based art style, with bright colours, cartoonish animations and a kid-friendly feel. This design choice was done with intention, due to our target audience of ages 13 - 25. The way the art is presented, it comes off as a calm, kid-safe game, that a parent can trust their kids playing. While playing the game, you do have predators that are there to deal with the seal but the way the seal interacts with these enemies is simple and pleasant way. It would be unfitting to the art style if when the seal collided with a shark, that it was "eaten" with blood effects and gore. Instead, we went with something that matched our art style, and would keep the audience happy. When the seal collides with the enemy, it disappearsand bubbles fly out in all directions. This sends the message that the game is over in a pleasant way, without the need of gore which could have has ethical implications.

The second ethical design choice we made was how our game uses in-app purchases. Steel Seal has a shop where players can purchase skins for their playable character. These skins can only be bought using real money, and cannot be obtained in game in any way (with exception to special events such as the Christmas skin). It also has a place where you can purchase power-ups that can give you certain abilities at the start of a game. This decision was made in two parts, how much was everything going to cost, and how was the purchases going to change the gameplay.

Our team wanted IAP (in-app purchases) for our game, because after researching marketing methods, it seemed to be the best choice for our game. It was then the decision on how to incorporate them into our game, without it being 100% necessary to make a purchase. This is how we came up with our system. Skins, which are cosmetic items only can be purchased with real money only, and have no effect on gameplay. We wanted this to be the case because we didn't want our players to feel like they needed to spend money to get the full experience out of our game. If a skin was purchasable with real money only, but gave players an inherited advantage, such as a multiplier, or a shield for extra resistance, they would be earning higher scores than players that had the generic character. This would cause an unbalance, and mean that some of the players using the generic character would feel cheated, and no longer play the game, which is not what we wanted.

Instead of the skins giving extra powers, we integrated power-ups into our game. These power-ups spawn randomly during gameplay, or can be bought with snacks (our in game currency) or real money. The power-ups can spawn at any time during game play and give the player abilities. They also have variations that are bought through the shop, can be purchased with real money or in game currency and work slightly differently to the playthrough ones. They can only be applied at the start of a playthrough to remove any sort of pay to win aspect of the game. The reason they are applied at the start of a play through, and not activated at anytime is because it doesn't matter how many power-ups you have purchased, you can only use one paid ability each game. This means the person with a single speed boost, has just as much chance as someone who spent $10 and bought 20 of them.

When undergoing a large project, like the one recently completed by my team this trimester, it is important to have a strict project plan and project management processes. Unfortunately for our team, we didn't stick with our project management and it caused some trouble within the project.

Ideally in a large scale project like this, you need a project manager, or someone who keeps track of things such as updating schedules, keeping team members in order and to generally keep the project running smoothly. Unfortunately for our team, a project manager or team leader was never assigned to anyone, so these tasks were looked over and at some stages through the trimester, completely ignored. Occasionally throughout the trimester, we started using the schedules again, but every time we did, within a week they were forgotten about again. This caused confusion and frustration for all team members and I believe hurt the final product of the game for release date.

When you are working in a team on a project, there are a few different things that are a necessity to keep the project on track. The first thing the team needs to do is sit down and plan out the project. This is usually in the form of a GDD (Game Design Document). It is super important to plan out as much stuff as possible in this document so that scheduling and task assigning is done correctly. The next important thing is to try and create a full feature list, including scripts and assets. With this full list, we can then break them down even further into separate tasks. Once everything is broken down into tasks, you can start assigning tasks to different people in your team. This is where scheduling comes in. Scheduling has a few important parts to it that are important and cannot be forgotten. When you are scheduling tasks for people to do, it is important to be aware of dependencies, which is something that requires something else to be done before it. For example, you can't start creating texturing models, if the models don't exist. This is where a gantt chart is useful, or more commonly in recent years, a third party management software is used.

There are a lot of choices for third party management software these days. The common ones are Microsoft project and Excel, but there are a lot more available now that offer new and helpful features. HacknPlan is a good example of this. HacknPlan is a project management tool that is made specifically for game design. By using "cards" you enter in all of your features and tasks that need to be completed. Then with these cards, you can assign dependencies and assign people to these tasks. This visual interface is good for seeing exactly what tasks you have assigned, when they are due, what stage in the process they are currently in, and what dependencies they have.

An example of HacknPlan's interface for a different project.

The schedule our team used.

So what went wrong with Steel Seal. From the beginning, we started off strong with our GDD and task assigning. We each communicated well and we assigned tasks to each other and set ourselves goals on when we wanted them completed. After the first week of production though, things dropped off. Instead of using a project management tool such as HacknPlan, we decided on using a basic Google Sheets document, but as you can see above, it left much to be desired. This document only really contained key milestones in the project, and didn't outline all the tasks that needed to be completed and their dependencies. As the project progressed, this document became more and more outdated and useless to us, so it was neglected even more.

This lack of management caused us to miss some of our key milestones, as well as our final product missing some of its features for release day. The lack of any sort of asset or feature list, other than the small bit in our GDD meant that we were always not sure on what needed to be done, and the lack of gantt chart or schedule meant we didn't know who was working on what and when. This meant things were left to the last minute and some features such as the fishing boat power-up being left out of the first release. I believe that most, if not all of these problems could have been avoided if a proper schedule was used.

Designing levels is probably one of my favorite parts of designing a video game. In Steel Seal, even though there wasn't much design in the way of levels, there was design in the way the difficulty of the game ramps up over time. When it comes to level design, I enjoy creating not just levels, but experiences for players. This is why level design is my chosen specialization. We have all played a level in a video game that has made us sit back and think "wow", and that's what I like about it. Creating a memorable experience for players.

As mentioned before, because Steel Seal is an endless runner of sorts, there are no defined "levels" that the player navigates through. Instead the levels are more of a difficulty ramping scale that progresses the difficulty as the player gets higher scores. This implementation was done using a tool that Eli, our programmer created for me. The tool reads a few different CSV (comma separated values) files that determine when the difficulties are to be loaded, what spawns on that difficulty and how often. Eli chose CSV's to be the level manager because of how easy it is to learn, and how simple it is to go in and change spawn rates.

How it works is the level manager CSV reads what score the player is currently at, then loads in a respective difficulty. Each difficulty has multiple versions that load randomly to add a bit of variation to the lower levels. For example, Difficulty 1 has 4 versions. (1.1 through to 1.4). When the game starts, it randomly chooses one of these four variations of CSV, which makes each play through slightly different. When the player reaches 250 score, it loads in a random variation of Difficulty 2, which changes up the spawn rates and chances of everything from the enemies, to the power-ups.

The layout of the CSV is easy to use, and can be easily edited within excel or google sheets. The picture below is a screenshot of the Difficulty 4 CSV. Wave chance is the chance that a difficulty can be used. The difficulty is where the level manager reads to see what level it is reading. The object column is where things start to get interesting. Each object listed there is a spawner, which is why there are duplicates of some of the objects. More spawners equals more chance of one of those things being spawned. The spawn position is where on the screen its spawning. Obviously, sharks and orcas are spawning at the bottom, like polar bears walk in the middle of the screen. The SpawnTime, TimeRangeMax, Amount, and Chance all handle the spawning itself. I will use the first row as an example. The spawn time is 2 and the TimeRangeMax is 3, so every 2-5 seconds, there is a 100% chance a single shark will spawn.

An exmaple of a higher difficulty CSV

This form of level and difficulty design is really easy to edit and balance, because each object spawn can be controlled manually by only having to edit one of these CSV's in excel. This made designing the difficulties in Seal Surfer a breeze, and balancing the levels game me no problems.

In Steel Seal, the player can make different choices that effect the way the game works for them. Our game offers in app purchases that can effect the game play to a small degree. These purchases are small power-ups that can be applied at the start of a play through. In this blog I will explain choice design and how they apply to the powerups in Steel Seal

Choice design, also known as meaningful choice, is design that is implemented into games that causes the player to make significant choices that will effect the game itself, or the way that they will play the game. A common example of choice design is The Walking Dead game. The Walking Dead is a story based game that lets the player make obvious choices that will effect the gameplay. When it comes to choice design, there are a few components that need to be touched on. These are

- Awareness, whether the player is aware they are making a choice- consequences, what the consequences of the choice are- reminders, how the player is reminded about their choice- permanence, whether or not the player can go back on their decision.

If your games choices cover these points, your choices are going to have more impact on the player and the game play.

Steel Seal offers in-app purchases for power-ups that can be bought in the shop. These power-ups that are bought in the shop and can be applied at the start of a play through. The choices that the player has in Steel Seal are a little different to normal story driven games. The game play itself is very linear so the player doesn't have much choice, other than to swim up or down. The main choices that effect game play has to do with the power ups and in game purchases. These power ups change the way the start of a play through by giving the player a boost. These powerups include:

- Invulnerable: For a small amount of time, the player is invulnerable which guarantees a score of at least 50. This isn't a very high score, so its not a pay-to-win power up, but does give the player a choice. - Magnet: The magnet means all the pickups in game are dragged towards the players position.-Speed boost: This power up gives the player a large boost to approximately 150-200 score. This score is certain when the power up is used and gives the player an opportunity to go for their high score. - Feeding Frenzy: this power-up spawns 5 times more snacks that the player can collect for a short amount of time. This is a good power-up for when you are running low of snacks.

With these power-ups, the player has to make a decision on when to use them. The player is aware of their choice, because at the start of every play through they are reminded that they have power ups to use. The consequences the player has to accommodate for is that they may waste their power up, and therefore waste their snacks. After a power up is consumed, the choice is permanent and the player cant take back their choice.

In 2016, the mobile game market was responsible for 37% of the total market revenue, closely followed by PC and Console at 32% and 31% respectively. When designing Steel Seal, we had a good idea on how we were going to monetise our game to maximise the amount of revenue generated.

Over the past 5 years, the amount of games using a fremium model, where the game is free but you spend money on in game items, increased 30%, while apps using a paid model has heavily declined over the past couple of years. In app advertising however, stayed fairly consistant with only a slight increase over the 5 year span.

The average earnings of each monetisation type also helped us make our decision. For advertising, our team is using UnityAds, a service provided by Unity that integrates ad's into your game. When using these ad's, the average eCPM (effective cost per 1000 impressions) is $6-$12. The final figure depends on a few factors including region, billing type, ad lenght and the ad itself. For IAP (In-App Purchases), 80% of developers reported that under 5% of their users made a purchase, but from those few users, the average purchase was around $6 for android users, and the most popular IAP prices were between $0.99 and $20.

For Steel Seal, we decided to design IAP that would allow the player to customise their game experience, without the game becoming pay to win. We did this by creating multiple costumes or "skins" that the player could purchase with a premium currency. The only way to obtain this currency is to purchase it with real money. Taking the route of IAP for cosmetic items only is not neccessarily the most effective way to get customers to purchase items, but the team believed this was the most ethical way to do it. Making people who play your game pay money for a chance at the high score boards is not the kind of game we wanted to create. This is why powerups in our game are applied at game start, and can be purchased with an in game currency that can be obtained just by playing.

Steel Seal also has a secondary form of monetisation in the form of in app advertising. These advertisements are secondary to IAP, becasue our team though that having a constant banner in game would be distracting and annoying. Instead of that, players can watch an ad after a playthrough for a chance to win a prize. This ad is completely optional, and if the player watches it they are rewarded with a prize.

We chose these two forms of monetisation in that order because of the way the research reflected the downfall in popularity of paid games. From the chart above, it is clear that IAP are the most popular form of monetisation and they have a higher chance of earning money from a smaller audience, rather than relying on an add reaching 1000+ people. Because our game probably won't reach an audience close to 1000+ people, going with ad's as a primary earner would be pointless. Instead, having cheap, affordable IAP that the player can use to customise their gameplay experience, and marketing towards a smaller audience would yield higher income.

Another important part of monetisation is branding and promotion. For Steel Seal we created a Facebook page that we could use to post updates and information about our game and easily promote it to friends, family and the public. On this page was our recognizable logo and a familiar banner, along with posts with updates and screenshots. This form of promotion seemed to be quite successful with 40 page likes, more than what was expected. This also translated to actual game downloads as well. Currently, the game has 51 downloads and 33 active users.

For our Play Store page, we again have our distinguishable logo to greet the customer. On the main screen we have some colorful screenshots. These screenshots are attractive to customers and give the game a professional look which attracts the player to install the game. The combination of interesting logo, and professional screenshots increase the chance a player installs our game.

From the data showing within our developer dashboard, the amount of downloads we currently have is more than what was expected. From this we can determine that our branding and promotion through word of mouth, and our Facebook group, our game was successful.

What is Steel Seal

This trimester, we were given 13 weeks to completely design, prototype and produce a commercial mobile game for the Android market. We were put into small teams with another designer, as well as a programmer. I was paired with Carlos Melo, another very talented game designer, and Eli Deeth, a skilled programmer. The only restrictions we had to conform to was that it had to be a 2D game, released to the Android Play Store, and that the game had to have some sort of monitization built in. The first three to four weeks was the prototyping phase, where all students made a basic prototypes to test ideas and concepts of games. From here, we gave our prototypes to peers to get feedback on the basic mechanics we were presenting. We then had to narrow it down to a single prototype which we would then produce into a fully functioning mobile game.

The game we designed was originally called Seal Surfer, which we had to change due to a name clash with another game. The premise was simple, you play as a seal and you have to collect food, and dodge predators. This is done by a single touch input. Touch and hold the screen to swim down, and release to swim up and breach the surface.

What Was Successful

Overall, I would consider the project a success. We released to the public in time for the deadline, and I am proud of the product we presented.

Scope and Final Product

From the start of the project, our scope was fairly manageable and kept within what we could achieve as a group. The main mechanics were simple and easy to implement, and features of the game were designed in a way that they could be edited fairly easily. As production continued a few things such as camera effects and shaders, one of our power-ups and sharing functionality was pushed back and altered due to the fact that we were running short on time. As a group we decided that these things are not 100% necessary to the games core loop, and they can be desirable's that can be added at a later date. The share function and camera effects have now been added into the game, after the core game loop was up to a standard we were happy with.

Theme

With our game, we wanted a consistent theme throughout. From day one we had a clear idea on what we wanted the game to look and feel like. When creating a theme for your game, it is important to keep it consistent so that each scene or screen looks like it belongs to the same game. With Steel Seal, all the colours in our game are bright and saturated and our icons are in bubbles. This consistent theme makes the game feel complete and familiar to the player.

What Could Have Been Better

Documentation

The documentation for this project started out strong. In the first few weeks of design and production we created our Game Design Document. This document hit the deadline okay, but from there it didn't evolve with the game. Normally, a GDD is updated along with the game and is the bible we stick to when designing. Unfortunately, after the first iteration, there weren't a lot of updates to the document. It was also missing important information including exact prices for items in our shop, all the information about enemy metrics, including scale compared to the player and speed and information about our monetization.

This lack of information definitely had an impact on the project. For example, when our programmer Eli was implementing power-ups, he had to guess values which the designers had to go back and adjust later. This meant that myself and Carlos had to revisit power-ups that were already set-up. A similar case was with how much our power-ups costed in the shop. When Eli first implemented them, he referenced the document, but couldn't see it anywhere. This meant again, we had to take time to go back and change them instead of working on something else. All of this back tracking could have been avoided if our GDD was kept up to date and had all the correct information in it.

For future projects, to avoid this happening again, the GDD should be revisited at least once a week to update it with any information we may have glossed over, and update it with new information about our game.

Communication

Communication is an extremely important part of a project. Without communication, the project basically self destructs. Similar to documentation, communication started off strong with meetings in person and over Skype, as well as chatting through social media discussing ideas and changes we would like to see happen. Unfortunately though, the communication dropped off significantly around week 7. I would still communicate well with team mates in class, but out of class I didn't make contact with my team for a couple of weeks. This caused frustration for Carlos and Eli, not sure on the status of different things I was working on. Because I wasn't transparent with what I was working on at the time, this meant that Carlos took on extra work to cover for what I should have been completing. I will elaborate more on this in the workload sharing part of this post-mortem.

As mentioned previously, communication with team members is vital when you are working in a team. Without communication, things can get quite frustrating and cause problems within the project. For future projects, a set meeting time, either in person or over Skype is necessary. Once a week at minimum the team should organise a time that they are free that they can meet and discuss what they have done. These meetings should be run in the "stand up" format in which each person talks about what they have done this week, what they are planning to do before the end of next week, and what factors could possibly stop you from doing this. In doing this, it keeps each team member up to date with what the others are doing, and allows an appropriate amount of workload share amongst all team members.

Workload Sharing

Workload sharing was a problem from the start of our project, and should have been something addressed early on. From early on in the project, Carlos took on a heavy work load compared to myself, and this stayed consistent throughout the entire trimester. The reason for this came down to communication between team mates and skill sets each person had.

Carlos is a very talented artist, and he also is quite good at programming and design. Eli, being a programmer is very strong in C# programming. I am a game designer, so I am strong in design and balancing, but not so familiar with programming. Because we all have different skill sets, the work load had to be divided out among us. This is where things went wrong. Carlos worked fast and hard and got lots of work done. On the other hand, my work pace was a lot slower so I got a lot less work done in the same amount of time. Because I don't have any sort of art or graphic design background, and my programming skills are average, Carlos took on the role of main graphics artist as well as helping Eli program the game.

In future projects, to help split the workload up properly, I need to take on tasks I am not 100% comfortable with. By doing this, I am learning new skills as well as taking some of the work of team mates so they aren't as stressed.

Summary

Overall, the project was completed on time and released to the Android Store. There were definitely things that went wrong in the project, but there were also a lot that went right and the game itself turned out great. It is important to use this as experience and apply what I have learnt so that I don't make the same mistakes in future projects.

This trimester, we were tasked to create a commercial mobile game, and release it to the Google Play Store. Because we were releasing it to the play store so that the public can download and play our game, there was a lot of testing to go into our game to make sure it was balanced.

There are a few different types of play testing techniques commonly used in the industry, and each have their pro's and cons. I talked about two of these in an earlier blog which can be found here. In that blog I went through two common techniques used, but in this blog I will be focusing on what technique I used for our mobile game, Steel Seal, and why I chose it.

For our game, we used vertical slice testing, which gives the player a slice of gameplay that is fully functioning. We used this technique because of the way our "levels" were designed. Because Steel Seal is an endless runner of sorts, it doesn't have definitive start and finish levels. Instead, the levels are a form of difficulty scale, and blend with eachother as the game progresses and becomes more challenging. To test levels, we loaded which ones we required at what time. Sometimes we would load just one or two difficulties, other times we would load multiple in, depending on what we wanted to test at the time. What this allowed us to do, was to give testers specific difficulty levels to test, so we could get feedback on them, rather than giving them the full game and hoping they reached later difficulties.

With our vertical slice testing, we could give players specific difficulties and get feedback on that. A common thing I would ask my testers was what difficulty they thought they were playing on, on a scale from 1 to 5. Their answer allowed me to tweak the level to spawn more or less of something, depending on the feedback. This type of testing allowed us to tweak the difficulty of each specific difficulty, to make the entire game feel more balanced and fair when playing.

The way I ran full game tests was fairly straightforward, but gave me enough information to improve the game play experience. Ideally, when play testing you don't want people who are good friends, because they tend to say more favorable things and sugarcoat feedback, which defeats the purpose of having a play test. For the testing I did at home I used a mixture of acquaintances, and good friends to compare feedback between them to try and get the most accurate feedback. The first test I did was within Unity, using a mouse to control. I launched the game in full screen to the menu, and got them to take control.

The second play tests I ran was on a friends mobile device. I booted the game on his Samsung Galaxy Note 4, and got a few people, both acquaintances and friends, to play it. I received pretty much the same feedback as the computer play tests, with the addition of an extra comment. Most of the play testers noticed performance issues with the game, including stuttering and frame drops which made the game harder to play.

From these play tests, it was noted that the game was extremely difficult because of how fast and how many enemies were coming. Another bit of feedback that was received was the size of the enemies. They seemed a bit too large and if there was more than one enemy on the screen at once, it was almost impossible to dodge. Both of these issues were fixed quickly, with the speed of both the Orca and Shark being reduced, as well as both of them being slightly shrunk. As for the performance, the feedback was taken into consideration and the problem was found out to be with the animations and sprites. The sprites were then resized to a smaller resolution and the animations had their frame rates cut so there wasn't so much information being read. This helped the performance greatly.

References:

St. John, V. (2016). Gamasutra - Best Practices: Five Tips for Better Playtesting. Gamasutra.com. Retrieved 16 December 2016, from http://www.gamasutra.com/view/feature/185258/best_practices_five_tips_for_.php?print=1

Creative direction in video games is an important part of keeping the overall theme of your game on track. When creating a game, it should try and portray a certain feeling or emotion through its theme. Whether it is a horror theme portrayed with dark colour and gloomy music, or an 8bit theme with pixel art and animations.

So why is it important? Creative direction is an important part of any project, whether its games, film or advertising. When creating a project of any kind, you have to have a final goal in mind, otherwise you aren't going to get off the starting line. Once you have this final goal, whether it is for a client or for your own project, you can start the design process. Keeping a consistant feeling or theme through your entire project is important because it keeps the player grounded and familiar with your game.

Straying from your games main theme isn't always a good idea, but sometimes it can be used effectively to suprise your audience. Changing themes alot can confuse your player which may make them lose interest. An occasional change in feeling or theme can sometimes be welcomed, as long as its done correctly. Returning to your main theme is important to keep your player grounded.

A world famous game designer that is known for his great creative direction is Hideo Kojima. Komjima prides himself on his work and is well known for his creative direction and is mostly known for his work on the Metal Gear series. Kojima's games are all very well made as they focus heavily on story and changing up the game industry. Metal Gear was his first big title and was originally supposed to be a war game. Instead, under Kojima's direction Metal Gear was created a stealth combat game. This forced players to think intuitively about their next move in order to finish the game, rather than running and gunning like similar games around that time. Another thing Kojima is known for is his long, dramatic and cinematic cutscenes. He had a great love of film which really shows in his games. These heavy cutscene set the mood and theme for the player which are very unique to Kojimas games.

Storytelling is an important part of human culture, and is a huge part of making a memorable game. During this trimester at University we created a few games that required us to tell some sort of story to them. When creating Tunnel Vision, I wanted to convey a feeling of emotion and a backstory to the player without physically telling them about this story.

For Tunnel Vision, I mainly used the point-of-view and the show dont tell techniques highlighted in the Gamasutra post that I linked below. I used the POV technique in Tunnel Vision because I wanted to portray a feeling of emotion to the player. Instead of using a third person camera, I used a first person POV which puts the player in the shoes of the character. This is an effective technique when trying to portray a feeling of emotion to the player because instead of watching someone expereince an event, they are experiencing it themselves. For example, in Tunnel Vision, as you move through the hallway, all the other characters in the game are looking directly at you. In first-person, the characters are looking you directly in the eyes, which is much more effective at getting an emotional response than the NPC's looking at your character.

The second technique used was the "show don't tell technique". When playing Tunnel Vision, the player expereinces a change in movement speed, colour saturation and blurriness. These changes occur as you move through a crowd of people in a hallway. As the player, you expereinces these changes first hand, which envokes a feeling of emotion and gets the player thinking about what is causing this change.

This is only one example of how different storytelling techniques are used in video games. I will definately be referencing these techniques in future projects. If you are interested in reading up about storytelling in video games, I have linked a few posts about it below.

For Project 3 we were given the task to create a game that had home as an underlying meaning. We had 3 weeks to design and create the game, and then we would exhibit the final product to the public. I was partners with Jake Andrews and were referred to as Jake^2 (squared). We were going to create a game called Doggo Cribz, where you played as a dog, and you wanted to pimp out your kennel to make it your own. We were aiming for the feeling of home to come from being able to choose what to decorate your crib with. We had a gangsta theme to the game to make it more happy and lighthearted compared to the other 2 games we made this trimester, which were both heavy and had strong personal meanings behind them.

After the pitch, we had a lot of valuable feedback about the game. A lot of people liked the idea of doggo, but not so much the theme. Another common question was how were we going to give a feeling of home. After some redesigning, we tried aiming for home as a sense of community. With this pivot, the game moved from an entire neighborhood, to a dog park, where you are playing fetch with your owner and making friends with other dogs.

What Was Successful

Overall, the project was fairly successful. There were definately hiccups along the way, but we still presented our game at the exhibition to the public. Here is what went well with the project.

Collaborator Material

In this project we had a large group of animators making 3D models for our game. Because of the level being set in the dog park, we wanted a lot of different assets to put in our dog park to make it feel very interactive. Unfortuneately we didn't get as many assets as we wanted, but we got a whole heap of fantastic models that we used in our game. One of these models was the main playable character "Doggo", which turned out really well.

Project Pivot

As explained before, the original idea for Doggo was completely different. Our original pitched idea was great, but didn't quite hit the mark when it came to the feeling of home. After a week or so of dicussing the game and how we could change it, we decided to pivot more towards home as a community, rather than home as a place you live. I think in the end, this was a good decision and this version of the game hits the brief more than what the original idea did.

Team Communication

In this project, we had a fairly hefty team of 2 game designers, 1 programmer and 6 animators and an audio student. For me atleast, this was one of the bigger teams I have worked with. From experience with other collaborators in other trimesters, I know how important it is to keep in contact with the entire team and keep everyone in the loop. In this project, we had a few meetings in person, where we caught up with everyone and talked about progress, we also used gmail and Slack to communicate quickly as well. I made sure that every couple of days, I would send out a group email to everyone involved in the project to let them know how the game itself was coming along, and to also keep in the loop with what everyone else was doing.

What Was Unseccessful

The project, even though was an overall success, still had some hiccups along the way.

Animations

Even though we had a handful of animators working on our game with us, we never managed to get animations for the playable dog to work in our game. This was due to a couple of things including miscomunication, scope and time managment. Firstly, we wanted multiple dogs in our dog park, all of which would be doing something, whether that was playing with a ball, or just idling. Either way, we needed multiple dogs rigged, and never having animated before, I wasn't aware of the actual size of the task we wanted completed. Secondly, the miscomunication between myself and the person doing animations pushed us back a week later than we wanted. After recieving the animation a couple of days before the exhibition, we realised it wasn't working properly and we couldn't get it to work in Unity. By this time, it was far too late to reanimate our dog, so we did without.

In future projects, setting a clear deadline on when we want assets such as 3D models and animation will help remove the last minute crunch. Also, asking collaborators how long it takes them to do certain things will give me a better idea on when we would be recieving our assets.

Scheduling

For this project we had a project plan and schedule set up so that the team knew exactly what needed to be done and when it was due. Unfortuneately the schedule wasn't updated enough to be useful. At the start of the project, we filled in what needed to be done for the first week. These things were the Game Design Document, the Technical Design Document and High Concept Document. After these were completed we, updated the schedule so we could see what we needed to do next, but after that we stopped updating our schedule. I think this had an impact on time management and overall scope of the project. To help aid this in future projects, I could use scheduling apps like trello so that I can access it, add and remove tasks and resolve tasks from my phone, rather than having to log into my google drive.

Asset List

Our asset list for this project was something to be desired. When we first had our animators come up to us, we started creating a list of assets that we wanted made for the dog park. Some of these things were houses, dogs and toys. Both Jake and I updated this regularly to see what animator was doing what, and when they were aiming to have it done by. Unfortunately, the animators forgot about the asset list, and some didn't even put there name done to create some of the assets. For future projects, I would make the asset list a more important document, rather than something that people can fill out if they feel like it. This would help us keep track of how our assets are doing, and it would allow us to manage our animators better.

The floor is jelly is a 2D platformer made by Ian Snyder which was released onto steam on the 30th of May, 2014. The game has stunning visuals, beautiful audio and fairly calming gameplay mechanics. The game focuses on the whole world being made of bouncy jello, while you traverse platforms, making your way towards the end of the level.

The game uses certain techniques to make the player feel certain emotions while playing, and this is what inspired the design of certain parts of Uplifter, a game a made for University. The biggest parts of TFIJ's (The Floor Is Jelly) design that make the player feel is the audio and the movement mechanics.

Audio

The audio used in TFIJ is not very complex and has a very happy vibe to it. Depending on what kind of terrain you are in the audio feedback can change. For example, in the first few levels as you bounce around, there is an acoustic guitar playing a happy, calm tune. The sound that player makes as he jumps of the jelly is a high pitch plop sound. This makes the player feel happy and calm and lets the player know instantly what kind of experience they are in for. When the level scene changes, the audio also changes. For example, when you enter a cave scene the background music stops, and cave sounds start, and when the player jumps, it echoes. This gives instant feedback to the player.

When designing Uplifter, audio was a big part of portraying feeling to the player. Each level is supposed to make the player feel a certain emotion. That's why each level has a different audio track playing, each of which was chosen because it suited the emotion we were going for in that level.

Movement

Movement in TFIJ is very smooth, fluid and bouncy. The feeling this gives the player is free, calm and happy. When you jump, the ground beneath you wobbles like jelly which allows the player, if timed correctly, to trampoline higher than before. This is an extremely fun mechanic and adds to the freedom and bounciness of the game. When designing the movement for Uplifter, I wanted each level to have unique movement attributes. This would in turn hopefully make the player feel certain emotions. For example, the first level was sadness, so the movement was slow, the jump was almost nonexistent and the bounciness was much to be desired. This was done on purpose to make the player feel like they were struggling to make the tiny jumps put in the first level. In level two, which was the anxious level, the music changes to a more fast paced tune, and the movement is a lot faster. The ball rolls quite fast, and jumps high, but doesn't bounce much. In the third level, which was calm, the ball's gravity is reduced and the jump size was increased, so the player feels like that are floating through the level.

When designing a game with emotion, it is important to focus on certain aspects of the game that will affect your player the most. In The Floor Is Jelly's case, the movement and sound track helped get the feeling of emotion across to the player, which what inspired aspects of Uplifter.

When creating a video game, it is important to test certain aspects of your game to see whether or not you are going in the right direction in the design process. The two different playtest methods I will be focusing on in this blog will be greyboxing and vertical slice playtests. I am specifically focusing on these types because I have used them during my education at University.

Greybox Testing

The first playtesting method, and the one I have used the most is the greyboxing method. A greybox playtest consists of the testers playing a nearly fully functioning game. This means that the game (or level) you want to test is mechanically complete from start to finish. Because this is a greybox playtest, not all aspects of the game or level are complete yet, including textures, in-game 3D models, dialouge and audio. Usually, recycled models, cubes and untextured models are used in place of the final versions.

The pros of greyboxing is that as a designer, you don't have to worry about how the game looks for the playtest, and focus on the mechanics of the game or level. Greyboxing is a great way to test whether or not a new feature is working as intended such as level layout or a new mechanic.

Greyboxing, even though effective more tackling mechanical issues, can also be problematic. If your level or game is trying to portray an emotion or trying to get the player to feel something, greyboxes and stand-in music generally wont cut it. A good exmaple of this is with my Studio 2 project called "Uplifter". This game had to make the player feel 4 different emotions throughout the play time. A huge part of triggering these emotional responses in our game was our colour scheme and audio. Without the audio, the game was extremely boring and became unplayable after only a few seconds. This is why we found Vertical Slice Playtesting to work better for us for this project.

Vertical Slice Playtesting

Vertical slice playtesting is another widely used form of game testing, and is one I have been using myself. Vertical Slice Playtesting differs from greyboxing because of the way a game or level (or part of a game or level) are presented. As mentioned previously, greyboxing usually focuses heavily on the mechanical side of the game, and less of the look. Vertical Slice focuses on a short section of the game or level, and tries to bring the full experience to the player. This is very similar to what a demo is used for. Vertical Slices usually have all final models, textures and mechanics, but focus on a certain thing the designer wants to test. For example, I used Vertical Slice to test the emotional response from the first level of my game Uplifter. This level had its final layout, as well as its textures and audio implemented. This gave us a very accurate reading about the player experience, something we couldn't have gotten from greboxing.

The pros of Vertical Slice playtesting is that it allows players to experience a small section of a game to its close-to-full potential. This gives the designers really valuable information on how the player interacts with the game, as well how the game makes the player feel.

Some cons of Vertical Slicing is that it takes a lot of time and effort to create a section of a game to close-to 100% completion and the designer might not even get the desired information they are looking for because they are missing out certain parts of the game and level.

For the first two weeks of trimester I have been working on a small project. This project was a solo project where we had to make a game that was based on a personal experience.

Good

Scope

Because this project was only 2 weeks long, appropriate scope was an important part of this project. From day 1, I had an idea of what I wanted to create. I know what skills I am confident with, and what I needed to learn about to get the project running. So I estimated how much time it would take me to learn the required skills.

Pivot

Project pivotting is an important part of making a video game. After my first playtest, it was apparent that something needed to be changed. I defaulted to a win and loss state for my game, which didn't really fit. I had a bar that when it reached full, the game would end. I got a lot of feedback about the bar and how it took the expereiecnce out of the game, so I decided to remove the lose state of my game.

Bad

Documentation

Due to the short turn around on this project, there wasn't any time to do any proper documentation. Because the project was only small, it didn't have a large effect on the final product but with documentation such as a level design document, game design document and high concept document, the final product could have been better.

In Conclusion

Overall, the project went fairly smoothly and I managed to get everything I wanted to into the game. I am quite happy with the game I made in the past 2 weeks.

Week 1 of Trimester 2 is complete and we are already on the way to creating our first game. Our first brief revolves around emotional and meaningul design. We have to think about something that has impacted our life, either good or bad, and make a short 5 minute game about it.

With this task we were asked what does emotional and meaningful design mean to me and how it could improve my skills as a game designer. I believe that this creating projects with meaningful or emotional design helps create a more relatable character. For example, the soldiers in Call of Duty. Those characters aren't memerable and as a player, you don't have an emotional attachment to them which means anything could happen to them and it wouldn't matter. On the other side of the spectrum you have Joel and Ellie from The Last of Us. Both these characters have emotional backstories that are fed to us throughout the game These meaningful cut scenes and moments help the player connect to the character on an emotional level. When this happens, the player cares about there characters wellbeing more, and helps set up an emotional attachment to them that lasts, even after the game is finished.

This first project is good practise at creating a character with emotional meaning and background. I know that before this I haven't had a meaningful character in anything I have made, but already 1 week into this project my main character feels more human. With this practise, hioefully in future projects I can apply what I have learnt to make a more memorable and meaningful character.

Another thing we were asked was what we want to get out of Studio 2. My answer kind of ties into everything I spoke about previously. The biggest thing I want from Studio is experience. The best way to learn about making games is by actually making games. In the process of making games, you also make mistakes. These mistakes are a good thing, because it lowers the probability of them happening again in the future.

Creating a 3D model is only part of the 3D design process. Once the model is created, it is just a solid white object, which doesn’t really fit into any game. With the 3D pot plant I created (which I talked about in a previous blog) it needed a texture on it so it fit into the scene we created.

The pot plant, when I imported it into our game scene, it was just a plain white object. This really didn’t fit into the scene.

Pot Plant model without textures

Because I made this model myself, the animators hadn’t made a texture for the object. This is where Unity’s inbuilt material creator came into effect. The look I was going for was a clay brick finish. I chose this colour because the level is set in a backyard, where clay pots are common.

I created the material in the editor and found a colour that was similar to what clay would look like on a pot. Once I found the colour I added the material to my pot plant. This instantly made the pot plant fit in the scene better. But it was missing the “plant”.

Fortunately for me, the animators created some great sunflowers with very nice textures. I added 2 sunflowers to my scene, and made them a child object of my pot. I then positioned them in the pot and created a prefab. The scene now had a pot plant with a texture and an actual plant, that my team could move around and add to our scene.

Game design opens up a lot of different paths for me when I finish Uni. The type of development I am interested in is level design, and how these levels come together in different ways to become the final level.

My interest in level design stems from being addicted to command and conquer and age of empires world editors when I was a kid. The design process of starting with a blank canvas, designing the layout of the level in MS paint and then spending hours upon hours terraforming the map and adding resources, trying to create a fun and balanced multiplayer experience for everyone who played.

My career goal is to be a the lead level designer for a large game publisher. My favourite type of maps to create are multiplayer maps, so I would want to work on the multiplayer maps. What interests me about multiplayer maps is the balancing and making it fair and fun for all players. There is nothing I hate more when playing a multiplayer map than coming across a map that is really one sided.

Some ways I can work toward this is with small steps in the game industry. The first step for me is to make personal indie projects. This ties into one of my personal goals, which is to have a game on Steam. Once I have built up a small portfolio of projects that I have worked on (I already have some projects in my portfolio) I will try and get a job at a small publisher. Once I have my foot in the door, it’s about learning new skills and improving on skills I already have.

Ideally, my career goal would be to work for a large game publisher as a level designer, with a couple of my own games on Steam or another marketplace. I am already on my way with games on itch.io for download and a start on a portfolio.