Enoch's IGB220 Blog

During the whole assignment 3 development process, I think the most important part of the reading that helps me is chapter 9 playtesting, and chapter 14 communicating your designs. During the whole assignment process the most important part for us is to do playtest and get feedback, then redesign and fix our game according to their responses, I think the page 302 basic usability techniques and page 306 data gathering is very helpful for our playtest. This links to one of the tools we used in our playtest, it is too but different elements of the game in scale for the player to rate it.

It was very useful for us to find which part of our game is most liked and most disliked so that we can plan with part we should work on according to that.

Talking about one things that I reflect on is that one thing that I would change about how I developed the prototype is the communicating between me and my team. I learnt this from chapter 14 page 451 of the book, such as using flow chart, I feel like during the whole process of making this assignment 3 game, although our team had some short communication during part A and the beginning of making the game, such as sharing our vision and such, but our whole communication is very lose, it is not as clear as using the flow chart, sometimes when we are making this game we have different shape in mind of how the game looks like, and we slightly worked in different direction. I think a tool such as Flowchart can get all of us a more clear path and direction of which we are working at, then we can see the same piece of work more clearly.

For our play-test we used a tool google form to put both the questionnaire and survey in it, then ask the play-tester to do the first part before hand and the second part after hand.

During the first play-test, the player find our world, art and game play mostly enjoyable, and thinks that there are enough difficulties.

Some things that the player point out are for example, some times they through a gap is jump-able but turns out the hit-box is a bit bigger than expected and failed.

For the first two play-test, player thinks it is easy to play, so one aspect we might consider to is change back the algorithm to make it more hard to play, but then add more item to give player tools to fight against the increased boss chase, so that they have tension and fun at the same time.

One interesting finding in the time recording is that player actually take a bit more time to approach a new thing that they first saw, such as seeing the clock for a first time or seeing the slime for the first time took them 1 more second to interact with them. This might be cause they are thinking about the new things, and they also have this reaction when they touch the clock and afterward say," oh, so it stop the thing for a bit", new item might also be a fun part for the player, we can add more to it depending on the situation.

More add-ons after the whole process:

During the second playtest, in this playtest we have already renew our game from the first version, we added the item for the play to use. But during the playtest I figure that sometimes the icon of the item is not as obvious as I think, so player failed to understand what the item do, so they couldn't effectively use the item the way is should. On top of that, some player also thinks that the item hotkeys are hard to use, so other player thinks the item hotkey is friendly because it is close to the control key "WASD", one thing that I found about the item is that sometimes the situation of the gameplay is so quick and the player failed to press the item quick enough. Another finding in the playtest that is most important is that player thinks the control of the character is very slippery, and the character hitbox is weird and easy to fall off the platform while turning.

All of this and that problem we changed for the final prototype, we removed the sword from the character, the actual reason we found that the player find the character turning very weird and fall off platform, is that the sword of the character also counted in the hitbox, so when the player thinks the foot of the character is still on the platform, it is actually the starting point of the sword is the half-way point of the hitbox, causing confusion. So we decided to remove the sword.

(before and after)

We got some good stuff to do for making our racing/platform running down game.

So during our development we have first decide to use google drive to put some resources on it, also we use Trello to manage the task that we need to do and have been done, at first we also decided to use Git to collaboratively work on the project together. But then after we try to sort of the working process on Git during a meet up section in the workshop, we find it very hard to work it on Git for GDevelop5 so instead we decided to just work on it one by one and upload the whole package to google drive, and write down what we have done and make changes on Trello and Discord. So this is our work ways.

Then we started working on it, for the other group members part they worked on basic UI, background, sound effect and also the level placement, design.

For my part so far, what I have did what created the Grim that hunt the player from top to bottom, at first I used a placeholder art of:

Tripling it as what I myself did in my racing game to the good width:

I designed the script to chase down the road in constant speed, and it would only start chasing the player after 2 platform, so that allow that player some time to run, giving the player enough tension but not instant death. Later we did changed on the art and behavior of the Grimm a bit.

Another thing then I added is the original portal part, but I just put it in a placeholder for and wrote the related script to it, then someone replace the art and made it all look good together.

The new portal part art or runes:

Then I worked on at least one item before the play-test start, I decided to add an item the would slow down the Grimm from chasing when touched, I decided to just put a cross for art first anyway, either as the art or just a placeholder is fine:

I at first set the script to have a pause time of 0.75 second, not sure if this would be a balanced value, this would need to be tested out in play-test.

Then later the art got changed to a clock:

