Another week of the semester has come and gone, and the game continues to creep ever closer to completion. Things have been achieved, things have been lost, but overall – it’s been a good week.
Monday. I began the week by opening up the game’s development Trello board (which can be found in the Semester 2 menu above) and adding everything that I could think of to a new general “To Do” list, in order to get a full idea of just how much more work the game would require so that Josh and I could better organise priorities and how we were going to approach various aspects of it – things like that. One thing that then became fairly “I need to get on that!” quite quickly was the game’s UI. It had received a major design overhaul last week in Fortitude 1.1 (a Pause Menu, tutorials and general colour scheme and font design) but that ugly-as-sin placeholder UI in the game’s top left hand corner that displays things like Fuel and Velocity was still there, and it badly needed an overhaul. This was something I’d known for a while now, but seeing it amongst a bunch of other things in our To-Do list made be think that it was finally time to do something about it.
I started by looking through our old Design Document and reaffirming exactly what we wanted in a UI system; namely as minimal a UI as possible. I then started thinking about exactly what we needed to display on said UI, and then thought about how to approach each of those variables as a displayed aspect of the game. After a brief chat with fellow Games Designer Dean about UI, he recommended the dynamic interface designs of Metroid Prime as a good baseline for excellent UI:
The difference between this and standard UI is that the interface forms part of the game (it’s actually displayed on the player’s helmet) so it doesn’t actually look like a game UI at all. Now obviously I wouldn’t be able to do something as complex as Metroid Prime, but the basic idea behind it was cool, and I decided to take a bit of inspiration from it. The most important displayed function of Fortitude is the ship’s velocity, so I took that variable, plugged in the new font from Fortitude 1.1’s UI designs and attached it at an offset to the ship. Note: only to the ship.
The end result was this. The new UI is displayed at an offset to the ship so that it’s viewable at all times, but is only attached to said ship, so it can quite literally be walked away from as shown in the screenshot above. Additionally, the new UI can be toggled on and off altogether via the “H” key, so the player can choose to have it off the screen at any time of their choosing. Using this design as a baseline, I then added things like “Distance” and “TimeScale” to the UI, but they only appear whenever said variables are changing (i.e. the “Distance” scale only appears while in-planet and TimeScale only when Time is increased). Overall, this new design is as minimal as possible, gets the job done and I think actually looks rather good while it does it. It’s certainly a great deal better than the previous placeholder UI, and all-in I was rather pleased with myself after it was done.
Tuesday then rolled around, and since I was on a bit of a roll with doing general game improvements that needed to be done, I decided to tackle something that had been continually suggested (mainly by our tutor Adam) for weeks and weeks now; controller support. For a game like ours where flight is involved, joystick movement generally feels better and I had really liked Adam’s previous suggestion of making ship thrust on the Left Trigger, so that together with the joystick you could control the entire movement of the ship via just the left side of the controller. It was an intriguing concept, and on Tuesday I was quite keen on making it a reality.
Subsequently, adding controller inputs to all of the game’s various controls took a lot longer than expected, and even now (the end of Friday) some of the new controls don’t quite work properly. As it turns out, massively changing the fundamental and basic controls of a videogame right near the end of its development can be somewhat problematic. Who knew, right? Still, the new controls work pretty well now for the most part, and I’ve found that actually the game feels much better controlled with a controller. Flying the Fortitude ship for example feels a lot nicer, particularly the action of pulling a trigger to engage thrust and hurriedly pulling the other trigger to engage autopilot when things go badly wrong. Making the Pause Menu function with controller was quite difficult, but you can now scroll up and down the various options (Resume, Restart and Quit) with the D-Pad and select with the A button, which feels good as always. All-in, I’d say Fortitude is better now that it’s controller-based, but implementation wasn’t without difficulty.
With controller support more-or-less there, it was then Wednesday, and Josh had just sent over the brand new full planetary surface designs for the world of Diadem. Much of the day was then spent implementing said designs; putting all of the various surface elements together like a puzzle (as Josh had sent them in 3820 x 2160 chunks to stop Unity from compressing them and losing quality) and making sure they all lined up perfectly, before then adding all the rocks and the infinite-looping-terrain function from the previous update (so that the player can never find the “edge” of the world).
The surface of Diadem, Fortitude’s brand new planetary surface
I then tied everything together with a nice code-based bow as I made sure landing worked properly and added a few of the environmental effects implemented initially for Elcalowda in Fortitude 1.1. Since Diadem has no atmosphere (as it’s like our Moon in terms of planetary style) there is no wind or clouds, so it was just a matter of adding enough camera shake to make landing interesting and tinkering around with the gravity so that it was light enough to feel moon-like but not so light that landing was made too easy. I also then fiddled with the on foot astronaut’s jetpack boosting, so that now the player can lift off the ground and “jet around” for three seconds before needing to touch the ground again to “recharge”. In hinesight, I feel that this small update was actually quite important, as with the planet’s low gravity manouevring about on foot is now super fun (or at least I think so) which massively adds to the whole “needs to feel good” element of Fortitude’s gameplay.
Towards the end of Wednesday, I then set about starting work on another aspect of the game’s narrative that I had planned from last week; the Sentient Bacteria event. Since it primarily takes place on Diadem, obviously the surface needed implementation first, but now that it’s in work could begin. The basic premise for this event (full initial idea available in the Design Document) is that the player sets down on an alien world, goes off exploring, finds nothing and returns to the ship only for it to begin acting erratically during takeoff. As per our narrative discussions in Week Twenty Nine’s walkthrough, the ship would then weakly point towards Elcalowda as a salvation point, and the player would then need to pilot through the various erratic ship problems and successfully land on the planet in order for the game’s finale to begin.
The game’s full narrative designs from Week Twenty Nine
I began with working on the sub-events taking place on Diadem’s surface, namely the ship giving the player various warnings throughout their on foot exploration that suggest that something is approaching the ship, but when they return to the ship the player sees nothing wrong. To do this, I returned to our online ship AI voice generator (see here) and made a few lines for the ship to say at various points after landing on Diadem, and then coded them into the game at specific timed intervals. Now when the player lands on the surface of the world, a timer begins, and upon that timer reaching two minutes the ship begins to speak. It starts with a simple “Proximity Alert” before then moving into “Detecting Organisms” and then “Multiple Organisms” and continues in this somewhat alarming vein for several minutes. To add atmosphere, I then opened up Audacity and distorted a few of the voice lines, so that the ship’s AI appears to lose power and start malfunctioning as time goes on, suggesting that something isn’t quite right. It then stops speaking altogether after a time, and hopefully at this point the player is rushing back towards it to see what is wrong, only to find nothing (visually, anyway).
I then decided to have the secondary “malfunctions” sub-events occur while in space, not during takeoff. This was because takeoff is difficult enough as it is without adding destructive narrative events to it, and also the player’s concentration will be on piloting during takeoff, whereas it won’t be so much when travelling in space as its easier, leaving their attention more likely to catch various malfunctions with the ship. Thursday then rolled around, and I spent a considerable amount of the day creating various sub-malfunction-events that the ship could experience during the Sentient Bacteria event, and then coding them in at various timed intervals. These events include:
- Random Thruster Firings
- Random Rotational Movements
- Random Power Losses
- Random Player Ejections From Ship
- Random Autopilot engagings
Each of these events is designed to imitate this idea of a malfunctioning outer space vessel, as the Fortitude is slowly being taken over by a “sentient bacteria”. Said events will occur every minute or so after exiting the atmosphere of Diadem, and the player will need to be constantly aware of what the ship is doing (or not doing) in order to successfully pilot it through its malfunctions and reach the safety of Elcalowda. The events are entirely randomised, so literally anything could happen at any time (although there are specific timed intervals between events so that they don’t become too irritating).
While I was in Audacity tinkering with the ship AI’s vocal lines, I also noticed something rather interesting. I was fiddling with the audio’s speed and pitch in order to get the ship’s voice to sound like it was losing power or glitching out, but at one point I set the speed of the audio clip way too low (at a speed of 0.1 times it’s original) and so the clip was massively distorted and slowed down to the point of being unintelligible. In it’s place however was this really long, drawn-out groaning and ticking sound that sounded eerie and frankly quite terrifying. I then sent it over to Josh as a bit of an experiment, and his first reaction was that it was a very scary noise, and he wondered if this was my audio work for the ocean creature of Estabahn’s ice moon.
https://vocaroo.com/i/s09HDsqqcgdf – the edited audio clip from Audacity
I made sure to store that particular audio track for the ocean monster event, but this idea of slowing down the vocal cues of the ship’s AI to make scary noises stuck with me, and I decided to also use this technique to make the Sentient Bacteria event a tad more scary. Heading back into Audacity, I slowed down another of the ship’s audio cues, except this time to a speed of 0.25 rather than 0.1. At this level, the ship’s voice is ever-so-slightly-but-not-quite recognisable as an actual voice, and I wanted to use that aspect particularly in order to emphasize the narrative event’s rather spooky atmosphere. After all, there is literally an unknown alien entity onboard your ship with you, and I feel I needed to get that across with more than just weird ship malfunctions.
This new sound is like a mixture of really distorted ship AI voice and a horrifying alien growling, and after adding it into the game and coding it to play at various intervals during the ship malfunctions, I found it massively added to the overall “fear of the unknown” tone of the event and the game itself. Even just with a sound the event is much improved, as it really emphasizes the “there’s something here with you” aspect of the event which for me increases my fear a lot, not to mention the fact that it’s just a very spooky noise in general, making an already nerve-racking story event (as your ship is out of control and in flight) even more terrifying.
Overall, I felt that the new Sentient Bacteria event worked quite well. The initial “set-up” of the ship warning the player about incoming organisms really set a spooky tone right at the start, and that combined with the player finding nothing as they approach the ship really emphasizes the “fear of the unknown” aspect of the overall game. You can’t see the enemy, which makes it a million times more scary. The subsequent ship malfunctions and creepy noises then increase this fear level a lot, resulting in a rather nerve-racking yet surprisingly entertaining flight from Diadem to Elcalowda as the ship quietly suggests you land there, and hopefully desperate to rid the ship of a rogue and unknown element, you reluctantly obey.
I was then quite keen to playtest the game’s brand new story event, so I enlisted the help of my little brother Syd (who’s fourteen) to test out the new mechanics. He’s somewhat uninterested in games in general (not to mention the fact that he’s not particularly great at them – this is an important point for later) which makes him a unique and kind of interesting demographic to test out Fortitude on. After teaching him the basic controls via the game’s tutorial, I was then keen to not tell him anything else about the game. I also made a point of pointing at the ship’s red trajectory line and asking him what he thought it was for (to see if it was intuitive) and his reply was simply “it tells you where you’re going” which is absolutely true, so I was pleased with that.
A screenshot from Syd’s Fortitude Adventures
I then had him attempt to land on Diadem, a task that was met with moderate success as he landed but managed to semi-crash at the same time, coming to a stop with the ship on its side. Still, it was nothing a simple autopilot toggle couldn’t fix (as it automatically rights the ship) and so with the ship upright I encouraged him to go off exploring on foot. He took particular joy in blasting off the little astronaut with the new jetpack-timed-recharge mechanic, and spent many a minute jumping around in Diadem’s low gravity and he seemed to actually enjoy it, which was great. The ship then began audibly warning him of organisms in its proximity, and it was here that Syd’s attitude started to change. The fun started to drain from his eyes, and he became increasingly worried as time went on and the ship’s voice got increasingly intense and distorted. This resulted in him running back as quickly as he could upon its call for “immediate evacuation” and his surprise at arriving and not seeing any alien bad guys was quickly replaced with urgency as he entered the ship and blasted off as quickly as he could.
Things only got worse though as the ship started to warn of malfunctions, with thrusters then firing unexpectedly and power losses starting to occur. He began heading towards Elcalowda after first slingshotting around the Sun, all the while battling the ship’s various malfunction sub-events and notably getting increasingly annoyed at how they were breaking his ship. He also reacted exactly as hoped towards the creepy alien sound effects, becoming quite scared at the idea that there was something inside the ship with him. Landing on Elcalowda sadly proved unfortunate as he then lost power during a critical orbital manoevre, resulting in the ship slamming into the surface at too high a speed to handle. Game Over.
As a final aspect of his half-hour-long playtest, I then asked him what he thought of the game overall. His response was that it was really fun, particularly emphasising how much he enjoyed flying the ship during landing and jumping the astronaut around in Diadem’s low gravity. In terms of the Sentient Bacteria event he found the overall story quite scary, pointing the finger particularly at the Audacity-created sound effects as major contributers to the tone. He did however also say that he found the various ship malfunctions initially scary but then just irritating after a while, so in response I decided to widen the timed intervals between each sub-event, thereby making them less frequent. Overall I was rather pleased with his reaction as he had enjoyed the game far more than I had thought he would, and seemed to grasp the new controls quite well considering he doesn’t play games very much. He did struggle with some aspects (landing for example he found difficult) so obviously improvements need to be made, but all-in I found it to be a particularly useful playtest, and so well worth mentioning here.
Friday then arrived, and I spent much of it writing this blogpost along with showing Josh the various different elements of Fortitude 1.2, particularly getting him to try landing on Diadem and experiencing the brand new Sentient Bacteria narrative event. His overall reaction was pretty similar to my brother Syd’s, in the way that he enjoyed a lot of it (particularly the jumping around in low gravity) but also found the randomised malfunction events irritating after a while, so I decided to decrease their frequency yet again to combat that. Otherwise, the only other event of importance was a discussion with Adam around what work we had left to do for the semester, resulting in this post-it board:
Obviously the game’s story is our biggest priority, with user testing and resultant bugfixing being the next largest issue. Sound design is also something we have been meaning to tackle for a while now, so we took action and booked one of the film studios for next Tuesday morning in order to try and record as many sound effects as possible during that time (main ones being the rocket and astronaut sounds). The day (and the week) then drew to a close with me getting Fortitude 1.2 fairly bug-free before then zipping it up and calling it a day.
Reflection On The Week
Week Thirty One has been a very productive week, and the game has taken significant strides forward in its development as a direct result. The game’s narrative is now much improved, with the new Sentient Bacteria event now fully implemented and functional for the most part. It still needs a fair amount of playtesting and ironing out, but the basic and fundamental elements of it are now in the game (i.e. the hard part is done, hopefully anyway).
The game has also received a few much needed quality of life updates, including a new UI system that replaces the very ugly-looking old placeholder one and full controller support (that took a surprisingly long time to implement) that overall I feel much improves the feel of the game, particularly through the use of joy/analogue sticks to control the movement of the Fortitude ship. The game is currently in its most stable build so far, so things development-wise are looking good at the moment.
The plan for next week is to hopefully create most of the game’s sound effects on Tuesday, and then by using these and Josh’s various asset designs the Ocean Monster narrative event will be the next major point of development, along with implementing the final planetary surfaces of the game. Depending on how well this goes, I may then continue with quality of life updates, perhaps looking into map targets or new tutorials to explain things like landing and each of the planetary bodies.
So far, so…OK. Still got a long way to go.