Unlike a fair number of previous weeks, Week Thirty Three has gone pretty much according to plan. Well, except for a game-breaking visual bug on Monday that damn nearly gave both myself and Josh heart attacks. That was fun.
Let’s dive right into that, then. This week’s Monday began as most have done in this semester, with me getting up at around 8AM, sitting down in my desk chair and preparing for what’s always likely to be a busy day of coding Fortitude. This week however was different; I was worried (more so that unusual). You see, the day before (Sunday) Josh and I had been playtesting the game, and while we had been exploring the game’s beautifully crafted Solar System (haha) we had come across something rather strange in one of the gas giants; a large snake-like line of pixels flying about within the giant’s many gaseous layers. This was puzzling, and at the same time I noticed something else; one of the bars of the ship’s fuel gauge was missing, despite fuel being at 100%. At the time we just thought it was a build error, but sadly we were very wrong.
So on Monday morning, I decided to look into the snake phenomenon and try and figure out what was causing it. I built a brand new build of the game, loaded it up and headed out towards the same gas giant to see if the snake was still there. Bingo, yes it was. And so was the fuel gauge glitch. Two visual issues side-by-side, and I could’ve sworn that they hadn’t been there last time. Scratching my head, I decided that they were minor issues and that they didn’t need massive attention right then, so I moved on and began adding things for Fortitude 1.4. That is, until I saw this:
This is an image from the other gas giant (not the one with the pixel snake) and unlike the snake one, this was a major problem. That up there is not just some random line of small particles, it’s a good ten percent of our planet-sized gas giant that essentially has visually broken. I nearly had a heart attack as it looks an awful lot like a graphics card problem, and I worried that mine might have been toast. The next few hours were then spent worriedly diagnosing the issue, trying out various changes and rebuilds but nothing was working; the problem was still there. It was here that I started to get drastic, ripping massive chunks out of the game one piece at a time so that I could narrow down the issue. Eventually (Monday evening at this point) ripping out a chunk worked; the planetary surfaces. Suddenly the gas giant was fine, and the fuel gauge bar had been restored. Of course, the game can’t be without surfaces, so I set about finding the exact cause.
It took another good few hours, but eventually I was able to diagnose the issue mainly thanks to the Unity Forum guys; apparently, Unity has a 4GB texture limit, and with the latest game update (1.3) we had just exceeded ours (as our game has a lot of very large 4k textures), with the latest build reading 4.2GB of textures. Rather than just telling us this however, Unity decided in its infinite wisdom to present the issue as a series of very scary-looking visual glitches, and so it took way longer to diagnose than expected. I then had a quick chat with Josh about the issue, and I explained that essentially we needed to downsize the game.
Plans were then made, and we got to work. The first things to be dropped in resolution were the UI elements, and they’re not massively important in the grand scheme of things. Then, all planets except the gas giants were resized, as they’re only really seen from a distance in the game map anyway. Resizing drastically reduced the amount of space each texture took up, and by the end of our “purge” the game was sitting at a comfortable 3.2GB. We then decided to keep cautiously implementing game textures as planned, and if the issue was to rise again (as it likely would) then more things would have to be done. For now though we had escaped having to actually remove anything from the game, so victory had been achieved.
Tuesday then rolled around, and Josh had sent me the first of the two final planetary surfaces that still needed implementing; Rika’s Moon. Per our original design document, this Moon is a highly volatile and partially volcanic world, so I was keen to make its environment as harsh as possible. Since it doesn’t have much of a role in the game’s narrative besides having a few ruin-like structures in its cave system, Josh and I then had a chat, and decided to have an event of sorts occur instead; an eruption. Our thought process essentially was; hey, this planet is dangerous. Why don’t we make it more dangerous? The idea was simple; having lava start to creep up towards the player as soon as they touch down, which would eventually consume everything including the surface itself. We felt that this event would re-add the excitement from the Moon that was otherwise missing as a result of it not having a role in the narrative (whereas other worlds do) and it would also be quite fun. Imagine running desperately for your ship as lava rises up behind you. It’s scary as hell, but it’s fun.
Implementing the surface designs and then creating the lava event took most of the day, but by the end we had a pretty enjoyable gameplay experience fully (more or less) implemented. Upon entering the atmosphere the player is greeted with a harsh atmosphere (with borrowed and modified cloud-based elements from Elcalowda) and upon touching down, something entirely new; weather.
Even after implementing the harsh atmosphere and the lava, I still felt that something was missing. This was a highly volcanic world, and it just didn’t feel very dangerous when I landed. Things were too still, too quiet. To combat this, I grabbed a few elements from the atmosphere and then modified them considerably; stretching them out, dropping their opacity to near 0 and then moving them to just above the surface. The result? Wind. With their modified variables, these old clouds had become incredibly fast wind, and the impact on gameplay was quite something. The player can now be “blown around” by the wind if they are not careful, and if it isn’t parked carefully, the ship itself can be blown over.
Lava slowly rises up to greet the doomed player
To wrap things up, I then revisited my usual royalty free sound effect site (FreeSound.org) and added a storm-like sound effect to the surface, as well as making it quieter when you’re within the ship and louder when you exit (this makes the ship feel safer as things feel calmer, and also helps to add atmosphere). Overall, both Josh and I were rather pleased. It was a fairly basic weather system, but we felt it worked very well to make the environment feel much more active, and also added elements of danger to the supposedly volcanic moon.
It was then Wednesday, and Josh had just finished up the last of the needed-to-be-implemented planetary surfaces; Estabahn’s Moon. This of course meant one thing; I was going to have a busy few days. After all, this moon was a little different than the others, as in addition to its actual surface, it also has a sub-surface ocean. Within this also is where the previously planned Ocean Monster narrative event is supposed to largely take place, so needless to say I had a lot of work to do. I started with implementing the surface itself, putting together Josh’s 4K building blocks and lining them all up until they were perfect (more or less). Since it’s an ice world, I then borrowed and modified some weather-based elements from Rika’s Moon’s environment, designing a similarly harsh atmosphere and then changing a few numbers and colours to make a snowstorm-like event occur on the surface. A visit to FreeSound then gave me another royalty-free stormy sound effect, and then the atmospherics of the Moon were complete.
I then moved on to the ocean itself. Josh had already visually designed it, so it was just a matter of putting blocks together and then coding in a swimming mechanic to match. To achieve this I added a few lines of code that massively increased the player’s drag upon entering the “water”, resulting in slow movement that I felt heavily simulated the effects of water upon a person. It took a couple hours of playtesting and tweaking, but eventually the mechanic was there.
There was still something missing, however. There was just something about the transition from land to water that just didn’t feel right. Even though controls-wise it felt like I was in water, I just didn’t really feel it. Thinking sound might be the issue, I revisited FreeSound to grab a few royalty free water sound effects, and implemented them to see if that made a difference. Atmospherically it very much did (as underwater sounds are always eerie) but I still didn’t feel like I was in water. Perhaps then, I wondered, it was a visual issue. I tinkered about with placeholder images from Google, figured out what the issue was and then sent Josh my findings:
How the land/water transition usually looked
How the land/water transition looked after my Google-sourced edits
As you can see, there’s a substantial difference. In the second image there’s a hard disconnect between the water and the land whereas in the first it’s much more suggestive, and that I felt was where the problem lied. The first image looks cool, but it doesn’t look like water – more of a transition into darkness. The second image has a very clear water line, as well as a dark blue/green texture underneath rather than simply black. Josh and I both agreed that the second one looked far better, and so he set about editing the visuals while I began work on the Ocean Monster event itself.
The original plan for the event was fairly simple; having something in the water emitting spooky noises to scare the player (implying some kind of alien monster in the deep), but to be in-keeping with the whole “fear of the unknown” theme, the player would never actually be able to find the source. This week however, we felt that that wouldn’t quite be enough, so decided to take things a little further. We would actually have a monster, but a shadowy one. It would then move about in the water and emit very eerie noises, and by using surround sound we could then make it so that it sounded like it was coming from any particular direction (i.e. it sounds like something is moving around the player). Josh then took this idea and designed a monster.
It’s just a shadow, but upon seeing it for the first time I found myself taken aback at just how…creepy it was. I then spent the rest of Wednesday and much of Thursday working with this creature, adding some basic movement AI (so that it moves around on its own) and fiddling with surround sound in order to make it sound as eerie as possible. In terms of actual sound effects, I made sure to grab the spooky-distorted noise I had accidentally created in Week Thirty One (see that Weekly Walkthrough for more info) and after a great deal of coding-based work, the creature was in. Josh had also worked tirelessly and had successfully fixed the visual disconnect issue between land and water, making it much thicker and “bluer” so that it both looked and felt like deep, dark water. As a finishing touch I then added a small light to the player that activates within the water, so that a small area around them is lit up at all times. This made nearby things brighter but also further things darker, which I felt massively added to both atmosphere and fear factor while playtesting. The overall result looked like this:
A promo image we made for the update – you can see the shadowy creature towards the top of the beam of light
To still be in-keeping with the “fear of the unknown” theme, I had added another mechanic that gradually faded the creature out the closer the player became to it. The result of this was that if the player followed the noises around and successfully tracked down the wandering creature (which would take a braver player than I) or even if it just wandered across them, it looks like a fleeting shadow in the background. It’s enough to suggest “wait, did something just move?” anxiety, but not so much that it ruins the mystery. If you’re wondering, it took a ridiculous amount of tweaking to get the creature’s opacity just right.
To finish up the narrative event, I then added a few ship AI lines that tell the player a while after touchdown that they have successfully triangulated the “Mysterious Signal” from the opening “In The Beginning…” narrative event implemented in last week’s update. Once the player then exits the atmosphere, the map zooms out automatically and the ship speaks again, pointing the player both audibly and visually towards the planet of Elcalowda, where the soon-to-be-implemented (next week) Alien Ruins event will then play out. It had taken a while (pretty much two straight twelve hours sessions of coding) but the Ocean Monster event was in, and I was pretty pleased with it overall. Both Josh and I feel that it captures our theme pretty excellently (though obviously this needs confirmation through playtesting) and so we both felt that our work on it had payed off considerably. Certainly I became reluctant to explore the waters simply because the darkness alone scared me.
As one final addition, I then took a look back at a game mechanic that had long since needed a bit of an upgrade; remote control. In previous builds, you could remote pilot the Fortitude ship by pressing the Y button, but the camera perspective stayed on the astronaut, so you could only fly the ship so far before it disappeared from your line of sight. At the time this seemed like a good balance, but as updates passed I found that both I and playtesters used the mechanic less and less, and soon it became nearly forgotten a.k.a useless. The reason for this I felt was that since you could only use said autopilot while close to the ship, it kind of negated using it, as why would you use autopilot if the ship was right there?
So to combat this, I decided to fix up the mechanic a little this week to try and make it more important. With 1.4, the camera now actually switches to the perspective of the ship (albeit with a blue filter for a remote control screen-esque look) which makes the mechanic overall feel much nicer (as you can actually use remote control to rescue yourself from distances now if you get into trouble). With this in mind, I then added a small tutorial for it that plays if the player spends too much time in the ocean (and their fuel gauge becomes low). Said tutorial encourages the player to remote pilot the ship into the dark waters to try and rescue the player, and visually I think it looks very cool. During subsequent playtesting, I felt that the revamped autopilot added considerably to the game experience, and regretted not having changed it up sooner. Remote controlling anything is always fun, and being able to save yourself with a remote-piloted ship is just cool.
A remote control underwater rescue
Friday then arrived. Things had been wrapped up on Fortitude 1.4 on Thursday (as I felt that the Ocean Monster and environmental additions where more than enough for one update) so I decided to get a bit of a head-start on Fortitude 1.5. Something that I had been meaning to tackle for a while now was lighting, in particular how the ship is light up by its thrusters firing. The type of lights I had used for this don’t work particularly well in 2D, so I felt it was high time to switch this up. An hour or so of tweaking and testing later, the result was this:
Original on left, new on right
Overall, I felt that the lighting of the ship was much improved. Even though the new lights are less spread out than with the original, the way the light now works feels much more realistic, not to mention how fantastic it looks while you’re landing (or at least I think so):
It still needs a bit more tweaking, but overall I feel that this new lighting looks far better than the old one, and it also causes far less visual lighting glitches as these particular lights works far better in 2D games than the previous ones.
Reflection On The Week
Overall, I think Week Thirty Three has been quite a success. We had a rather unfortunate setback on Monday because of the Texture Bug, but thankfully I was able to solve the issue rather rapidly and so we only lost a day or so of coding. As of right now the game is sitting at 3.8GB of textures, so we may need to downsize more assets or even just cut bits of the game as otherwise the glitches will start to return. Other than that though, we now have another fully implemented narrative event with the Ocean Monster as well as all of the game’s environment now in the game. Environmental Design (as least the fundamentals of it) is now complete.
Additionally, we feel that the new narrative event adheres considerably to the overall “fear of the unknown” theme, as it makes for a pretty scary event to play through in terms of ambience, and I feel that the way we molded the creature to be more of a suggestion rather than an actual visible threat makes it far more creepy as a result. After all, we fear what we do not understand, and even just the idea of something lurking in the darkness of the water is enough to scare me.
Next week, the plan is to implement the “Alien Ruins” narrative event, as hopefully by then Josh will have completed work on their visual designs. Hopefully that won’t take particularly long, as I want to try and get the “Game Finale” event in too, as it takes place in the same location (at least initially) in the cave systems of Elcalowda. If everything goes well, the game’s story should be more or less finished by the end of next week.