The last thing that I added before play-test is at least one type of enemy, that was what we planned to have for the essential play-test, to keep it easy and for the respect, I just added the slime as the very basic type of enemy, with a very basic idling animation that wiggle up and down, and a 10 frame dead animation of which the slime melt:

I added a simple enemy interaction of killing the slime if the play land on it, and otherwise if they player touch it from sides, the player would get knocked back, although this might seems very insufficient, it is actually very deadly when the player is getting chased by the Grimm, the little bit of time could make the different, but how much of an effect it really have, or is it in a balanced or unbalanced way, this would all need to be tested during the play-test to get more feedback and worked again.

To be continued...

More to add on, during this development of the game, the things that I added and changed is mainly base on the playtest feedback, but still the playtest feedback only told me what to do, but HOW to do it is still a lot of things to learn from the book.

Frist one thing is that I finish added the other two item, the drill and the cross, the drill allow the player to go through platform, and the cross kill all enemy in a range.

I used a global variable to keep in store how many of each item the player have, and then I added a condition checking the item count, if there are item then the play can use it. Here are some related code:

I also make sure to update the displaced item count text that the play have on their screen after every time triggered.

Then I added a second enemy that have more hit point and float in the air following a path.

This ghost is a more budget one, it have less animation than the slime. Another thing I added is the some text description about the item when the player hover the mouse over it.

Of course, in order to buy item we also need a shop menu and a shop owner. These are some code:

this is pretty much my part of the development of the script, but I also adjusted the level a bit.

(level 2 and level 3 respectively)

I went on to play-test my game with other people, and they gave up some variable feedback that I would use to change the game and make it better.

For example, play-testers find my game really unbalanced and don't enjoy playing it again, not only that the hitbox is too harsh and narrow, they find it very hard to dodge the car, and the frustration that come up is that by eye it look it they have dodged the car, but the "stupid" hitbox still collided and they boom up.

Another problem is that the viability is very limited, instead of a more regular rectangular window, my window is very square like, and give the player very less information, making them unable to have enough time to react to the against side of cars, this create a problem that the player either just play on the left side of the track, or they go to the right side and play with RNG.

Overall, I find that it is really important to do play-testing, this relate me to the textbook chapter 9 and 11, the play-test process give us a lot of insight to the user point of feel, for example, because I designed the game, it might find it much easier to dodge the hitbox because I know them better, but that is not true to the player, and this will make their 99% game play very bad and don't want to play the game again. Also when relating to chapter 11, just because it is challenging to dodge that narrow hitbox between the car does not make it super fun, and I really need to be careful of that.

During the development process of the racing game, I decided to add a threats to the player to create tension and reason of play, I added a horde of zombie that slowly chase behind the player's car, so the player need to keep running from the zombie to keep playing.

I found some online zombie with a top-down view, then duplicated it and put them side by side to make it the width of the road track.

I also fixed the control, making the player only able to perform left and right movement for the car. So that the player cannot freely go up the track and avoid the horde of zombie easily.

Then in-order to help the player escape from the zombie, I added speed boost, in the shape of fire, touching it would allow the player to boost up the track and run from the zombie in such way.

I decide to put the fire in the middle of the track so that player can easily access it in time from any position on the road.

And at last I also added a timer, the player online need to survive through the timer to win the level, releasing the player tension and give them some time to rest before the next level.

Some example shot of the game:

The reading that inspired me most in this game is chapter 4 page 97 challenge and chapter 2 page 38,46 story, I think unlike other game such as platformer, in a racing game it is most important to keep giving the player a tension or a challenge that push the player on the road, since the main aim and playable part of a racing game is much less than that in a platformer game where you can explore around, if they player is not consistently pressure they might lost fun in this racing game. But when I was making the challenge of zombie chasing from behind, I think that I it is good to have a bit of story around the zombie chasing the car, what would happen a bit later the player get away from the zombie, I think all this can link together to make the whole game more playable in a whole.

The title of the game is "Zombie! Run!"

The breakout elevator pitch is that this game is about the player is getting chased by a horde of zombie so he jumps on his car and starting racing he way to flee, where the player can pick up speed boost and coins on the way to level up the car for better racing next level.

The image or the concept art is:

image from: https://www.dreamstime.com/royalty-free-stock-photos-two-undead-zombies-pursuing-car-apocalypse-image30196008

The control diagram is:

The three unique selling point of this game are 1.) time limits from zombie chasing 2.) speed boost package on the road 3.) car upgrade

