For our recent project, our main mechanic was “mimicking”. After deciding to base the game around a stick insect name Stanley, our team knew we had to create this mimic mechanic from the ground up.

When deciding on how this mimic mechanic worked we went through a few different iterations of how this mimicking would work. In the original pitch, we said that each limb would be controlled separately using the keyboard. In this iteration of the game, the top 4 limbs each had 2 buttons to control the movement. These buttons were QA,WS,OK,PL. One button to move it up, and another to move it down. This would give the player complete control over where each limb would be, but we ran into the problem of this using far too many buttons and it ended up just being confusing for the player.

After some redesigning, the limbs were now moving by themselves. The limbs would start straight out, and slowly drop over time. When a player pressed the corresponding key, the limb would move upwards. The buttons we decided on were QWOP. Q and W would move the top limbs, and O and P would move the bottom limbs. This is the control scheme we decided on for our prototype. We chose this control scheme because it was more simple to learn and use than the original scheme, but still was a challenge for the player. The QWOP keys that we chose for the limb controls were chosen for no particular reason, other than those keys are familiar to some players because of the game QWOP. For the goal of the mimic mechanic, we originally wanted a silhouette of the goal figure to be overlayed on top of the character. Instead of going for this in the prototype, we decided on a dummy next to the character that the player would have to mimic.

Looking back now, the control scheme and buttons we chose is still far from perfected. The QWOP keys are okay for controlling the limbs but there are much better alternatives. A good suggestion we received was that a controller would be ideal for this control scheme. We could have used the analog sticks to control Stanley and the camera, while using the triggers and buttons on top of the controller to control the limbs. This would be a much more natural control scheme to use, rather than the player having to have to move their fingers and hands to different positions every time they switched from mimic mode to standard mode.

When making a game, an important part of the experience is the main menu. Usually, it is the first impression of your game that the player will receive and can cement the players mood for the rest of your game experience. For our main menu I created a few different sounds using BFXR, for different interactions with the UI. BFXR is an online tool that you can use to create video sounds, royalty free. It is a great tool for making placeholder audio, or in this case, UI sounds.

The first sound I made was a sound that activates when the mouse is hovered over a button. This sound is a very short, blunt sound that is quiet, but subtle enough that the player would recognize that the thing they are hovering over is a button.

The second sound I made was a confirm click sound. This sound is a similar sound to the first, but at a higher pitch. The sound itself takes a little longer to decay so the audio clip has a bit of a tail. This sound would be attached to a button and when the player clicks to complete a valid command, this sound would play.

The third sound I made is a deny sound. This sound is a sharp sound that sounds very similar to the first hover sound. The difference between this one and the hover sound is this one has a longer decay. This means the audio itself plays for longer, and drops off slower.

The fourth sound I made using BFXR was a cancel sound. This sound is a mid ranged beep that would play when the player would hit the back or previous button in the UI. The sound I went for was a mid ranged pitch so that it wasn’t a positive sound like the confirm sound, but not as low pitch as the deny sound I mentioned previously.

The final sound I made, and my favourite out of the 5 was my invalid input sound. This sound consists of 2 sounds stitched together. This sound is played when a player tries to click an invalid button. It starts with a short, low pitched beep, that then is followed up by a slightly lower pitched beep.

BFXR is a fantastic tool to create basic game sounds for placeholders or for your final game. After playing with it and becoming more familiar with this tool, I will be using it more in future projects.

Project pivoting can sometimes be an important part of the design process. Project pivoting usually occurs after a prototype is released and feedback is received. For our third project, Sticky Situation, we had both an internal and external playtest session. From the feedback we received I think it would help the projects final product if we pivot towards an easier to understand main mechanic.

What People Liked

After our external play test we got a lot of constructive feedback. Overall, the people who played the game enjoyed the aesthetic the game was offering. Some other feedback we got was that people enjoyed the scale of the world compared to the player. Another piece of common feedback was that players liked the idea of mimicking to hide from predators.

What People Didn’t Like

