gamedevelopmenjournal

[gamedevelopmenjournal]

Week 13: Postmortem

I think it was very pleasant to cooperate with others in this group assignment. My group members were all very tolerant and patient when communicating with me. I think this was a perfect experience, but there were also many personal ideas that I couldn't realise. Since I have been making animations most of the time, I feel that I am a little disconnected from the core content development of the game. This is reflected in many aspects. For example, I don't know how to correctly import my animation into the game in the form of a spirit file, resulting in the animation I painstakingly produced being presented in the game in a very vague form in the end. For instance, I hardly participated in the implementation of the core system of the game and gameplay. Despite having several previous games as practice, my proficiency in GDevelop is still far inferior to that of the other three classmates in the group. Moreover, my update speed is very slow. Within two weeks, I can hardly produce enough art content to support the entire game. Most of the animations, backgrounds and art materials are free spirit. This makes me feel that I have contributed almost nothing to this game. It was only after I finished drawing the animation that I found there was a serious colour difference, which made it impossible to separate the enemies from the background. This problem is particularly reflected in the bat.

If I had finished a sample art earlier and compared it with the game background in the game, the final visual effect might have been much better. Moreover, if I had finished earlier, I think others would have had more time to refine the enemy's action. Although I mentioned in the questionnaire that the current dashing spell makes the players' process of clearing levels overly simple, during the playtest, once players master the gameplay of sprinting in the air, they almost all use sprinting from the very beginning of the game and do not land until the end of the first chapter. However, I think the behaviour pattern of the enemies and monsters being single and posing no threat to the players at all is also one of the reasons why clearing the game becomes very simple.

[gamedevelopmenjournal]

Week 12: Iteration and Changes

At the end of last week, we published our game, so we can sought out more people to conduct playtests online and fill out surveys and questionnaires.

I invited my friends to experience our game. At this time, the game had been partially modified based on the feedback collected at the playtest party last week.

[gamedevelopmenjournal]

Week 11: Playtest Party and Reflection

Since I spent most of my time working on animation-related content, I wasn't very familiar with the actual gameplay of the game. Therefore, I participated in the playtest of our game at the playtest party this week.

Just clearing the prototype content of the first chapter took me almost an entire class. After I finished, the remaining time we had was only enough to find one player to do the playtest. After that, I carefully filled out the survey and questionnaire and truthfully answered my feelings on the spot. In the workshop before, I remember we had a problem. Probably when the player held 'Shift' to draw runes, the character would float in mid-air and stay there. Finally, Potato's suggestion was that this could be directly retained in the game as a feature in line with the game style (after all, we are mages). It's quite reasonable that the character can fly. For this, I drew a floating animation of the character floating and casting spells. But I didn't expect that in the end we would turn this feature into a unique gameplay.

Besides, I feel that the biggest problem related to my work is that the resolution of the animated spirit uploaded to the game is very low. Many details are so blurry that they cannot be seen clearly. I guess it might be because the canvas size I used on the iPad was very low (because it was a pixel art), and when importing the game, it couldn't be scaled proportionally as a vector graphic but was directly enlarged according to the size of the computer screen.

[gamedevelopmenjournal]

◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆◆

Assets📕⭐:

Magic book (not adopted in the game).

We originally intended to create content similar to an album in the game, allowing players to check the types of magic they possess at any time during the game. I drew this magic book as the UI for this function. It can be placed in the upper left corner. When the player clicks, an animation of the book flipping can be played and then jump to the interface of the rune directory. However, we didn't have enough time to produce a perfect interface, and I also failed to complete the relevant animation. Moreover, the current prototype only has two runes. Therefore, instead, we have created a relatively simpler feature. When players hold down the P key, the drawing sequence and instructions of the two runes will pop up.

The Magic Portal

Placed at the end of the chapter map, it is used to teleport players to the next chapter and is planned to be the birth point of the second chapter. Players can activate a portal by interact it with any magic. Below are the activation animation of the portal, its inactivated state, and the loop animation after activation.

✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦✦

Enemy🗡🗡🗡💔↓：

Crocodile

This is a trap enemy. Since some people called this Scene the "Water Scene" when everyone was discussing the first chapter together, my initial idea was to add some lotus leaves on the water surface as a platform, and players needed to step on the lotus leaves to jump over the water. Among a pile of lotus leaves that can be stepped on, one or two such crocodiles will be mixed in. In standby mode, they are basically exactly the same as lotus leaves. When the player accidentally steps on them, they will be eaten. This can add some fun to the game and increase the difficulty of clearing it. But this idea was not realized in time in the end.

Bat

It falls at the bottom of platforms in some dark areas. When the player approaches, it suddenly flies down and attacks the player, causing collision damage.

Vine

