Comment for assignment (6th comment)

Your blog has a lot of information, in a good way. I’m able to understand how you felt during the development of the game and where you felt you lacked. Being able to see your own flaws is not an easy task but it is the first step to better yourself, good job! It seems that you now know a lot of things which could be useful for the next course.

Just something that I was confused about in the blog was the first paragraph, unsure if it was a reference of some sort but it flew right over my head. One more thing that could be improved, just being more elaborate on the authority part. Since I’m unsure of how your group split up the work to each role, I don’t understand the position your in.

For example, in my group, all the design decisions are left to the designer, so even if the product owner wanted a certain feature in the game, he would have to talk to the lead designer etc and come to an agreement.

Got nothing really much left to add, all in all, a great blog, was fun to read!

URL: https://andersdotgames.wordpress.com/2018/03/14/dead-on-arrival/comment-page-1/#comment-19

Postmortem

The end result of the product is way beyond of what I initially thought it would be. I’ve studied game-related courses before on a more beginning type of level. And the products we produced there were only sometimes playable. There was no motivation, no drive to complete the games. However, here at this university, every soul I meet has a passion for creating games in their own way.

I have learnt a lot of what is needed of me as a designer. When I first started I didn’t really understand my own position and what use there was of me. During the first 1-2 weeks, this was still true. But the further we came into development, the more I learnt about my role and the more my team could depend on me.

I understood that I was supposed to be the person who had to know the limits of both my artists and programmers. And within their limits, I was supposed to design something they were able to construct.

During those first weeks, as I mentioned before, I did not know this. This made our progress slow and a lot of miscommunications happened. It was thanks to an experienced programmer in my group that I understood how important my role was. He explained to me why it is important to for me to design and present mechanics etc in a detailed way.

Because if I did not, how was the programmer supposed to know why the mechanic acts in a certain way or what even the purpose was.

Something that was really useful in my learning experience as a designer was this tool my programmer made for me (As shown below). This allowed me to adjust the different attributes of the enemies we had in our game.

 

With this tool I learnt a lot about level design. Combining this with the playtest I could get a hunch on how many enemies are needed in certain areas and how fast they should move and shoot.

It was only a beginning on my design learning process but something I will remember throughout my entire university education. At the end of the course, I felt I was capable enough to design mechanics for my programmers and be able to explain the feeling the art should convey to my graphical artists.

That was something I did not feel at the beginning of the course.

Playtesting

When making a game, having playtests to provide feedback on your work is crucial. Usually, as a creator, you’re biased towards your own product and will fail to spot the flaws of it, having others spot them for you is important.

And this is exactly what happened during the playtest. We constructed questions where players could tell us how to improve on certain features. Either the ones we thought could be improved or how the core mechanics felt.

These were the questions we had for the playest

Why we had just these questions were because of one simple reason. The game was in alpha, we had no idea if anything we had to show during the playtest would remain the same, be changed or removed.

Because of this, we had to adjust the questions in such a way that it would still allow us to get feedback we could work with. Therefore we asked them how the avatar’s movement felt according to your input. Why this was a question was because the avatar’s movement was a core mechanic to the game.

It was a flying ship with a tilt mechanic and had to feel like one, if it did, we were on the right path. The second question was just to see if our most basic construction of a level had a decent pace to it. This was also to see if we should continue constructing levels at that pace or to change it in order to balance it.

The third question was because we wanted the player to feel overwhelmed by the game. To feel insignificant but then come out on top. Sure, we were in alpha and it’s quite hard to convey feelings without any sort of art, but if the gameplay could give a small bit of feeling of being overwhelmed, we would know that we got the core mechanics right.

We also had a small section where you could write down what you thought about the game, this one is however not less important than the others. Some people could potentially spot bugs or just give advice on certain art that would fit the game to convey our feeling.

The overall answers affected how we further developed our game. We found out that our way of constructing levels made the game too fast-paced. We had designed our first enemy avatar with the distinct features of looking like it’s capable of fast flight.