As well as positive feedback, we also received some negative feedback that well help us distinguish what players liked and disliked. A very common occurrence in the feedback was that the controls weren’t very good. They were a bit stiff when controlling Stanley around the map and the controls for mimicking were very hard to work and were confusing. Some other feedback to do with mimicking was that it felt useless and had no point. This was because the AI didn’t react to the player at all, and while in mimic mode, your hunger still went down to the point that you would die. Some other feedback included players wanting to be able to scale the scenery, disliking lack of animations and wanted to be able to mimic everywhere.

What is Changing

I think from the feedback, the big thing that needs to be changed is the mimic mode. By adding better AI to the predators, it will give the players a bigger incentive to use the mimic mode. By also removing the health depletion while mimicking, it will allow the player to take a little bit more time and focus more of the gameplay on the main mechanic of mimicking.

Another big change would be the controls. By making the controls easier to learn and understand, and making them smoother, it would make the play experience more pleasant. Another thing that would help the controls that got some mentions in the feedback would be making the game controller ready.

By pivoting the project in these directions it would tend to the feedback of the players and make the game much more playable.

The level design document for a project is important because it tells the level designer how to construct a level. The document needs to explain why everything is placed where it is, and how players will approach and encounter the game mechanics. Unfortunately, the level design document (or LDD for short) that we made for Sticky Situation did none of this. In our LDD, which is far from finished, we explain is slight detail about how the map was originally going to be created, and that't about it. These are the things that our LDD was missing.

As mentioned before, the LDD should explain the layout of the level and the game mechanics required to complete it. The start of the document should have an introduction to the level, to set the scene. For Sticky Situation for example this should have been a paragraph that outlined that the game was set in a backyard at around midday. This sets the scene for our level.

The next thing our level design document needed was how the game mechanics are integrated into the level. This section would have included where the food for Stanley would be, the places where the player can enable mimic mode, as well as where the enemies would be within the level. Each section would go into detail about why it is important to have why each mimic mode zone is where it is, as well as why there are certain things around it. For example, a paragraph explaining why this mimic zone has more enemies patrolling around.

The next thing our LDD would need would be a couple of different images to show the layout of the scene. This image would consist of the physical layout of the scene including obstacles and level boundaries, all the the collectables that are available to the player, all the of the mimic zones, and all of the enemies and their patrol routes (if eligible). To help distinguish between each specific object, they would be colour coded.

Unfortunately, our project never had a fully completed LDD, or even a completed level for that matter. But if we were to continue to work on this project we would need to update our LDD with this information so when it came time to actually create a proper level, it wouldn't be a jumbled mess like our temporary scene.

Audio in video games are just as important as graphics and models. In some of the projects I have been involved in this trimester I have had to source audio assets for my games. Unfortunately I have no skills in creating these audio assets, but there are a many online databases of music, sound effects and more that is available to choose from that you can either pay for, or use for free. Some of my favourite websites to use are newgrounds.com for music and freesound.org for sound effects.

In my first project I had to make a 2D game where you control a spaceship. For this game, I needed an upbeat tune that went for approximately 1-2 minutes long. The tune itself didn't have to loop, but if it did it would be a bonus. After searching newgrounds for a bit, I found I nice little tune called "My Pixelated UFO". The song is 1-2 minutes long but doesn't loop perfectly, but on repeat the end does blend into the start quite smoothly.

I also needed a shooting sound effect for this game. Because the ship uses a front mounted laser, I looked on freesound.org for some laser shooting sounds. After searching a little bit, I found a good one that was short and solid. When I imported it into Unity and wired it up to fire with my laser canon, I didn't like how low pitched the sound was. So inside the unity inspector I changed the pitch to 1.3, which meant the sound would play a little faster, as well as little more high pitched. This felt much more suited to the feel of the game. I also found an explosion sound effect for the death of the ship on freesound.org.

In the third project, I didn't have to find as many sound effects as I did for the first project. I did create the main menu which required a click sound when pressing a button. Once again, I went to freesound.org and searched for a UI click that I thought sounded okay. Once I found one, I imported it into Unity and attached it to my button, and I had a working click sound effect on my UI buttons.

Audio is extremely important for setting the feel for a scene or just giving the player audio feedback. I would like to learn how to create some of my own audio assets, but until then, there are a lot of websites out there that offer royalty free sound effects and music.

