Link to Krzesimir’s post mortem: https://krzesimirsite.wordpress.com/2018/03/20/fear-is-in-me-postmortem/
My comment:
Hi, Krzesimir!
Happy to be giving some feedback to you 🙂
Your post is very clear and has good structure as well as English, and with everything combined – makes the text easy to follow and understand.
You describe clearly the positive aspects as well as negative aspects of the project, in addition lessons learned. Reading your post mortem gives an impression that in overall, you were happy with both your group and the outcome of the project. I sadly haven’t tested your game even once, but wish I did!
It seems that you have been a great manager in your team – bringing up topics that in a long run may have “poisoned” the team if they weren’t. I’m glad to hear that your team appreciated this approach you had.
I do agree with the negatives that you present – especially with us managers having zero training in Scrum before and even (more or less) during this project. This makes us look weak to our co-workers, since we were not able to fully perform Agile/Scrum with the team throughout the whole project.
I feel like I have a learned a thing or two by reading this post of yours. I, too, will try and establish more control and structure for the upcoming projects that the future teams will hopefully benefit from. I believe it is important, and something we have learned now, but that we unfortunately had no clue of before initiating the shoot em up project (as no one really told us how to begin the project or things that are important to know etc. or maybe that’s just me) (for example the PID, kick off meetings, sprint velocity charts etc. Speaking of… sprint velocity charts were only described by the teacher solely to our second-year scrum masters…).
Good luck with your future projects!
I see you around,
During this Shoot ‘Em up project we, team Kraken, have accomplished a lot more than I had anticipated in the beginning. I had, for example, no idea how skilled the artists or the programmers were. In the end, I am happy that I ended up with the people I did. Even though our project has had its ups and downs. Especially after hearing how tough other teams had it with some of their own team members.
The game
The result of the project, our game, includes a player avatar with two different shooting mechanics, two enemies, a unique power up, whale boss appearances with some armor tearing off going on and the final boss fight (which is less polished than the other features).
I am very pleased and content with the game as a whole. The group has worked really hard throughout most of the project, and rarely complained about things, or stand-ups. Which is good! I as the manager didn’t have to twist my head around, figuring out how to make everyone’s wishes come true (since we were working in an agile way, every individual’s opinion matters).
Main game features
What I have learned
This being the first project, and me being a manager for the first time, made me learn an abundance of new things. I feel like I gained experience points which will help me in the upcoming projects.
Few things I learned:
oMore QA
I didn’t realize how important it is to assign a QA responsible person until it was few weeks left of the project. This goes especially for art assets. No QA resulted in disappointment in a few cases because there were things lacking in those assets and could’ve been avoided if another person would give feedback. (For example – this color doesn’t fit our background, it should be blue. Then the asset’s owner can change it quickly and the problem is solved)
oMore Testing
Our game has a few difficult mechanics that are easy for us developers to understand, but not to the outsiders who play the game for the first time. This was especially apparent during the final playtesting session. It made me realize that we should have made more room for playtesting the game and let others playtest it to use the feedback and improve the gameplay. It was mostly the coders who did all the playtesting. Lesson learned.
During the last playtesting session, considering the feedback, it was visible what the majority of testers had issues with – the power up bugs and the final boss battle. For the final boss battle, you were supposed to shoot the harpoon at the whale’s mouth/tongue, which was not clear at all. We taught them in the beginning to tear armor plates off, and that is what they aimed for during the boss battle. This could’ve been avoided if we’d let someone from outside playtest the boss battle. Regarding the power up – when used during a checkpoint scene – it would bug the entire game – the background would be grey, the obstacles (islands) would be invisible and such things. In my opinion, we should not have aimed for this unique power up – which spawns a storm cloud and makes the enemies loose track of you. It is what it is.
A student enjoying our game
oEXP gained in management and use of scrum/agile
With no previous experience or Minor lectures in Scrum, I tried my best to use this framework. It wasn’t too complicated to comprehend, especially incorporating the agile mindset by having the Agile manifesto in mind, at all times.
And like mentioned earlier, I was a manager for the first time, which in itself resulted in a lot of new knowledge about group dynamic, leadership etc.
oFor next time – establish structure, rules (group contract, PID) in the beginning
I’ve already begun gathering information and lessons learned that I will use for the upcoming projects. A group contract and a PID (Project initiation document) will be the starting points. Since these documents are created by the whole team, the team members will have the power to decide and come up with rules that everyone will have to follow (more like a guideline than something set in stone – have to continue with agile mindset). I believe this will help with motivation and excitement to start working but will also serve us a helping hand in times of conflict.
Some positive things
The team itself is a positive thing. Most of the members took initiative and worked harder than necessary, which I am proud of, of course.
There were rarely any issues with code etc. to an extent that it had to be consulted with the teachers.
Meetings and stand-ups, I am especially happy about since all of the meetings had a positive effect on the group and the project and is something I will continue doing in the same pace. My team appreciated them a lot, and that I created weekly schedules that included time and place for: sprint reviews and plannings, daily stand-ups, a design meeting or two, in addition some other information related to game design course (like lectures, playtesting session…)
Some negative things
However, no team is perfect. I had issues with one team member in terms of communication throughout the whole project, which made the team irritated and confused. There were tasks done by Kim (pretend name) that were never discussed by the team and that weren’t supposed to be included in the game. The communication was biggest issue. I could rarely reach out to Kim, let alone get a response. In the end, it didn’t feel like Kim was fully a part of the team. I’m not saying that Kim was a total roadblock, Kim did do a lot of work and contributed to the team, nonetheless.
Another negative thing (related to communication once again), was that not everyone was active on our Slack channel. For most of the time it felt like a monolog, or dialog. This made me frustrated as a manager because I never knew who took part of the information posted there and who didn’t.
This was partially solved during a sprint retrospective which we started having after our scrum master, Raoul, introduced us to it. During the retrospective, the manager asks the team three questions: “What should we start doing?” “What should we stop doing?” and “What should we continue doing?”.
When the team was asked “What should we start doing”, a question regarding lack of activity on slack was raised. And a suggestion from the second-year scrum master came that we could incorporate a reaction system. As soon as you see a post, you react with an emote of your will.
This idea was awesome and helped tremendously. It didn’t feel like a monolog/dialog anymore.
Link to Emma’s post: https://graphiccollision.wordpress.com/2018/03/11/the-wonders-of-playtesting/
My comment:
Hi!
You clearly describe the main aspects of the game that testers gave you feedback on (power up and portal to the next level). I like that you focus on two “bigger” aspects and elaborate their “evolution”, rather than describing a bunch of feedback. I believe most of us get a lot of feedback that touch a lot of different features – but there is always something that the majority of testers gets stuck on or misunderstand. So good job on listening to your testers and focusing on two of the aspects in this blog!
It was interesting how the “crystal portal” was seen differently between your team and the testers. The solution was really smart – with the portal. I myself play tested your game during the second session and I really liked the portal. I bet it was difficult to leave the crystal-look behind since you all really liked it…
It’s always sad to read about groups that don’t get along very well or have issues communicating. I, as a manager, automatically consider this a lot when reading other posts (because it’s managers’ job to more or less create good communication, even though many don’t realize that it goes both ways) and try to think why so many teams have issues. It seems like there is no perfect team, but some have it better than the others. I’m glad that playtesting gave you hope for you and your game anyway.
The text flow is very smooth and is easy to follow. You write in a way that makes me, the reader, want to continue reading. Which is great! Interesting post overall.
It was however a little confusing which paragraph belonged to which playtest. It felt like a mixture of both, but in the future, you might want to separate them, to not confuse the reader too much.
Hi!
it’s blog time again! This time subject being playtesting and its effect on our game development.
Both the first and second playtesting session has been helpful for us, team Kraken, in order to improve our game, Aetherial. When observing the testers try out our game, we noticed many things regarding the gameplay and design that have not been obvious to us earlier. I, as manager, added extra time to our meetings in order to go through all the data that we’ve collected during the playtesting, and then prioritize the feedback that we could work on. Due to time constraints, obviously, we can’t improve/change every aspect of our game that testers have critiqued, which is why we had to prioritize the most important and constructive ones.
Playtesting session 1
A lot of students playtested our game on our two-computer-set-ups, but it became clear very fast what we had to work on and put our time into. Almost every single tester got stuck on the same scene, which meant that we, who observed, had to more or less baby sit them and get them out of the confusing situations by telling them which keys to use and such. Our game doesn’t only include shooting at enemies, we also have boss appearances (not to be confused with final boss battle), and during that appearance the player has to shoot (only) the harpoon, being second weapon, at the whale’s back and tear one of its armor plates off. The least obvious aspect to the testers was to use the harpoon, but even more confusing (partially our fault, but hey, it was Alpha stage) to use “F” button which fires the harpoon at 45 degree angle downwards.
This is one of many feedbacks that we thought was vital for the gameplay.
Compared to where we are now, we are currently including a tutorial-like dialog between crew members and the player ship’s captain, to teach the player what to use and when, in a subtle and engaging way. If the player gets stuck and dedicates most of his/her energy to figure out something that isn’t obvious, he/she will slowly get frustrated and won’t be able to progress smoothly, or even enjoy the game.
Guidlines for obervations used during both sessions
Playtesting session 2
Since the first session, we have included a second enemy and a second checkpoint + more polished power-up.
During this playtesting session, we quickly noticed the reoccurring bugs and what features lacked feedback to the player in our level. The feedback in terms of sound and animations was therefore prioritized and we are currently working on that as well. The feature that lacked most feedback is the power-up. The player doesn’t seem to know that what he/she obtained is power up, and upon using it, doesn’t seem to know that the power up is in effect. We are confident that with our feedback improvements via sound and clear animations, in addition with tutorial, this won’t be a problem anymore.
Both playtesting sessions have helped us tremendously. It is important that people from outside test your game occasionally and give feedback.
This feedback is what helps us know what the game is lacking. It is deeply appreciated.
Link to Ander’s blog post with my comment: https://andersdotgames.wordpress.com/2018/02/28/1-love-to-all-party-members/
My comment:
Hi, Anders,
Interesting blog post you have here. I do not fully recognize all of your references; however, your main topic is clear and easy to follow.
Now, you say that you encouraged informality early during the project, which I personally think is important as well. As you say, everyone wants to feel comfortable around each other, this is true because it will motivate the team members to come to meetings and collaborate. We do have some informality in my team, although I personally, keep most of the meetings formal kind of automatically, even though I’m a person who’d like to joke around more. However, we producers, have the responsibility to manage the team and project and with that comes formal needs. Someone has to be the serious person in the team, right?
From your writing, it seems like you and your group get along well, but at the same time, some of your sentences are contradictive – like the urge to throw a processor at someone’s head? I do understand your point though. (Hopefully no one got hurt so far)
It also seems that you have incorporated an agile value – individuals and interactions over processes and tools (or something down that road), when you say that every person needs to take a break to relax, or that it’s not a big deal if the product backlog is unattended for some time. Since we aren’t working in a professional environment, we are bosses of our own, so we choose how we work (to some extent) and what is best for our team. Admirable by the way.
I’m glad for your sake, that your group is motivated and complete their tasks. It would have been interesting to hear more about your team members’ perspective on the project as well… Do they feel similarly to how you feel about the project?
Hello and welcome to another one of my blog posts! Today I will write about an art task once more.
This week I have taken some art assets to work on. One of them is the main menu of our game. To be more precise I have been designing the game’s title – Aetherial, and also choosing font and color for main menu words (like “Start the hunt”, “Exit”, etc. – See picture 1)
I have always liked working with letters, or names and titles to be more exact. Twisting them for their purpose and meaning. (For example band or song names)
So I thought I’d be fun and exciting to once more create interesting letters. This time for our game title. I did have to contain myself from not overdoing it and not letting my imagination go too wild, so the player can actually easily read the title…. The QA for this task, one of the artists, helped me with just that.
Apart from the title and menu letters, the whole set up of the menu (see picture 1) with the whale boss in the background, was my idea. I showed a prototype of the idea via PowerPoint to my team members and they seemed to like it. The whale will float in from the right side of the screen, and when it stops, the menu letters will appear. The harpoon is there, because, well, (spoiler) the player is meant to use the harpoon to attack and tear off whale’s armor plates.
Picture 1
To go back to the title, which is the main struggle of the task…
For every letter, I made a new layer, so I could transform each one of them the way I wanted and move them around separately. Starting with letter “A”, I wasn’t sure what I was going to do with it or how it was going to look, so I kind of followed my hand, making smooth curves… Which resulted in the letter you see in picture 1. The ‘A’ became “floaty” which suits the environment, where everything is floating/flying. The color blue has a reason of course, it is the color nuance of one of the floating islands made by one of the artists.
Letter E. My favorite. I wanted to include something from the gameplay, and I noticed that one of the enemies, the manta-angler creature’s head is kind of shaped like an E, and that’s the story of how it became the letter E. The coloring is almost identical to the creature’s original colors. Some of the details, like teeth, are missing, as it had to look like the letter ‘e’, so details had to be excluded.
T… This is one of the letters that had to change. I made it look more like a T in the final version, and less edgy (see picture 2)… The yellow –blue color combination also suits the environment and is alike the player avatar’s colors which are light blue and yellow-orange nuance.
H… It didn’t turn out as cool as I wanted it to be. Like with A, I just followed the flow and hoped for the best. In the end, at least it looks like an H, which is easy to read. As for the color, it is of another floating island’s color nuance, which fits with the blue color of letter A and partially T.
R. Another letter that had to change. The first version was a panick-faced R with one of its feet inside E’s mouth… I knew it would be too much, so I didn’t mind changing its design to what it is now. Its design is nothing special, but sometimes a simple and readable design is needed.
I… I had to change letter “I” as well as R and T. Initially, it was sitting on R’s “face” and looked like a simple ‘I’ with a mermaid tail. ‘I’ is one of the letters that is tough to modify and design, so I am quite happy with how it turned out, with its cute head and pointy bottom, looking almost like an island, floating.
L…L wasn’t very easy to design either. It does look pregnant, but I didn’t want it to look like a plain L, so I added some curves here and there. The bottom line resembles a slug. One of our enemies is a sky slug, so it makes me at least think about the sky slug.
Picture 2
Last part, the background “cloud” behind the title… a tricky part that I had to redraw a few times from QA point of view. It is hard to know what fits with the title, so to add a cloudy look was initially a thought.
I am glad that one of the artists is QA’ing my tasks for another point of view, and since he is studying graphics in his minor, his input is important and knowledgeable.
Note that picture 1 is a prototype. The placing of Islands and other attributes might be different in the final version of the menu. My task is solely to create the Title and decide upon a font and color for Menu words.
Link to Linda’s blog post: https://lindakhamphoukeo.wordpress.com/2018/02/22/scrum-for-making-boaty/
My comment:
Hi, Linda
You have explained how Scrum works and how you guys are working with it (sprint reviews and planning meetings) in a short, but quite effective way, although I would’ve liked to hear more about what you guys are exactly doing during those meetings. Not all teams do the retrospective during sprint reviews for example. My team’s dear scrum master (second year manager) has taught me all about it, and it helps the team members to reflect and come up with suggestions on what to improve/start doing as a team, as one example. Perhaps your team should try it out, if you haven’t already?
I also like that you are correlating working hours with a professional environment. It’s not easy estimating hours when it comes to art (especially animations), but it is a good way to lean more about your working pace for the future, when working in a company, like you mentioned.
I would’ve been interested to hear more about for example those unnecessary discussions you had, and more elaboration on how Scrum has helped you within your team (from team’s perspective. You wrote mostly from your personal perspective, which of course is necessary to write about as well). Was there anything else that didn’t work out in your group because of scrum (roles, daily stand-ups etc.)?
Link to Lina’s post: https://linafemling.wordpress.com/2018/02/15/alpha-presentation/
My comment:
“Hi, Lina!
It is awesome that you have shared your true thoughts and feelings regarding the presentation. I personally could relate to every word, from the fear of failing to loving make PowerPoints that convey meaning through pictures and visual effects.
You have described your inner fight very clear and I’m glad that you weren’t presenting alone! It is really not easy to present something in front of such a big crowd (or at least I think 50 people is a big crowd), but you have managed to grab the bull’s horns and steer it (great metaphor by the way!).
It is definitely something that all of us will improve over time, as we present more and more throughout the years, as our confidence grows.
I agree that we, producers, have to automatically present everything that has to do with the porject. When I asked my group if anyone wanted to join me, everyone shook their heads. I did say I was okay with presenting everything, but even so, I expected at least someone to help me out.
It is motivating when you say that the presentation went well, even though you were nervous about it. I feel like I am not alone, feeling like this to be on stage and presenting. If most of us can do it, then I can do it too.
One thing you could have written more about is the game itself, and how you used the game images for the PowerPoint.
Today I will be sharing my experiences with Scrum as a producer (Scrum master??) for team Kraken.
Don’t mind the title, just follow the tune
Sprints and tasks
For this project, the sprint length was pre-determined to be 1 week long (although 2-4 week long sprints are most effective), which I am not very content with. However looking from another perspective, it makes fellow team members work pretty much every day. Starting with small steps is good for them, rather than starting with 2 week sprints.
One reason why I would prefer longer sprints is to give members more time to complete a bigger user story that requires more time and attention (for ex. A user story covering an enemy. With all animations, one week is barely enough)
In the beginning, not all tasks were delivered at the end of a sprint, even though our second year scrum master and I explained clearly that the tasks group members choose, have to be done by the sprint reviews. If any issues occur, where someone feels that they can’t finish all their tasks, they are supposed to be brought up during the daily stand-ups. However, that part was taken for granted by some of the members.
Task overload meant we had to move leftovers to the next sprint, or even remove an asset or two forever (for ex. a dying animation for an enemy).
At the same time, there is no real “punishment system” if someone doesn’t complete all of their tasks, whereas in a professional environment, that wouldn’t be accepted for long and the employee would risk losing his job. The employee also gets a salary for his work – here in university not everyone is motivated to work, show up for meetings, take initiative etc.
I am pretty lucky with my team. Almost everyone comes to all of the meetings, are there when needed, take initiative and are motivated to do their job. That is SUPER important for a project to succeed, and is a way to gain full benefit from agile approaches, such as Scrum.
(I don’t want to mention individual/group-specific “bad examples” because of respect to my team)
Daily stand-ups
The daily stand-ups have been going really well compared to my initial expectations. I’ve even had them at 8.45 for a week and people still showed up! I don’t have them at 8.45 anymore, though. That was because of 9 am lectures.
Thanks to the stand-ups, everyone knows each other’s progress in terms of task completion. If anyone needs help with a task, she/he can ask for aid at the daily stand-up from a fellow team member. These 10-15 min meetings also provide increased communication between the team members. I think it is important to meet each other physically often. Every individual has their own preference in communication style, whether it is over a digital chat, over a phone call or meeting physically, our group has a lot of both physical and digital (over chat), which creates a good balance, in my opinion.
The only issue I experience regarding stand-ups is the “same place and time every day” aspect of it. It’d be really nice to actually have an office/work space dedicated to the team – which would make the “same place” of it all easier and more motivational for the team to show up. Practicing daily stand-ups here at campus entails room-booking, which is shared with all campus students, which means that chances of being able to book same room every sprint are minimal, speaking from own experience.
I’m not even going into detail regarding “same time” stand-ups..
To make daily stand-ups more effective, and properly practiced, it is recommended to have a Team Board (Kanban board or similar, made out of for ex. post its) present as well. So when a member says he/she is done with a task, that task is moved to “done” section. This is impractical to execute for our project due to lack of a stable work space.
Visualization improves communication, and a team board is one of the approaches, which makes it easier to keep track of team’s progress. Right now, this is only visible in “sprint planning” sections in team’s Scrum document.
Working Agile
Even though I’m mentioning lots of negative factors, I do enjoy working Agile, especially when my team members work agile as well and understand importance of it all. It enables high level planning rather than low level planning, which gives space for change. I do my best to listen to me members’ opinions and suggestions and also accept change. As an example, I create high level weekly schedules for my team. If lead designer wants to add an extra design meeting then I add it to the schedule. I don’t neglect it and force everyone to follow the pre-made plan engraved in stone. That is the opposite of agile philosophy.
It feels like there is so much more I’d like to include in this post, but I have a DSDM framework (not Scrum) exam tomorrow to study for. Bye!
Today I will write about a task from previous week, (because it is more interesting to write about art assets than alpha presentation preparation that I did this week)
This asset has to do with the health and aether bar (which I wrote about in my first blog post) in a way that this is a power up indication animation! And the animation happens beside the bars. This animation will activate when you, as the player, pick up the power up after destroying a crystal from the Whale boss’s back. This power up will spawn a dark cloud mob/storm and make you invisible to the enemies when activated.
The process of me animating was the easiest part – making the sprite sheet (which I probably did in a wrong way) is another story.
So, the progress and design… Well, during the sprint planning we were discussing how the power up indication should be like, and it wasn’t really hard to come up with a design, since we knew that the power up itself will spawn a storm more or less. So why not spawn a storm in the ship icon’s (beside the health and aether bar) background? It had to be obvious for the player that he picked up a power up that is ready to be used at his/her own will.
Sprite Sheet 1
(Sprite sheet 1) I started animating, frame by frame, starting with two clouds. I didn’t draw a new cloud for every frame (that’s just hardcore and unnecessary workload), instead, I dragged existing clouds a few millimeters to the right with every frame. I came to a point where I the existing clouds started disappearing, so I had to draw new ones. After a few frames with the new clouds, I started positioning them like the old clouds, for a simple reason – to get a “loopable” animation. The fact that the animation loops, saved a lot of work.
After the clouds where done, I added rain. I drew 3 or 4 different rain scenarios and simply copy pasted (reused) those randomly for more frames. Instead of drawing new rain scenario for every frame. The rain might catch the player’s attention more as it is moving quite fast.
It might not be as visible in the sprite sheet, but I also added yellow flashing contours around the ship that spawns and disappears, spawns and disappears. For extra extra attention and for the player to know that what he/she picked up is interactable.
The yellow flashing is caused by a lighting strike, which I added to be in the beginning of the animation. (Sprite sheet 2) The reason the sprites are separate is because the lightning happens once – so it is not loopable. For coding purpose.
Sprite sheet 2
I am overall content with the outcome. I have animated before, so I know the struggles and that it takes really long time to animate only a few seconds. Thus, for time limit reasons I didn’t spend too much time making detailed or very pretty animation, even though I would have gladly done that if I had like 2 full weeks without minor being in the way, and not 3-4 hours which I had planned for this task.
What took most time (~3 hours) with this task was positioning each sprite with the same distance from one another (which I tried doing in three different ways). I really tried my best, despite not having learned how to do that… However, it turned out to be wrong anyway. Frustrated 3 hours went to waste. In the end, I let one of the artists fix this, which he did in less than half an hour. At least I tried. But I felt like a GTA character after dying with “Wasted” screen going on, the moment lead code told me that the sprites ain’t good enough during a meeting.
Juste's Blog 