Skyler Chen

Now that the whole project is complete, I’ve been reflecting on it, especially how it could be improved.

From the results of the playtest, the playtesters seemed to like the visual style, but I think there’s still room for improvement. The scenes could definitely use some environmental details like fluttering petals animation or more varied platform elements, and also decorative items in the background. These could make the scenes look richer. Improving character animations, such as making enemy movement or interactions like pulling levers could make the world more lively.

Though from the surveys the playtesters are generous and give our mechanics and puzzles generally high score, the complexity of the game was still one major problem. It’s simply too easy to be fun, even I felt that way. It was a bit frustrating to be honest, but then again I had some time to dwell on it and came up with some big plans for it. First, expanding the sizes of the maps may allow for more interconnected puzzles. Then we could work on the platformer aspect of this game, like introducing moving platforms, more varied enemy behaviors, timed switches that require the players to act fast, and things that could hurt the Shadow, such as light, perhaps? Because the playtesters have commented that it felt like they could just use the Shadow throughout to complete some levels. There isn’t enough incentive to switch back to the player. This could also be improved by some dual-character puzzles that would put both characters to work and operate two levers, etc. I also brainstormed some new level mechanics for future development, including gravity-inversion levels and levels that separate the Shadow and the player into two perspectives. I also feel like I should probably integrate the story into these levels, since currently there’s not much story in this game. I also thought of adding collectables, such as hidden mementos that contain fragments of the story, and obtaining all of them could unlock a secret ending. These changes could potentially strengthen the relationship between story and gameplay, improve player engagement and make the game more challenging and fun, though further testing is definitely required.

Aside from these, there are also a few necessary quality-of-life improvements, such as adding sound feedback for character death, making shadow portals two-way, creating a level selection menu and so on.

Overall, this project provided me with many valuable insights with game design and game development. Despite the challenges, building this game with my team has been an incredibly rewarding and inspiring experience. I’d say we collaborated well and it was an enjoyable project. Given the chance, I would like to keep working on it in the future since I personally like it a lot.

We conducted our playtest during the Monday playtest party by inviting five classmates to try out our prototype. The environment was a little noisy and we unfortunately forgot to turn on the game’s sounds for the first two playtesters. Although even after fixing it, the music is still hard to hear. My role was the playtest conductor. I need to guide the participants with the playtest instructions and encouraging them to share their thoughts and opinions as they played. Overall, I think the playtest went smoothly. At first I felt a little embarrassed, but our classmates were kind and provided some valuable insights through both feedback and their in-game behavior.

Something they all praised on is the game’s visual style! Which I really appreciated since I spent a lot of time on it. And the biggest problem they had with our game was it was too simple. While the players seemed to like the core Shadow mechanics with, they found the puzzles were too lacking in challenges and didn’t feel rewarding. This aligned with my own concerns during development. It made me consider where the source of this problem lies. Is it due to the map sizes being too small, so that there is not enough space for more intertwined puzzles, or we had not fully explored the mechanics’ potential, or the mechanics themselves being not complicated enough, or my brain being not good enough for designing puzzles? Perhaps all of them, this is something I need to think about.

A few interesting things happened during the playtesting. One playtester failed extremely hard with the platform jumping and it turned out they rarely play games. This explained their struggles, though they still figured out the puzzles with no trouble. Another major issue is the playtesters easily forgot the controls, despite the game only using four interaction keys besides moving and jumping. One of them didn’t even find out the controls through the tutorial, which was really hilarious. They finished the prototype without realizing how to change perspectives. I realized the dialogues from the flower may have been too subtle. Adding a UI for the controls seems really necessary.

A game that caught my eye recently is Blue Prince, a roguelite puzzle game, two genres that I never imagined could be combined together. It also received a very high score of 92 on Metacritic, even higher than Split Fiction. I’m very curious about how its mechanics work and went to look for its playthroughs. After checking some of them out, which actually took longer time than I expected, I finally understood what it meant by combining rogue and puzzles.