During my design of the game, chapter 3 and 4 have helped inspired me the most in this game, all the resources, conflict, boundary, challenge and play element have been most used in this game. I think this game have less iteration element than the last platform game, because in this game a lot of element are random, for example the zombie spawn and also the bullet hitting the zombie have some part of randomness, so when I was making the game there are less I can do about the level design to give experiences to the player. So chapter 3 and 4 become more important, I need to make the game more fun with dynamic element or formal element such as resources to control the game.

Then base on the play test result I also have changed some part so that the game is a bit different from the original designed prototype, for example, more play test think it is fun to play with and likely to play the game again, and some wanted stronger weapon, so I added short gun upgrade, instead of the original idea of player selecting UI and upgrade the weapon, I changed it to auto upgrade when the player get enough score.

Some asteroids development post, when I start making this game, first I reuse some resources that was made during the workshop and changed based on that with the art resources that I and going to use. I found some top-down zombie shooting game art work resources online so I first replace my player and zombie with it,

Because the player is a unique sprite, but that I mean there will only be one player in the scene at a time being controlled, so I drag it on the scene that manually adjusted the size of it.

But this could not work for the zombie, because the zombie are spawn every few second like an asteroid, so I need to resize the photo source of the zombie and then put resized photo to be the animation for the zombie, so that when the zombie spawn they are normal size zombie.

On top of the lives system that was already made in the workshop version, I also added a score system, so that for every zombie killed, the player will get 10 score displayed.

So now that I have get some basic on my game, it have most of the basic lives and score system with zombie keep on spawning.

Some gameplay photo:

When I was working on the game, some element in the game makes me relate back to chapter 3 of the reading book, in fact, a lot of chapter 3 concept are used in this game, for example, in chapter 3 page 81 it mention about a resources lives, which is really just the lives part in my game, lives is a super good resources in Arcade game with will make player start the game again when they ran out of lives, which our asteroid game is a bit or an Arcade game if we think of the theme. Then in chapter 3 page 85-87 it also mention about another 3 important element that I took and used in this game, which is conflict, obstacles and boundaries, the obstacles present makes conflict for the player making them lose, and also most importantly the boundary stop the player from just escaping from the conflict. The spawn of zombie create an obstacle that conflict the player by taking about his lives, and the boundary which the the game play area make sure the player cannot just flee away and ensure the conflict tension, this makes a really good enclosed loop and make this game fun and work.

I also think that zombie give more tension then just rocks and the player controlling a gun to kill zombie give more challenge, this is also some content in chapter 4 page 99, keeping a challenge and give the player a clear goal and feedback, how every, I would say although the feedback is clear, so if you killed a zombie you get 10 score and if you got touched you lost lives, the goal is not too sure or exciting, the player is just keep on killing the zombie in some point of view and you cannot really see the end. But as the theory said in class, I feel like this game is more about the moment to moment game play, so the shooting part and clearing zombie is the 90% gameplay that the player is mostly experiencing and that part is doing a good job to make the game fun for the player. The player is not thinking about endless wave of zombie or the game would never end, instead the player are have fun when playing the moment to moment gameplay or the 90% part of the game.

some code for the game:

Overall, in this platformer development process, I mostly used idea and materials from the first few classes of reading, play testing feedback iteration and also my know knowledge of games to make the platformer game.

For example, chapter 2 page 36-39 or also something like chapter 4 page 93 and in fact many more page in the book, mentioned about conflict and challenge. Where as conflict and challenge are the main theme for my first game, a lot of the plays in my platformer game are related base on that, the player are constantly challenged my zombie and need to react to the threat.

During the development process, when I was making the boss, I originally planned to make it a big boss, because in games like Monster Hunter or Elden Ring there are huge monster/enemy as bosses, but then I come to difficulties when designing the boss level is that because the boss is so huge, and we need a conflict that the boss is chasing the player around, the player actually cannot jump over the boss and will always get kill when they entre the level.

This really inspired me and give me a hit in the head when I think back of games that I have played, unlike in 3d game where player model and do side dodge like in Elden Ring, Hollow Knight is more of the game close to my game, how when I was actually designing the level myself, I not understand better why the big size boss in HK such as False Knight do all the crazy move and keep on jumping around in the boss fight, especially the large size boss in the early game where you do not have much upgrade yet. These boss design is actually giving player a challenge that is beatable. Now that I think of it in a designer view, I understand it a bit more in both player and designer perspective.

The title of the game is "Zombie Hunter"

The asteroid elevator pitch is that this game is about the player control a zombie hunter that have a gun and just start shooting the horde that is coming toward him, get better gun upgrades after beating each wave or zombie.

The image or the concept art is:

image from https://www.indiedb.com/games/over-9000-zombies/images/over-9000-zombies-2d-top-down-zombie-shooter

