BLOG BLOG

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

Whenever you're working on a big project with a group, you need some kind of plan to follow along. Wether you are working on an extensive homework, a garden project or as in our case a game, starting off without any plan will lead to nothing. This is where Scrum comes into place. Scrum is an agile way of managing work and is widely used in software development and the games industry. The idea behind Scrum is that everybody knows what they're doing, what others are doing and what has to be improved. Scrum also puts a big emphasis on constant feedback. Using Scrum comes with a Scrum Document, in which you take down Sprint Goals, a Product Backlog, Sprint Planning and Sprint Reviews. My work in the "Sprint Planning" section of the scrum document The Sprint Goals define what needs to be achieved each week. This section does not only include milestones like Alpha, Beta and Release of a project, but also user stories for each sprint (usually "sprin

Testing game play in the Unity editor Recently I realized how important it is to play test your game. I always thought of play testing as a thing a developer has to do every once in a while, but did not take play testing and all of its facets too serious. However, a play testing session that we had at university on Monday proved me wrong. I didn't expect  a lot from the play testing. We prepared a few questions about our game, that we could ask the testers about. Some of the questions were about the play feeling of the game, others were about specific mechanics, music or the art style. Nevertheless, I was actually really confident with our game and did not really expect too much useful feedback, but more response on issues that we already know of. However, when the play testing started, we already faced our first issues. As we never build our Unity project as an actual .exe file, there were a few things we have not tested out. When our testers started playing in full scre

Finished version of the centered bee swarm following the player The bee swarm in “Game of Beelonging” is one of the main parts of the game concept. Whilst playing the game, there is a bee swarm constantly chasing the player, helping you out when enemies come to close and assigning a new player on death of the main bee. The swarm is supposed to always be vertically centered in a compact swarm, even if one of the bees die, which makes programming the swarm quite difficult. As I was aware that setting up the bee swarm was the most difficult part of creating “Game of Beelonging” I started off with it right away. I began creating ten empty game objects called “slots” representing  all the positions, each of the non playable bees could go to and added a script to each of the slots containing a pointer to their current bee, a pointer to the next slot and a boolean that tells if the slot is occupied or if it is not. The idea was that each bee will constantly check