This is a weird puzzle game with resource management and randomized puzzles. In this game, the player explores a 5×9 grid mansion by drawing rooms on a blueprint. Each grid is a room with a standalone mystery. When the player solved the puzzle and progresses, a random generation of room choices appears, letting the player choose which room they want to enter next. Basically, creating the map is also part of the puzzle because the main goal is to reach the other side of the mansion, a 46th room, and each room has a unique shape, as in the exits are not on all three sides, so eventually it may lead to a dead end (which is what happened most of the times). In a sense, this is similar to a maze, or a jigsaw puzzle.

Each playthrough resets with each day, since the player has a limited number of steps, aka the number of rooms they can visit, and this is part of the resource management mechanics of this game. Other resources include keys, gems and money which all serve their purposes and add elements of strategy to this game. There are a large number of room types which serve different functions, containing different items or different rules. The variety of rooms is really impressive, and as more and more room types get unlocked, the game just gets more complicated and interesting. The rogue mechanic of the game is also integrated nicely. As the player progresses through each day they gradually get permanent upgrades via collectibles, allowing them to enhance their step number, shop variety, etc, making them closer to forming the correct pathway to the end of the mansion. I feel like this game really starts to show its potential and depth after the first few hours.

This week, I focused on polishing the art assets and designing some later levels. I drew some decorative items and implemented them in the scenes so that the game looked less hollow. I also added some details to the platforms and backgrounds, making them look more varied.

In terms of level design, our other art team member built levels 2 and 3, while I focused on designing 4 and 5. For the later levels, we gradually introduced new mechanics which are movable boxes and shadow portals. I had some interesting ideas for the final level, a trap platform that would disappear as soon as the player stands on it, to encourage clever use of the Shadow mechanics. To avoid the player from jumping directly towards the platforms hidden in the ground, I added a box in front of the starting position so the player will have to interact with it first, and when they do, the trap will immediately activate, causing them to fall. It would require some quick reflexes, but since it’s just one swap, it shouldn’t be too hard. Though I did make it very obvious, so the players should notice something is off with this level if they observe the environment and think a bit. However, I still included a tutor flower to give the players a hint, since the purpose of this level is to introduce the players to a “stuntman” trick they can do with the Shadow. By always leaving a Shadow out there, the player can quickly swap with it and return to safety, if they find themselves in some sort of danger.

The flower dialogue system seemed very complicated at first but our programmer nailed it, although I struggled to understand how it worked and failed to add one for my new levels. Fortunately, we worked it out during the workshop and it was actually not very hard! I was then able to add new flowers with specific lines for each level. I also changed the fonts to a more artistic one, and worked on improving the dialogue texts to make them feel more immersive and less robotic.

In the final stages, we also decided to add a title and ending screen, which I made use of the images I made back from Assignment 2 and quickly cooked up two pictures for them. Adding these certainly makes the game feel more “complete”. Our programmer also added background music and walking sound effects which matched the game’s vibe well. He also tried to include a volume setting, though unfortunately it didn’t seem to work, so we had to delete it. After the final version is set, I recorded the final prototype’s playthrough for a personal record.

Our plan for this week is to complete the game’s core mechanics, including placing a shadow, swapping places with it and switching between the perspectives, as well as the basic platformer mechanics. We are also going to include invisible platforms and enemy ghosts in the tutorial level.

I had already completed most of the game’s visual art during Assignment 2. Since I have the good habit of drawing on different layers and keeping things tidy, I just need to convert these arts to sprites that can be used in GDevelop. It still took me some time since I need to reshape every piece of art and all, but overall the process went well. Although on hindsight, I still got the resolution wrong… I misused the units, took pixels for cm and the final sprites ended up too large. After I organized the work-in-progress art file, I sent it to our other artist so she could start working on the animations based on my sprites. Meanwhile the programmers began building the prototype in GDevelop.

For Assignment 3, we are going to form a group and choose someone’s game concept from Assignment 2 and make a prototype out of it. Our group formation went pretty smooth and we are very lucky that the skills of our team members are quite balanced. We have two members, including myself, from the animation major, and the other two have programming backgrounds, so our task allocation just seems straightforward. Naturally, us two animation students would be working on the game art and design, while the programmers will be implementing the mechanics in GDevelop.

