Blog Comment 6

Link to designated blog:

https://kaijunqilin.wordpress.com/2018/03/21/postmortem/

 

My comment:

Your blog was enjoyable to read although a bit lacking in details. You talk about why you and your team are happy with the results and reference the last playtest and the positive feedback that you got, but I would like to know if there was anything you guys were not satisfied about and if there is something that the testers did not like because you only mentioned the good feedback you got, and that is fine, but I think you should also take the reasonable negative comments as well.

I like the part about what you have learned from this course and how you divided it into different criteria, but you did not go into details for any of them, you just briefly mentioned what you learned but not how it is going to be useful to you, and you I would have liked to know what some of these difficulties that you had were, I think mentioning some examples there will make the blog appeal more to people who have probably faced the same difficulties.

Overall it was an enjoyable read, but lacked some details that were not necessary, but would have added more substance to your blog.

Postmortem

After 8 weeks of production, we have finally reached our goal. What started of as a design concept by team Bugbear is now reality. We chose their concept “Behemoth” because it was simple to make and left enough room for us to be creative and our own touch to it.

The end result of the game includes a Behemoth avatar with 4 shields that can be activated separately, and a cannon that can rotate over an angle as well as move up and down on a track. The cannon had two different shooting mechanics, a single projectile and a laser which you have to charge up, and a reload mechanic. The game also had three different types of enemies, a Drone enemy which moved towards the Behemoth in different patterns and could spawn in swarms, a Shooter enemy, and a Spawner enemy which spawned drones. The enemies spawned in waves and moved from the right side of the screen to the left. When you destroy an enemy, they had a chance to drop a power-up, and after picking five of them you can shoot a shockwave.

We chose to go with a pixel art-style and 8-bit sounds, for the sound effects and music, which complemented each other pretty well. Some of the mechanics from the original concept document were changed like the movement of the cannon, we added the ability to move vertically between 3 nodes instead of just rotating the cannon and of course limited the angle you can rotate so to not make the player too agile, we added enemy types which were not in the original concept document to add variety, as well as designing the shockwave power-up that moves across the screen destroying all the enemies in its path.

Working on developing and creating this game was the first time I have worked with the same team for an extended period of time, I have participated in game jams before but none were longer than 48 hours, while for this course we worked for 8 weeks together. During this period I learned a lot about working with the Unity engine and the basics of making a 2D game, like setting up game scenes, working with and implementing animations, a little bit about shaders, managing the all kinds of different game objects in the game, and adding background music and sound effects, by completing the tutorials provided on the Unity website and others from YouTube. I feel like I built a solid platform for myself so that I can learn even more about programming games and improve my skills.

During the final showcase of our game, it was very obvious that we did not balance the game properly, although many enjoyed the game, only a few managed to win or even reach the later stages of the game, and that was due to not having an outside party play our game and give us feedback about the difficulty of the game.

Other than that, I learned a lot about the the dynamics of working as a team, and in a scenario were your work progress depends on others and vice versa. The purpose was to ensure I do not become a liability to the team and ensure that the development process goes smoothly. Some of the lectures about teamwork helped by showing us how you are supposed to act in a team, and previous experiences in working with teams also helped.

You need to have a certain work rhythm as a group that everyone follows, meaning no one should lag behind, and equally as important, no one should get too far ahead. In our team we had both cases were art was a bit behind, and code was way far ahead. As a team we handled this scenario in a good way, but not in the most ideal way, by removing some assets that were not vital to the game, but I personally handled it in a bad way and kept moving ahead, and what this caused is that I had to do more work after I got the assets from the artists in order for me not to fall behind. Most importantly I learned to appreciate the work my teammate do and to trust them more.

Working on this project made me realize some things about myself that I never took notice of, such as how important making progress is to me and to my level of motivation, which is definitely both a positive and negative thing, how much I get stressed and frustrated when I do not feel like my team cares about the project as much as I do, and the sense of relief I get when I feel the opposite, and that I am more efficient when we worked together as a team in the same room.

