Week 1 - 06/09/17

Design Jam #1 - L game:


This week began with a design Jam. It was the L-game in which 2 players or teams compete for space on a board. This game is played in turns. Each turn a team needs to pick up an L piece and be able to put it somewhere else on the board. When they are able to do this, they can then move a pog around the board to make it more difficult for the other team to replace an L-piece. We got the instruction to make this game more interesting.

We thought a big problem with the game was the difficulty. There was simply to much space to move your pieces around and nobody ever lost if you did not do anything stupid. The idea that we got after brainstorming, was to make it so the game is about losing space on the board. So we made the playing field bigger, and instead of having 2 pogs that can be moved around, now when you move your L-piece you get a new pog and place it permanently on the board.

After testing this a few times, we concluded that this was a good idea but still a little shallow. The beginning of the game was boring because it did not matter where you placed the pogs in the beginning. Maybe we needed to reward the team if they can easily move their L-piece. So we made some new rules. If you moved your L-piece without rotating and flipping it, you get to place 2 pogs. If you moved your L-piece without flipping it, you get to place 1 pog. This made the game way more fun, since each team started planning in advance where to place their pogs in order to make it more difficult to place their team's L-piece. after this, I got informed that I need to make a game as a hand in assignment for game mechanics. The only requirements set at the start where that the game engine needed to be Unity. I am going to use this game as a learning experience. I am quite confident in my ability to make a game in Unity since I already started learning the engine in my summer vacation. This classroom will be a good environment to test my design descisions.

I always wanted to make a top down shooter with roguelike mechanics and I found this project suitable to finally get started on this idea. In this class I will get to test my design decisions which will help me later in my career.


Homework Assignment - Core Mechanics diagram:

Homework Assignment - Core Mechanics diagram:


















Week 2 - 13/09/17

In this week, I learned about reward systems and got to pitch my game. While the pitch itself was very quick (I did not even get the time to stand up), it went okay. The teacher gave me a warning that it was a very big scope for the time I had to make the game, which I knew was true. Yet I still want to try and make it. I have confidence that my design desicions will lead to a sufficient mark, and I will probably continue development on this game after the lessons have ended.

Homework Assignment - Reward System:


















Concept Pitch:


What I will be focussing on in the rubric:





































































Week 3 - 20/09/17

.

Homework Assignment - Kishōtenketsu:




















Week 4 - 27/09/17


Design Jam #3 - Dungeon map:


In this weeks lesson we learned about level design. This was theory I was already familiar with. While this information was usefull for later, I could find little use in it for the game I am currently working on. I plan to have the levels in my game randomly generated and I think my skill in coding is not yet high enough to think about design when I make my own level generator.

Also in this weeks lesson we had a design jam in which we designed a classic Zelda dungeon using the Kishōtenketsu theory from previous week. We thought of introducing a new item in this dungeon, that fits the dungeon itself. The dungeon was bull themed, and the item you got in this dungeon is a whip. With this whip, you could aggitate bulls, which afterwards run at you and break weak walls when they collide with them. The wip also allows the player to hang on hooks located on the ceiling.

In the beginning of the dungeon you encounter bulls as enemies and weak walls acompanying these bulls. When searching entering the room with the whip, you get locked inside without a visible way out. You have to use the whip on a hook which allows you to go to the next room. In this room you have to agitate a bull to break the weak wall. Now you learned all the mechanics, the Ki. Afterwards the player can use his learned skills to get bonus items hidden in the dungeon, the Shō. The boss is a giant bull. You can only damage him by aggitating him and letting him smash in a wall, but the player can only dodge by using the whip on hooks on the ceiling since the bull leaves no room to dodge horizontally. Here we let the player combine Mechanics, the Ten. The ketsu is in the rest of the game where te player can use his new item.


In game screenshot:

Playtest #1 notes:

Playtest #1 Analysis

I went to this weeks playtest with high hopes. I had a strong prototype, and I knew what kind of information I wanted to obtain from my testers. I wanted to look at their playstyle and the tactics that they will try on their first impression.

But some things are not meant to be. At the start of the test extra importance was layed on feedback given by the game. Now that was all that my players would think about. Every comment I got afterwards were only about the feedback of the game which I litteraly had worked the least on.

The most frustrating part about this, is that I could have easely put some feedback in the game if I knew importance was layed on this beforehand. Despite this setback I did get some usefull data out of it. I just kept asking people questions until I got the answers that I wanted in the beginning. It still is a shame that I had put a lot of effort in getting usefull data out of my testers but it is still better than no data at all. The most important issues were as follows:

    The player feels slow
    The weapon feels weak
    Almost nobody noticed that shooting the weapon depleted your resources
I made the following design decisions to tackle these problems:
I thought the speed of the character was not too slow or too fast. To tackle the feeling of moving slow, I added a dive button. With this you get a slight speed boost but you can’t change your trajectory when diving. So you now have the option to trade speed for precision in movement.

To tackle the weapon feeling weak, was hard for me. I knew the weapon felt weak, but that was the point. I want players to have a weak weapon in the beginning so they keep an incentive to upgrade their weapon. Overall, I saw people not buying enough upgrades as they should. For now, I decided to make the upgrades cheaper to make it more alluring to buy the upgrades.