After sharing our A2 assignments with each other, my team decided to choose my puzzle platformer idea, Shadowy Friend (I am quite honored!). We had a discussion during the workshop based on my one page and changed a few mechanics. For example, the “Shadow can transport through shadows” mechanic was renamed to “shadow portals” for clarity since the original one is a mouthful. We also decided to simplify its logic a bit since it seemed to cause some confusion, so instead of my original idea which is rotating lights against walls to cast shadow portals, the portal will now only be activated when there’s no light. My team members thought this would be more intuitive and easier to implement in GDevelop. The other mechanics are mainly left unchanged. I still felt they are a bit too few and wondered if we should add more, but since we haven’t really touched how to do puzzle mechanics in GDevelop and that meant the programmers will have to go through some work of figuring out how to do things themselves, we are just leaving them like this for now.

I finally completed the concept for my game Shadowy Friend. It is a puzzle platformer focusing on placing and swapping with a Shadow of the player.

I hand drew all the game elements in this assignment, mainly because I had a specific style in mind and I wanted to keep the design to it. I chose a quiet, dark color palette with soft gradients. It still took me some time to do the arts though it isn’t a complicated art style, but in the end, I liked how it supports the game’s lonely, dreamlike atmosphere.

I have included a sample level with labeled mechanics in my one sheet. In the final design, the player can leave behind a Shadow and swap positions with it at any time. I have added some more features to enrich the mechanics of both characters. There will be enemy ghosts that can only detect the player and spikes that only harm the player. The Shadow can pass through them unharmed and it can also walk through thin walls. It however cannot interact with objects, like boxes and levers. There are lamps that can be used to cast shadows, which can be used as portals for the Shadow, if there is an object blocking their light, like a wall for example. In the later levels, the player will need to rotate the lamp to create shadow portals at the correct locations in order to reach them. I also introduced a blue flower that acts as a tutorial guide to give information and hints to the player and help them understand new mechanics in each level.

In this project, the part that I am most satisfied with is the car selection system. At the opening selection scene, the player can use the left and right keys to switch and the selected car will be a scaled up a little as response. Then the player can press Enter to start the game with their choice of playstyle. I didn’t really give it too much thought when I designed the three types of cars, since I don’t really know much about racer games. My design concept was based on the mouse-frog-lizard cycle discussed in the lecture. I was thinking about the distinctive characteristics of these three animals and tried to translate them onto the racer cars. I imagined mice to be small and quick, and this is reflected quite literally in the mouse car. Frogs can perform far jumps, I thought it would be cool to let the frog car has a skill that allows it to teleport a short distance, but after considering how that would be like in game, I am uncertain it could work well, and to be honest I don’t really have an idea on how to implement it in GDevelop, so I had to resort to the more conservative method of using a speedup skill instead. For lizards, they can give up their tails when in danger, so I interpreted it as good survival ability, thus the invincibility skill.

After finishing the prototype, I reflected more on this design. The Mouse car is fast and small, which should suit players who enjoy fast-paced games and want an intense gaming experience that require quick reflexes.

The Frog car is slower and has a powerup ability which is ideal for players who prefer stability and want to choose when to speed up to dodge cars.

The last one, Lizard car, is also the most balanced choice. Players who want to survive as long as possible should pick this car since the moderate speed and a 3-second invincibility skill make it the safest option. Thus, three different playstyles are offered for the players to make their own strategic choices.

For this assignment, we were asked to come up with a game concept and make a one sheet and one page for it. My understanding is the one sheet is basically a poster for advertising the game, and the one page is like a design blueprint. When I brainstormed ideas for the game, I considered the three types of games we explored in this unit, which are platformers, asteroids shooters and top-down racers, however, I don’t usually play any of them. But then I thought about a type of platformers that I used to like a lot. Back in the Flash game era, I’ve played my share of 2D webpage puzzle platformer games, so I just decided to explore this idea.

One game that immediately came to my mind was a very old game called The Company of Myself. At the beginning of this semester, I thought of it in one of the in class discussions. It is a game I really liked. The art is very simple, the mechanics look very straightforward, yet as the game progresses, it is presented in a very profound and interesting way that really blew my mind when I first played it. In that game, the player can leave behind copies of himself that will repeat his exact actions in the previous loop when pressed a restart button, and the player can move on. These copies have a physical collision and can be interacted with by standing on them, etc. The player then needs to use this mechanic to solve time-based puzzles. I found this mechanic extremely smart and was amazed by how well it reflects the story.

