florin@fogdd.com

A Leaf To Sharp – and the delicate balance of variables (game design process)

This one started with a newsletter from my Wireframe magazine subscription – a contest for the Fuze Programming Language on the Nintendo Switch. I decided to prototype a mechanic I was using for implementing another game that gave the game a partial feeling of a turned-based strategy.

A tree in the middle of the screen, attacked by all sorts of creatures coming at it from all sides, and the ability to shoot leaves for defense. The enemies would advance only when the player made a move and attacked with a leaf – this should also say something about the hero that creates the villain.

To give the game a kick, in my initial design, I decided to add enemies with different abilities, as well as weapons that behaved differently. The progression would be linear and new enemies and weapons would be added over time – after 50, 100, 150, etc. kills. But this would be better off as a short prototype to showcase all the features within minutes (or perhaps seconds) of gameplay. The result was that you get all the enemy types at once, and only one type of weapon.

Control Variation

There’s really nothing that complicated about controlling the character. You need a stick and a button. Due to the switch’s capability of playing single handed – either stick or any button would work. The action was mapped to the “A” button and the “ZR” one. Depending on the player’s style, they would have the option to play either way. The stick would control the position of the weapon which would rotate around the player and the action button would fire in that specific direction.

In the first version, the location of the leaf (which was at the time represented by an actual sword) would map exactly to the location of the stick (even if that was on the 0.25, 0.5). This led to the sword be in the middle sometimes. The player would shoot the sword from there, but because it had no direction, it would not move at all. The enemies would advance, and the player would have no clue what happened.

This meant I had to restrict the position of the weapon. When the game started, the weapon pops at location (0, 1) to give the player a starting direction. Rotating the weapon was now only available for values of the stick which resulted in a vector with the magnitude over 0.9. This let the sword always be on the edge of the player, but at the same time give them some flexibility compared to the fixed magnitude of 1. The weapon is never in the center, and something always happens when the player hits action.

A weapon you cannot control

The problem with the weapon rotation came as something surprising, as well as quite confusing. The leaf in the final game has some minor undulations. But the sword I used initially was more curved. This resulted in a weird player perception, where the he would point the sword in a certain direction, but feel like it went completely a different way. I drew a line from the center of the tree to indicate the direction better, which seemed to alleviate the problem a little. But that did not look very aesthetic so I replaced the sprite with something that was straighter, then offset the rotation by 20 degrees. Even now, I am not completely sure the perception of the player matches the actual direction calculations in the game.

Enemies, attack variations

Spawning the first few enemies, should place them in clear visual range, otherwise the player might not know what to do and who to fight. Then, with every leaf that was shot, they will advance toward the player. At first, all the sprites of the game were double in size, which left room for very few enemies to be on the screen at once. The leaf would disappear after hitting just one enemy once, leaving the player with a very tedious task of killing one enemy at a time.

I asked someone to play the game for testing. It was obviously tedious and seemed like nothing much happened on screen – at one point, there would be no enemies on the screen and the player would be very much lost. While I did not care much to listen to the actual feedback (because “it’s kinda boring” is not as helpful as you might think), I did analyze the way he was playing and his reactions. These led me to make the sprites half the size, change the weapon to hit more enemies, add a larger number of total enemies, make enemies spawn more often, and adjust their speed accordingly.

Some few changes created a completely different gameplay experience, where the game no longer feels like a tactical 1 on 1 battle, but like slaughtering hordes of enemies at a time. I extrapolated those as variables to help adjust difficulty – if I were to expand this on multiple levels, I would just have to tweak the number of enemies, their spawn rate, and speed. However, doing so, created an unexpected side effect.

The game should transmit a feeling

If you are watching any of my recordings of the gameplay, and you speed it up a little, focusing your vision to the center of the screen, you will suddenly start to notice an interesting illusion, similar to those “star trips” simulators. https://i.pinimg.com/originals/25/76/13/2576133b59150ec69567e1d57d888c9a.gif

I did not make that happen on purpose, but I decided to capitalize on the effect and even try to amplify it. That’s how that big moon ended up in the middle – it’s supposed to attract your attention to the center, at all times. The bushes on the sides were initially placed there to move toward the player gradually, giving a feeling of amplified claustrophobia, while obfuscating most enemies on screen.

But something went completely wrong, and scaling the bushes proportionally with the numbers of enemies did not turn up to satisfy the effects I was looking for. But they make for a nice frame, and create an immersive experience for the player, reasons why they still exist in the current version.

A final word on Fuze

Fuze seems a bit like programming with Love/Lua. It is a lower-level language, than what I am used to with Unity and C#. There are still a lot of bugs with the editor (even with selecting line), features that do not come out of the box (dynamic arrays or lists, multiple code files), and the overall experience of writing the code on a relatively small screen (even with physical keyboard support) is not that satisfying.

I would rather do fast prototyping, and Unity is the better choice for that. Had it not been for such tedious code management, I would have definitely added more features, including VFX, multiple levels, and maybe even a variety of weapons. But for now, I am left to say the game is just “good enough” for its purpose.

Extract from Wireframe Magazine