Overall this was a wonderful learning experience in many different ways, and definitely something that did help me improve in various aspects, just wanted to thank my team for making it a positive working experience.

Blog Comment 5

Link to designated blog:

https://programminggamesafunworkload.wordpress.com/2018/03/08/how-has-playtesting-effected-my-games-development/

 

My comment:

The blog was very well written which made it fun to read. I liked that you explained what playtesting is and some of the different ways developers do playtesting, although you did not mention “alpha” playtesting which was something we went through and many different studios run for their games.
You explained why playtesting was important to developers and the development process in general really well, and in a way that main of us relate to, especially the part about getting to familiar with your own game and not spotting some of the bugs.
What I would have liked to know is the reason you and your team decided to ask these questions to your testers, and the difference between the questions you asked in the alpha and beta playtests, as well as the effect the feedback you got had on your development process and how you reacted to this feedback, was some of it expected or was it useful to the game in ways you did not think about before hand. You mention that very briefly in the end, but I would like to know more details about the effect the alpha and beta playtests had on your development process.

Play Testing

We got the chance to have our game play tested twice by our colleagues, once during the alpha phase of production and again during the beta phase, and during these play tests we had a survey for our testers to fill out where we asked them about the different aspects in our game like the different mechanics and controls, as well as the overall feel of the game.

Alpha play test:

During the alpha play test, we had our testers try out a build of the game which had the basic core mechanics of our game Behemoth, primary and secondary shooting, shields, power up, movement of the cannon, and taking damage. We had a losing condition but no win condition and a very basic level design which featured two out of the three enemy types in the game.

We were looking to get feedback mostly about the game as a whole, wanting to know if all these mechanics we have added to the game have helped us convey the theme of our game, operating heavy machinery. The feedback we got on that question in particular was overwhelmingly positive, almost all of our 29 testers said that they felt that they were operating a heavy machine and that the decision we took to not use the mouse as a source of input, which the original concept document suggested, was a really good idea. Most were satisfied with the overall controls except for the shield controls as well as the shields themselves, thinking that it was hard to know when a shield was active since they had a cool-down, and we got a few remarks about the pixel-art art style complementing it, however many thought that the game was too gray.

The feedback we got helped confirm that we were moving in the right direction, especially the feedback about the overall feel of the game. It was obvious that there had to be some changes especially to the input and the shields. For the shields, we decided to remove the cool down and instead add activation time, and with the addition of animations and audio to the shields, we thought that would make them better to use. Other than that, we just followed the beta backlog that we had set.

Beta play test:

The build we used for this test had 70% of the animations and sounds we wanted to have, a more thought out level design, all enemy types, and of course the changes we did after the feedback from the last play testing. We had a win condition and added a reload mechanic, were the player had to input a pattern after a certain number of shots to reload his cannon.

We wanted to know if the new mechanics still helped convey the aesthetic goal, if the sound affects music fit the overall feel of the game, and if we did a better job with the shields.

We had 21 testers this time around, and the feedback we got regarding the overall theme was more positive than before, and people especially thought the reload mechanic added a lot to that. We got more feedback on the shields, and it was apparent that we had improved them, the only thing the testers did not like was that you had to hold down the button to fully activate the shield instead of just press it. The feedback on the sound was really positive, no negative comments there, and same goes for the art style except for the fact that we got the “your game is too gray” comments again. What was very obvious though was that the game needed a proper tutorial phase, and not just some text on screen telling the player what to do.

After going over the feedback as a team, we decided to put more focus the tutorial phase of the game, and agreed that some major changes had to happen to the background because that was what made the game too gray, and not only that, it also made the enemies harder to see. As for other things, we wanted to add more visual and audio feedback to the game to let the player know what was happening.

Summary:

Play testing has helped us make sure we are moving in the right direction and in turn made the development process much more efficient by helping us detect problems we were not aware of, or have given less priority too. It is also a nice motivator and confidence booster to see people enjoying your game.

Blog 4 comment

Link to designated blog:

https://ouroboroshamtaro.wordpress.com/2018/03/01/boaty-intelligence/

 

My comment:

The blog was really enjoyable to read, your writing style complemented the context really well in my opinion and makes me want to go read your previous entries. You do a good job at explaining what you worked on and the reason you made these design decisions referring back to the original concept document.
The technical explanation was also well put, it gave me a clear idea of what you did and how you did it, and the figure you have that shows the vectors and the angles really helped in making things even clearer. The last paragraph was a very nice bonus and it showed some of the struggles you might have had when working these artifacts.
I think the boss design deserves a bog of its own. Although you do explain some things about it, I still feel like there are more things I would like to know both from a technical perspective as well as a design perspective, and especially from a design perspective since the original concept document did not have a boss in it, and I would like to know the motivation behind making the boss the way it is.
The article was a really fun read and I look forward to your future blogs.

Adding Animations

This week most of my time was spent on adding animations to the different enemy types as well as the Behemoth Cannon to give the game more life and to also give some visual feedback to the player when he does certain actions or when certain things happen on screen.

In order to add an animation, I first get a sprite sheet from my artists that has each frame of that animation in an equally sized cell, I then use the Unity sprite editor to slice that sprite sheet into the separate frames based on the cell size, note that you need to select the “Multiple” option for “Sprite Mode”. I slice the sprite sheet based on cell size instead of using the automatic function because it works better for sprites that are not one single avatar. After that I drag the sliced sprite sheet into the game scene to create the animation.

After that I add an Animator component to the game object I want to animate, and give it an Animation Controller where I create transitions between the different animations using various triggers.

One thing I had trouble with in the beginning was how to trigger functions on specific frames, I started hard coding timings at first, but then realized that when using the “Animation” window in Unity I could add things called “Animation Events” to a specific frame which then allowed me to call a function from any of the scripts attached to the same game object. As you can see above, the Enemy Spawner, creates an Enemy Drone when the door is fully open, and this was done by the method I just mentioned.

Adding some of these animations did cause a bit of a problem for my fellow coder and I since they forced us to make some drastic changes to some of the scripts we have already worked on. In some way this led to cleaner code, but it was also work we did not think would require so much work, but all in all we are happy with the results, and most of the timings we had to keep track of are not needed anymore because the “Animation Events” allowed us to pinpoint the exact frame we wanted something to triggered or called.

 

Blog 3 Comment

Link to assigned blog:

https://gotlandblogblog.blogspot.se/2018/02/mastering-big-projects-with-scrum.html

 

My comment:

You do a very good job at explaining what scrum is and why it is used. You go into some very useful details about the scrum document and explain how it is divided and what each section is used for and why it is useful to the team members, and I like how you describe the different stages of a sprint. But seeing as how you go so much into explaining scrum, I would have liked to see some references to some trustworthy source to provide more validity to what you are try to tell your readers, and I think you should have mentioned how your team does things because this felt like it was a general explanation of what scrum is and not how your team used it. You only briefly mention that scrum was useful to your team and I would have liked to know why it was useful and how.

Blog 2 Comment

Blog Link:

https://lovliegamedesign.wordpress.com/2018/02/15/flight-of-the-bees/

 

My comment:

You clearly explain why you decided to work on the bee movement relating it to the feedback you got during the play testing and that the movement you had was just a placeholder. What and how the movement was changed was also explained pretty well, but I would have liked a more technical description of the movement system you made and a more detailed explanation of how it worked. Also I would have liked to know if this decision to change the movement was also related to the overall aesthetic of the game or if it had any implications on it, and how it affected the feel of the game and the interaction with the rest of the game elements like the different enemy types and obstacles or even the level itself. The gifs that you added really showed the progress you made and what was the thing you worked on. Overall good job and fun to read.

Working with Scrum

This week I am going to talk about how the scrum development framework has affected the development process of our game. Scrum is a development framework that is based on the agile manifesto which has a few core values and principles such as adjusting to change rather than following a concrete plan, and valuing the individual team members and the interaction between them over the working processes or the tools used as mentioned in the course book “Agile Game Development with Scrum” by Clinton Keith.