I was inspired by this game and wanted to design a game with this kind of shadow-based mechanic, and thus came the idea of Shadowy Friend. Its mechanics are a lot simpler though, instead of recording past actions, I just let the player create one Shadow at a time. The player can swap places with the Shadow and also switch to its perspective. Each of them has distinct interactions with different objects and respective obstacles. For example, there will be platforms only the Shadow can step on and only the player can use a lever, etc. The two will collaborate to solve puzzles.

It does sound much less exciting, to be honest, and I’m not even sure if this mechanic will be possible to implement in GDevelop, but since the assignment is only about the concept, I just wanted to do it as my heart desires. Visually, I intend to use dark tone, minimalistic cartoon style. I’ve started drawing a sample level layout for the one page so that I can show how all the mechanics work. Hopefully I can refine this idea by next week.

This week I have added some features to the racer game. It’s the type of game with a top-down perspective, where the player controls the car on a reverse lane to switch among the four lanes to avoid the oncoming obstacles. After learning about player choices in gameplay in week 9’s lecture, I am tempted to try to apply it to this game. I intend to include three different car types with different features, so the players can make their strategic choices depending on their play style, instead of having to rely on hand speed.

During the development process, I found this one the hardest among the three projects in this unit, probably because it is the one that is the most similar to programming. I did find the arrays introduced this week very useful. My understanding is it can be used to handle random events, for example, spawning things randomly at multiple predetermined positions, which is certainly a nice trick to learn for making games. The tutorial also guided me through setting up the player and cars, simulating lane switching using tween which is very interesting, and implementing score based on the number of trees that passed by, which could be interpreted as the amount of time that the player persisted. I also added a feature of cars randomly switching lanes to increase the difficulty a little. They would flash for two seconds and then appear on a different lane so it is not completely unexpected.

To apply the player choice system inspired by what we learned in class, I designed three kinds of player cars with different features. There is the Mouse car, with higher speed and smaller size for easier dodging, the Lizard car which has moderate speed and a skill of entering invincibility for 4 seconds with an 8 second cooldown, and the Frog car with the lowest speed, but has a 3 second speedup and a cooldown of 5 seconds.

Road Racer

X Statement: A fast-paced top-down racer game where your car choice shapes your strategy — and every second counts.

In Road Racer, pick your car from three choices and dive into a chaotic reverse-lane traffic. Avoid obstacles, gather speed boosts and invincibility power-ups. Master sharp reflexes, smart lane swaps and survive the endless rush. How long can you stay on the road?

This game’s target demographics are for those who love fast, skill-driven games with simple controls, quick sessions, and players enjoy pursuing high scores in the challenges.

After playtesting, one playtester commented that they liked the bullet time mechanism. It made each round longer and easier for players that are not good at fast paced games. I personally think by creating the 15 enemies bullet time mechanism, it set a goal which makes the player more enticed to engage. For the enemies you destroyed, you could get a reward which is both recognition for your achievement but is also helpful for keeping you alive longer. And I think it could be an example of the dynamic difficulty adjustment in video games, introduced in week 3 lectures. When the game gets harder and there are too many asteroids for the player to destroy, it provides them a chance to slow down and catch up with the pace. Though I did get a useful suggestion to add a display of available activations of bullet time so it’s easier for the players to keep track of them, which should be easy to do by creating a variable.

Another thing to note is when a playtester played the prototype, they queried how they were dead so quickly. It was at that moment that I suddenly realized there is no response for when the player took damage! I should have added an animation of a flashing player ship to indicate they are being damaged. Otherwise, it is hard for the player to notice when they are hurt. I was too focused on adding unique features that I neglected the basics.

If I were to make multiple levels, I feel enemies able to actively attack could be a feature to gradually increase the difficulty, and even tracking missiles. There could also be items that change the bullet rate of the player, or stuff like mechanical toolboxes to replenish health, just some sustenance to make each playthrough longer.

