Environmental Station Alpha - post-release thoughts

Environmental Station Alpha, the adventure action platformer I've been working on for the past 3 years, was released in April. It's been a very exciting and educative experience to commercially release a game for the first time, but what has interested me most has been the player feedback to the game's design. Now that it's been a month since the release, I wanted to gather some thoughts about the design decisions of the game, how they worked and what could've been improved. The text will contain some rather large spoilers about the game.

The game started as a test for a limited colour palette. I had noted that limiting one's design choices can be very helpful in learning how to approach various problems. I wanted to test this approach and arbitrarily chose 32 colours that I liked and made the picture above with them. Making a nonlinear adventure platformer had been in my mind ever since I started making games back in primary school, so once I convinced myself that this artificially limited approach could work very well on a game of that genre, I started working on a prototype. The limited palette and resolution allowed for a faster working pace, which came in handy seeing that apart from the audio, I worked on the game alone (the music was composed by Roope Mäkinen, and the sound effects were made by Joonas Turner & Niilo Takalainen). The game was made using Multimedia Fusion 2 by Clickteam, which helped with prototyping the game's engine but posed me with other problems discussed later.

It's been very interesting to see people's reactions and feedback on the game's difficulty. Most of the testers were people who've played a lot of games, so I knew beforehand that the feedback I got before release was somewhat skewed. After release I did get a lot of feedback & criticism on this aspect, and eventually implemented the easy mode as a response for the criticism. I felt that since the game had already been completed by some people who also told me they had had fun playing the game with the "original" difficulty, it wouldn't have been a good idea to outright change the basic game experience but instead apply those changes into a whole different mode.

People on the Steam Community Hub made a really interesting point about why they felt the difficulty was frustrating - instead of the game being tough all the way through, there was seemingly a large difficulty discrepancy between boss fights and the rest of the game; this way there were players who didn't mind the overall difficulty but would get stuck in singular encounters. Hopefully the current version works better in this sense, though.

I love large boss fights in games, and the game really reflects that, at least in terms of boss quantity. Boss fights can be much more unique in nature than many other parts of games of this genre, and since they're fought (usually) only once, it's easier to concentrate on making that singular encounter memorable. I'm especially fond of bosses that work like puzzles, which is of course a staple in adventure games. That said, there are 3 things I wish I had concentrated on a bit more while designing the bosses.

1) The actual diversity in boss designs. Many of the bosses use a similar base concept of the boss itself being stationary, not using its body in any meaningful way but instead concentrating on shooting at the player. While the nature of this stationary-ness varies between them, I feel I could've worked out some better solutions for this. According to the general feedback people have liked how different the bosses are as-is, but of course one could always improve! I actually even changed two fights after designing them once (Station AI and Tomb Spider) to reduce the amount of bosses that do not move by themselves at all (although the latter of the two needed a redesign for other reasons as well).

2) The boss "puzzles". As it is, those are nearly nonexistent in Environmental Station Alpha. My approach to game design is very freeform and I didn't really think of any deeper design concepts while working on the game content (apart from some exceptions). This along with the fact that it's much easier to design a boss that you just need to mow down made most of the boss fights not require that much problem-solving rather than "just" dodging and learning the boss patterns. I think I did a pretty good job compensating this lack of puzzles in the fights with interesting patterns and attacks, but again, there's always something one could improve. :)