For our final project for the trimester, I challenged myself to create some 3D assets for our game. Fortunately, we had a group of very talented animators doing most of the heavy lifting when it came to the models, but I still wanted to try it out myself. I started of by downloading a trial version of 3DS max, as I have used it oncebefore.

Our game, Sticky Situation, is set in a backyard so I wanted to make a 3D model pot plant and add that to our game scene. How I pictured the pot in my head was a rectangle with a lipped edge around the top where the edges stuck out from the main rectangle. I started off by playing around with the cube tool, getting a feel for the camera movement.

After struggling with the cube tool, I made this odd contraption that slightly resembles a pot plant. I think.

As you can see, the top of the pot plant, is just 4 rectangles overlapping each other, which isn’t ideal, but it would work as a temporary model. After I exported the file as a .obj extension, I imported it into our Unity scene. This is where I encountered my next problem.

The pot plant’s scale is way off. I had to zoom out quite a bit to even be able to get it in the camera’s view. The temporary fix to this problem was to rescale it, at a texture to it and create a prefab, but I wanted to find out why it was so big.

The first thing I did was change the unit scale of my project, so that a 1x1x1 cube, is 1m^3. I then selected all the pieces of the pot plant, and used the scale tool to make the entire pot plant a scale of 10. In comparison, the original was approximately 60 units tall.

After that, I cleaned up some of the edges near the top of the pot plant, giving it a smoother look. I then exported it as a .obj, and imported into my scene. Here is the comparison between the original and the iteration.

All I needed to do now is add a texture, add some flower models the animators made and create a prefab so that we can now use it as a game object. After all this trouble with scale, I now know how important it is to take it into account. This also exaggerates the importance of an art bible so that the artists know what scale to make their models at so we don’t end up with a problem like this again.

In project two my team created a board game called "War of the Wizard Kings". In this board game, you had to take control of territory on the board by casting spells with your spell cards. Fortunately for us, we had a bunch of very talented artists helping us create the cards.

After our external play test, we got a lot of really good feedback from our testers ranging from game play improvements to card improvements. The most feed back we got was about our amazing artwork on our cards. One thing we noticed with this feedback was that the earth cards were a little bit hard to read. After looking into it a bit, we discovered that the only reason it was hard to read was because of CMYK.

CMYK is the colour model that printers use. Printers use the base colours cyan, magenta, yellow and key (or black) to do all their printing. The reason that the text looked fine on the computer was because monitors use the colour model of RGB (red, green, blue) which allows monitors to reproduce millions more colours. Unfortunately for printers, because they are using CMYK, the colours they can produce is a lot less. If you want to read more about it, I found this website that explains the difference between the two quite well.

Fortunately, I know the basics of Photoshop, so I made some changes to one of the earth cards to try and make it easier to read. Here is a before and after of the cards.

Click to enlarge

Click to enlarge

The first card is the original card with a green background and in the colour model of RGB. When it was printed, the text was really hard to read because the printer couldn't properly print the 2 different shades of green. The second card is the one I changed. I changed the colour model to CMYK, then changed the background of the card to a dark brown, which I think matches the Earth theme a little bit better than the green. I kept the text colour the same so it would stand out on the dark brown background.

I haven't had the card printed yet, but the card being saved in CMYK would mean the printed version will look similar to what I can see on the screen. Overall I am happy with the improvements I made, and think it adds to the earth theme that the cards have.

Over the last 4 weeks I have been working in a team to create a game called “Sticky Situation”. This project had things that went well, but also some things that didn’t go well. In this post-mortem I will explain what happened, why these things happened and how it can be avoided in the future.

Good

Animator Collaborators

Our team was lucky enough to be working with 3 very talented animators to help us create 3D models and animations for Sticky Situation. Learning from previous projects, I knew it was important to have a way to contact our animators as early as possible in the project. Our team did this by creating a private thread on Slack that we added the animators too. This allowed our team to keep in contact with our collaborators and allowed our animators to keep us updated with how the 3D models were coming along.

Scheduling