Overall I think scrum has really helped in speeding up and making the development process of our game more efficient and fun. The scrum documentation helped me personally as a programmer break down all the assets in our game which helped me plan ahead when it comes to how these different assets would interact with each other in future iterations, as well as what I could reuse when it comes to code. Also the daily stand-up meetings as well as the sprint reviews acted a as a motivator for me because it’s always great to see the progress you have made and know that your teammates are putting as much effort as you are.

Despite all its positives, I feel like scrum, especially in the later phases of development, has slowed the development process down, and felt inconvenient to me personally. For example, for code we  finished most of the what was needed for the entire game by the alpha phase, and that is because the code needed was relatively simple, my fellow coder and I have both either worked with unity before or prepared really well to work with it, and because as lead code I wanted clean code from the start and no placeholders, because we had enough time to do that. But if you move forward to the present, the pre-beta stage, we do not have much left to do, both because we have finished most of the items in the scrum backlog and because we have to wait on the artists and the team members responsible for sound to hand in the assets they are working on.

I think that the scale of the project has more to do with this than scrum does, but what scrum did was either make you underestimate how much work you had to do in each sprint, for example, you think the work you were assigned is enough to cover the hours you had to work, but you end up finishing early, so you either do more work or ask to be assigned more work in the next sprint and end up with less to do later on, which is the case for the coders in my team, or overestimate it, by giving yourself less work to do early on or spending more time than what was needed on a specific item from the backlog, and then in later sprints you will have more work to do which might cause delays or leave other team members with less/nothing to do.

Enemy Spawn Controller

This week I worked on making an enemy spawn controller object which allows me to implement the different levels we want to have in our game, the levels being waves of enemies varying in size and in the types of enemies that spawn. Using this object I can spawn as many of each type of enemy as I want at different locations on the screen, but for the purpose of our game I only needed to make them spawn from the right side on the screen.

The way this was setup makes it very easy to add new types of enemies to the spawn controller just by simply increasing the size of the Enemies array(of type GameObject) and dragging the new enemy prefab into the new slot, and this makes it easy to integrate newer enemy types through out any stage of production . It is also easy to change the positions where they spawn by changing the “Spawn Position Values” X, Y, and Z values as shown in the image above, which are world space coordinates and not pixel positions. For my spawn controller, I use the X component of the “Spawn Position Values” vector3 as is, but use the Y component to choose a random elevation to spawn the enemies, and the Z component is ignored because the game is in 2D, but is still needed because the Instantiate function I am using takes a vector3 parameter to determine the position where it creates an instance of the object. These values can also be changed at any time through out the game which allows us to create specific spawn patterns that can be used in the tutorial phase or when we want to introduce a new mechanic to our player.

Some other variables that can be changed easily are the wait time before the spawning starts, the wait time between each enemy spawning, and the wait time between waves. The way these delays can be added to code is by using a coroutine which is a function that can suspend its execution until a certain provided time has passed. This allows us to manipulate the spawning times and create spawning rhythms that help in invoking different feelings in the player, for example, we can make the spawning time between the enemies very fast to make the player feel stressed, or slow it down in the tutorial phase or during the first few waves to allow the player to get used to the different mechanics.

Internally this script keeps track of the wave number and the number of each type enemy to be spawned in that wave. There are some initial values for the number of  each enemy type and depending on what wave you are on these values are changed, for example, on waves 1 to 3 you start with only the one enemy type spawning but increase to number that spawns each wave, on wave 4 you introduce the second type of enemy, and increase the number of that type of enemy for the next 3 waves while decreasing it for the first type.

When the numbers for each type of enemy in the wave are decided, the corresponding index for that enemy(reminder that the enemy game objects are stored in an array as mentioned earlier) is added to a List of type integer which then has its components shuffled around to randomize the spawning order of the enemies using the a variant of the Fisher-Yates shuffling algorithm, and I do this to add replay value to the game and make it a bit unpredictable. After that the List gets iterated upon and the enemies get spawned, and also I have to mention that the List is cleared of its data after every wave.

I am generally happy with this artifact, but it can be and will be improved to make it more easy for my game designer to use without having to edit the code.