blog comment Michael Degirmen

Here is a third comment, as i can’t find any blog posts from my fellow designer in your team.
Now, I’m not sure what i could add here that hasn’t been said already. Your post is very well written and fleshed out, a fitting summary of you and your teams struggles during the course of the project.
There is a lot to take away and learn from in your post, understanding how you and your team dealt with what could be considered almost worst case scenarios such as team members leaving is really valuable. Suggestions directed towards readers is also really helpful. I really like that you are considering keeping a visual track of future project as this is something i agree with and consider greatly myself. communication is key and pictures speak a thousand words, with issues of communication in my own team I really think communicating with pictures and also keeping documentation with them can help any project immensely.

Anyways, great post and good luck on future projects
-David Åström

blog comment tomas savela

Gathering relevant feedback is tough for sure, especially with how unpredictable the testers can be. I think you put good focus on this complemented by your tips on how to improve the quality of the feedback. It is a shame that your post has bad sentence structure (some sentences are way to long) coupled with a few spelling errors, as it made the post confusing to read at some points. Also the pictures of spreadsheets are impossible to make out and you never explain what they are supposed to portray and never refer to them in the text. I would recommend at least putting descriptions under the pictures next time as I don’t think they add anything to you post as they are right now. Other than that I do think the post is valuable, but it could use some spellchecking to make this more clear.

Blog comment hampus serrestam

Alright let me start of by saying that this was a pretty good read, it is very clear that this is about making a tutorial. And a decent explanation of how (although i would like some more details personally, and some descriptions for the pictures). Why is also very clear with the explanation of how tester feedback prompted the making of the tutorial. Is the post valuable overall? sure! since tutorials tend to be a part of most games (I loathe them personally) it’s interesting to see how you approach to avoid making yours the least painful to go through as possible. The post could be improved in a few ways, fixing a few spelling errors could be one, another could be to give the non meme pictures descriptions so that someone like me that hasn’t seen your game before know what i am looking at (not that the ones you had in this post were necessarily unclear but might be good to include in the future). Other than that good post :^)

Blog comment maya siden

Alright this was a pretty good post, you make it clear on what the post is about (boss design). The explanation on how you planned and carried out your design process was great. And lastly you give a clear case for why the design of the boss is so important with a challenge for the player in mind and all that. So overall it’s a great and interesting read. However, I can’t help but wonder if you might have missed the instructions for this week’s post as it was supposed to cover how scrum has affected your development. Aside from being about an incorrect subject, it is a valuable post that cover practices that I, as a fellow designer might borrow some inspiration from in my coming design tasks. Can the post be improved? Fleshing out the part with the arbitrary number equations to give an idea for what they actually meant to your design would be great, also a picture to help visualize how you carried out your design. Writing about the correct subject could also be considered an improvement 😉 but other than that, this is the best post I’ve read so far. 😀

Blog comment Tim Wergeni Johansson

Is it clear what is done? Yes, you have clearly conveyed that you had a play-testing session where your gathered feedback. Is it clear how? To a lesser degree yes, the circumstances regarding how the play-testing was carried out is explained. Is it clear why? Yes, to gather feedback but perhaps not motivated very well, you could go into more detail on this. Is the post valuable? in my opinion not exactly, but that might just be because i value motivating and explaining more on the why part higher than is necessary. Can the post be improved? definitely, there are spelling errors, odd sentence structure and a word used that makes absolutely no sense in the context. On the other hand i do think your post contains everything necessary to cover the three pointers (what how why) well. But since the above mentioned errors contribute to conveying them clearly it can be really hard to tell. Do some spellchecking and try reading your own post out aloud before posting next time and you should be good 🙂
Also don’t forget to tag your post with 5SD064.

Blog comment Simon Ågren

What: I get that you are trying to put focus on the user stories.
How: you make it clear that you broke down the user stories onto a page of ideas and used them to plan your sprints.
Why: you wrote that the user stories made it for your team to understand the coming tasks but It’s hard for me to see how as you don’t go into any further details to motivate how it has actually been useful.
The post is valuable in the sense that it gives a bit of background to how pre-production looked in your team.
There are things that can be improved, grammar and sentence structure to begin with; there are some errors in the post that i found a bit distracting and the structure made some parts confusing and made me have to re-read them to understand what you were trying to say.
perhaps make a more clear topic for the next post? even though you had an emphasis on user stories the post felt a bit lackluster by not giving much in terms of details.
Also that fuzzy looking picture could be improved 😛

Postmortem: Aetherial Archon

