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.

Level Design

The most important task i currently have ongoing is creating the level layouts for our game. Aetherial has an aesthetic goal of making the player feel like a champion, of which I interpret the difficulty of the game will largely convey.  And so I am attempting to find a good balance between making the game difficult while at the same time empowering the player, making them feel like they are really good at the game quickly.

Creating and testing levels is particularly hard because it feels like I’m attempting to complete a puzzle with half of it’s pieces missing. There are planned enemies, obstacles and player abilities that are incomplete or not implemented yet, which makes my level planning feel a bit arbitrary since I can’t actually test the difficulty of something that does not exist. The beta deadline’s soon approach requiring the game’s challenges to be “close enough” implemented amplifies my issue. At the latest play-testing session it became apparent that placing out enemies and obstacles without much thought made the game next to impossible if you didn’t know the layout beforehand.

 

 The level layout used for the play-testing session would completely swarm the player.

I am personally not very fond of tutorials, it’s fine if they exist in a game but they should be optional. I want our game to ease the players into it, allowing them plenty of time to learn how the game works before ramping up the difficulty. The only thing that would feel tutorial like would be a simple “how to play” keyboard layout instructions that could be shown in the menu before the game starts.

An interesting (and slightly frustrating) part of designing the levels is that their length are limited by the length of the background. Though the background will divided up into three segment to act as a kind of checkpoint, there is a fairly limited amount of space i can work with. To help me achieve my overall goal, i have given each segment a sub-goal for the design. The first segment will introduce the player to the game and its enemies, and will be of easy to moderate difficulty. The second segment will throw a lot more enemies to try and swarm the player, putting what they learned in the first segment to the test. And the last segment will mainly contain the boss entity (although I am unsure of anything beyond that since the boss isn’t implemented yet at this point in time).

 

 

 

Scrum in Archon

Working with scrum has been useful to plan out workflow but difficult because the team fails at the execution. While we were all given some prior knowledge of what scrum entails, nobody in the group has had any  practical experience with it before. The team has done a great job of planning and distributing work for each sprint and everyone (almost always) actively attends the daily stand-up meetings. The issues come with gauging work hours needed compared to actual work hours used, leading to work being incomplete after each sprint.

Scrum has been useful when it comes to keeping our work planned and organized, which has seen a drastic improvement compared to our previous project. Thanks to scrum we all have a much clearer picture of what need to be done and when.

A snippet of the sprint reviews, where as can be seen the work is clearly divided and planned well, but mostly not completed.

As i mentioned, the biggest issue we have in the team is work not being completed on time in accordance with the sprint planning. To rectify this we have taken steps from the course literature book “Agile game development with Scrum” by Clinton Keith. The first is to push work from the previous sprint into the next one based on a priority of importance. This of course means that coming work needs to be pushed to make room for the previous week’s leftovers. This has lead to us having to cut down on planned features by re-evaluating what is important and crucial to the core of the game. And lastly, if we decide that there are not enough things we can cut to make time, the last resort is working overtime. As this overtime usually means working on the weekend we decided to make it 100% optional to not put any unnecessary stress on any of our team members.

The upside is that we have seen a steady increase of completed items each subsequent sprint review. Learning from the mistakes of the previous sprint and becoming better at estimating the required hours to complete tasks. So although the team has a few issues following scrum properly, I think it has been a positive benefit to the project overall.