This week’s Walkthrough will be rather a short one (much to the reader’s relief I’m sure) as it’s quite a short development week for me, with EGX Rezzed 2019 on Friday and a holiday to the misty mountains of Scotland taking me away from Fortitude until the end of next week. Despite this though, Prototype 0.9 is all done and dusted, and as a result I can safely say that the game is currently at its most stable and playable point yet.
Work began on Prototype 0.9 on Monday, and I knew already from last week that it was going to be another quality of life update; meaning a whole lot of optimisations, bugfixes and tweaks without much in the way of new content. While these updates tend to look smaller than the larger content ones, they are of course absolutely necessary to development, as new mechanics need to be freed of bugs and optimised to the point where they are as enjoyable and functional as possible. Last week’s refueling update was a large one, and while the game was fairly stable by the end of Prototype 0.8, there were a number of things that needed addressing.
Before I fully started on Prototype 0.9 though, Josh and I decided to have a discussion via voice-chat in order to talk about the current state of the game and how it would look going forward. Narrative obviously formed a large part of this, as we draw ever closer to the end of Semester two so time is running out, and the story is the only aspect of the development of Fortitude that currently isn’t in the game at all. As I wrote at the end of last week, my plan for the Easter Holidays was to try and implement as much of the narrative as possible into the game, and so I relayed this to Josh who absolutely agreed that it was a good idea. Our tutor Adam had also had a few ideas about how we could approach certain elements of the story, for example perhaps having a timer in the game that counted down to some apocalyptic event, so the player only has say half an hour to finish the game and escape otherwise they will die. Both Josh and I agreed that it was a great idea, as it would massively increase the whole fear aspect of the game as well as making it replayable (i.e. if the player fails, or if they succeed but don’t explore all of the game in time).
I then relayed my idea to Josh; why don’t we use the Rogue Planet Event (see the Design Document link in the menu above if you don’t know what that is) as this “timer”? My idea was that instead of having it appear in the sky with just one planet, it would appear in all of them, slowly getting larger and larger (thereby indicating how much time the player has left) before then eventually crashing its way into the Solar System, causing havoc and presumably killing the player. Narratively the idea fits rather well, although certain elements will need to be moved around (if the Rogue Planet is the destruction of the player then they obviously can’t land on it, so the Sentient Bacteria Event will need to be moved to another world). Adam had also suggested that we use each of the narrative events as a “checklist” of sorts, and so if the player completes them before the Rogue Planet hits, the end of the game will play (The Next Event) and they’ll get an answer to the “Are We Alone In The Universe?” question.
The Next Event concept – note the alien “hand” in the top right corner
With all these ideas in mind, Josh and I then discussed exactly what story events would make up this “checklist”, which then led to a list:
- The “Alien Ruins” Event on Elcalowda
- The “Ocean Monster” Event on Rika’s Moon
- The “Sentient Bacteria” Event on Estabahn’s Moon
There are a lot of things that need to be discussed and/or ironed out (i.e. if we also include the Containment Patrols Event that succeeds the Sentient Bacteria one in the Design Document, but this will depend on time as it is running out) but this list forms the basis of the game “checklist”, which will need to be completed before The Next Event can occur. It’s a good starting point, at the very least. Finishing up the discussion, I told Josh that I would begin work on the main Rogue Planet Timer mechanic as soon as possible in Week Twenty Nine (as I’m in Scotland in Week Twenty Eight) and we then parted ways, and I went back to coding Prototype 0.9.
Last week’s update had been primarily an experimental mechanics trial, and so a lot of experiments had just been left out in the environment and not everything had been cleaned up and added yet, so clearing all that away was the first task. The planetary body Estabahn had been the subject of rigorous testing in 0.8, so the first thing I did was fix up a few issues with it and add a bunch more Fuel Clouds and Nasty Clouds so that it was relatively gameplay ready. Heeding Richard’s feedback from the end of last week, I also spent a fair amount of time playtesting and fiddling with the various force-based variables of the refueling mechanic, which subsequently led to me drastically reducing the gravitational pull of the EstabahnSurface GameObject as well as the movement speed of the Nasty Clouds. These changes much improved gameplay, as the frustration switched up into excitement and at points, fear. The new mechanic wasn’t quite as unforgiving as it had been, but there is a fine balance between difficult and annoying.
With Estabahn more or less ready, I then set about doing the same with Rika, the other gas giant in the Solar System. Like with Estabahn, I spent a fair amount of time creating a surface counterpart for it and then adding a series of Fuel Clouds and Nasty Clouds throughout its atmosphere. Rika will be easier to get to in the final game as it doesn’t have an asteroid belt (and Estabahn will) and so Josh and I had discussed ways to make Rika more difficult in order to balance things, but I found here that the game had pretty much done that for us already. The Fuel Clouds and Nasty Clouds are coloured yellow and red respectively, and so they are easily seeable in Estabahn (as its purple), but Rika is (you guessed it) yellow and red, which made things a hell of a lot harder. Suddenly, while refueling you couldn’t even see the dangers that approached as they were often hidden behind red clouds of gas, and as I playtested I found that it increased by fear tenfold. Refueling was achievable for sure, but a lot more challenging with Rika. To finish up, I then added a few lines of code to the “AI” of the Nasty Clouds, making them affected by the gas giants gravity so that they wouldn’t fly off into space and disappear (as they had done in Prototype 0.8).
The new Rika “surface”
With the gas giants then in place and the refueling mechanic optimised to maximum fear and enjoyability levels (it was the end of Tuesday at this point), I turned my attention to focusing on adding a few heavily requested game mechanics that I just hadn’t gotten around to yet. For example, we have had an ongoing issue recently where no matter how high the resolution of Josh’s design work, when the camera zooms in, they start to become noticeably pixelated in comparison to the Fortitude ship. This was a particularly apparent problem in the various testing implementations of Josh’s surface designs. To combat this, Josh had suggested that we lock the zoom level of the camera while the player is exploring a world on foot, as it would solve the issue as we could therefore control how pixelated things get, and it also wouldn’t affect gameplay too much as zooming in isn’t really necessary while on a planetary surface. With this in mind, I spent a fair bit of Tuesday afternoon coding this mechanic in, and it now works pretty well. Once Josh’s surface designs are complete we can see just how well this locking-zoom mechanic works, but for now it functions as we wanted it to.
Another highly requested feature was an auto-rotation mechanic for when the player enters the atmosphere of a planet. Due to the way landing is coded into the game, when the player approaches a planetary body, they are transported (unknown to them) to a surface GameObject that is underneath them, pulling them downwards towards it with gravity. The issue is that if they approach a planet from say the east, then they will suddenly be facing to the right of the surface as opposed to down towards it (it’s a tough thing to explain, best shown in video really so check out this week’s Coding Walkthrough if you’re unsure what I’m on about) so the player will need to react quickly to rotate their ship upwards and slow down, otherwise they’ll die by splatting on the surface. To combat this issue, I spent much of Wednesday coding in an auto-rotation mechanic that (upon entering a planetary atmosphere) rotates the ship upwards regardless of its current rotation, so that it is ready to land without panic-induced input from the player.
Thursday then rolled around, and most of it was spent talking with Josh in voice chat as well as writing up various blog posts and finishing things up before the busy side of the week arrived. I spent a lot of the day bugfixing Prototype 0.9 and optimising various mechanics (for example giving the Entering/Exiting ship mechanic a long-awaited overhaul) and so generally making it as playable as possible. Josh had also finished up an early version of Elcalowda’s surface design, so I implemented that into the game in order to get a bit of an idea as to how that was going to look.
Josh’s early surface designs for Elcalowda, complete with Alien Ruins in the caves below
It looked very cool, and while there was a bit of a pixelation issue we pretty quickly figured out how to solve it. The problem was that the image Josh had provided was 30,000 by 10,000 pixels, but the highest image resolution that Unity can handle is 8192 by 8192, so it had automatically resized it to fit these requirements, thereby decreasing its quality massively. To combat this, Josh was going to split the environment designs into 4096 by 4096 (4K) chunks, so that they would not be resized by Unity and therefore hopefully fixing the pixelation issue once and for all. This will only be test-able however once the designs are complete, so fingers crossed that it will work (it most definitely should, but you never really know with Unity).
Reflection On The Week
As of right now (late Thursday evening) Prototype 0.9 is pretty much good to go. It’s relatively bug free, optimised and contains a considerable amount of requested changes and features that overall make it one of the most stable and playable game builds we have had so far. Tomorrow I’m off to London for EGX Rezzed, and then further to Scotland on Saturday, so as a result there will be little to no game development in Week Twenty Eight, and so no Weekly Walkthrough as there won’t be anything to report.
The plan for Week Twenty Nine however is to implement one of the most important aspects of the game’s development so far; the Rogue Planet Event. By the end of that week, the game will hopefully have at least one of its endings (the bad one where the Rogue Planet blitzes in and destroys everything) as well as a massive emphasis on the overall fear theme of the game that it has so far been lacking. Incidentally, that update will also mark Fortitude version 1.0, so I’ll do my best to make it a good one.
Overall, this week has been a pretty productive and useful one. Optimisations and bugfixes have gone pretty well, and everything is more or less going according to our new plan. Hopefully by the end of the holidays the narrative will be at least mostly implemented, and I am reasonably confident that we will accomplish this feat. Fortitude is nearing the endgame now, so fingers crossed we can make it the best it can be.