I was also thinking if hit feedback would work well with this type of asteroids game. While sound effects have no issues, I fear if adding screen shake to every asteroid destroyed would be a disaster. Perhaps I could add it only when the explosions are triggered. Since the frequency of spawning explosive asteroids is lower, this should be more tolerable while giving more feedback to the players. Besides, adding shaking and being pushed back for when the player is in the explosion range should also be a good idea rather than just reducing their hp. I get the inspiration from the hit feedback in action games. When players destroy something and get sensory feedback, they could feel more satisfied.

Recently I have played a bit of Split Fiction and just happened to think of the core mechanics discussed in class.

Maybe it’s just me not having played enough games? But I feel like for most games, there is usually only one core mechanic throughout the whole game, which the developers would keep polishing until it’s fun and balanced enough for the players. While survival games and farming games also do have several elements, it’s different from what Hazelight is doing because in their games, those mechanics are more or less single-used. Making one core mechanic good is hard enough, but Split Fiction is like merging several games into one. For each level a brand new mechanic is introduced, and I must say up till now I have not found one that disappoints me. They are all very interesting and fit the theme very well. I could only imagine how much effort the devs put into this. One major advantage of this strategy is definitely freshness. The players could never get bored and everything feels so new and exciting all the time. I am always engaged and could feel myself entering the “flow state” when playing this game.

If I were to find a word to describe my experience playing this game, I would say “smooth”. The game controls themselves are extremely smooth and comfortable to play. I did not have to fear falling from just missing a small margin. The jumps and climbs are very generous. And just like the previous game, It Takes Two, which I loved very much, the transition between different sections is very smooth. For a game that has various perspectives and challenges and puzzles, I did not find it abrupt when the scene or task at hand suddenly changes to another. The challenges are also designed deliberately by changing the types of tasks rather than simply increasing the difficulty. The overall difficulty is coherent and relatively easy, even my friend and I, who don’t usually play action games, did not get stuck for too long, which I believe is a great choice for 2 players co-op game (more family-friendly!).

Over the week I have added some features to the game and tried to make sure I follow the advice of Fullerton to add features one at a time and test their impact in Chp 7.

First I added an enemy ship that will always target and fly towards the player. At first when the enemy ship appears, it would rush towards the player and fly out of the screen in one second because the speed is too fast. I suspected this should be a problem with the angle and after testing several times, it finally started to work as intended. I considered briefly if I should add shooting behavior to the enemy ship, but fear if it would make the game too hard.

Then I made a type of explosive asteroids that would explode when being hit by bullets or colliding with the player. Upon exploding, it would damage all the objects around it. I wanted it to be a mechanic that provide both danger and opportunity for the player. The implementation logic is for it to create an explosion range when being hit, dealing damage to nearby enemies and other asteroids, and also damage the player if they are in range. This explosion range will last for 2 seconds and disappear. This was the part where I struggled at the most when making this game. It seems simple but when I playtested it, I encountered a bug where the explosion would not be generated when the player collided with the explosive asteroid. It worked fine for the reaction with bullets so I was very confused and spent more than half an hour trying to add various conditions and actions and adjust their sequences. In the end, the problem turned out to be an event which deletes the explosion range as soon the player collides with it, making the deletion faster than the damage. I added this before I implemented a timer for the explosion range and completely forgot about it afterwards. Truly speechless with my stupidity 😅, but I guess it’s the same as programming, sometimes it’s just hard to identify your silly mistakes…

The last mechanic I added was bullet time. The time flow will be slower for 2 sec when the player pressed LShift. I created a variable that counts the number of objects the player destroyed. For every 15 objects destroyed, the player can enter 2 sec of bullet time once. The flow of time is multiplied by 0.5 during this time span and the player can have more leeway. After that, 15 is deducted from the variable so the player can accumulate the activation of bullet time. I wanted it to be a mechanic that gives some breathing room for fast-paced games like this, and I wanted the player to be able to use it as they wish, rather than constantly stressing about how many scores they wasted by not using the skill in time.

Bonkeroids

X statement: It is a multidirectional asteroid shooter with a retro vibe, while also combining the application of strategy through explosions and bullet time.

In Bonkeroids, you play as a small spaceship to traverse the dangerous universe. Dodge and shoot the deadly asteroids. Be careful of the explosive ones as they can be both be your aid and destruction. Make good of your power to slow down the flow of time, gained by destroying the asteroids, and survive as long as possible.