When the player is not approaching, the vine will only lie in wait underground. When the player gets close, it will sprout a small bud, stay for about one second, then grow rapidly to whip the player, and then return to the initial state again.

When the vine finishes a whipping, it will stay on the ground for one second. Players can choose to clear it with magic.

═✧═✧═✧═✧═✧═✧═✧═✧═✧═✧═✧═✧═✧═✧═✧═✧═✧═✧═

Motion✨💫🌟：

Floating Magic

Some problems emerged during the development of the game. When the character used magic, he would suddenly bounce into the air and remain stationary throughout the entire process of the player drawing runes. So the other members of the group asked me to draw an animation of a character floating to make up for this problem. This latter feature has become an important gameplay element in the game.

The following animation is done based on the existing free character Sprite. I added the floating effect and corresponding modifications to the character's casting animation.

[gamedevelopmenjournal]

Assignment 3 Development Progress

This week marked the beginning of Assignment 3, and I formed a team with three other classmates. We exchanged contact details and created a Discord group to facilitate communication and file sharing. It was a smooth and friendly process, and everyone seemed excited to collaborate.

During class, we shared and discussed our OneSheet and OnePage assignments. Everyone has a good Onesheet and OnePage outcome and a good elevator pitch, and we decide to vote to find out the game we want to work on. I vote for "Whole" because I think it has a really rich gameplay, which I think integrates a lot of game elements.

“Whole” is a 2D Metroidvania-style platformer that combines exploration with Pattern Drawing Mechanics. In this game, the player draws specific shapes or symbols on the screen to activate different abilities—like casting a fireball, dashing, applying buffs, or even using a grappling hook similar to the one in Terraria.

In the end, we decided to work on it with the advice from our tutor. We created a Google document to summarise what we hope this game prototype will include and the content that everyone wants to be responsible for.

Since I really enjoyed making different enemies and animating them when making my last game 'Rotten Kitchen ', and I think this is what I'm best at, I still want to continue working on enemy design and animations in this group project.

[gamedevelopmenjournal]

A2-Final Design

[gamedevelopmenjournal]

Racing Post-Mortem

[gamedevelopmenjournal]

Week8 Racing Game Development:

[gamedevelopmenjournal]

Week 7 Elevator Pitching:

My game Rotten Kitchen is a 2d top-down shooting game. The selling point of the game is the diverse types of enemies and props. Players move and shoot by using the mouse and computer buttons. The goal of the game is to avoid as many enemies as possible or defeat them with props to survive longer. As time goes by, the enemies in the game will become more complex, with more attack methods and bullet comments emerging, making the game more difficult.

[gamedevelopmenjournal]

Week 7 Asteroid Game Postmortem: Playtest for "Rotten Kitchen"

This week, I completed the prototype production of "Rotten Kitchen", invited a friend of mine to try it out, and recorded her feelings about this game. After that, I asked her some questions. The following is the record of this Playtest:

------------------------------------------------------------------------------

Q: What is your favourite part about this game?

A: It feels great when the bullet hits the enemy and the enemy explodes. I like the way these vegetables split, but I think that a bit more of the impact could be added. And I also enjoy the animations, it's really cute.

Q: Which part of the game makes you feel uncomfortable？

A: I think the control method of the game still needs to improve; the feeling of moving is awful. Many times, the vegetables are nearly struck on my face, yet I was uncertain how to move back. It feels that the character is not very flexible.

Also bullets and health bars are not very clearly visible in the game. Especially the health bar, sometimes I don't even notice that I'm losing health at all.

Q: What else do you think the game can be improved？

A: Maybe add more animations or effects on the character after it gets hurt. Or increasing the size of the health bar. So, when the character gets hurt, I can feel it more intuitively.

If possible, I hope the movement mode of the game can become the full directional walking, or make the character turn a little faster. I hope the feel of the game becomes more controllable. Sometimes I feel as if I can't control my character at all and can only press randomly.

------------------------------------------------------------------------------

At present, the biggest problem of the game lies in the fact that the movement mode provides a very poor experience for players. Since all the movements in the game are based on physics, the initial movement of the character is very slow, and it is too fast after moving. It is almost inevitable that players will lose health by colliding with the surrounding debris after trying to accelerate to avoid enemies. So players will feel very helpless because it seems that no matter what they do, they can't survive in this game.

[gamedevelopmenjournal]

Week 6 Asteroid Development:

This week, I completed the basic content of 'Rotten Kitchen ', including：

The health system: Character has four lives at the beginning and loses lives after being hit by enemies.

Rotational thrust-based movement and fire bullets: Press and hold the up arrow to fire cream, and use the' W', ' A', and 'D' keys for rotational movement.

After being hit, the enemies will split and scatter in all directions based on physics.

Animations for the enemies and the health bars.

Animation for the health bar:

Animation for the enemies:

Game screenshot：

But at present, there are still many areas in the game that need improvement. The most important scoring system was not completed. Furthermore, since the bullets fired by the character will remain if they don't hit the enemies, as the number of bullets fired by the character increases, no matter how many enemies there are on the screen, they will be cleared quickly. So far, only two types of vegetable monsters have been produced. The mushroom monster that was previously envisioned to fire bullets has not yet been made.

[gamedevelopmenjournal]

Week 5 Asteroid Game Pitch: "Rotten Kitchen"

This week, I will pitch the game idea of 'Rotten Kitchen'.

This game continues the format of the classic Asteroids game. Players must control the Tomato Fairy to fire cream to smash the rotten vegetable monsters in the kitchen. Just like the classic asteroid game, players can only move by pressing the 'W' key, while pressing the 'A' and 'D' keys can only make players rotate left or right.

This game has no end. The primary goal of players is to ensure their own survival and kill as many vegetable monsters as possible to win a higher score. As time goes by, more vegetable monsters of different styles will be spawned in the kitchen, making it more difficult for players to survive.

The main selling points of this game are:

A wide variety of vegetable monsters.

The game features a variety of rotten vegetable characters. Each vegetable moves uniquely based on its real-world weight and size. For example, a rotten tomato moves quickly when hit, breaks into multiple pieces, and scatters widely, increasing the chance of hitting the player. In contrast, the pumpkin is heavy and barely moves when struck. It blocks the player's path and causes collision damage. When destroyed, it splits into two pieces, each dropping two pumpkin seeds.

Simulate real physical movements.

This game features the screen wrapping of the classic Asteroids game, where the characters simulate real-world collisions and accelerations. Players need to think calmly about how to move to avoid rotten vegetables and their broken pieces.

There is no end. Players try to reach higher scores through skills.

Contact detail:

Student Number: n11209194

Email: shan.yunhan@connect.qut.edu.au

[gamedevelopmenjournal]

Week4: Platformer Development

This week I've read through chapters 3-4 of the Game Design Workshop and focused on realising the main pitching content within the Gdeveloper. I didn't plan to draw my own character sprits or tiles due to time constraints but chose to use the free resources available in the store. So the current outcome looks very different from what was described in pitching. But the main way of moving and the drilling system I wanted to implement were basically realised. In this iteration, the food is strawberries, and the enemy is green pigs. Players need to win the game by following a planned route from the start point of the map to the endpoint. There is a time count representing the satiation will count down for the duration of the game, and the character will die when the countdown ends. Strawberry collection increases the counter time. There were some landscapes (platforms) that the player couldn't cross easily by jumping. Such as the higher stage in front of the starting point. And also, the cliff after the first green pig enemy. Players could use the box and the underground tunnels to get over it.

Problem Summary：

Pushing Boxes:

The biggest difficulty was that the idea of the character moving the boxes and letting the enemies eat food was difficult to achieve.

During last week's exploration of Gdeveloper I learned how to get a character to pick up an object. The idea is to add to the event that when the character collides with a pickable item, put the target item on the character. However, the problem is that the target item from last week's practice was not set as a platform. Therefore, the character could overlap with the item and pick it up.

But this week, I want the player to pick up a box that allows him to step on it. Then I have to set the box to a platform that the player couldn't pass through. Although I've set “ignore objects that are touching each other on their edge but are not overlapping” to “No”. It still couldn't get a satisfying result. For this reason, I have to give up letting the player pick the box up and push the box forward instead.

Enemy System:

Another hard problem is making the enemy (the green pig) move towards the nearest food, eat the food and then run away from the player. The main problem of this section is hard to make a specific pig to eat the nearest strawberries around it.

My first idea is to make a separate layer, then place some tiles as the checkpoints, at a small distance in front of the green pig. Then hide this layer. Therefore, as the player moves along a certain pathway. They have to collide with those invisible checkpoints, and the green pig will move to the strawberries within a distance of 200 pixels.

But the green pigs in this whole map are sharing the same resources, as same as the checkpoint tile and strawberries. After the player collides with the first invisible checkpoint, all the green pigs in this map will move to their nearest strawberries and eat them.

Although I've used up many times to search for the solution, it still can't be nicely solved. So, I just changed the enemy track to the character. In most of the conditions, the food is set in between the enemy and the character. Then as the enemy moves forward, it will collide with the strawberries. Then the strawberries will be deleted.

The current prototype flow is as follows: 1. When the game starts, the player needs to jump onto a higher platform by pushing the box and stepping on it. 2. Meet the first enemy. Enter the underground tunnel to avoid the enemy. 3. Stopped by a cliff. Players have to enter the tunnel and then climb up from the dirt background. 4. Kill the enemy that blocks the entrance to the tunnel with the box on the platform and reaches the destination.