To tackle the problem of people not noticing that the weapon depletes ammo, I need to change the UI so this is more obvious. But I think this is not necessarily a problem. When I will add a tutorial level later, this will then be explained.















Week 5 - 04/10/17

In this week we learned about economy and feedback loops. Information that was usefull, but information that I already knew except explained in a way I found was difficult to understand. The lecture about economy gave names for certain processes that, for me personally, made no sence to what it actually was describing

Homework Assignment - Economy:





































































Week 6 - 11/10/17

This week we had lessons in which we learned about emergence and we had another playtest session.

Design Jam #4 - Rapa Nui Island:


Playtest #2 screenshot:

Playtest #2 notes:

Playtest #2 Analysis

This Playtest session went much better. I added the dive mechanic to the game, and I made the safehouse where you can buy upgrades actually safe. The house has guns which shoot enemies when they get in range so the player can buy upgrades in peace. I also made sure that when the player starts playing, that he/she has enough resources to buy upgrades immediatly.

I got a lot of usefull data. The most important issues were as follows:

    The player gets overwhelmed with enemies if they make a mistake.
    Players are not dodgerolling
    The goal of the game is unclear if I do not point it out
To tackle the problem of the player getting overwhelmed I decided that when the player gets hit, that he/she should get knocked back. Then the player will have some space to run away from the enemies after they get hit.

To tackle the problem of players not diving as much as I like, I need to make sure that you need to dive in order to progress in the game. I can only think of making the enemies faster, but this will probably result in the players complaining that they feel slow. I think that if I will add feedback to the dive, that players will be more incentivized to use it.

To tackle the problem of the goal being unclear, I will put a arrow around the player, that always points to the safehouse. Hopefully this will solve several problems. This will help players always find the safehouse and will litteraly point them towards the goal of the game. I think this will also make players buy upgrades more, which I still think players do not do often enough.























Week 7 - 18/10/17

Playtest #3 screenshots:



This week we learned about polish. A bit dissapointing since we already learned a lot about polish in Game basics. We did get tips about where we could find free music and sound effects but, like I wrote earlier, I like to make them myself.

Playtest #3 Analysis

This playtest went really well. I added the safehouse indicator, but it does not always point directly to the safehouse. It changes when you change the resolution, which I have no idea how to fix. Furthermore, I added turretplates around the safehouse. These show to the player where the range of the turrets are, and gives feedback when you stand on them (angry face if an enemy is on top, smiling face if the player is on top). I also added knockback when te player gets hit. I did not yet have the time to add feedback for diving. I also added random generating levels in this build

I got a lot of usefull data. The most important issues were as follows:

    It is unclear that enemies get tougher when you go to new levels
    Getting resources is too easy
    Players do not see look at the UI

For tackling the issue where players are not aware of enemies getting stronger, I will put it in a help screen. This is a lazy solution, but I would like to spend my time in other things before the final build of the game.

Since getting resources does not have any risk, I got the idea of a classmate to add some. I think this is a great idea. I will change the houses into rocks that need to be mined. These rocks will only be mineable when you dive into them. This also solves the issue with people not diving enough, since it will be mandatory to complete the game.

To solve the problem where players do not see the UI, I think I will put a portrait of the character next to the important data. This portrait will animate when the player takes damage, or when the player gets resources. I hope this will draw attention to the UI, which will make the feedback more noticable.

Since I do not have time to implement my original story anymore, I will change the part where this takes place in the real world where your experiment changed every woman into a man. Especially since the houses will now become rocks, I will make every level a dimension which you travel to. Now I can make the enemies slimes, which are easier to animate, and do not have to face a direction.

Playtest #3 notes:


Playtest #3 evalutation:







































Week 9 - 29/10/17: Final Thoughts

Final game screenshot:


What Went Well

Things that I am deffinetly proud of are my level generation. While it does not offer much to the design currently, this is something that does not take away from the experience which is something to be proud of.

I am happy with how the game feels. I think the character moves around nice, and I think my UI ended up really well. There are a few sprites that look a bit off, but for the most part I think I did okay.

I also think that I did a good job analysing my playtest data. I Always tried to look at the cause of a complaint and considered how I can solve this issue or if it needed solving in the first place.

Final game screenshot:

What Didn't Go Well and What's Next

I do have many things to improve on when I will work further on this game in the future:

One of those things is balancing the game. I do not think the game is to difficult. What is a problem is that players often can not make multiple decissions when buying upgrades. This is because the upgrades are very expensive since they are very powerfull. To achieve balance I need to test it a lot. This is not hard, but it just takes a long time.

Another thing to improve, is that I need more randomness in my game so that every play session feels different from the last. While players do have variety in rock placement, this fundementally does not change enough. Adding more weapons is a obvious solution for this problem. I think that instead of being able to improve your firerate, you can exchange the same amount of resources to get a random weapon from a pool which automatically discards your previous weapon. Everytime you do this, all the weapons will get better overal. This is important to keep a sense of progression. The random weapon changes does mean that your playstyle will have to adapt which I think will make this game really fun and trully give it something unique. This will take a long time to develop, but it will be worth it.