[Devlog] Vertical slice and first playtest feedback

[celes]

Hi everyone! After an intense first phase of development where the base for the game's engine was set and some initial amount of content added, we are starting the fun(!?) part of development that consists of making sure the game is actually fun to play! :D

A Steam Playtest Build
For people to play the game, the first step was to create a playtest build for the game. I'll save you the trouble of showing you the horrors of the steam back-end (unless you want me to ), but the end result is that the game can now be installed on Steam and I can issue keys for it:

image.png (942.31 KiB) Viewed 43 times

Steam has various ways of letting people play your game before it is out for sale, but out of them, the playtest version is my favourite. A playtest build creates a separate version of the game, different from the "main" game (the one people can buy) and the demo (the one people get for free).

For small indie studios such as ours, the main benefit of a playtest build is that people can receive a free key for the playtest version but that does not impact their ability to show support by purchasing the game once it's out and, much more importantly, leaving one of the first 10 reviews! Steam does not consider reviews for games that were redeemed via key (free or otherwise), so it's very important that our most diehard followers are accounted for.

Initial feedback
After the playtest build was out, the plan was to share this widely and obtain lots of feedback. I set up a way to collect feedback through polls and an analytics server to receive gameplay statistics (only shared with user's consent!). This time, unlike Carrot Survivors, we don't ask for consent at the start of the game and instead we do it at the end of the run, before the data is about to be sent. I feel that is less distracting for people and I don't care about the small amount of info we may lose from people force-quitting the game at this stage.

But before any widespread sharing, I decided it was a good idea to let some of our trusty insiders try first to rule out any obvious issues, and oh god did they find issues... ^^' I was able to fill the backlog from just a few playtest sessions.

My impressions from those first playtest sessions are that the game combat hits the spot and people generally have fun smacking enemies. The innermost gameplay loop looks solid enough for the time being, with some important things to improve that can probably wait.

Almost all of the constructive/negative feedback I received was about things relating to the outer gameplay loops: The goal of game and its mechanics are not clear enough. Depending on the kind of player, this manifests in different ways: Some act lost but persist, others get bored and quit. Everyone is confused about the core mechanics, and while I can't expect people to get it all during a first run, it was a bit too much "being lost" even for that. Although being honest, I'd much rather have this problem than the opposite: A game with perfect UX design where players just don't find the finer grained interactions interesting and fun is a much tougher beast to address...

Either way, this is a lesson I already should've known from Carrot Survivors and the fact it happened means I know what to do: UX, UX and UX.

Clearer objectives
Knowing (or at least, thinking I knew) what I had to do, it was work time. The first thing I noticed was the game has a panel with objectives at the top left, but I bet even with all the red arrows I added here you folks won't pay attention to it... It's almost like the thing is invisible! But I'm not blaming anyone, there's a lot going on on screen at once and it's very unintuitive how obvious some things feel when you are the one developing them vs how much people notice them, especially on a first playthrough:

image.png (1.72 MiB) Viewed 43 times

The goal here was to make the higher level goals clearer. This turned into a couple of addressable improvements. The first one being this little UI animation, putting the current objective front and center every time the quest objective changed:

untitled.gif (4.57 MiB) Viewed 43 times

The second one, was adding quest markers. They show up at the edges of the screen, telling you where you need to go. I added them for all mini-quests as well as in the general overworld, pointing you at the next fort:

untitled2.gif (7.21 MiB) Viewed 41 times

In-game controls
Another thing that was obvious to me is that everybody jumped right into the game, life is too short to read the little markup table I wrote with the controls, so having an on-screen display for the game's controls for your current device would improve player experience a lot.

And this is what I did! Kenney provided the assets, this time I won't bother with pixel-art icons, I feel players don't care if the style of the button prompts doesn't match the style of the game. This is how it looks now:

image.png (1.35 MiB) Viewed 41 times

The box is situational, showing only the controls that matter for that particular part of the game and distinguishes between keyboard and gamepad based on the last detected input device.

Enemy aggressiveness

The one thing about the combat that almost everyone pointed out is that enemies outside bossfights didn't seem to do much. It was fun to smack them, until you realized they were not doing much fighting back.

What was going on, actually, is that enemies had a hidden energy gauge they had to fill before they could attack. That guage started filling up from zero when the player was nearby, and took between 2 and 5 seconds depending on the enemy. Two seconds is an eternity, even with tons of enemies on screen, and what's worse: it resets every time you hit the enemy.

This was inspired by how the small fry works in musou games. Have you ever been hit by a random bokoblin in Hyrule Warriors? Me neither. But that didn't feel right here given our style of game, I wanted a bit more challenge so enemies need to fight back.

The first fix for this was quite simple: The attack energy gauge for enemies starts full, not empty. So once you're in range, they start attacking immediately!

aggro.gif (4.57 MiB) Viewed 41 times

This didn't quite fix it, because when you approached a large enemy mob, they all attacked at the same time, launching a massive combined attack that killed you in one hit. To rate limit that a bit, I added a scene-global system: A fuel gauge that fills up over time. Each enemy attack consumes fuel from that gauge, and there's only enough fuel for about 3 or 4 attacks to start at the same time. That way, you don't get bombarded with enemies during the late game, but early game fights become a lot more challenging where you can notice enemies actually fighting back.

This is the kind of change that required rebalancing some things. After some major tweaks to enemy spawn rates and damages, I'm quite satisfied with the end result ^^

Misc. Improvements

There's been quite a bit more going on! Here's a few more interesting things that have been going on!

• Mark all fort doors with a "danger" sign to distinguish them from regular buildings
• Display an animation when you don't have enough money to do something
• Add a little teleporter at the end of fort quests that takes you to the fort's exit to avoid backtracking
• Add UI scale and world zoom sliders in the settings menu. Adding this one was easy, because I had planned for this and already had a slider for this in my dev tools. It was just a matter of exposing it. Design with UI scaling in mind from the start! Or you will suffer.
• Added lights to map events so that they're visible during the night

Closing

This is all for now, but tune in for the next devlog and let me know if you're interested in getting a playtest key! Next batch will be handed out really soon(TM) and I'm looking for about 2-3 more people to try the game for the first time.

Those first time experiences turned out to be super valuable which is why I'm going to be slowly opening up the playtest. Lesson learned!