It’s been a rough road and a hectic ten weeks (especially the last one) but team Archon managed to pull together and complete our game. Am i happy with how the game turned out? As a whole I don’t dislike how the game turned out, I am however dissatisfied with my own lack of contribution. I have spent the most of the ten weeks trying to figure out what my role as lead designer meant to me and the team. And meanwhile there were so many things that went wrong or not to plan that makes pointing out the positives difficult. I don’t think our game turned out even remotely close to how anyone in the team had envisioned, especially not me. However this may have worked in our favor as I do believe our game turned out to be the most unique among the five Aetherial games made.

The boss encounter, scrambled together during the last two days before the deadline

Proper planning is crucial, our planning and estimation of work hours failed constantly, which lead to a gigantic crunch during the last week before the deadline during which it felt like half of the game was made. Despite this I think our game turned out alright, a bugg filled scrambled together mess of alright. Most of the people who played the finished game seemed to enjoy it, especially those who managed to win.

Our Aetherial set itself apart from the other Aetherial games by being the only one where you could decide the pace of the game yourself. Players could roam free within the bounds of the three stages we had, using the same strategy as the first Super Mario game; just go to the right. With three different ways of defeating enemies, the regular harpoon, the target seeking missiles and the teleport with an explosion radius, there was some variety to how players beat our game. Some took it slow aiming from afar with the harpoon, some did a speed-run past everything with the teleport, but most realized that spamming the missiles were the most efficient and easiest way to win. The game might seem hard at first glance or play-trough, but really it’s just a trick of overwhelming the players with enemies, especially the boss that could throw 20 things at once at the player (seen above) but all problems go away once the players learned to use the very overpowered missiles that clears the screen automatically.

Defeating the boss rewards the player with a giant happy nuke that blows up the boss and the whole game too as it exits to the menu immediately.

It was hard for me to find a way to document all the work we did properly, mostly because the actual work being carried out would change between planning and execution. I have mentioned in an earlier post that our programmers would discover that a planned was too difficult for them to carry out and change it into something else, as was the case with the missiles that our game features for example. These spontaneous changes were frustrating for me to keep track of as they didn’t get logged into the backlog properly. I have learned for future projects to put a much bigger emphasis on documentation to keep track of everything that gets done. If nothing else, it will be easier to learn from mistakes if they are documented with details.

Team Archon has now formally disbanded, which i feel is a bit of a shame as it felt like we have grown a lot as a group over the months we’ve worked together and worked more and more optimally with one another. Regardless, it was a fun learning from failure experience.

Feedback Implementation

So I made a previous post about how i approached gathering feedback from the play-testing sessions, this time i will write about how that feedback influenced our game.

Now the first thing I need to make clear is that the feedback has barely impacted anything major in our game that already exists and I’ll try to explain why. The biggest reason is usually because of a shift of focus on what is worked on. For example; from the latest play-testing session we received a lot of feedback on the teleport ability that our ship has, it was clear from this that the teleport needed a lot more polish. But what ended up happening instead was that a new ability was added to the ship instead, not to replace, but i suppose you could say ‘hide’ the flaws of the teleport. This new ability are missiles, unfortunately they were implemented shortly after the second play-testing session took place.

An early iteration of the missiles hanging out around the ship

Now I do think the missiles are a good addition to our game. However, with only a week left of game polish left at the time I’m writing this, the missiles won’t get to receive any feedback the same way the teleportation. Also neither of the abilities will get enough deserved time to be polished.

Another common feedback answer was on the game’s difficulty, almost all testers agreed that the game was way too hard. This was mostly due to the fact that I had designed the layout of our testing level to swarm the testers with enemies. What ended up happening was not redesigning the map or spawn rate of the enemies, but ramping up the power level of the player ship. The new missiles mostly contribute to this, but also small changes like allowing the primary fire harpoon of the ship to pierce enemies, making the previously weak harpoon to feel infinitely more powerful if you line up the shots just right.

some of the feedback we received

So for the most part the feedback has been useful for tweaking numbers within our game, such as the movement for the player ship constantly changing and taking the comments from the feedback on it to find that sweet spot.

Första blogginlägget

Det här är ditt allra första inlägg. Klicka på Redigera-länken om du vill ändra eller ta bort det eller skriv ett nytt inlägg. Om du vill kan du använda det här inlägget till att berätta för dina läsare om varför du startade din blogg och vad du tänker göra med den. Om du behöver hjälp kan du fråga de vänliga personerna på våra supportforum.