The play test plan for cycle 3 can be found here. There is a play test plan for our target audience Sally and then also one for our other testers who will provide a broader scope of details.
Our focus for the design was Sally:
• Age: 21
• Gaming Background:
– First game: Warcraft 3
– Current favourite game: SIMS 4
– Likes PlayerUnkown’s Battlegrounds
– Mobile games: Two Dots, 1010!, Pocket planes
– Does admit to playing Kim Kardashian game
• Gameplay experience
– Has been playing games since she was 10
– Plays approximately 1 hour per day
Sally has always seen herself as a gamer and started fairly early on in her life. She has around 11 years of gaming experience and still play approximately 1 hour each day. For this cycle we wanted to make a game that could be enjoyed in short spurts as Sally doesn’t sit down and play hours for hours on end.
Approach to learning and finding information:
Through the last 3 cycles of the design process of these games, there have been many learning points for myself and I’m sure for many others in the course. As with all learning it takes practice and through the small 12 week cycle of these games I have seen a progression of quality and design from the initial game. I now have a better understanding of the process required to design for a target audience, and I have spent a lot more time thinking about what not only what I would enjoy in a game but also what someone else might enjoy when thinking about game mechanics and interactions.
Non-Technical Skills Developed:
Something that I consider very important that I have had the pleasure of developing in the 3 cycles is the social/team based learning that I believe is an integral part of design. I think very highly of the opinions of others and have found nothing but improvements to my own ideas when discussing them with my studio group and the other studio group opposite me on the table. At the beginning of the cycles I wasn’t really talking as much to my group members, this was evident in the creative differences that were in the iterations of our games. I think other than the category it was hard to find any underlying commonalities to link the earlier games together. In more recent cycles I think the discussion of the games and bouncing ideas off of each other has brought together the tones of the game and it’s more evident to someone with an outsiders perspective that the games came from the same studio.
Strategies managing team based and individual assessment:
It has been an interesting experience working so closely each week with the same individuals, unfortunately during cycle 2 we had someone in our studio drop out. This left me and Joel as the only remaining members. I don’t feel like this was detrimental at any point other than some of the activities for cycle 3 we have needed to do a bit of extra work leading in to our own activities for the cycle. Both Joel and I have been able to work together when needed and are not afraid to ask the other for help. We spend a lot of time communicating outside of the tutorials, discussing ideas for the game and changes that the other might want to make to theirs. It has been very easy working in these groups, I have probably found more difficulty in the individual side of the work. I have really needed to set myself small goals through each cycle to prevent myself from leaving things to the last minute. It’s not that I don’t enjoy doing the individual work by any means but having someone to work with, in my opinion, escalates the quality of the work and I lean more towards this style of team integration rather than individual work. Planning has been probably the most important part of this game development cycle, good time management has had a very positive impact on the work load.
Some of the important parts that need to be considered when working in a team are, sharing an even workload, participating in group forums and making choices together. The reason these topics are important in teamwork is because if one person is doing the work it isn’t fair on them, groups are formed so people can work together and engage with each other. Having an open forum where choices can be made together as a group is an excellent way to socialise and have outsider perspectives to your own, every had a different childhood and group up different ways, so listening to others opinions broadens your mind to design possibilities in a game that may previously not have been thought of. This would be why developers are not working in their own little box when making games, they have developer meetings and bounce ideas off of one another.
The following assets can be located at the following URLS or attributed to these persons:
As we have in each cycle, Joel and I had discussions about ideas but as we are doing a 2d and a 2.5d game we haven’t really shared anything other than ideas this cycle.
Platform movement code – HTTP://forum.unity3d.com/threads/moving-platforms-2d-platformer.175594/
Skybox – RKD, NightSoundGames
Army Car – IGIIID
Airforce Plane – walterlima3d
Fires – Digital Ruby (Jeff Johnson)
Walls with Vines – bitsong
Sniper Rifle – Sagh
Exit Door –DNK_DEV
Skeleton – Polygon Blacksmith
Abandoned Buildings – Aleksey Kozhemyakin, LowlyPoly
Audio – BitsAlive Game Studios, Daniel Kole Productions
This cycle gave me much more to reflect on that the previous game.
I feel for this game my professional development has slowed since the last project. The quality of my coding skill has increased and I have learned a lot about game design, mainly the fact that no part is too hard it is simply the fact that to get a good result you need every aspect to be worked on by a separate specialist. The problem I had with this game is that while the game worked I was not happy with the outcome as in the end I found many little things that annoyed me with the game but were bound to other elements and therefore being too difficult to remove. I suppose it is logical for a larger scale project to have this but for the next game I will try to polish and be happy with each part before progressing. I also noticed with this project my computer struggling to run the game as it became more complex and should look into investing in a better computer as I wish to continue in game design and programming into the future.
A major take away from working on the first-person game was the importance of the different majors. Before this project I didn’t think of the majors as all that different but after trying my hand at 3d animation and modelling I now understand that each major is distinct and important. The game design major is important as they create the hooks for the audience to come back and create the core of the enjoyment of the game while the animators visualise these elements and ensure the animations and characters look as they do in the team’s vision, Finally the programmer works more behind the scenes connecting everything together to make it work. All the majors are important for a game to feel full and not like a prototype.
Most satisfying element:
The most satisfying element in this project for me was a small feature I implemented into my game where the player can in some circumstances jump over the instakill car that drives down the street. I wanted to create something like this because personally some of the most memorable moments in games come from the player attempting and succeeding at a creative solution that they don’t expect to work and I wanted to be able to bring that feeling into my own games.
Ethical issues of First person game based on real events
I feel that there is a major ethical concern with this game in both the task given and our teams interpretation of it. Creating a game based on a news story can be quite problematic as the news generally reports more on bad news and making a game from bad news is difficult to pull of without feeling insenstive. I felt this in our game particularly as more features were implemented and attempted to push away from the initial news story of a drunken fight outside of a kebab store to be more respectful to the saddening cases of people who are killed in random drunken attacks by shifting the story away from fighting people to fighting clones. Next game I intend to look more at what my game is saying even if it is unintentionally saying it.
This cycle i used the same series of playtesters with an adjusted form of playtesting to focus on the session goals established.
The notes take from the playtests can be found (here) with the results sumarised below:
Key findings across players:
A common element noticed during the playtests was that the difficulty in general was too high with players rarely winnng the game.
The story of the game was also found to be lacking with none of the playtesters able to explain what the game was about.
Fix building colliders to prevent players becoming stuck in the buildings
The controls were better synced with the animations for a more streamlined experience
The car was slowed down
The enemies movement speed was slowed
The enemies damage was lowered
The change in enemy spawn rate based on the players drinking was improved
A story section was added to the how to play menu so players would better understand what the game was about, the title was also changed to reflect the story. With more time ideally i would have incorporated the story better into the game itself rather than a wall of exposition text.
To improve the quality of our games the following playtest goals were established:
Goal 1: to balance difficulty
Goal 2: To test the players understanding story and their goals and reasons for in game actions
Goal 3: To check for exploits, game breaks or bugs.
Testers: For our play testers we will each choose 3 friends to get feedback from a variety of people with different gaming skills and knowledge of programming
Approach: Our method of playtesting will be very hands off. We will take notes beforehand on the player’s strengths, weaknesses and interesting traits before letting the player play the game for 15 minutes with minimal tester involvement, only when the player becomes stuck / has problem. During this 15 minutes, we will continue to take notes on what the player does well and what they seem to struggle with. After the session, we will ask questions based on our test goals. This playtest is close in structure to our previous game playtest however we havev shifted our focus onto keeping the session goals in mind with regards to the questionnaire at the end.
We will measure responses and data gathered in Approach and compare them with our session goals to determine improvements to be made.
Analysing responses: To be able to analyse the results we will compare the 3 playtest results to see if a pattern emerges, if a pattern is not found we will weight opposite responses based on player skill level. To ensure the player understands the story and motivation of the game we will ask open ended questions of the player to see if they can reach desired results. Bug fixing will be based on the events where the player needed help. We will decide how to improve any segments requiring tester intervention so players can complete the task without assistance.
After some discussion within our group we decided on the following guide for our games and how they would play.
In the game, you will play as a drunken man fighting against waves of enemies. The game will take place outside a kebab shop in the early hours of the morning after a big night out. The player will attempt to defeat all the enemies within a time limit to be able to order a kebab in peace and continue their night out. The player achieves this by attacking the enemies to destroy them.
Player stories X 10:
As a fighter, I will defeat the enemies by attacking them.
As the player, I will use movement to traverse the map to be able to survive.
As the player, I will use my special awareness to keep track of the locations of enemies to maintain optimal distances for attacking without taking damage.
As a fighter, I will move to avoid enemy attacks to keep their health high.
As the player, I will use my reflexes to avoid and circumvent environmental obstacles to keep moving.
As the player, I will play the game quickly and prioritise targets to beat the clock and win the game.
As the player, I will utilise the environment to slow down the enemies.
As a drunken character, I will drink to regain health while balancing the negative effects.
(NOTE This game play story may or may not be in the final project as it does touch on a taboo subject of glorifying drinking but could be needed depending on the games difficulty set up. After some discussion we decided to leave the story here but only implement it into the game if we felt the game needed it for balancing difficulty.)
As a fighter, I will attempt to increase my score by defeating enemies.
As the player, I will strive to defeat all the enemies to win the level.