The control diagram is:

The three unique selling points are 1. bird eye view shooter, 2. shotgun and 3. different zombie

Some platformer development post, at the first sight I don't really know where to start, so I really just start simple at first, I really just referred back to the Tracy Fullerton game design workshop book, she said in the book chapter 1 that it is most important to start prototyping quick and simple, in page 17 she mentioned "If possible, try to do this entirely with temporary graphics that cost very little to make. This will save time and money and speed up the process." where as she is referring to software prototype in this section, and also many more example I recall like this such as page 212, Chaim Gingold mentioned to work fast, so that we can fail fast then restart fast and at last success fast, so really the idea behind is to just go fast at prototyping. With this in mind, I just started a very quick version of the game, in this version I really just make the player and the first zombie with Paint the classic Microsoft app, and a raw single colour floor. It at first looked something like this:

Then now I need to add something more to the game, so I referred back to the book to for example chapter 2 page 36-39 or also something like chapter 4 page 93 and in fact many more page in the book, mentioned about conflict and challenge. So I recalled back to most of the 2d platformer game I played before, I decided to add a sword for my player so that it can fight the zombie with conflict and challenge, and also this will allow the player to kill zombie and get points and upgrade, that was planned earlier in the pitch.

Then I added a few more platform and zombie, as well as make player and zombie collision to kill the player, the weapon hitbox to kill the zombie, and as well as just thickening the platform to make the area look more nonvoid.

I also added an air wall and the end of the wall way such that when player walk to the end they will get teleported to the next scene.

From here, I decided to and a new scene, and use this 1st scene as a practice platform for the player to get use to the jump, attack and hitbox.

In the 2nd scene I decided to start adding some challenge, make the zombie move, so I draw a new zombie type to make clearance between zombies, and also added the classic left right arrow to control the moving.

And then when I started playing with these new element, some problem that I did not realize earlier really started to pop up, that really reminds me of the workshop, prototyping is really a very iterative process, finding existing problem then solve and fix it.

Because now that the zombie walks, somethings I really have to jump over them then attack from behinds, then I found out that I can only attack on way, so from extent of that I changed the facing direction of the players and zombie, making them able to face the way they are walking towards.

Some codes, for scene 1 and 2 in order

Then I decided it is time to make the boss, so I added scene 3 for the boss fight. First I added an epic big zombie boss that just from the start already look different from the other normal zombie, and much bigger in size.

And then I added an enclosed arena to make the player fight the boss, I added pathfinding for the boss so it would chase the player around, and as it is a boss no way it can get one shot so I also added some hit point system to the boss, so that it needs 3 hits to kill the boss, challenging the player. But then when I play it, it turns out that the boss is too tall, and the player could never jump over it and just got killed every game after the scene started for a few second. So I added a blue red colour jump pill, so when the player touch the pill, they would eat it and jump a bit higher, enough to jump over the boss to not get cornered, but if the played walk too slow and let the boss eat it first, the boss will get a speed boots and it is a sure dead. From this game I really learn and understand about why platformers games like hollow knight make the big boss with all these jumping move (the first boss in HK the False Knight) it is because in the early stage of the game when player don't have dash or double jump yet, it is impossible to avoid the hitbox of such big enemy, so they designer need to make the boss jump around to create some counter play for the player. This is some valuable game design lesson I learnt.

Some code for scene 3.

Some reference of links for resources used,

The title of the game is "Save your family from Zombie".

The platformer elevator pitch is that the core game play mechanic is the player control a starting character and fight their way through each platform level while collecting points that can be use to level up their character through killing different zombie enemy in order to save other family members.

The image or concept art is something like:

(Designed and sold by DeadMotor on www.redbubble.com)

The control diagram is:

The 3 Unique selling points of my game is: 1. zombie, 2. double jump and 3. limited resources

first of all, I have some handmade zombie platform enemy, also I have a special double jump mechanic and also I have designed the game to have limited resource so that player and make meaningful option, or say relatively more meaningful option if they are not too game and playing with the mechanic.

The genre of the game is an action platformer game, and I think it would target audience that like action platformer and zombie.

Hello everyone! My name is Lok Ching Enoch Tam, or just call me Enoch Tam or Enoch by short. I'm currently studying Bachelor of Games and Interactive Environments (Game Design) in QUT.

My interests in game development for now is that I like to make good zombie game or farming game, I like zombie a lot because it is fun to play, and I also like farming a lot because it is very successful to farm your own things, my short vision in my game development path is to make a zombie game or a farming game of my own, or maybe a zombie farming games.