We decided we could keep it and have it further into the game instead of the start. So, this playtest affected our graphical artists more than the rest of us. With our game engine we had tools that could adjust the speed of the enemy but for the art, it would have to be redrawn by the artist.

It changed our development schedule a tiny bit, since we had to come up with alternate designs for our enemies, but in the end we still managed to complete all the tasks we had set up at the beginning.

All in all, the playtest was a great opportunity for us as a game developing group to get somewhat useful feedback to work it.

Level design

Something that was a bit hard for me as a designer was to make a varied level of our game since only one enemy had been implemented so far. What that meant was that I had to come up with multiple formations that were still somewhat balanced to make it seem that the level is varied.

However, even after I came up with more formations, since the enemy was still the same it just felt off. What I did then was to take the same enemy and remake it’s trajectory path so it flies in a linear path and then making it into a prefab which I could put into our Spawner in unity.

To make it easier for you to understand, this is how the movement looks like for the original enemy.

The blue line representing the enemy’s movement path.

 

This is how its movement was originally.

This was the new values for the new prefab’s movement

 

What this did was to have the same skin for the enemy but it acting like a second one. By putting the values to 0, the movement it had was removed, making it fly in a linear path towards the enemy.

Why I chose to do this was because by having an enemy that shoots the same way, deals the same amount of damage and looks the same, I thought that I could make the player accustomed to it before introducing a stronger version of it. The stronger version being the original one of course.

This made the learning curve more balanced and the game wouldn’t be as frustrating because you wouldn’t have a strong enemy thrown at you at the very beginning. Also having an enemy with another movement allowed me to create different formations for the game, pretty much doubling the amount.

That is how I temporarily solved the balancing of the level design before more enemies were implemented. However, when more enemies are added I would potentially have to rebalance the entire level. Since adding an entirely new enemy into the mix could shake the learning curve up a bit.

Comment for assignment (5th comment)

Your post is very well made. It never lost track of what you were trying to convey which made it easy to understand everything you did from point A to B. I really like the structure if your post, making small titles for some of the paragraphs made me understand what it was going to be about. Making it easier to understand the paragraph and the entire text as a whole.

You also got a picture in it to show how many voted and what they voted on which gave priceless insight on why you decided to change things. One thing that could have made the post just a little bit better would be to include a link to the post where you mentioned the movement you were referencing at the beginning.

Since I haven’t read it I didn’t understand that part as much as you would have wanted the reader to do.

Other than that I can’t really see anything that you need to improve. It’s well made, well structured and easy to read. All in all, a great blog!

 

URL: https://thephantommenaceisnotthatbad.wordpress.com/2018/03/08/the-power-of-playtesting/

Comment for assignment (4th comment)

In your blog you take care of explaining how your game works before going onto level design which I think is great. Makes it easier to figure out the issues you had and how you solved them. One thing that would have helped a lot would be pictures. Even though you did a great job explaining which enemies you had and that the setting was in the forest.

Without a picture it’s hard for me to understand precisely how the level looks and why it was hard for you. However, since I am a designer as well and been working with level design I understand what you’re trying to convey and it’s not done in a bad way whatsoever, just a tip to make it easier.

Since the other minors would probably have a hard time understanding. Other than that it was good. Writing about something relatable made it incredibly fun to read.

URL: https://kassandergd.wordpress.com/2018/03/01/level-design/comment-page-1/#comment-10

Comment for assignment. (3rd comment)

In your blog, you explain everything very thoroughly which makes it very easy to read and follow. If I were someone who didn’t know about Scrum I would still understand the parts you’ve explained. It’s a very well written and structured blog.

I can’t really seem to find any issues with it, I had no problems whatsoever understanding what you wanted to express. You’ve also included pictures of how the Scrum tools you use look like. This, combined with the information you have given the reader, makes it incredibly easy to understand what Scrum is, and how it works.

You also describe when certain things are useful and why such as the daily stand-up meetings allow you to see if anyone has any problems and you can, therefore, stop it before it slows down the project. The last part that I find very positive on your blog is the placement of your pictures.

