Things haven’t gone quite as planned this week, but honestly that’s been something of a recurring theme for the past few weeks. Besides, as a result of this change of plans, I successfully completed the largest update yet for Fortitude – The Refueling Update.
The week began on Monday (as it usually does) and the main event of the day was the latest of the game user-testing sessions scheduled by Adam. Development of Fortitude was at the tail end of Prototype 0.7 (the game’s second quality of life update), so as it happened we had a fairly stable game build to user test with. It wasn’t quite as exciting as the demo we had created for the trip to Andover College a couple weeks prior, but due to my experimentation with asteroids in 0.7 players had quite an eventful surprise waiting for them (namely the asteroid shower that hits the player’s current position after forty seconds).
Reception for the prototype was largely positive, with players praising the new handling for the ship (after the previous playtesting session we slowed the rotation of the ship right down as players said it was too sensitive) as well as the explorative elements of the game (a few attempted landing on a nearby planet, with mostly unfortunate results) and the navigation-through-asteroids gameplay. There were a few bits of criticism and suggestions, which are largely showcased here on this handy note:
Essentially, the biggest issue that players felt was that they didn’t know they were moving when they were moving i.e. due to the complete blackness of space there was no visual representation of spaceship movement. Additionally, since the asteroid field was a fair distance from nearby planets, the map was black so the players didn’t really know where to go. Adam then suggested that perhaps we add a travel indicator to the map i.e. something that points towards the current objective or even just to the nearest planet – essentially giving the player something to head towards. He then went on to recommend that the purple directional line currently in the map should be modified somewhat, as players didn’t necessarily know what it was meant to represent. The line points towards the player’s current movement direction, so getting that fact across to the player is quite important as it is a rather useful mechanic.
Overall, the feedback was quite useful, and we’ve definitely now got a few things that need improving along with a couple suggestions for UI design and general game elements going forward. After the session, Josh and I had a rather lengthy chat about the current state of environmental designs, and it became pretty clear after a bit that they weren’t going to be ready as expected (i.e. ready for implementation this week). Josh wanted to get them exactly right, and that involved a great deal of iteration as well as testing and refinement; all of which would take time, as it’s imperative that we get the designs just right.
The fact that Elcalowda’s surface design wouldn’t be ready for a little while longer was unfortunate, but I feel necessary in the long run as we do really want to nail this game’s visuals. As a result though, I realised that the plan for the week had just gone out of the window. The question now was; what could I do instead? The game had already had two quality of life updates recently so I felt it wouldn’t be a good use of time to do yet another one, so instead I decided to focus on fixing up and refining a long neglected aspect of the game; the refueling mechanic.
Tuesday rolled around, and I began the day by finally completing the Tethering System that had been a major thorn in my side for several weeks. The idea behind this system was that it would tether the astronaut to the ship, as refueling can only be conducted by the astronaut while on EVA (as it’s far scarier to be forced outside the comfort of your ship into the darkness of space, and I wanted to make the typically mundane task of refueling as exciting/terrifying as possible). However, I had previously attempted to create a rope between the astronaut and ship several times (using HingeJoint2D’s and Rigidbody2D’s) with limited success, as the rope did technically work but it was buggy to the point of being useless in most circumstances. This time however, I decided to completely abandon the idea of creating a physical rope, and instead drew a line between astronaut and ship with a LineRenderer and used C# scripts to simulate the physical effects of a tether instead. The resulting mechanic worked quite well (though not quite as well as a real rope) so at long last the game had the Tethering System necessary to progress with developing the refueling mechanic.
Fortitude’s new tethering system, complete with a “rope snap” mechanic that triggers if the player exits the circle seen above
As we had detailed in our Design Document from semester one, the plan was to make the outer atmospheric layers of gas giants the primary refueling location in the game. This was simply because it would be awesome and terrifying at the same time; seeing the gases swirling around you and battling severe gravitational forces and toxic gas pockets while at the same time trying desperately to refuel the ship. In principle it made the refueling mechanic a lot more interesting, and so I was pretty excited to bring that concept to life.
Pretty early on I decided to have gas giants go down the same developmental path as normal land-able planets, namely the player flies towards the world, touches a trigger collider and gets teleported to the “surface” (obviously without their knowledge, to them they’re just landing on the planet). I decided to go the same way with the gas giant (i.e. making a “surface” that the player is teleported to on approach) as it would allow me to have greater customisable control in terms of gravitational forces, fuel clouds and other environmental aspects. As a result, the rest of Tuesday was spent coding this into the game; creating another “surface” gas giant for the player to be teleported to, customising the variables of it and writing a few lines of code that offset the player’s location depending on their angle of approach e.g. if they approach the gas giant from the east side, they’ll be transported to the east side of the “surface”.
The Gas Giant Surface – currently being tested with Estabahn
Wednesday then arrived, and I started by refining the new Tethering System so that it functioned a little more rope-like (i.e. dragging the player about as they are essentially tied to the ship) as well as generally bugfixing and testing it to make sure it worked properly. I also spent a fair bit of time fiddling with the autopilot mechanic previously implemented in Prototype 0.7 – now whenever the mechanic is enabled, the ship will automatically orient itself away from its current movement direction in order to give the visual impression of “burning away” its velocity.
With refinements complete, I then focused my attention on continuing with implementing the full refueling mechanic. I began by taking the placeholder Fuel Cloud GameObjects that had been put in the game way back in Prototype 0.2 (back when I first created the game’s Fuel System), cloning a whole bunch of them and then placing them at various points in the outer atmosphere of the Estabahn gas giant “surface” GameObject. As before, whenever the astronaut GameObject (or OnFoot as it’s called in the Unity Project) enters the On Trigger Circle Collider 2D of a Fuel Cloud, the ship’s fuel level starts to rise. I played around with the clouds and tested refueling a few times, but found that despite the gravitational forces of the gas giant being a constant worry, refueling was fairly easy as the player could just park the ship inside the giant Fuel Cloud and refuel to their hearts content. There was no real danger, and so subsequently I decided to rectify that issue.
The rest of Wednesday and all of Thursday was then spent on this idea, but in hindsight I definitely feel that it was worth it. I began the implementation of “danger” by adding a simple new mechanic to the Fuel Clouds that made them smaller as the player refueled the ship; making it look like the player was actually consuming the Cloud. It made refueling a tad trickier as occasionally the player had to move the ship closer, but other than looking cool it didn’t do much to increase excitement levels. Time to up the ante. The next sub-mechanic I created then made things rather more difficult – the ship would be damaged by physical contact with Fuel Clouds, so not only would the player have to use the Tethering System to refuel the ship, but now they would have to park the ship carefully alongside a Cloud and then manouevre on foot towards the Cloud. Entering the Fuel Cloud while in the ship will now cause the engines to stutter for a few seconds before then cutting out completely, and they will only restart if the ship exits the Fuel Cloud. Essentially, things just got a lot more dangerous.
Testing and refining the mechanic-in-development after the new implementations, I found that refueling as a whole was a lot more nerve-wracking. While outside and refueling you had to keep a constant eye on the ship so that it didn’t drift towards the Cloud (as even with autopilot on the gas giant’s gravitational forces have a slight effect) as well as making sure the Tether is connected. However, I still felt that there was something missing.
Re-reading the document, I saw that we had suggested the idea of other toxic gas clouds in the gas giant, and so I decided to implement those too, as I reckoned they would add the extra edge of danger that I was looking for. Coding it in, I decided to up the ante even more by making the clouds dangerous to both ship and player, and also made the clouds move slowly towards the player while refueling was taking place, as narratively they’re attracted to the large concentrations of fuel within the ship. Playtesting this, I found that refueling as an event was pretty close to perfect. Refueling was a pretty great combination of terrifying and exciting, as the player has to keep constant watch of the ship to make sure it doesn’t drift off or isn’t being attacked by gas clouds, and these new events also made for some pretty dramatic and entertaining gameplay sessions as I had a few close shaves several times.
The new Fuel Clouds in the outer atmosphere of Estabahn
I was on a bit of a roll at this point, so decided to take things even further on Friday by heavily refining all of the new sub-mechanics for the refueling system so that they functioned damn near perfectly, and also implementing a few more game sounds to make it a tad more cinematic as well as even improving the UI slightly. In terms of sounds, the game’s first taste of ship AI has been added, as a robotic-style voice now says various things when certain events occur, i.e. when the autopilot is enabled it goes “autopilot engaged” and when the ship drifts into a Fuel Cloud, it says “losing power” as the thrusters begin to flicker. This was done via an online text-to-speech engine that we found back in semester one, link is here. The thrusters also have new placeholder sound effects, with an engine failure noise if the player sticks around in a Fuel Cloud too long and a subsequent engine start noise as it exits the Cloud.
Heeding the words of Adam a few weeks prior who talked about the importance of UI in the game, the final implementation of Prototype 0.8 was a basic UI to represent the ship’s current fuel levels. It was fairly simple, just being a series of coloured bars that together formed a semi-circle around the ship, with the top bar being full green to indicate full fuel and the bottom one being bright red for limited fuel. I then added a short script that disabled and enabled fuel bars depending on the level of fuel within the ship. The resulting UI looks like this:
As I said, it is rather simple, but I feel that it actually makes a considerable improvement to gameplay, as the player no longer has to squint and stare at a small number in the corner of the screen if they want to see current Fuel levels; now they can see this handy UI that tells them exactly how much danger they are in.
With Prototype 0.8 then more or less ready to go, I grabbed Richard, one of my fellow game designers to test the brand new update. He spent a good while playing it (which I guess gives us points for game addiction, right) and while he stressed that he liked the newly implemented mechanics as a concept, their current variables (i.e. various speeds) made the actual refueling element of the game currently kind of irritating rather than scary. The example he gave was the gravitational pull of the gas giant, as while refueling he sometimes couldn’t get the ship to sit reasonably still, so he kept having to come out of a Fuel Cloud to reposition the ship so that he wouldn’t lose the rope tether, which he found annoying. He also said that the speed of the other toxic clouds was a tad high, which made for some frustrating gameplay. All of his issues were thankfully quite easily fixable (as most were just a matter of fiddling with numbers) and overall he liked the new mechanics, mainly stressing that they just needed some tweaking.
The remainder of the day was then spent doing various bugfixes and optimisations, as well as having a brief chat with Adam about the current state of development. He also playtested the new Prototype 0.8 mechanics and agreed that they served as a large improvement on the game overall, although he also criticised the fact that the game (particularly the controls) are getting rather complex, and so suggested that a series of tutorials ought to be implemented somehow, perhaps via the ship’s AI voice or even with set “missions” that show up on the ship’s UI that tell the player what to do at a given gameplay moment.
Reflection On The Week
For the first time in a while, I am actually really proud of the current build of Fortitude. I got properly invested in perfectly this new refueling mechanic this week, and after a couple days of really crunching development we now have this pretty well refined and functional mechanic that is actually pretty exciting to play. I also feel that the overall “fear” theme of Fortitude has been expressed fully for the first time here, as this new method of refueling is both highly entertaining and pretty damn terrifying. Obviously, that is just my opinion and I’m sure it will need a few refinements and fixes along with some improvements that user testers will spot that I haven’t thought of yet, but overall I’m really happy with this update, and I feel that it marks the game’s first major step forward to becoming the great game that Josh and I know it can be.
The Easter Holidays are now fast approaching, and my current plan for them is to continue generally improving the game as well as beginning the Narrative Design. It’s something that Adam has been hounding us about for a good while now (although in fairness he does have a good reason – it is the most important part of the game). Environmental Design hit something of a major standstill, since as of right now none of the planet surfaces are in the game. This happened for various reasons (Reflective Journal, personal setbacks, wanting to perfect them etc.) but the bottom line is that we are way behind schedule, so as a result I’ve decided to continue without the environment for now, and so design and implement as much of the game’s overall Narrative as possible. This will be the main focus of the Holidays and likely several weeks after them. The immediate plan however for Week Twenty Seven is to do another quality of life update, as for me its only a half week (as I’m quite busy after Thursday) and there are a fair number of bugfixes and optimisations to do as a result of this week’s rather expansive update, as well as changing and experimenting with a few variables in order to make the new mechanics more scary and less frustrating, as per Richard’s suggestions.
Development is going better than ever right now, and I’m very excited for the coming weeks of development.