Fortitude has taken significant leaps forward in Week Thirty, with its latest update (version 1.1) adding a few much needed general features and mechanics as well as further progressing the game’s overall narrative structure.
The week began as it usually does on a Monday, with me sitting down at my desk in the morning, opening the game’s Unity project and reviewing my Weekly Walkthrough from the previous week which detailed my plan for this one. The main plan for Fortitude 1.1 (this week’s update) was to implement more of the game’s narrative; specifically the tutorial side of things, including teaching the player about basic controls and refueling. On Monday however, spending hours meticulously designing tutorials wasn’t exactly screaming appeal to me, so I decided to focus on something else instead, pushing the narrative work until a later point in the week. A few days before finishing Fortitude 1.0, I had encountered issues with the creation of the Rogue Planet Event which resulted in me having to completely disable all the asteroid-related debris that was floating around in the game’s Solar System. This wasn’t a huge issue as the asteroids badly need a revamp anyway, and so I decided to spend Monday working on that instead; a complete resign of orbital debris.
I began by grabbing the various placeholder designs for asteroids that Josh had given to me earlier in the semester, and started playing around with layouts and tinkering with the effects that the debris had on the player. As I did this, I also had the game’s narrative in my head (as I just happened to be thinking about it at the time) which then gave me an idea; why not incorporate some kind of story or event into the asteroid fields of Fortitude as well? With this in mind, I began thinking about how the player would react in such an environment, as well as what their general priorities would be at the time. This then led me to the idea of Fuel. It’s a very precious resource in the game, with it only being available within dangerous gas giants. What if then, I theorised, there were to be occasional Fuel Clouds within asteroid fields too? Not many of course, as we want the player to experience gas giants, but little pockets of Fuel that would keep the player going for just a little while longer.
This was the end result of my subsequent idea generation and GameObject tinkering; a large number of asteroids both large and small, slowly rotating around a central Fuel Cloud, which would form the centre of the asteroid field overall. After much playtesting with the positions of the various asteroids I settled on this formation as it is quite difficult to navigate with the ship (not to mention dark and scary, so torchlight is a necessity), and often I found myself forced to leave it parked outside, resulting in quite a nerve-racking navigational experience as I had to then venture towards the Fuel Cloud on foot. I still however felt that something was missing. That event I had been thinking about just wasn’t there, yet.
The more evil side of me then started to take over, and I began to devise a way to put the player in even more danger. I made the asteroid field overall a great deal larger than before, and then placed a series of very tiny asteroids on the outer edges of the field. Said asteroids are completely disabled and unseen until the player enters the Fuel Cloud, at which point they begin to move. The ship then warns the player of nearby orbital debris, but leaves its position unknown. The tiny asteroids move faster and faster towards the player’s location, caught in the slight gravitational pull of the Fuel Cloud. As they move, they fly into nearby asteroids, causing them to move towards the player as well. As there is no sound in space, the player is completely unaware of the cataclysmic destruction heading right for them. The ship then warns them of debris again, and the player wonders why do you keep saying that? It then dawns on them that its warning them of other asteroids, and they then spring into action, leaping into the Fortitude and blasting away just as the literal sea of asteroids crashes into the area around the Fuel Cloud, causing complete devastation everything around. The player escaped, but only just.
That’s the ideal situation in which that event would unfold, anyway. It’s tense, scary, and you barely escape with your life.
The final Asteroid Field design – note the Fuel Cloud in the centre (in terms of scale, the player is less than half the Cloud’s size)
With the new Asteroid Field designs then completed, I found myself on a bit of a roll in terms of atmospheric game design, and so decided to tackle another previously neglected aspect of Fortitude; lighting. A basic light system had been introduced back in Prototype 0.7, but other than providing lights for the Fortitude to shine about, no other GameObjects are affected by it. I spent much of Tuesday rectifying this situation, by adding light sources to all of the planetary bodies as well as experimenting with sunlight on the surface of Elcalowda (as its always been our planetary surface for testing things). The results at the end of a day of tinkering were quite conclusive; the game looks a great deal better with actual lighting. Take this screenshot as a good example;
The sunlight on Elcalowda really helps to make Josh’s planetary designs stand out, and the gradient between the sunlight on its left side and the relative darkness on the right really makes it seem like an actual planet. I later relayed this and several other screenshots of the new lights to Josh, and he agreed (quite considerably, actually) that the game looked far better as a result of the new implementations, not to mention a lot more atmospheric (as lighting does wonders for atmosphere, see pretty much every game/movie ever as evidence).
Wednesday then rolled around, and spurred on even more by these recent game design successes, I decided to go back to some of the implementations of Fortitude 1.0 and improve on them – specifically tackling the mechanics of planetary landing. Last week I had added an atmospheric wind system to Elcalowda, making navigation through the planet’s atmosphere a great deal more challenging than it previously was. However, it wasn’t quite as scary or as nerve racking as I wanted it to be yet, and even right after creating Fortitude 1.0 I knew something was missing from it. The first change I made was taking the current trajectory line from the game’s map and adding it to landing, so that the player can view their current movement direction at all times. Since the map is not usable while on a planet (due to design reasons and also because disabling navigational assistance during landing makes it a bit scarier) the player will need to rely considerably on this and the distance counter (which tells them how close they are to the surface).
I then spent a little while researching how planetary landing works in real life, in order to get some inspiration on how to further improve the game’s landing mechanics. Major inspiration then came from watching various clips from the 2018 movie First Man, which is a biographic drama film centred around Neil Armstrong and the Apollo 11 moon landing. This clip in particular caught my interest;
Note how scary the entire sequence is. For a brief moment about two minutes in Neil gets a slight window of tranquility, and then as his ship tips back towards the atmosphere of Earth things start to get very tense. Here, the camera pays particular attention to Neil’s altitude counter, which constantly tells him how far away he is from the planet’s surface. The camerawork overall here is quite extraordinary, as it really makes you feel like you are inside a small craft plunging into the atmosphere of a planet, and it really sells this idea of tension and fear in particular. First Man is particularly renowned for its realism in how it tackled portraying outer space, so I was keen to take as much inspiration as possible from it, particularly of its landing sequences.
Since the distance counter forms a major aspect of planetary landing both in First Man and in planetary landings in general, I decided to move it out of the game’s UI in the top left corner and instead place it right in the centre of the screen during landing, just to the right of the Fortitude ship. One thing that I also took particular note of during my research was sound (wind especially) so I grabbed a placeholder wind sound effect from YouTube and added it into landing, also making it become louder and louder the further the player went into the atmosphere of Elcalowda (as it once again became the testing ground). In the clip from First Man, the camera also shakes quite considerably in order to get across the roughness of space flight as well as the difficulty Neil was having in controlling the ship, so I knew that needed to be implemented too. Camera shake was actually a tad easier than I thought it would be, and after grabbing and modifying a few lines of code from a Unity tutorial online, that was in the game too. Like with the sound effects, the shaking also gets more intense the closer the player gets to the surface.
Finally, after a few consultations with Josh and a great deal of playtesting, I decided to lock the zoom level of the player camera for landing, completely disabling the scrolling in and out zoom mechanic for the event. I then zoomed the camera quite close to the ship, so that you can only really see the ship itself, the distance counter, trajectory line and a few small bits of the environment around you. In First Man, one thing that particularly struck me was how little Neil could see of the world around him. The craft he was in only had a couple of small windows which showed very little, particularly when he was in the upper atmosphere. The camera also payed far more attention to the altitude and Neil himself over the outside view, keeping a somewhat claustrophobic feel throughout the entire experience. For me, this was what added the most in the way of fear into the scene, as it plays right into the fear of the unknown; you can’t see whats outside but you know you’re in danger, which makes it infinitely scarier.
Afterwards, the result of all of these new implementations in the game was quite extraordinary. For me, the entire experience had actually been transformed. The combination of the new sound effects with the now much larger emphasis on the trajectory and distance measurements, as well as the locked zoom which put focus on the ship rather than the environment (and increased the fear of the unknown tenfold as you couldn’t see nearby winds that could throw you off course) made the experience of planetary landing so much scarier. As the player, you must now constantly keep the ship upright while fighting atmospheric winds as well as keeping a keen eye on the distance counter, which all together make landing a pretty terrifying and indeed thrilling experience.
Additionally, the shaking and winds now start to fade away once you hit a thick cloud layer near the surface, and sunlight begins to bleed through as you get within thirty metres or so of the ground, allowing the player to breathe slightly and placing a large emphasis on actually landing rather than battling atmosphere in the final moments of the game event, which is also a major improvement on the experience. It’s not quite perfect yet (as it needs full playtesting with other people and a bit of tweaking) but overall, planetary landing has taken considerable leaps forward in 1.1, and I would now consider it one of the game’s best mechanics.
Thursday then rolled around, and it was then that I decided that I should probably begin working on the game’s tutorials. It isn’t exactly the most enticing design aspect of the game so I admit I had been avoiding it, but they are a necessary part of the game and they needed doing, so I finally set about working on them. After a little while, I actually began to enjoy it as I was rather pleased with my UI designs and aesthetic. The end result of the first tutorial (refueling) was then this:
It’s not perfect yet, but the overall aesthetic is there for the most part. It takes considerable inspiration from design ideas that Adam gave me before the Easter break, particularly the idea of using images of the game’s various design work in order to make the tutorial very clear and more aesthetically pleasing i.e. using a clear image of a Fuel Cloud and a gas giant to show what Fuel looks like and where it can be found. The text is as minimal as possible, giving the player only necessary information that they will need to enact refueling in the game. The font choice is from the DELTA-V Trailer that I created back in January, as I feel it fits well with the game overall; being quite outer-space-y but not so much that it looks like font from a Sci-Fi movie. In terms of fitting with the tone of the game, I think the font is pretty damn near perfect. In terms of colour usage, I used specific colours that would stand out but also fit with the colour scheme of the game, for example the blue is the same blue of Unity’s Trail Renderer’s so it blends with the map, the red is the same as the trajectory line, and the white just looks nice against a black background.
With the refueling tutorial done, I was on a bit of a roll UI-design-wise, and so decided to take it one step further by implementing something that the game had badly needed for a while now; a Pause Menu.
It uses the same aesthetic design as the refueling tutorial, with the same font and colour schemes as well as font sizes and general design ideas. One thing I was also keen to add were the controls listed on the right hand side, so that if the player ever needed a refresher on the game’s controls then all they had to do was hit ESC. Additionally, I made the menu ever so slightly transparent, so that you can still see the game as it currently is behind the menu (for example – in the image above, the player is in the game’s map).
The game’s opening tutorial then followed suit, again using this new templated Fortitude UI aesthetic to illustrate the basic controls of the game as well as giving the player hints and clues towards their objective in Fortitude (i.e. making contact with advanced extraterrestrial life) as well as the limited time they had to complete their task because of the incoming Rogue Planet Event. Unlike the other UI designs however I wanted to make the opening of the game quite dynamic, so I added a fade-from-black to intro the game followed by a series of animations that slowly fade each paragraph of the tutorial in and out, giving the player time to review each one individually. Finally I also added a skipping function for returning players, with the ENTER key now skipping the tutorial entirely so that they don’t have to suffer through it if they’re just playing again. The full opening of the game can be viewed here:
It’s not perfect yet either, with some elements that most certainly need changing (like Josh pointed out that the text is a tad small) but overall it functions adequately as a tutorial, telling the player just enough to get them started without giving the entire game away. I then coded in the refueling tutorial to appear once the player’s fuel levels went below 40%, a pop-up which is then also reviewable upon pressing the T key.
Friday then rolled around, and I was just about ready to wrap Fortitude 1.1 up for the week (as its been a big update, hence the big Weekly Walkthrough) but the week had other ideas. Lying in bed early on Friday morning, I was thinking about the game’s map (as I had Fortitude on the brain at this point) and how much I didn’t really like the instant change between controlling the ship and entering the map. It had been suggested in playtests months ago that there was a bit of a disconnect between gameplay and the map, and so I decided to spend Friday tackling that issue.
Since all the map is is just a massive zoom-out of the game, I decided to Lerp it rather than insta-change it, essentially making it so that upon hitting M the game actively and animatedly zooms out, showing the player their exact location relative to the game’s world as well as how small they are in comparison to it. In order to make this technical achievement a reality however I needed some help, so I enlisted fellow Games Designer Dean for a few spare moments. His coding expertise is legendary amongst my peers, and so with his help my vision was fully realised, and I must admit that I would not have been able to do it without him.
He also however suggested something else at the time; since the new animated zooming mechanic automatically zooms the camera to map size and then back again upon keypress, the same could be applied to the rest of the game. namely it no longer really needed the camera scrolling in-and-out mechanic. I decided to test out this idea by temporarily disabling the camera scroll and using Dean’s new code to zoom the camera automatically in when the player was controlling the astronaut, and out when they were in control of the Fortitude ship.
The automatic nature of the camera movement had quite a polished feel to it, and was a great deal smoother than the scrolling-in-and-out game mechanic that we’ve had since the early days of the game. Replacing it wasn’t something I had particularly considered as I felt the scrolling was adequate, but playing the game with an automatic zooming function just felt so much better in terms of gameplay (plus it was one less control to worry about) so Josh and I decided there and then to use Dean’s idea, and scrap the scrolling camera completely. It was a feature that we’ve had for a long time and we were sad to see it go, but honestly the game is now so much better for it. The camera forms a central part of any game, and with Dean’s new code with its automatic zooming, Fortitude suddenly felt a hell of a lot more polished and aesthetically pleasing, so out with the old, in with the new I guess.
Reflection On The Week
Week Thirty has been a very busy one (I know I say that every week, but comparatively, number Thirty has been considerably busier) but as a result of my heavy coding throughout it, Fortitude has leapt forward considerably in terms of development and design. Several game mechanics have received complete overhauls that make them a great deal more interesting and better overall than they were before. This is particularly the case with the new planetary landing mechanic, as for the first time I feel that we have truly captured the fear of the unknown in a mechanic, as well as introducing tension in a unique way that really adds to the game’s overall atmosphere. Landing obviously still needs polishing and actual playtesting by people other than the developers, but I really feel that it is close to being perfect, at least coding-wise.
The new additions of lighting and Asteroid Fields also pushed Fortitude closer to completion, with the former adding atmosphere and generally making Josh’s designs look better than ever, and the latter adding intersting yet quite scary environmental dangers. The new tutorials also mark major strides forward with the game’s narrative, and the brand new camera system is simply the icing on the cake.
Next week, the plan is to introduce a few more of the planetary surfaces as Josh has nearly finished designing them all now (plus they now all need the same atmospheric treatment that the testing planet Elcalowda has received). If there’s time, I would also like to get cracking more on the game’s narrative, in particular focusing on Diadem’s Sentient Bacteria event, as the game’s story is the one department that Fortitude is lacking considerably in at the moment.
Things are going very well, but there is still a while to go.