Hi Isak, good to see that you’ve gained something from this game project. It’s clear that you have a game at the end of this that you’re proud of, and I can attest to say that the boss laser charge attack is awesome. What I’d like to see more of would be images or even GIFs of the game to give the reader a little more connection to what you’re talking about. As it stands, you are one of the many (3 or 4?) groups that made an Aetherial, and I only know the game you speak of since I recognize the sky slug. For a reader that has no connection to the game, it would be hard to relate.
Jerry made a GifCreator for Unity Games as a Unity pluggin. It’s a 15kb download, and it’s on slack if you search “GifCreator”. It’s super useful.
Although in some areas it’s very implicit what you have learned, it’s a little more opaque in others. What would you do differently when communicating with style guides with other artists in the future?
Focusing on strong shape design and clear silhouettes seems like good advice to a game designer, and i think that’s valuable.
Hey, thanks for sharing your process of getting playtester feedback. From your post it’s easy to understand what the playtesting in the course was about and when they were scheduled in the course. You mention that you had 2 members that were taking notes on what was being done. I’d like to learn more about your data gathering methods, Did you have a survey in addition?
There is a distinct correlation between changes made in the game and feedback from the play testing sessions. It’s clear that playtesting has impacted aspects of the game in a very direct way, but I would like to see how playtesting has affected the way you thought about making games, or at least your takeaway from having others play something you made.
Having other people outside the playtest, and outside the Game Design course play the game seems like something valuable. That they gave similar feedback is something that I will take with me from this post. It speaks volumes to the idea that it’s hard to make something good, but easy to point out that something is bad, even for a “layperson”.
I think ending the post with a connection to the Aesthetic goals of your game was a good decision, as it emphasizes that you have used it to inform the changes made to the game.
We made a game, and it was playable. I am honestly proud of this simple fact.
We used the MDA and achieved something adjacent to the aesthetic goals. We cut features in the concept document that would not have aided those goals, and in general had a consideration for the player. Our goals were;
feeling of being overwhelmed
Constantly in Danger
Fear of a relentless pursuer
We made assets that were regarded positively. We had a very cohesive visual design that was rough around certain edges but in the end mostly worked out.
People seemed to enjoy the game, and I heard a lot of positive feedback from testers in different stages. The game never felt like a complete bore.
We made good use of user stories and we had clear ideas of what the game needed at various stages. We had mostly clear communication and workflow, with some kinks in the mix.
We took Playtest feedback seriously and made changes that took further steps towards the aesthetic goals. We kept consistent data from each playtest
I now feel comfortable navigating and exploring features in Unity, as well as implementing assets. Having one Programmer was an incentive for some of the team to get familiar with Unity. Me, Hampus (game design) and Wiktor(Programmer) became the Unity team, working in Unity Collab since it only allowed 3 people to share a project.
What we ended up with
We made a nail bitingly intense and difficult game where the goal of the player is to guide a submarine through a treacherous and dark 2D environment filled with narrow caves, spiky rocks and hostile fish, all the while being pursued by a giant and evil-looking creature from the depths. The player could shoot small torpedoes at the fish to kill them, and could use a rechargeable speed boost to move forward. The fish damaged the player if they came into contact, and also hindered the player from moving forward, thus aiding the large pursuing fish in catching up to the player. If the creature catches up it eats the player, resulting in instant death. Several checkpoints are strewn about the level, and the player could pick up health as well as a shield boost that would protect the player from damage for a limited time. The player always had to play through an easy tutorial level before being exposed to the real pursuer. If the player got to the end they were greeted by a victory screen.
What went wrong – and what we should have done
We could have done more game designing effort. Too many assets were imported in the game, implemented, and then tested until they fit the minimum criteria for being an asset. We could have done more experimenting early to get something excellent. I can think of plenty of features right now that would have deviated from the concept document, but increased the likelihood of reaching the aesthetic goals if tested.
More prototyping. Not just with software, but paper. Make something barely playable and test it. Make ugly art and spaghetti code and throw it away. I have come to learn that Unity is a good engine to prototype in and getting something playable and dirty up and running. Next time I’m getting my hands filthy.
We should have made more mistakes early and failed faster. This could apply to all of us. None of us have been in a similar production pipeline before, so coordinating what needed to be done and when was difficult. For the coder and artists to know that they don’t need art assets because Unity offers squares and shapes. Artists needed to realize that all art created early would be replaced no matter the amount of effort, so make trash before you make fidelity.
The artists of the group (Ellen and me) didn’t always have good ideas of how long individual art assets would take, and so would spend more (or less) time on certain aspects than necessary. These problems were evident on a few items of significant magnitude. This comes with experience, and isn’t something we could have done better at the time. But a good rule of thumb is; if you don’t know how to do something, double your time estimation. Sometimes you should add 25% for good measure. The product backlog exists for a reason; if you finish early you just keep working.
We should be slaves to the aesthetic goals, not the mechanics. Don’t be afraid to change something that isn’t working, and examine critically why something is in the game. Does it adhere and add to the aesthetic goal? if not, you can cut it. If it does, make it do that, but even better. At some point during development the submarine Player character was given 3 health as a placeholder. It was also decided and tested that the player should take damage when colliding with walls. The damage added to the feeling of being constantly in danger, pressured, but it negated the main enemy as the main source of death. This was amplified when the fish enemies also started dealing damage. This didn’t truly become a problem for the aesthetic goals until we changed the level design.
Since those decisions were made the level design had changed a lot due to playtesting and increased experience. The level became harder and more difficult to navigate, and player death was much more likely. We had made checkpoints because we knew the game was difficult and players would need to feel progress in order to stay with it. This was in the concept document, but didn’t really feed into the aesthetic goal. It was at this point (after alpha but before beta) that we became too rigid in certain designs that we had become accustomed to. We didn’t stop and critically examine the mechanics themselves, and rather tried to reinforce the aesthetic goals using the mechanics we already had. Putting mechanics on the chopping block didn’t occur to us in a meaningful enough way to voice those thoughts, as we all believed the game to be good where it was.
We could have doubled down on certain things that made the game engaging; the speedboost mechanic was implemented late in the cycle, but it became apparent to me that it was the main thing that made our movement engaging, and should have been emphasized more.
And finally; group dynamics. Making it clear early what is expected from members when it comes to commitment and engagement, distribution of work and similar. There are many things I could have done to ensure all members were on the same page and engaged with the project; encouraged learning and working in Unity, working in the same room, and making contributions feel meaningful. A better strategy for group coordination would go a long way.
All of this is made possible because I have the luxury of not being in the workforce yet, I am a student. Having a minimum viable product is good but my main objective is knowledge and gaining skill.
I am here to learn, and the best way I learn is to do it wrong with the right intentions.
I count my failures as successes.
I hope these hurdles will aid me in failing faster in the future, because life is like a videogame. If there are obstacles in front of you, at least you know you’re going the right way.
-Benjamin Thomas Harbakk
Thanks Team Ettin for making this an enjoyable experience. I hope you fail quickly in your future endeavors. 😉
There have been two official playtests conducted at Uppsala University Campus Gotland for this course of Game Design 2. We have used these playtesting opportunities to great effect, and the tools that have aided us most is the fundamentals that we were taught early in the course. Using the MDA we have throughout the project tried to keep our eyes focused on our Aesthetic goals. These goals define the feelings and the experiences we want the player to have while playing our game. For the project these goals have included:
feeling of being overwhelmed
Constantly in Danger
Fear of a relentless pursuer
As described in the Concept Document authored by team Poltergeist. When the team has lost the way and has been struggling with how to balance the mechanics, we have always gone back to look at these aesthetic goals in the context of what the game was supposed to be.
During the play testing we collected data from the players describing their behavior during gameplay, as well as let them fill out a survey so they themselves could describe what they enjoyed or did not enjoy from the game.
These were the results we got from the Alpha survey. Most notably the feel of shooting the projectile has a low score, as well as the average for the monster pressure. This data told us that told us that there was something wrong with the balance of the game, and it wasn’t related to the gun feeling overpowered. Feedback and visual analysis of the game-play showed that many players found the level too easy. This was the opposite of what our Aesthetic goals were aiming for.
This was rectified in the next play test, where we exposed players to a more difficult level. We also made the movement of the Monster quicker, so that players rarely escaped it for long before it showed it’s head again, causing distress. We used the same questions to the last survey for certain aspects of the game we wanted to gather comparable data with, and saw a big increase in the feel of pressure from the monster. We tweaked the mechanics of both the monster and the level (in it’s design), we changed their dynamics with the player character, and in the end course-corrected to our desired gameplay aesthetic.
In the end we found a lot of the feedback valuable, and made several changes to the controls, movement, shooting mechanic as well as hitboxes based on the data collected. Playtesting for us has been key in the iterative process of making a quality product, and I doubt the game would be any good without it.
Hey, thanks for writing about your scrum.
Recording your meetings and adding artifacts that you remember after-the-fact seems like good methods of staying on top of the workload and documenting the progress.I find it interesting to hear about the tool Trello,as I haven’t heard about it before and it definitely seems useful as a program to track work in Scrum.
As far as structure of the written article itself I would suggest reworking or even consider removing the second paragraph of the text. It contains a lot of redundant information that is repeated in the end of the text, and maybe incorporate the nuggets of unique information into the other bodies of text.
I would love to read a little more about how Scrum affected how you developed the game, and of you sharing an anecdote or reference to an artifact that changed due to the framework itself. Including a picture would also benefit the reader in getting a sense of what you’re working on. If I came to the blog as a reader without reference to what Aetherial is, I would have a hard time imagining what it is and what you are doing.
Thanks for writing. I’m sorry to hear you have some issues with finding the fun, but I’m glad to see you writing it out. It shows that you’re reflecting on what you would like to do better next time, and it is ultimately the best way to learn. The reader gets to digest your challenges as well as your positives to using Scrum.
Your honesty is appreciated here, as honesty will in the end offer better learning experiences for both you and the reader, instead of a false image that you did everything right the first time. Maybe your group can work out some of your Scrum issues for these final sprints?
I don’t think you need to apologize in the end. I didn’t consider the text to be “ranty” until you suggested it, and then you started to color my view of your text. Reading it a second time it still works and isn’t a “rant”, so feel free to remove that part.
Short, clear and concise. You describe the problems and the process at arriving at a solution, detailing this production cycle on the crates. You justify design decisions and show a definitive willingness to work iteratively to reach the desired aesthetic goal and overall cohesiveness of your game. All I’m missing is maybe better labeling of the images, and maybe different placement of them. I would also maybe like a better resolution. I feel I’m left hanging without a ”final word” on the matter, but that just might be nitpicking since I can’t find anything else to critique.