Hi there Teo!
When it comes to seeing your creation come to life I feel just like you do, it is truly something magical.
The ‘what has gone well’ part of the text seems so short, you start it of with “First, I’d like to start with what have gone well:”, which signals to the reader that there will be several things that you will bring up that has gone well during your project. If just having a game is the only thing that has actually gone well with the project then maybe that should be made more clear.
I can also resonate with you with the core loop issue, we had the same problem with our game, it’s a shame that you feel like your game’s core mechanic did not reach higher than you had wanted it to.
I have not played A hat in Time, but I have heard great things about it. It seems to take what made Mario good and I can appreciate that. The point you make is also very valid, I wished that I could have seen that sooner with our project.
It would have been nice to see you expand on what it is that you have actually learned during this course, it all seems fairly vague at the moment. Apart from that it was a nice structured and well written post, good luck and have fun in the next course!
Cheers! /Daniel
Hi there Max!
Right of the bat you let the reader know what the post is all about, great!
It would have been nice to know what your survey’s questions are, giving the start of the post more substance. If you could have written any of the differences that you found when observing your testers during the alpha and the beta would have been interesting to read about, if there were any that is.
I am not sure how being sped up is meant to be a downside, in regards to your right-click ability, do the bees speed up a significant amount to the point of them being hard to control? Judging by the text it is both a yes and a no, some testers killed of their bees but it was somehow still a dominant strategy? I am not sure I understand that part of the post. Was the ability only usable if the player’s skill level was high enough to control the bees?
I can totally resonate with you on the last part of your post, having tester from outside your team really lets you know if your design is functional or not.
A nice post, even though I know I asked a lot of questions I do not think it was bad in any way, I am just curious!
Cheers! /Daniel
Hello Adam! The first couple of sentences made it instantly clear as to what the post is about, the second half of the first paragraph is not as clear however. Considering that you are a programmer I take it that the enemies in the game has been, up until this point, in a placeholder state coding wise. I do, however, recall that the dragonfly looked differently before and acted fairly similarly to the way it does right now. It would have been nice to know which of the enemies that you were polishing was in a placeholder state before and which of them were basically ‘done’.
I like that you have included gifs, they help with the visualization of what was written about that particular enemy. I do think that it would have been prettier and it would also have made it easier to read about how the Spider shoots at the player if you had some sort of visuals accompanying the text.
I am not quite sure what the last sentence of the Wasp paragraph means, what is the randomized post?
Hello there Isak! It is good to see that you feel like you have improved your work ethics! I know all too well about the trap that is procrastination, I have been there before and still am, to an extent.
Your post highlights the most important part of scrum, which would be the communication and re-iteration aspect. I do feel however, that you could have gone more in depth on how you and your group handle meetings were you discuss how an asset, or assets, should look and/or function.
It would be interesting to read how you have motivated yourself to work in these short intervalls everyday as well. It could motivate others who are having the same struggles as you have had, and maybe they will finally brake free from the bonds of the dreadful procrastination curse.
Thank you for the great post and I hope you will continue with this upwards trend that you are currently on!
Hello Roberto, Very interesting and well-structured post! The insight on why the cannon looks like it does is appreciated and I have a few questions on the few things that seems to have been left out of the original post.
First up, between the first mock-up and the alpha version the cannon has changed in color, it would have been interesting to know about the reasons for this change.
Second, you mention Super Metroid and Star Wars as inspirations but there are no specifics given regarding where from those IPs inspiration was taken from. More explanation and insight on what objects were directly or indirectly influencing the design of the cannon would have been great to read about.
Thirdly, the mock-up cannon has six ‘bars’ in its charge bar, but the alpha cannons have four, or is it eight? It is not super clear just from looking at these pictures how many shots the cannon can hold at one time. I am sure this question is answered when animation is added to it, but in its current state it makes me a bit confused.
The start of the post should act as an introduction to the rest of the post, right now it introduces the game your group is making instead of what the actual post is about. I can understand that you would like to introduce the group and the game that you are making but maybe that is for another post.
Disregarding the introduction, the rest of the post is very clear what it is about although it is not super clear on how the procedure of actually writing the group contract went. How much influence each group member had on the contract would be interesting to know. It would also be interesting to know what the current “punishment” is for being late since the only example given is a theoretical one.
It would have been nice to read about the structure and content of the group contract and how you decided what to write in it rather than that you did write a group contract and the general reason for why you did it.
It is finally time to harvest our crops after much work, our game is finished and after everything is said and done, it is not half bad. What we showed at the golden playtest session was a polished game with not too many apparent flaws.
The final iteration of You May Kiss The Bride is a top-down, semi-isometric 2D shooter and looks little something like this:
The first enemy of the game is trapped in a ring of benches so that it is no threat to the player, it is meant to teach the players how the enemies look
The player plays as the character Brad, Brad is having bad dreams regarding his wedding and does not want to get married. As Brad is about to be wed he decides to run away since this is not what he wants, this angers Brad’s bride, who in turn transforms into a demonic banshee that chases Brad. Brad is now forced to run for his life, shooting his way through the hordes of demonic guests that try to stop him from escaping.
When Brad finally manages to escape the church he wakes up in his bed, right next to his boyfriend. Brad is still haunted by all the norms of society that his parents pushed on him, when all that he ever wanted was to be himself, which he can gladly be now that he has left his former life behind him, living happily ever after.
The game is set in one place, the church that Brad was meant to get married in, but it is in a demonic state. There is only one level in the game and the objective of the game is to reach the top most part of the level, traversing between benches, holes, fires and enemies that either swing their arms or spits tar from their mouths.
To teach the players what holes are and how they work I made it so that enemies would start walking towards the player before they appeared on-screen so that this would happen:
Just as the player starts seeing the hole, an enemy walks into it, alerting the player that there is danger in walking straight forward
Right after the first hole in the game, I try to teach the players how fire works, the fire tutorial works in two stages
The first stage: the player walks through a fire corridor with enemies walking through the fires, the enemies starts to burn and takes enough damage to die
The second stage: with no other way to go, the only way to get forward is by moving through the small fire in the middle, making the player take a minimum of 20% of their health
The last tutorial of the game is meant to showcase the pick-up of the game. The pick-up is a one-time use item that freezes all enemies, including the Bride, that is around Brad.
To create a sense of urgency I set up the tutorial like this:
The pick-up is placed before a choke-point with several enemies moving towards the player
The Missing Pieces
Not many testers were hit by the melee only enemy in our game, but those that did received varied results. Some testers were pushed further than they should have, seemingly teleporting them a small distant, catching them off guard. My main suspect as to why this bug happens would be that if the player got hit by two melee enemies in quick succession, the two forces makes the player get pushed back the ‘correct’ distance but not in the correct amount of time.
Some other things that are not correct are the number of features our game was meant to have, we missed some to say the least. Well to be fair there are not too many more features in the concept document than there are in our game, but i digress. We were meant to have one more enemy, one more hazard, a boss at the end of the level and the melee enemy was supposed to be a man, according to the concept.
The reason that all of these features did not make it into the game has to do with time constraint and inexperience, and those two combined leads to poor time estimations for the work that is meant to be done.
Ooh boy, the level design, my sweet summer child. I have not had too many lectures on level design, I think it racks up to about 3-4 hours in total. The game’s level design was completely up to me, everything is manually placed, every bit carefully constructed so that the player could either play it safe or play the high risk/reward style. Now I say “carefully“, but to be quite honest, I had no clue whatsoever as to what I was doing after the tutorial part of the level. Most of it are just patterns made out of benches and then fires replaced some benches to create shortcuts, it is a mess quite frankly, but somehow it worked out. Now I did not hear it personally, even though I stood right next to my game the entire day, but apparently I got high praise for my tutorial from Jerry, yay!
Two second year students competing over who could beat the game first
Our game was considered one of the most difficult on the “show-floor”, with only 9 people completing the game. With over 40 participants it is not hard to see why people thought that. While not everyone that played our game answered the survey we had, there are some facts that I am quite proud of, kind of. The first being that 85,7% of those that answered the survey reached further than 70% of the level. With that in mind, 82.2% gave a 6+ in difficulty out of 10, which means that people thought the game was challenging but they could still reach the later parts of the game.
While these statistics look good on paper, the truth is that the difficulty of the game ramps up significantly after the 70% mark, an oversight on my end, to say the least.
Speaking of difficulty, if you have not read my last post; Test, Test and Then Test Some More, The Great Regret, I highly recommend it, it gives more insight on the upcoming segment, it is however, not necessary.
The Aftershock
What I immediately learned from watching people play my game was that nothing is obvious, they have no prior experience with the new features that we had, why would the new features’ functionality be obvious to them? this was most apparent with the newly added fires, the enemies walk through the fires and they die, so why would the player not meet the same fate? Almost every single tester that had not seen other people play the game before them did not proceed beyond the first fire obstacle on their first playthrough. The first fire obstacle is meant to teach the player that they CAN walk through it, they just take some damage from it and then they get a healthpack right afterwards, simple, effective. It would have worked fine if it was not for the simple fact that the healthpacks were places outside of the viewable play area, which meant that there were no incentive for the player to walk through the fire in the first place, except for the fact that the only way they can walk is up.
This problem could have easily have been taken care of beforehand if we had only brought in external playtesters. I was practically the only one who tested the game extensively, so my eyes had partially turned blind to the game’s flaws and these small issues are no exception.
I am not a very confrontational person, I do not speak my mind unless there is something that really bothers me. In the case of our game project, I held my mouth closed far more than I should have, I am supposed to lead my team in the same design direction, but that is impossible if I don’t speak up, even against the small, seemingly meaningless issue. It would have saved me a lot of headaches from hearing the words “I assumed…”.
Tying in with the last two segments, I should ask for help more often. I am a part of a team, I do not need to do anything alone and I should especially not do playtesting alone.
I do not even have to ask my team for help, the other teams would also benefit from having a playtesting exchange every once in a while. There is no shame in asking for help, learning is why we are here, and learning from your peers is not only good for you, but also good for them.
Playtesting in all of its variation is an integral part of iterative design. when used well it can help identify problems that were hidden in plain sight. How and when you playtest is of most importance, testing often and testing specifics of your game gives you a greater understanding of your game and its systems. With greater understanding comes greater mastery of your game, which blindsided me to the difficulty and learning curve of me and my team’s game.
Me and my team’s game’s greatest weakness is that the only balancing that it gets comes from me. Now that sounds weird, of course the the person who has studied the most design should know the most about balancing, and while that is true, my eyes for what is hard and for what is easy are tainted. For reference; when I was younger I played semi-professional Call of Duty, right now I am in the top 0.3% of all unranked Rocket League players, and I used to be in the top 4% of ranked players on the server I play on in League of Legends when I took that game seriously. When I play a game a lot, I get good at it, and in the case of balancing my game, it is a detriment.
At the same time that this is happening, my teammates do not play our game that often, even though they can play it anytime they want. I do not get enough feedback from them to know if the game is still too hard or if I have made it too easy.
This is the last challenge in the game, the magnetic looking things on the sides are placeholders for holes (grey) and fires (red). The slightly brighter, red enemies are melee-enemies and the darker ones are shooting-enemies. The yellow light is the game’s power-up which the player can use to freeze all enemies and destroy all enemy projectiles in an area.
With all that said, is this too easy, or is it too hard? I know how to get past, but will someone who has never played the game before? Would they even make it all they way there so that I could find out? I simply do not know.
The official tests
I will be honest, the alpha playtest was kind of a joke on our part, and not in a fun way. We were missing our key feature, the Bride, and didn’t know what our test should be about, so we picked some generic questions. What was your least/most favorite moment?were two questions of the five we had. Along with that, we did not bring any mice to the playtest which meant that all of our testers played with a trackpad, which is not ideal.
Coming in to the beta playtest we knew that the game was hard, we did not give ourselves enough time to test the game with the bride in it, and it just so happened that she did not add too much to the game in the state that she was in anyway. We could and should have tested a lot more internally before the beta testing, but we did not, which lead to a lot of fairly redundant information stating that the game was hard. While the game is supposed to make the player feel threatened and stressed most of the time, they felt so for the wrong reasons during the beta test. The game is not meant to be hard, just feel like it.
For the reasons stated above I can say with confidence that we have squandered our playtesting opportunities and the game has taken an unnecessary hit because of it.
I do blame myself for these mistakes as well, I should have asked for my team’s help and I should have reached out to my fellow students for more feedback.
As the title suggests, my group is not using user stories. The reason for this horrendous act can be summed up in two parts.
First of all, the user stories that I had been given from my fellow designer were lackluster (I have no ill will towards you, it was everyone’s first attempt at user stories). The amount of stories were poor, they did not cover the entire concept document and the parts that were supposedly covered felt like they were missing critical user stories that would have helped when designing.
But Daniel, why did you not just write the missing user stories yourself?
Excellent question myself, the second part of the horrendous act consists of a few factors as to why I did not write them myself.
The first reason was that I had been asked to write the backlog for the project by one of my programmers. Why did I listen to my programmer regarding a design decision?
Good question once again myself, for you see the answer to that question is that in my infinite (read very limited) wisdom, and confusion regarding the scrum sheet assignment, I made the decision to write out all the features in the backlog, just to be on the safe side. A big mistake, as it turns out, because it has lead to a few issues.
The confusion regarding the scrum sheet assignment can best be summed up in four words:
-A clash of frameworks.
As my fellow students might be aware of at this point, and if you have read my last post, is that the project is meant to be worked on using the agile scrum framework, but the way the course is set up makes it lean more towards the waterfall method (if you are curious as to how, please read my last post and if you are still confused after that, leave a comment).
The final and probably most influential reason as to why it turned out like this would be that I was, and still am, a procrastinator. I can complete assignments to save my life, it is not that bad, but it is not exactly helpful in any way, shape or form.
How the Cookie Has Crumbled So Far
While I would not say that our project is a disaster, it is far from it in my opinion, I would be lying if I said that it has been smooth sailing. The worst part about not using user stories is probably that the discussion part of it seeps into other parts of our meetings, side-tracking them and making them unnecessarily long. When there are no clear cut place and time for design discussions, the features that we work on are open for interpretation which causes confusion when two different ideas of the same feature clash.
Supposedly, I am the product owner, or at least I have been told so by my design teacher, Adam Mayes. That is however not what the project managers have been told, according to them the course responsible is the product owner, which does not make any sense to me whatsoever. A product owner is supposed to attend every meeting, a course responsible cannot do that, it is physically impossible for them to attend every groups’ meetings.
This clash of information created confusion but more importantly, I feel like I have less control over the project because of it. Not to mention that when I do not use user stories I cannot direct my group members with set paths, they make their own paths according to their understanding of the feature, which leads me to another annoyance.
Why are there leads in this project?! No scrum environment has leads, there are Product Owners, Scrum masters, and Team Members, no more, no less, so why were we told that we should assign leads to our team members?
Learn from the Past, Focus On the Future
This post got a bit ranty I have to say and I apologize for that, but to round it all up, here are some reflections on my situation.
Firstly, since we do not work 100% according to scrum and user stories, we are missing out on crucial experience, I would say that I am the one who misses out the most.
Just as the header suggests however, I have learned from my mistakes and the next project I work on will be better because of those mistakes, hindsight is 20/20 after all.
Working with scrum as our framework has aided us with scheduling our workload efficiently, for the most part. I cannot speak for everyone, but at least in my group we feel like the milestones set by by our course representative are diminishing the freedom that scrum is supposed to give the team. I can understand that it is easier to judge how far a project has progressed if they pass all the set criterias, but it feels like it makes the project take the form of a waterfall more than anything else. What I considered a core feature in our game, the Bride, had to be pushed farther into development because we felt the need to complete all of the criterias we had for the alpha, which stinged a little bit since we could not test said feature during our alpha playtest.
On a more positive note, the scrum framework has given more structure and has lessened confusion when it comes to planning and execution of plans. Which features gets worked on when and to an extent, how, is mostly clear due to having sprint planning/retrospective/reflection meetings, where confusion gets cleared up through conversation. Keeping track of what is being worked on this day and what has been worked on the previous day is made easy through daily stand-up meetings. So far we have been able to meet face-to-face for the daily stand-up meetings, only missing a planned stand-up once.
Having these meetings regularly has, in my opinion, been improving our team’s synergy, since we are forced to spend time together, we get to know each other better, both personally and professionally. It has helped with understanding what everyone is capable of, but also what they are willing to do. This what scrum is meant to do, encourage conversation, so I would suppose it is doing its job pretty well at this stage.
The beginning of the project however was not exactly the most fruitful weeks of work, considering I was the only one who actually knew what we had to do and how we would do it, I was surprised that the project managers we lead blindly in to this course, but that is all behind us and I have heard that it has been looked at by the department so hopefully the next years students can take more advantage of scrum than we could.
Daniel's Game Design Blog 