Blog comment 18-03-22

Blog:

https://thedudeleo.wordpress.com/2018/03/20/blog-6-postmortem/

Comment:

Hello, I’m glad to read your blog, first of all, you clearly introduced the background of the shoot’em up game, this is good. For the readers which first time to read your blog, they can easily understand the project, and they will not feel confused about what we did in this project.
Then, you described some of the understanding of the concept of umibozu concept document. Indeed, before starting the group work, it will lay the foundation for later work if you have a good understanding of the concept which you chose.
From my personal point of view, I have learned how to use scrum framework through this project, and I think it will be of great help to us both in the study and work in the future.
During the playtesting, I have played your game, and I thought it was a good game, although I didn’t know you cut a lot of features. If we had more time to finish this project, I’m so sure that your game would be better! But what we need to do right now is design a good concept for the next arcade game, and I’m sure you’re looking forward to the next arcade project just like everyone else!
Good luck with the arcade project!

Blog comment 18-02-13

Bolg:

https://oscargamegotlandblog.wordpress.com/2018/02/07/08-02-2018/

Comment:

I would say it is really a good idea to make all moving objects as children of the class ”MovingObject”. I have never thought about that before. I am a very beginner programmer, I am gladly read this blog and learn something from this blog. I have made scripts for every single moving objects, which is really stupid to compare yours. I could have saved more time to make other things better. If you can write more things about how you did it, that would be so great. Also, you are very right about we should make things wrong as much as possible now, it is always better than we make mistake in later, but yeah, at the same time, we should try to do our best on this project and learn as much as possible for next project. We always should be ambitious to make good games, that’s why we are here to learn;) I’m really glad to read your blog!

Blog comment 18-03-13

Blog:

https://guarbabel.wordpress.com/2018/03/08/playtests-feedback/

Comment:

This is a great opportunity to read your blog. I’m sorry to hear about the accident in your group project. That really affects the progress of the project. You described the impact of the accident on your game and how you group tried to fix it.
It’s great that you talked about the importance of playtesting at the beginning of your blog, but if the description of the two playtesting Alpha and Beta can be more detailed, that would be better. As a reader, I would like to read what questions you asked the playtesters in these two playtesting, and what changes you made to the game after you got the answer. If I can read your team’s analysis of the answers you got from the playtesting and the improvement you have made for the game after the playtesting, I think it will give the reader a better understanding of your game.
Anyway, good luck with your game!

Blog comment 18-03-06

Blog:

https://gamedesign673637781.wordpress.com/2018/03/01/level-designing-the-start-of-our-game-august-demirsson/

Comment:

Hi!
It is nice to read your blog! I like the part you will present the mechanics to the player at the start of your game as an introduction. This is really nice. Many games have a how to play button on the start menu as an introduction, but sometimes people ignore this information and start playing games directly. So it is nice to have a trail at the beginning of the game. This will make the players less confused.
Also, this picture clearly explains this small gap, otherwise it will be a little hard to imagine. But personally, I don’t really like the fact that you force player and the enemy are very close to this part. Anyway, I understand this part of the game is to give players a better understanding of the mechanics of the game.
Good luck with your game!

Blog comment 18-02-27

Blog:

https://clementpirelli.wordpress.com/2018/02/22/5sd064-blog-post-3-scrum/

Comment:

Hi, it is nice to read and comment on your blog. After reading your blog, I felt like I misunderstand this assignment, I might need to rewrite my blog again… I have written my whole blog to explain how scrum works in a team. But anyway, let’s get back to your blog. It is good to write both the good and bad influence that scrum brings to your group. To be honest, I have the same feeling with you about the daily stand-up meeting. I assume the stand-up meeting will work if we are working in a company, but we are students. Sometimes it brings inconvenience to us. Personally, I think the sprint planning is very useful for me, it can remind me clearly what I should do for next. I think scrum will give us a lot of help in the future whether it’s working in a group or in a company.

Blog comment 18-02-20

Bolg:

http://blog.erikrosenberg.se/2018/02/15/post-2-using-play-testing-feedback/

Comment:

Hi, Eric! It is really nice to read your blog! Also, I really liked the part that you quoted from the MDA framework and the book Fundamental of Game Design. This is a great way to combine your ideas with the ideas in this book or the MDA framework.
In this blog post, you mentioned three main feedback that you got from the playtesting. Through this, I see that you have a really good summary of feedbacks, but it will much better if we can see the questions that your group asked the testers.
The conclusion section is also pretty good, and in this section, you described the things that your team is going to focus on more, but a little bit short, you can get a little bit more detail about it. Anyway, this is a good opportunity for learning things by reading your blog! Thanks for sharing your blog!

Postmortem

After eight weeks of teamwork and every group members’ efforts, we finally completed the development of this shoot’em up game.  I believe that everyone has learned something that they can help themselves in future studies or work from this experience. I also believe that everyone is eager and ambitious for the next arcade game project.

This is a menu screenshot of the final version of our game:

I can say that our team and I are satisfied with the final version of our game.
Similarly, we are also satisfied with the results that we obtained in the last playtesting.

Our group prepared several questions for the last playtesting, such as:

· What was your favorite moment in the game?

· Do you have any final words for us?

