Posts

Comment #6: Clement

-
Link to the post Hej Clement! You provided a very informative and structured blog post describing the game you created, design decisions behind it and obstacles you came across. I also really like that you provided an introduction describing the game concept itself and a small conclusion. This creates a great framework for the reader to follow. I especially enjoyed that you showed a table with the initial Aesthetics described in the concept, to show which of these goals you achieved and where you had difficulties translating the given aesthetics into game mechanics. As you learn a lot from failures during the game process, it is very helpful that you provided information about where things went wrong as well as possible solutions to those problems. Besides that, you even incorporate lots of things we learned during our lectures, like for example the principle of rubber banding. However, I feel like your blog post seems rather negative and points out way more things that went wro
Post a Comment
Read more

Beelonging: A Postmortem

-
Image
This post has been updated 21/05/2018 So we just finished our first Game called “Beelonging” (If you want, you can play it here ). 10 Weeks ago we picked a concept for a shoot em up game about a bee swarm saving its hive from the evil bear, fighting various insect enemies and now we are finally done making this vision come true and additionally changing a few design decisions and releasing our game. Beelonging now consist of five different levels with various enemies, a power up, the ability to pick up other bees to join your swarm,  a boss fight and even unlockable costumes to choose from. While creating the game there a lot of things that went really well. We were only confronted with a few obstacles but otherwise had a smooth experience designing our Game. One of the main reasons for that is our team spirit. After choosing our concept, we were all really passionate about the product and had about the same vision in mind of how the end product is g
1 comment
Read more

Comment #5: Erik

-
Link to the Comment Hej Erik! I think you provided a very structured and informative blog post, that describes how you conducted playtesting in your own group, not only during the playtesting workshops, but also within your group and online on a constant basis. (By the way, how the heck did you get the Unity web player working? I completely failed when attempting that.) I additionally like the introduction and the conclusion you give to your post, as it creates a great framework for the reader to follow. Although in general enumerations are a good thing for the reader to follow, I had quite hard times especially in the introduction following all of your key points that were not just used for lists, but also occasionally within sentences as well. As you focus on the results of the last playtesting workshop, I really like the insight you give on your problem of finding a way to restrict your abilities and which decisions you took to find out about the players response on both vers
Post a Comment
Read more

Being prepared

-
Image
As this is my second blog post on the topic of play testing, I will rather focus on preparing for playtesting, than the value of playtesting itself. If you want to read about that instead, check out this post. When working on a game it is very important to be prepared for things as Alpha and Beta presentations, but also for events like playtesting sessions. This was unfortunately not the case when we had our first playtesting at university. Motivated, proud and confident about our product we went to show off our game and get opinions, but we were not really prepared for the playtesting session itself. We just thought bringing the game on a laptop would be enough, but we were proven wrong. As we only finished some of the assets, mechanics and game elements the day before, we did not really have the time to test the game ourselves. This seems a bit redundant, as the playtesting session is there for finding those issues, but there were some crucial problems that we did not fix bef
Post a Comment
Read more

Comment #4: Oscar

-
Link to the post Hej Oscar! I like that you provided a quite structured blog post describing not only the process of getting feedback and taking valuable information from it, but also how you personally felt about it and the obstacles you came across. With your introduction and conclusion you also create a good framework for your blog post, that the reader can easily follow. I also like, that your blog post takes on the issue on a design level, rather than going into details of bugs or code snippets that were or were not working. However, I wished you went a bit more into detail naming how you are planning to improve the game based on the feedback and what design decisions you eventually made. Additionally, I missed a picture or something visual that he reader could hold on to. This could have been a picture of someone testing your game, a screenshot of the improvements you made or an image showing the feedback or the notes you took resulting from it. Besides that, I enjoyed rea
Post a Comment
Read more

More Bees, Less Bugs

-
Image
Even though we are creating a game about bees, wasps and beetles, I only want bugs to appear on screen and not in my code. Unfortunately, fixing bugs is a major part of your work as a programmer and can get extremely frustrating when you can not seem to find out what is wrong. Especially after the last playtesting session there were a lot of things that needed to be fixed. For some reason, our main character or his companions occasionally decided to leave the screen, the pause menu did not work, dead things still managed to kill you, bees were hiding behind each other, random pieces of air killed you during the boss fight, the Game Over Screen popped up when you were not actually dead and the Win Screen refused to show up at all. Me seeing my stupid code not working As there was a huge amount of things to fix up, I tried to figure out the best way to debugging in Unity and figured out that there is a lot of approaches that might work depending on the situation. 1. The Conso
2 comments
Read more

Comment #3: Karel

-
Link to Karel's Blogpost! " Hej hej! You provided a structured and very informative blog post explaining scrum and handling priorities with MoSCoW. I really like that you describe both principles in great detail and connect them to your work on the shoot em up game. The introduction and conclusion you give also create a good framework for the reader to follow. However, there are a lot of technical terms in your post that could be hard to understand for someone who did not deal with Scrum before. Additionally, I feel like you focused a bit too much on methods of prioritisation instead of Scrum and agile development themselves. When it comes to the picture you used, i have actually no idea how a screenshot of tetris has to do with your post and I wished you used a picture of your team having a sprint meeting, a screenshot of your Scrum document and how you assign priorities in there or something else that is more suitable. Besides that, I found your blog post quite i
Read more