[gamedevelopmenjournal]

Week2: Game Pitching for the 'Rat Bedroom Adventure'

Full game pitching:

Rat Bedroom Adventure:

In this game, players need to control a rat across platforms from one side of a bedroom to reach a rat hole located on the other side of the bedroom. In this process, players need to collect food scattered on platforms before the enemy to maintain their satiation. Players can manipulate the rat to move left and right, jump, and drag boxes around them to jump onto higher platforms. Players can press the down bottom to enter the gap under the passable ground tile to elude their enemies.

There is a hunger bar in the upper left corner of the screen that will slowly decrease over time, and the game will fail when the last bit of satiety is gone. Food can be found on various platforms on the map, and players can eat food to fill their hunger bar. There are often cockroaches near food. When the cockroaches come within range of the camera, they will quickly run to the food and eat it. When there is no food in the surrounding environment, the cockroach will bite the player and steal a part of the satiety from the hunger bar. The map is distributed with multiple passable ground tiles that are different from normal ground tiles in colour. Play could enter the underground tunnel through the passable ground tiles. Cockroaches couldn't get into the underground tunnel.

My thinking progress:

This week I attended the lecture and read the chapter7-8 of the Game Design Workshop. I've learnt more about the game system and prototyping.

From my understanding of the book content, a prototype is mainly about the iterating of a basic game rule, and it will keep changing.    So I want to keep the prototype as simple as possible.    I hope there will only be one clear thing to do for the player.  Then they could have a really clear feeling of this game prototype during the playtest.

I want to make a platform game that allows players to wander around and collect objects to reach the next level.

In the beginning, I only hope there will be a character that can jump and move to climb the platforms and reach the destination.    But in the studio, we have been asked to consider how to make our game different to Mario. From the Chapter 2 content and the lecture, I also learnt that a complex system would improve the game experience.

The current system of my game is simply to move from one place to another. To make this more challenging, I thought it would be nice to have some obstacles or enemies on the platform so that the player would have to do more than just hold the move button.    Because there are enemies, then the character will have a health bar in most of these situations. But it still can't be any different from another platform game.

I think there must be a unique moving system that different to just jumping and moving, or a key object that is related to the whole gaming process (such as the Totem in the game Monument Valley).

My first idea about this game is to let the player control a rat and have an adventure in a bedroom. Rats usually love to hide in small gaps to avoid being caught by anyone. So I thought it would be fun to add an ability that allows players to go underground. It also makes the game different.

I added some ground tiles that are slightly different to the normal ground tiles. These tiles could be passed through by the player as they press the 'down bottom'. This allows them to access the underground tunnels that are out of camera range when they are standing on the ground.

To make this ability has a meaning in the game, I decided to use it as a way to avoid enemies.

That's all I thought about the game prototype.

Exploring to Gdeveloper:

The following GIF only shows my exploration for the functions in Gdeveloper. It doesn't relate to the game prototypes or the final game outcomes. I just want to try to apply a few of the basic abilities that I want the character to have in the prototype. It includes the basic moves and jumps, air jump, passable platform and pick-up objects.

[gamedevelopmenjournal]

Week1: About Me

Hello to everyone who is reading this journal. I'm a third-year student who is learning 3D animation as my major. Now I'm here to begin my study of game design. The reason that brings me to this class is only because I enjoy the immersive experience brought by games so much, that I hope I can make my own game someday.

As learning animation, sometimes I feel the immersion that animation can bring to people in some respects is limited. Sometimes I feel what I'm doing is mostly setting a stage with a set of characters. Then a lot of work goes into drawing the details of every move they make on this stage. Although this process was also exciting, I could somehow feel outside of the story I was portraying by myself. I think it will be the same feeling for my audiences who are willing to see my works and give me feedback.

 So I really want to explore a second way to apply my creative skills by studying game design. At the beginning of this week, I read chapters 1-2 of the Game Design Workshop. The book argues that games are a different form of entertainment from music and movies because they are played through the active participation of the player. I was encouraged by this description. I love games with unique imagery, and I just played through the Ori and the Blind Forest half a year ago. I still remember the first time I entered this game, its beautiful environment and music gave me a huge impression. The feeling brought by controlling a character to reach the end of a story after a series of challenges is completely different from the feeling brought by watching a movie.

I hope I can be closer to my aim with the exclusive learning opportunities within school. I really looking forward to having a deeper understanding of game theories, learning different game types, and exploring the systems behind every impressive game design.  Besides all of these, I also hope I can enjoy the experience of communicating with my peers through class activities and playtests. 

In the following few weeks, I hope I can go through the development of a feasible prototype with the basic tools available in Developer through studios and self-learning. Then I expect to apply this knowledge to develop a complex game in the future.