They are placed in such a way that it doesn’t interrupt my reading in any way but it instead adds to the information you’ve already given.

URL to Blog: https://karldesigncom.wordpress.com/2018/02/22/5sd064-game-design-blog-22-02/

Comment for assignment. (2nd comment)

The blog is really informative. You structured it into steps that made it easy to follow and understand your progress throughout the entire design process. There is not really much I can find where you can improve it. You provided pictures that matched perfectly with the steps you described, you have described why this decision was important and how you managed to do it.

You also take your time to explain what is going to be in the game and what is just placeholders. What I’d like to know next time if you manage to implement it is whether your choice of making the powerup blink in the UI is sufficient. If the player would happen to not notice it, they would immediately die and have to restart.

If you spawn a lot of enemies that are too much to handle for the player, they could be overwhelmed and not think about the powerup or even look at the UI. If it doesn’t work, making the game Pause could be an idea. Other than that, your blog is very well structured, easy to follow and read, good job!

 

URL to blog: https://annamalkannelson.wordpress.com/2018/02/15/powering-up-the-power-up/

Working with Scrum

For any kind of development in general where you need to keep track of things, I think working with scrum is a good idea. Scrum helps you set goals and keep track of what you’ve done so far and how it went.

Regarding my team, I believe that scrum has really improved our development. Why I think this is because earlier during our first semester where we were given tasks to create board games or design documents. We never actually set any tasks we needed to do before a certain time period.

This lead to us not completing things in time for the assignment deadline. We simply did not have a structure that could help us as a team. However, during this semester where we were given the task to create a 2D Shoot ‘Em Up game, we worked with Scrum.

In these pictures, we are using Trello to keep track of what we need to do every sprint and what has already been achieved.

 

We are also using Excel to keep track of everything. Why we are using both is because we are required to use Excel but in our team, we find it much easier to see every task in detail on Trello.

How scrum has helped us is simply by showing us what must be done before the project ends. What is currently work in progress, what needs to be tested and what is done. By having this list we can immediately see if anyone is behind or if things are going as they are supposed to.

This also helps us set up goals for each sprint which we try to complete. For me personally, it feels really good when I put something I’ve completed in the done list which leads to it giving me more energy to work on other tasks.

The best part about working with scrum is, in my opinion, the meetings. We have two meetings where we meet in person every week, monday and friday. We also have stand-up meetings every day in between which we usually have on Discord (a chat app) since our schedules are very different.

This means we can have direct feedback on everything we’ve done, every single day. This means that we can improve the game constantly which I find amazing.

How the boss is going to attack

In our team, we have discussed a lot about the boss. My team chose the Aetherial design document, and the core part of it was that you were supposed to hunt a huge monster (the boss) and feel like a champion. Because of this, it is quite an important part for as the designer, to design the boss in such a way that it gives you the thrill of battle, but is still winnable.

 

To make it a challenge, I came up with an attack pattern, I discussed it with both the artist that is going to draw the boss and the programmer responsible for coding its movements and attacks. I wanted it to be able to move around the screen, for this, it needs to be agile and to make it a challenge it needs to be swift.

 

Why I wanted it to be able to move around the screen is because I wanted it to be able to force the player to constantly move around. One of my group members thought of a moray eel. We all agreed that it fit the description and the artist found it good to work with.

 

Currently, this is a quick sketch from the artist on the size and design of the boss. 

 

So, my design choice for the attack was a lunge forward. The boss is going to be able to tilt his head in order to follow the player’s movement. The lunge forward is going to be in the same direction as the head is tilted. This allows the player to get constant feedback on where it could potentially lunge forward, but also give the boss an option to always be able to hit the player.

 

Because of this, we achieved a relatively simple attack that forces the player to move around giving it a challenge, but it is also balanced since the player will know which direction so they won’t become frustrated. This is just one attack of several we have in mind. But this one is the first one we have agreed on and it’s currently work in progress.