In this playtesting, we got feedback from 31 playtesters. I don’t really want to list the answers we got of these two questions because almost every answer is different, each playtester enjoys a different moment of enjoyment in the game. The reason I have shown these two questions is that we got a lot of good feedback, which makes me really happy. Since this is the first shoot’em up game that I programmed. I feel a great sense of accomplishment.

Through the course Game Design 2: Game Development,  as a member of a group, through these eight weeks, I have learned the division and cooperation in the group. I have also learned how the Scrum framework worked during in group work. Such as, make a sprint planning before a work phase begins and make a sprint review at the end of the work phase. I believe it will be helpful not only for my future group work in school but also for my future work in a company. As a programming student,  through eight weeks, of course, I have learned a lot of programming skills. This is the first time I have used unity to program and make games. So I also encountered a lot of difficulties in the process. But I have solved the difficulties which I encountered by watching the tutorial videos online or discussing the problems with other programming classmates in my spare time.

I am glad that we have been able to get through this game in eight weeks. It gives me a lot of confidence for next arcade project.

Thanks for reading my blog! I hope you all can finish a good arcade game in the next project!

What improvments brought from playtesting

So far, we have done two times playtesting. Our team prepared different questions for both playtesting.

The first playtesting was primarily for us to find out what we might not have thought of. I can’t list all the questions here, so I chose two that I think are the most helpful for our game:

· What was your least favorite moment or interaction?

· Was there anything you wanted to do that the game didn’t allow you to do?

We got a lot of feedback and most of the feedback is different. For the first question, some people thought our boat is moving too fast, but some people thought controls felt a bit unresponsive. For the second question, we have got a couple of similar answers, and some playtesters think that speed power up is a bit useless. After the playtesting, we added the things we needed to improve in the next sprint planning. Such as fixing the control of the boat. As for the accelerated powerup, although some people don’t like it very much, some thought it useful, so we added another kind of powerup which can enhance fire rate.

In the second playtesting, we asked the same question:

· What was your least favorite moment or interaction?

One of the feedback we got is the crystal of the end of the level is really confusing. During the test, we also noticed that, when a player was going to enter into the next level, there was going to appear a crystal in the interface of the game, then players will enter to the next level when they collide the crystal. But when the crystal appeared, many playtesters were so confused and they tried to shoot the crystal. So after that, we had a discussion with the group, and maybe it wasn’t particularly good to use the crystal as a sign to get to the next level. Then we decided to replace the crystal with a portal. It makes more sense to enter the next level through a portal.

To sum up, as designers, playtesting can bring us a lot of things that we haven’t noticed. This will help us to improve our game a lot.

Add a new enemy type: shooting enemy

Before the beta playtesting, I was working on adding a new enemy which can shoot at the player in our game. Before that, there were only two kinds of enemies in our game: glaucus and pufferfish, and they all behaved in a similar way. In the game they will only move to the player, not firing projectiles, which is a bit boring in a shoot’em up game.

Then our group decided to add a new enemy to our game: Sky ray. Why did we make such an enemy? A ray looks like it is flying in the sky when it swims in the sea. We chose to make a sky ray as a enemy in our game. Also we think at least we should have a shooting enemy in our game. Then we decided make it bacome our shooter enemy in our game. The sky ray is spawned at the right side of the screen, and it moves to the left side of the screen with a certain speed. Sky ray is going to be randomly generated from these five enemy spawn points. During the sky ray moves from right to left, it will shoot projectiles at the player with a certain fire rate. This is done by giving it a horizontal speed. We can do this by adding a 2d rigidbody component in unity. For the projectiles,  I gave them a direction every time when it is created, and this direction is the boat’s current position. Then when its x position is less than the x position of the boat, it stops firing projectiles.

In the process of programming, it is not difficult for making the sky ray to move or shoot, but it can be challenging to make the movement or shoot more perfectly or smoothly. After beta, my next goal is to improve the sky ray’s shooting, or, to say the least, let the projectiles find the player in a different way, not like now, it should be more fun when a player is playing this game.

The iterative and incremental development — Scrum

At the very beginning of the course Game Design 2: Game Development, we chose a game concept document, and then in the next ten weeks, we were going to develop this concept into a real game. In the process, we were taught a framework called scrum to help us to manage product development.

What is scrum? I was really confused when I first learned about scrum, but when our group actually applied scrum to developing, I understood how it worked. Scrum is a framework for managing software development. From my current understanding, it can be roughly divided into several workflows: product backlog, sprint planning, sprint, sprint review and releasable increments. I will go into more detail on how scrum works in a group.

 

 

 

 

 

The product backlog contains everything that our group needs to do for our product. This product backlog list needs to be in order. Then we select some of the requirements that we feel we need to do first in the product backlog and put them into sprint planning, which means these requirements need to be done before the next sprint. I have to say that my group was not really good at sprint planning at first. We planed too many things or fewer things in the sprint planning in the first two or three weeks, but we are gradually learning, changing and getting better. Then what we need to do next is to start developing the requirements on the list and do as much as possible before we have the sprint review. During the sprint, every twenty-four hours we should have a daily scrum, which is a fifteen minutes stand up meeting for track the progress. After the sprint, we need a sprint review to check that if the team members have completed the sprint plan. If they didn’t finish all the things that should be done. Then the group should put the thing hasn’t done back to product backlog or next sprint planning. Every time after a sprint review, there should be some releasable increments.

This is my current understanding of scrum. If there is anything misunderstanding or not good enough, welcome to point out my mistake!