Commenting on “Fear is in me” Postmortem – by Krzesimir Pszenny

Link to the original post: https://krzesimirsite.wordpress.com/2018/03/20/fear-is-in-me-postmortem/#respond
 
Krzesimir’s post describes what he learned from his experience as a project manager over the course of the development of his game “Fear is in me”. His post is well structured as it goes over the successes and faults of his project and goes well into detail on what he learned as a project manager, from the mistakes that were made over the course of the project. He not only talks about how he or his […]

Aetherial post mortem

In retrospective I am generally quite happy with the overall development of ‘Aetherial’, of course there are things that could have gone more smoothly or been better, but considering this was our first project of that size I am quite happy with the results.
The final product had a lot of improvements, visually and mechanically, since the beta version of the game. Most of the negative feedback we got was addressed in one of the last sprints and a lot of […]

Commenting on “What improvments brought from playtesting” by Kaijun-Quilin

Original Post: https://kaijunqilin.wordpress.com/2018/03/08/what-improvments-brought-from-playtesting/
 
Kaijun talks about the two different playtest sessions and what his team has found out about their game. I think the post is well structured as he talks about the first set of questions and their results in the beginning. And then the second set of questions in the end. His groups also made the same experience as my group that while feedback is important, it is almost as important for the developers to watch the testers play their […]

Playtesting and Aetherial

Playtesting has had a huge impact on our workflow and design decisions. More specifically once we started getting feedback from people who actually played our game we started to realize what problems it had that we hadn’t thought about before. This might be due to a lack of Quality Assurance within our group, but I think it is also always important to get a different opinion from someone outside the development team.
This is not as true for the second playtesting […]

Commenting on “Simple AI” by Natasha Megan

Link to the original post: https://programminggamesafunworkload.wordpress.com/2018/03/01/simple-ai/
The blog post is about the AI of the game “Friendship down” and describes the original design of the AI and how her group made it work for them. She gives great reasoning on why they had to abandon the original design of the AI and then goes into detail on how she implemented the simplified AI. Even though the AI was “simplified” to fit the scope of the project it is still […]

Learning about Sound Design and Feedback

Besides my role as programmer I am also the lead sound designer at our game project aetherial. I felt comfortable picking that role since I did have some experience in music (I played cello for about 10 years) and because I already had some very minor experience in editing and creating sounds digitally. However learning an entire software is no small task and I am still learning new stuff every day about FL Studio, which is the software I chose […]

Comment on Edin Karakurts blog post #3

Link to the post: https://ouroborosedinblog.wordpress.com/2018/02/22/game-design-blog-3/
The author describes in what way scrum has helped his group in making their game development cycle more efficient. He also touches on the fact that there are aspects of scrum, namely the requirement of filling in the number of hours you expect your task to take, which he doesn’t feel useful as we are still very new to game making and don’t have much experience when it comes to guessing that kind of […]

Comment on The importance of playtesting

Link: https://gotlandblogblog.blogspot.se/2018/02/the-importance-of-playtesting.html?showComment=1519685528991#c3827834413059094685
 
The writer explains well for what reason his team thought the playtest would yield little to no useful results and also how that presumption lead to his team being sloppy when planning the playtest, at least when it comes to building the game in Unity. He then was positively surprised by the feedback he got, in the way that the feedback was actually very useful. The author describes the issues that his team didn’t think about in […]

How scrum impacted our development process.

During our time of developing “Aetherial” we barely have any of our regular lectures. For me this poorly structured week can have negative consequences on my productivity. Scrum has made it easier for us to structure our work week and the daily stand up meetings help us to keep our head in the game and focused on what we have to do. It also greatly improves group communications, as problems with different aspects of the game will surface sooner. This […]

The Design and Code of Aetherial’s Harpoon

As I have mentioned in my previous blog post, we wanted the Harpoon to be more versatile than it was supposed to be in the original concept document. Instead of being the weapon of choice for the player we decided to make it slow firing, but deal a lot of damage. This way the player still wanted to use it in certain situations, but since the harpoon also couldn’t be aimed he would have to use the beam attack to […]

The beam attack in Aetherial

The beam attack actually wasn’t in the original design document of Aetherial, which was made by the group “Team Vampire”. However after looking at the players abilities we came to the conclusion that the player needed another ability, besides the harpoon, to deal with enemies who got behind him. Also we felt that the theme of being a “champion” wasn’t sufficiently represented by a ship that could only fire a harpoon; we wanted the player to feel powerful and in […]