The schedule I used consisted of the task, details on the task, the person or people that would be working on it and the estimated task length. It also had a progress meter for the bigger tasks and a column to represent whether it was completed or not. This allowed my team to see exactly what each person was doing, as well as having a clear representation on how much time I had to set aside for tasks. What this allowed me to do was spread my workload over the week rather than rushing to get tasks finished the day before it was due. To improve this scheduling in future projects, I have to start scheduling from day one, rather than a week into the project.

Bad

Communication

Communication in this project was not sufficient. Within our team, there was some communication through the slack thread and through our schedule, but we could have benefited from more communication such as team meetings and skype calls. To keep a project on track, the team needs to communicate effectively both in person and through other mediums. This can be done by scheduling a meeting, either as a conference call or in person, to discuss the work we have been doing, and what work needs to be done. This would keep the team on the same page and allow everyone to focus on important tasks and share tasks if needed.

Game Design Document

Our teams GDD wasn’t thorough enough to be able to properly refer back to it if we were confused about something. This was because our GDD wasn’t properly kept updated as we were planning and developing the game. This document could have been used to its full potential if it was properly updated to match the progress of the project. In future projects, the GDD should be updated regularly and changed depending on the way the project is pivoting. This will allow people working on the game to refer back to it if they are unsure about something.

Art Bible

The art bible was not in depth enough to allow the animators to refer back to it if they were unsure of the style of the models and materials they were making. This was because our team failed to update the art bible with the correct information on 3D assets in the game. The document contained information on the overall style we wanted in our game, but didn’t give insight into what assets needed to be created, and to what technical constraints such as scale, which we had problems with in the project. For future projects, when working with animators or artists, the art bible should contain the technical constraints for the project, such as scale, the style we require for the assets, and how each asset should look when they are submitted to us.

Technical Design Document

The TDD we used for this project had no where near enough information in it. This was because in the first pass of this document, there wasn’t the correct information in the document. After the first past, Ryan wen’t through and added all the scripts he would think he would need for the stuff he was doing, which made the document for usable, but it was still far from finished. For future projects, as soon as we start designing the game, the TDD’s should be updated accordingly with each script that will need to be written, and what each script should do. These scripts should then be organised into what objects they will be attached to. This will allow the team to visualize exactly what scripting needs to be done for each game object to work as intended.

Audio Collaborators

For this project we had audio collaborators on board to help us create an original track for our game. The issue was after giving them some information on what we wanted, we failed to communicate with them effectively. This was due to the fact that one of the audio collaborators was never present for the few meetings we had at the start of the project, and the lack of communication between our team and the collaborators. Another possible reason we didn’t receive anything from them was that we didn’t give them enough information on what we wanted. To prevent this happening again in future projects, consistent communication is a must. A document that explains to the audio people the theme and feel that we want from the audio, as well as sample tracks that give the collaborators an idea on what sound we like.

In Conclusion

Overall, the project had a lot of things that we as a team need to improve on, as well as things I need to improve on myself. It is important to use this process to improve the outcome of future projects to help better myself as a game designer.

Project 3 has begun and the brief has been received. This time around our brief has us creating a game around player types. Bartles player types is a system of defining how a player plays a certain game. For example, the player types that our game is targeted at is the Explorer, and the Collector. The explorer player type thrives to discover the boundaries of the game. Not just the game world, but the mechanics themselves, pushing them to the limit to get every piece of information about it. The Collector player strives to unlock or collect everything in the game. People who find themselves searching for all the secrets, or achievement hunting would fall under this player type. For more information on player types, here is a good read about player types. And here is a good video about Player Types.

Some other things we need to hit in our brief is making the game 3D, everything will need to be in a scale ratio of 1,3 or 7, and have an approximate 10 minute play session. We also have to incorporate two different music tracks of music that would react to the gameplay itself.

The tasks I have set myself for this project will help me reach a passing mark for my Studio class. My group and I have already completed a High Concept Document and almost finished our Game Design Document, but we are still updating these documents on a daily to make sure they are up to date. I have taken it upon myself to do the bulk of the Level Design Document as that's what I wan't to do in the game industry. I have also started to work on an Audio brief for our audio collaborators, and an Art bible for our artists and animators.

Overall, the start of this project has been really busy, and should stay that way for the rest of the duration, but I think myself and my team are on the right track to a good outcome.