3) The boss difficulty curve. I only realized this after the release - since there are two immensely powerful items (Dash Booster X, which practically allows the player to fly, and the Supercharge Module, which makes all the player's shots deal four times their normal damage), all bosses that can be fought after getting those two (or just the Supercharge module) become extremely easy. This creates a rather funky pattern where in the beginning the bosses get progressively harder (with Serpent 5 and Overgrowth being the two most difficult ones), but the ones after Multicore can be rendered practically harmless by getting the Supercharge module. My intention was that most people either wouldn't care about the optional powerups enough or would want to keep some challenge and not use the more powerful things while fighting, say, the final boss, but of course since the game never explicitly says "btw, these are REALLY POWERFUL, try beating the bosses without them!!!" it's understandable that most players do not approach them this way. On the other hand, maybe there's something cathartic to be able to defeat the latter bosses with ease after the early struggles.

Writing about puzzles reminded me of some other things I've been thinking about before and after the release. The game was made using a rather crude custom-made level editor because Multimedia Fusion's built-in level system is really terrible (imagine every room having all the game code stored internally, so that if there's a bug, all code needs to be copy-pasted to every single room (of which Environmental Station Alpha has over 200)). Since I wasn't very good at using MMF 2 when I started working on the game, I made the level editor to only support adding and removing tiles & putting enemies and such on the map. There was no cutscene editor or ability to add custom stuff to rooms in the editor itself; everything of that nature had to be manually coded in Multimedia Fusion. This made implementing cutscenes a huge pain, which can be seen in how few of them there are, although it of course doesn't concern cutscenes such as the intro or the ending, since those don't take place in the actual game world. 

Due to these restrictions the in-game puzzles had to be hardcoded as well, which proved to be pretty difficult and frustrating. I hadn't really planned that many puzzles beforehand, which caused a similar effect as with the boss design that since coding puzzles into the game was such a pain, in the end there ended up not being that many of them. At some point I coded pushable blocks to the game, and these can be seen in places like the triple-shot room; the temple was meant to hold some more traditional block-pushing puzzles along with more meta "think outside of the box" -type ordeals. However, I eventually redesigned the whole temple because it wasn't really up to the standards of the rest of the game, and decided not to include any block-pushing in time finished product. Some of the original temple puzzles can be seen in the post-endgame content, though.

It's easier to point out things that didn't work than things that did, but there are some things in the game that really positively surprised me. The biggest one is the hookshot powerup - originally I disliked the idea of using a concept as 'classic' as a hookshot, testing out some rather weirder ideas, as seen in this gif:

After some fumbling and realizing the hookshot would be a pretty cool thing after all, I implemented it in the easiest way I knew back then. I didn't really think much of it at the time, but I was content with how it worked. However, during testing and after reading actual player feedback it became apparent that the hookshot had turned out to be really satisfying to use, allowing for some pretty insane ~~SPECIAL STRATS~~ among other things. Part of the satisfyingness comes of course from the sweet latching sound Joonas & Niilo made for it! I've always really loved games where a somewhat basic item/powerup can be used or exploited to do really crazy stuff - a good example is the cape in Super Mario World, which is pretty handy even when used just to slow down the player's fall, but becomes immensely powerful at the hands of someone who knows how to fly properly with it. Another classic example is of course shinespark in Super Metroid and other 2D Metroids that include that mechanique. The hookshot isn't really comparable to either of these examples, but I'm still happy that it turned out to be much more useful than it initially seems! Here's how the the powerup worked in the end:

There were some other powerup and gameplay ideas I toyed with but scrapped in the beginning of the design process. One of the cooler ones was zero-gravity, which would've been present in certain areas that were exposed directly to space. Since the player is a robot, the lack of oxygen isn't a problem, but in these sections the player would've been forced to shoot in different directions to propel themselves. I'm sure the same concept had been done elsewhere already at that time, but it would've fit the setting. The actual reason this mechanique was scrapped is because of certain coding problems (a really silly reasoning, in hindsight! Now I almost feel a bit sad for not keeping that system in). In one of the earlier drafts of ESA, the game was set on a wreck of several smaller space stations & spaceships, requiring the player to use this zero-gravity movement system pretty often. Here's a screenshot of said iteration:



That screenshot also portrays nicely the design of the main character; they were always supposed to be a robot, but in this higher-resolution picture you can see the "brain-tank" -design better. The sprite of the player character in ESA used to be a bit larger, but I resized it to make the scale of the station feel bigger, and to make the player's collision mask a bit less ambiguous. Here's the original sprite:



Somewhat related to the player's abilities changing over time, the dash powerup actually started off as a bomb! It was fun to toy with but since I didn't want any random drops in the game, in the end it didn't really fit in.



The next iteration of the powerup was a shield the player could use to prevent damage. The problem with this was that I couldn't decide how to map activating the shield into the existing button layout, along with a set of other problems such as how to portray its length and cooldown, if it would damage enemies or just deflect bullets etc. You can see the somewhat confusing way the shield worked here:



In the end, I took the "makes you invulnerable & damages enemies" idea from the shield and incorporated it in two powerups, the plasma field & the actual dash. Here's the dash in its original form:

...and what I ultimately ended up using:

Story spoilers in this and the next paragraph! The basic concept of the game is that there's a computer virus that can infect any robotic equipment. I didn't plan the story that well beforehand (which can probably be seen in that description, heh). I had had some story ideas before of a virus that infected robots and made them act so as to infect more robots; at some point I was considering a game where the player is the aforementioned virus and must move between robots, gaining more power in order to target larger and larger robots. The idea is still kind of cool in my opinion, but it would require an engine and game world fully built around this hijacking system. I remember having this mental image of a cutscene where the player infects what would later become the boss Serpent 5 in ESA and "ride" it to freedom from wherever the game would've taken place. In this way, the basic form of the story was there to some extent even if I didn't really think of it that much. The biggest problem such a leisure style of design presented me with was figuring out a justification for the player to explore all the areas of the station. The journey from the underwater sector to the jungle sector proved to be especially tough to explain, solved in the end with two halves of a single journal. I think this design issue can still be seen somewhat in that many players seem get lost at some point about halfway through the game.

One fairly interesting thing I noticed after the game's release was that nearly everyone I saw beat the game thought that the reason the ending is kind of a downer is because they hadn't collected everything yet. I can understand the reasoning behind this, but since I had decided on the ending to be somewhat bleak well beforehand, I didn't foresee at all that people would of course assume for there to be some other, happier ending. If one thinks about it, in a sense only the normal ending is actually sad - the robot "dies" in some way in any case, but in the other endings this doesn't put others at risk. Thinking this way, the fourth ending (accessed by beating the game normally after finding the secret ending once) might be the 'happiest' one since in it there's no chance of the virus spreading any further. I find portraying death as something that isn't inherently bad interesting, and in my opinion there could be more games where someone dying isn't necessarily a mark of the player messing up and needing to, say, find all the secrets, but instead just the way things happen to be. Something something Final Fantasy VII something.

After finishing all the content I had initially planned to include, I decided to implement a secret post-endgame puzzle section because due to various reasons I had plenty of extra development time and it was something I had been pondering about for a long time. I really really love those kinds of obscure ARG-ish puzzles that the community has to collaborate on to fully solve; seeing people eventually figure out things like the secret stars in Braid is really amazing in my opinion, and even though I initially didn't plan to include this much post-endgame content in the game, I did feel that it'd be cool to try to get some of the same feeling of mystery that makes the player go "I don't understand all this, but there's apparently much more here than is initially apparent" in the game. Being able to go all out with the puzzle design made designing them much easier compared to the relatively nonexistent puzzles of the normal game content, and I had a lot of fun coming up with some really mean tricks. The only problematic thing was that since I wasn't totally certain how many players the game would garner, I wanted to make sure that at least someone would find out about this secret crazy puzzle stuff, and while doing so made it a bit too easy to get started with it. This resulted in a situation where pretty much every player stumbles upon the keys and whatnot and thinks "oh, this is what I must do next", only to find some intentionally very obtuse puzzles and possibly find them off-putting since they're so different from the rest of the game. After realizing this I did rework some of the hints to be a bit more reasonable, though. I'll just have to make a clearer distinction between "normal" endgame stuff and "hidden" endgame stuff next time!

Fun fact: originally the very very last puzzle of the game required the player to have exactly 100% completion rate to get the secret ending; any more or less and they'd just lose instead. Getting to the secret ending with 100% requires skipping something in earlier parts of the game, like a diskette, meaning that the player would most probably have needed to re-do the whole game with this specific puzzle in mind in order to "solve" it. I still like the idea, but it will need to wait for some other game, haha.

In the end, I think I succeeded pretty well in doing what I set out to do, i.e. make a metroidvania with lots of bosses and a large world to explore. I'm thinking of sometime making something a bit similar, but we'll see what happens; it'd be silly to promise anything at this point.

To end this huge wall of text, here are things I'll do differently next time, assuming there's one:

Thank you for reading, I hope the text was interesting! I didn't really talk about the audio here, but obviously thanks to Roope Mäkinen for the game music, and Joonas Turner & Niilo Takalainen for the sound effects.