This game’s target demographics are for those who enjoy retro-style arcade games with a mix of strategy, and also players who enjoy pursuing high scores in the challenges that require quick wit and precision.

To be frank, I’ve never been a huge fan of platformers. Having never played any classics including Mario, I was unsure how to design my own. So I decided to rely on what I learned in this unit. In the lecture, I learned the story of how Mario’s jumping system was continuously tweaked by the developers until it was perfect and that made it one of the greatest successes in platformers. In Chapter 7 of the textbook “Game Design Workshop”, the author encourages developers to focus on one mechanic in the prototype until it feels satisfying and to prioritize core mechanics over features. If I were to pick a core mechanic for a platformer, it will certainly be movement and jumping.

I spent considerable time adjusting behavior parameters to improve the player’s movement. The default settings felt slow and unresponsive so I made numerous small adjustments until the cat’s movement and jumping felt smooth and natural. However, these changes also brought out new problems with the platform heights and I had to reposition every one of them through repeated testing. I had to test and tweak and follow this process repeatedly. Honestly, this part was a little frustrating.

Another challenge was that when timing wasn’t perfect, the cat’s head would occasionally bump into the overhead platform, making things more frustrating. I had to adjust the platform placements multiple times to prevent such collisions to reach a relatively smooth experience, though it is still not perfect. I think that's a problem with my level design. Maybe next time I should look for some references to see how others do it, or an alternative way may be to modify the platform's collision size. I could keep only the upper half for players to land and remove the lower half, perhaps.

Additionally, my attempt to do the game art was a stupid move. Apparently, I know nothing about resolutions and DPI. When I tried to replace the default sprites with mine, it broke the game. Things were not appearing as they should. After searching for some tutorials, I managed to make it work in the end (still looked bad though but it will have to do). I found this youtube video quite clear and useful.

In hindsight, I would spend more time in planning to avoid incessant adjustments later, especially on level design and assets. I was wondering if adding randomization could be more fun, such as randomizing the surprises from breaking the pots, or even the location of the keys, but that would be too complicated for now. The process of making this platformer made me realize even small matter that seemed trivia can have great impacts on the player’s experience. It really has given me a much deeper appreciation for the meticulousness behind game design.

Reference:

Fullerton, T. (2019). Game design workshop : a playcentric approach to creating innovative games. Crc Press.

During this week, I have added some features to the game. The gameplay is for the cat to jump on the shelves in the kitchen to find the key to proceed to the next level. I have included health and enemies. The cat can be attacked by certain mice holding weapons and lose the game if its hp is reduced to zero. Besides that, I also thought of several other small mechanics.

The player can break pots and there will be surprises in them. For example, a cucumber might pop up and if the cat is in contact with it, it will jump thrice higher that enables it to reach previously inaccessible platforms. This is inspired by the fact that cats are scared by cucumbers. There are also dangers in the pots because I feel adding uncertainty could make it more challenging. Onion may come out of a broken pot and reduces the player’s hp.

There are platforms that are fragile and a slightly different sprite will be used for them. Jumping on these platforms will cause them to collapse so the player needs to move fast. If they fail, the player will have to restart this level by pressing R.

There are two types of mice. One is not harmful and will drop food which replenishes health, but it moves faster than the player. The other carries a fork which will reduce the player’s hp if they collide with it.

The key is not always in plain sight. It may be hidden inside a pot or even carried around by a mouse. So exploration is encouraged.

After I finished the prototype and played it myself, I wondered if it was too easy and unexciting, so I set the jump heights just barely to reach the platforms to add some difficulty. However, the two playtesters I found both expressed frustration. Players do not like to keep failing jumps by just a small margin. I listened to their feedback and made the jump height more forgiving. In the end, even I agreed the new settings felt much more comfortable.

The playtesters also showed confusion when they intuitively tried to use WASD to move while the default keys for GDevelop is UDLR. I have to admit this also confused me when I first used it. As a result, I added a picture showing the controls of the prototype at the beginning. This process of playtesting has given me a deeper understanding of the playercentric approach studied in class and made me better appreciate its significance.