Brace yourselves, this is going to be a rather long post.
Having successfully completed Fortitude 1.5 last Friday, much of the subsequent weekend (and a fair chunk of Monday) was spent playtesting the newly-MVP game. My friend James was chief among said playtesters, as he had previously played a few small chunks of Fortitude before 1.5, and also became our longest playtester over the weekend as he played for a good four or so hours before eventually reaching the end of the game.
Other than his first playtest, we successfully managed to record James’ various experiences of Fortitude. They are available to watch below. Notable/interesting parts of James’ playtests have been listed along with short descriptions of what each video entails. Please note as well that a lot of the bugs and issues present in his various playthroughs have been fixed as a direct result of him experiencing them.
Session 1 – James attempts refueling (09:22), landing and swimming about in the subsurface ocean.
Session 2: James explores Elcalowda (35:35) and Diadem (55:50).
Session 3: James explores Elcalowda again (16:35) and experiences the game ending for the first time (02:01:40).
A different James (not the previous playtester James) plays Fortitude, with some rather entertaining results.
On the whole, the various playtests that Fortitude has undergone over the course of the weekend and Monday have been mostly successful, if not fairly bug-ridden. Original playtester James successfully managed to complete all of the games story, and the vast majority of his deaths in-game were as a result of him either becoming content or relaxing his concentration during critical points (as Fortitude has a wonderful way of punishing players severely for not playing attention). Of particular note was his reaction to the ending of the game (viewable in the third playtesting session video at 02:01:40) which he not only completely understood right off the bat (realising that he had wiped out the Universe as he watched the stars going out, we had thought this was fairly intuitive but it was a relief to have this confirmed in testing) but also subsequently praised heavily as the ending of Fortitude’s story.
The game underwent several other playtesting sessions that were not recorded, including a few from my brother and a couple others who had never played the game before. Most playthroughs followed a similar pattern; landing consistently took a few tries to learn but players nearly always managed it in the end. Refueling seemed to be the place where players died the most, and a few complained about the constant having to move the Fortitude because of the movement of the Fuel Cloud, so this has been improved for update 1.6. Narrative-wise, players pretty consistently enjoyed it, particularly the finale where they essentially wipe out the Universe by letting the Sentient Bacteria loose.
There were of course various bugs and issues that players ran into (a lot of which are in this week’s Patch Notes having been either fixed or improved) but on the whole, the game is fairly stable and quite playable. Also, if there’s one thing that became apparent quite quickly as we watched others play our game, it’s that they were either tense or scared nearly constantly. Landing seemed to be a particularly nerve-wracking experience, along with swimming about in the dark subsurface ocean of Estabahn’s Moon (following the size and sound improvements of the “Monster” in Fortitude 1.5, players encountered its surround sounds a lot more, resulting in many a fear). On the whole, other than the various bugs that did my head in watching them crop up, I felt that players mostly enjoyed the game (with most wanting to keep going even after dying), and that the narrative seemed to be the star of the show, with players taking particular enthusiasm towards Josh’s ruins on Elcalowda, the Sentient Bacteria event (though this was more being scared than enthusiastic) and of course the game ending.
Following the playtesting, much of Tuesday was then spent fixing the various issues and problems that had cropped up during the sessions. Refueling was something that I spent a fair amount of time on, making it so that the ship will actually sit still now while refueling is in progress, and making sure that the player has plenty of time to react after the ship audibly warns them of incoming destructive clouds (though not too much time, can’t make it too easy after all). I then bumped the fuel consumption of using the ship’s thrusters so that players will actually need to refuel in the game, and added audible and visual prompts for it just after the player finishes the Alien Ruins event (as fuel should be at about halfway at this point).
I then added a few rocks around some of the surfaces as some players had gotten stuck in deep areas of some of the caves, and increased the Rogue Planet timer as time had sometimes run out for players before they could complete the story. I also then added said timer to the ship’s HUD after the ruin symbols are translated during the Game Finale event, in order to increase tension by continually reminding the player of the ticking clock until doom approaches. Upon a few suggestions, I also added a few more lines to some of the game tutorials in order to better get across some of the game’s mechanics as well as giving the player a few more hints and tips to help them on their way.
With bugs mostly fixed (though no doubt more will crop up as time goes on) I then set about adding the last of the game endings; the “good” one. Currently, there are two distinct ways that the game can end; 1. completing the story and accidentally releasing the Sentient Bacteria out into the Universe and 2. the timer runs down and the Rogue Planet rips into the Solar System, killing the player and destroying everything else. The full ending is a bit of a twist on traditional story endings however, as completing the story (and the game) actually results in the bad ending, as the player destroys the Universe by letting the Bacteria out. Letting the Rogue Planet rip through the System and destroy everything is almost a good ending because of this, however I wanted to also add another one just to kind of “complete” the game structurally. We had already had this one in mind for a while now, so implementing it didn’t take very long.
Right up until the player becomes Infected with the Sentient Bacteria, they can now if they wish to fly the ship right out of the game’s Solar System, by simply flying away from the Sun and planetary bodies until they are off screen. Upon then exiting the System, a Game Over screen pops up, noting that the player has completed their survey for extraterrestrial life and that they have “nothing to report” as they haven’t completed the story therefore they haven’t found the alien life present in the System. This ending is the only one in which the player can survive, as they are left for dead in the story ending and obviously die during the Rogue Planet one. It also fits rather well with the other endings as it too is a twist; the player can basically win the game straight away by just exiting the System, though they won’t know this without trying to leave the System, and obviously they won’t get to experience the story this way. Both Josh and I were quite happy with this additional ending, as it combined with the other two endings basically flips traditional narrative on its head (which we thought was pretty interesting).
What the player will be presented with if they attempt to leave the game’s Solar System
What the player will experience if they dither too long and the Rogue Planet hits the System
To wrap things up on Fortitude 1.6, something that has needed doing for quite some time was finally done; replacing the placeholder stick-man astronaut with Josh’s now finished astronaut design. It was a big moment, and I decided to make it even better by taking the Fortitude ship’s new thruster particle systems (courtesy of fellow Games Designer Sid) and modifying them slightly, making them smaller and white in colour so that they looked quite misty, and I then lined them up on the new astronaut and coded them to function as astronaut suit thrusters, replacing the placeholder triangle system that on foot movement has had since well…the beginning of development. The new particles in combination with the new astronaut almost made Fortitude feel like a new game; it was the finishing content-based touch to our game, and it marked a significant point in its development; its end. Hand-in was fast approaching, and documentation still needed doing, and I felt that development had gotten to the point where bugs were fixed, mechanics were stable and the story was fully playable, thereby…it was done, at least for hand-in (as bugfixing and improvements will still continue afterwards for the degree show). It was a big moment, and I found myself slightly stunned at the time.
Creating the game’s documentary was up next. Essentially, we had to make a “making of” video of sorts as part of hand-in, a short video where we talk about the game and some of the decisions we had made, while interspersing bits of the game with pre-recorded videos of both myself and Josh talking. After doing some brief scripting on what we wanted to say, Josh and I had borrowed a camera and microphone from the Media Store and had filmed our interview clips last Friday afternoon. Unfortunately, the studio space we had hired to film in had a bit of a sound issue (it was rather echoey) so the audio wasn’t of the best quality, but being rather pressed for time, we continued regardless. With the game being more or less complete, I spent a fair amount of the remainder of Tuesday filming a complete story walkthrough for the game, which can be found both here and in the patch notes section for 1.6:
I then took the video and chopped up some clips of it, mixing them up with various other videos that I have recorded of Fortitude over the past few weeks. I then grabbed the raw video files of mine and Josh’s interviews from Friday, and spent a good few hours editing them all together into a documentary-esque three minute video, which can be viewed here:
Overall, I was semi-pleased with the documentary. We hadn’t had a lot of time to make it (due to being rather busy with playtesting, coding and documentation for these past few weeks) but I think it serves its purpose nonetheless. Both Josh and I talk about the premise and style of the game and briefly discuss some of the decision-making and thought processes that went into Fortitude’s creation, and this interspersed with various clips of gameplay I think really sells the concept of what our game is. To finish up, I then attempted to disguise the rather unfortunate audio quality with a background music track – The Landing from First Man. It’s the same piece of music that we used during the climax of our original game trailer from the end of semester one, so I thought it would be a bit of a throwback/coming full circle kind-of-thing, and tonally it also fits incredibly well with Fortitude. The dramatic nature of the music combined with its level of build-up works very well with the overall theme, and I think is the cherry on top of this particular video-based cake.
Things then went slightly…awry during Wednesday. Adam (our tutor) had wanted to playtest our game with a few other people for a little while now, as he had trouble with certain elements (landing in particular) and although he had eventually managed it, he felt that perhaps the game needed a bit more testing just to be sure things were intuitive and playable enough. I was quite keen to do this, as I felt testing was what Fortitude needed the most at the moment (especially after all the minor changes that had been implemented as a result of previous testing sessions) so Adam grabbed a few people and sat them down to play the game. The results however were somewhat…unfortunate.
During the opening tutorial, a lot of the players became restless, fiddling with the game’s controls and ignoring the actual tutorial. As a result, the ship usually exited autopilot and became fully useable, and so it started to drift around which confused players, and that combined with the fact that they didn’t know the controls (as they hadn’t payed attention to the tutorial) made their experience playing the game more confusing than actually enjoyable. In a post-playtesting discussion, Adam reckoned that the issue was that players were seeing a cool looking ship right as the game began, and so wanted to just fly it around far more than pay attention to a bunch of words appearing onscreen, which then caused the confusion as they wanted to fly so ignored the tutorial and therefore didn’t understand the controls. I related to this, as I have never been a big fan of game tutorials (hence why Fortitude’s one is as short and concise as possible).
As a fix, Adam suggested slowing down the fade-in-from-black effect at the start of the game considerably, so that the Fortitude ship would only be fully visible once most of the opening tutorial had played, thereby forcing the player to actually read the words as there is no visible ship to control. He also suggested moving the map elements of the tutorial around slightly, bunching the controls-heavy segments together at the end as he reckoned that would be more intuitive (as players were likely to forget things they had seen at the beginning versus the end, so best to have controls at the end). Another issue that some players had was with swimming, as the controls change from the on-surface to the in-space ones upon entering the water, and some players did not understand this and became confused. To fix this particular issue, Adam suggested adding a visual (text-based) and audible (ship AI) prompt to guide players through swimming, as well as updating the controls UI to reflect changes for swimming/being in space/walking on surface. His final suggestion was then to make the map’s blue objective marker appear in normal view too, so that the player always had a pointer telling them the way to go.
The revised opening tutorial ft. the new blue objective marker for normal view
It took a fair chunk of the day, but the various changes were implemented, and initial playtests were apparently much more positive (I wasn’t in the room for this, as I tend to tell people what to do during playtesting the game, so best I stay out of it). I must admit that these issues cropping up did stress me out somewhat, as having to change major elements of the game this close to deadline was somewhat nerve-wracking. Still, they seem to have greatly improved the game’s opening (according to Adam, anyway) so I’d say that they were very much worth it, stress and all.
At this point, the deadline was rapidly approaching, but Adam had one final suggestion for us, and it had been something that I had been considering creating for a while now; an itch.io page for Fortitude. Itch.io is a website where people can upload their indie games for free and allow others to play them (for testing or just to release their game) and Adam reckoned it would be a good thing to have for the degree show, not to mention how much it adds to the overall professional-esque feeling we were trying to go for (as we have both Twitter and Instagram pages for the game too). It took a little while (as most things do) but I eventually had the page set up and ready to go with the latest game build. Bugfixes and things will of course be continually updated on it, so feel free to grab the latest game build there:
And that’s it, ladies and gentlemen. The week is over.
Reflection On…Well Everything
So, the day is finally upon us – the day that university ends. As of right now (time of posting) the deadline is less than twenty four hours away. The game is finished (bar a few Known Issues) and things are pretty much all ready to go. Lastly though, I feel a rather lengthy reflection is due, so…enjoy?
Fortitude as a game started with a simple idea; looking up into the sky, being fearful of what you might find in the darkness of space, but pushing through that fear anyway in your drive to explore. It’s a theme that forms a pretty fundamental part of humanity, with the biggest example of it being the Apollo 11 mission to the Moon in 1969. We looked up at the Moon and decided that we wanted to go there, despite the fact that there could have been literally anything waiting for us up in the stars.
This “fearing the unknown but exploring anyway” theme now forms a central part of Fortitude as a gameplay experience, and based off of our continual drive to achieve this feeling the game throughout its development as well as various playtesting sessions and bits of feedback, it would seem that if there’s one thing our game appears to have really nailed, it’s this theme. Words cannot express just how worried I was watching playtesters playing Fortitude for the first time, plaguing myself with questions like is it actually scary? Maybe the fear of the unknown isn’t there at all. Maybe the game sucks. I had spent so long meticulously designing the landing and outer space exploration mechanics to be as in-keeping with this idea of fear – locking the zoom of landing to make it feel claustrophobic, keeping the background in outer space pitch black to emphasize just how vast the emptiness of space is, adding breathing and ambient noises to create atmosphere – these are just a select few of the long line of things both myself and Josh implemented in order to try and capture our fear of the unknown theme.
Watching people playtest though, I found that I became less anxious and more pleased as time went on. Obviously the players uncovered many a bug or gameplay feature that needed improving or implementing, but the one thing that seemed pretty consistent throughout was just how…scared the playtesters seemed to be. Landing seemed to make them particularly tense, with James (one of the first playtesters, see the Walkthrough for Week Thirty Four for a description of his playtest) being on edge every time he experienced the event. Probably the biggest indicator was the massive sigh of relief he always let out upon safely touching down on a planet’s surface, and it was an indicator that was shared by a good number of players.
Upon reflection, I do feel that Fortitude’s strength lies in its narrative. Based on watching people play and just playing the game myself, I found the scariest moments to be swimming around in the dark subsurface ocean of Estabahn’s Moon during the Ocean Monster event, or experiencing the ship malfunctions in deep space during the Sentient Bacteria event. One thing that had become apparent during my “fear of the unknown” research during semester one (viewable in the semester one menu above), was that things are generally a lot scarier with the suggestion of something rather than the something actually being shown.
What we don’t understand, we fear. What we fear, we judge as evil. What we judge as evil, we attempt to control. And what we cannot control…we attack.”. – Dan Brown
As a result, when designing the game’s narrative I was keen to actually show as little as possible. To suggest this idea of alien beings being present within the game’s Solar System, but never actually show them (not fully, anyway). This concept later led us onto designing the Sentient Bacteria event, where a microscopic (therefore unseen) bacteria infects the ship and takes it over completely. You as the player never see the antagonist, but its presence is suggested through sound design (eerie sound effects and distorted ship AI lines). This is a concept that keeps the player guessing right up until the end, and that was exactly what we were after, in a thematic sense. The Ocean Monster event is similarly designed, with a shadow moving around in the darkness of the water, sounding like a sea monster but never being visually shown. Due the near-blackness of the subsurface ocean, we felt that the idea that there might be something in there with the player rather than fully showing a “monster” was a far scarier concept.
As a result of all this careful designwork (it took a while to write the narrative to the point where I was happy with it) I feel that the game’s narrative is the best reflection of our overall “pushing through the fear of the unknown” theme. Playtesters for the most part appeared worried and even scared by the events of the game’s story, but they all persevered anyway. James was a particularly good example of this, being audibly frightened by what was happening to the ship, but wanting to find out what happened in the rest of the story, so pushing through and continuing anyway. Narratively-speaking, I think we have done particularly well with Fortitude.
Where there are strengths however, there are also weaknesses. Chief among Fortitude’s weaknesses was essentially…time. We aimed big with our design document from semester one, mapping out an entire Solar System and story to go with it, along with complex game mechanics and visual designs to go with it. It became clear rather quickly during actual development however that we might have bitten off a bit more than we can chew, and as a result a lot of things had to be cut down or removed completely from the development plan. This was of course a massive shame, but a sadly necessary one.
To reach the “perfect” game level that we envisioned during semester one, I reckon that Fortitude honestly needed about a year of full development. It’s a big game (featuring an entire Solar System, after all) and many a mechanic, refinement and bugfix was initially planned that had to be cut simply because we just didn’t have the time. Certain game aspects took priority over others, and while I do now feel that those sacrifices were necessary for the overall quality of the game, they weren’t ideal.
Probably chief among the “Cut Content Crew” was the game’s environment. In our semester one plans, we had planned to completely design the game environment during the month of March, but these plans quickly fell apart as development continued. Getting the art style exactly right and then actually drawing each of the planets took Josh far more time than we had anticipated, and learning how to then code these and various relevant mechanics into the game took me far longer than I had expected. In semester one we had far less developmental knowledge than we do now (as we learned a great deal during this semester) and so had to plan based on theories rather than actual experience, and our theories ended up not being even close to estimating just how long certain gameplay elements would take to implement.
As a result, a great many elements from each of the planets had to be either severely cut down or scrapped entirely. You can view the Design Document in the menu above for the full plans for the semester (and so what did and didn’t make it into the final game) but I’ll give a brief list here. We had for example planned to have biomes on planets, with Elcalowda for example having both dust and snow areas, but this was cut as we quickly realised just how long designing one biome took. Weather took a big hit, with storms becoming a constant on the moon of Estabahn and Rika and disappearing completely from Elcalowda, simply because I didn’t have the time or technical expertise to implement them. A lot of the specific environmental features were also cut, such as trees and lush map areas, and the original plan was to have far more simple life (like animals) than ended up being in the final game, though animals specifically were removed not only because of time but as we felt their presence would be detrimental to the overall fear of the unknown theme. Planetary bodies themselves also had to be cut down, with several Moons having been not implemented or removed completely from the final game as they weren’t as closely relevant to the game narrative as others, therefore they weren’t a priority.
Narrative was of course the biggest priority of Fortitude, with work on it starting literally as soon as it was possible (design work for the Rogue Planet event for example began before the planet was even in the game). Worlds and environmental features that weren’t particularly relevant to the overall story were either reduced or cut, with the only notable exception being Rika’s Moon (which had initially been part of the story, but its part was cut as it felt unnecessary and dragged the story out).
Game mechanics got a fair amount of full development in the first few months as Josh was busy working on the game’s environments, so as mechanics go they are fairly refined, however they could for sure do with some improvement. For example, knowledge-wise I now know a lot more about the inner workings of Unity as an engine than I did at the start of development in early February, and as a result the building blocks of the game’s code made in February are somewhat…rickety in comparison to later code. Reviewing it I have found myself questioning my past self’s coding decisions on more than one occasion, but due to the fact that said code forms the backbone of the game (things like the Fuel System and basic movement mechanics) massive changes were difficult to implement at best.
One major mechanic that was cut quite early on was the Vector Prediction. In concept, this was a dotted line that eminates from the Fortitude ship and points towards the players current and predicted trajectory, telling the player not only where they currently are but where they are going to be heading if they stay on their course.
A very basic version of this mechanic was implemented into the final game (the red trajectory line) but the planned version was far more sophisticated. It however would have taken considerable time and effort to code into the game due to its significant complexity, and I didn’t have the time or the expertise (I’ve never been particularly good at Maths, and this is a very Maths-heavy mechanic) to create it, so it was sadly cut.
Sample collecting was something that we had envisioned during the creation of our concept trailer at the end of semester one, and it too ended up being cut, though for more reasons than one. Not only would it have been a fairly large and time consuming mechanic to create, but as time went on we felt it became less and less relevant to Fortitude, not to mention being quite dull (like who honestly wants to land on a planet and collect samples) so it too was removed from the plan.
The game’s narrative also had a few fairly significant redesigns during development, with the Rogue Planet for example playing an entirely different role in the final game than in the design document. Originally it was an explorable world, and home to the Sentient Bacteria, but this was switched to Diadem as our tutor had suggested the idea of a ticking clock to add emphasis on the overall fear theme (as time limits create tension) so the Rogue Planet’s role was changed to it being an incoming and visible threat in the sky rather than a planet that simply appears towards the end of the game. This change also meant that the Rogue Planet wouldn’t need to be explorable, which was another thing that then ended up being cut in order to save time.
The game’s ending was also changed significantly, with the original (and more happy) finale being the player getting to meet the aliens who created the ruins on Elcalowda, and the new one being that they have accidentally released a destructive force out into the Universe which then wipes everything out. It’s a far more scary ending than the original, but both Josh and I feel that it works far better with the game overall, being much more in-keeping with that “fear of the unknown” theme. Besides, the game does also have two alternate endings where you can “win”, by either letting the Rogue Planet blitz in (and destroy everything including you, but the Bacteria is stopped) or by simply leaving the Solar System right at the start (this is the only one where you get to live). Josh and I were particularly pleased with that last one, as it completely subverts expectations in a videogame (normally you can’t just win straight away) but also players are not likely to do it, as they likely won’t think its possible, and even if they do, they’ll want to experience the story rather than just end the game there and then, thereby dooming themselves simply by wanting to know more. Curiosity killed the cat, and the Fortitude too.
As you have probably gathered by now, time was our biggest enemy during the development of Fortitude. Given more of it, I would have liked to see a few more planets in the game’s Solar System that aren’t so relevant to the game’s story, so that the overall gameplay experience could be expanded somewhat, with an even bigger focus on exploration (as perhaps on some worlds you find nothing of interest, which would then emphasize the worlds on which you do find something). Environmental assets such as biomes and full weather systems would also have been cool, along with more emphasis on the outer space aspect of exploration, as although there are Asteroid Fields in the game, they are nowhere near as detailed or frequent as we would have liked them to be. Due to our time constraints, the game also still has some placeholder assets, with the most prominent example being the clouds in the atmospheres of planetary surfaces, as they were sourced from Google and Josh simply hasn’t had the time to fully design replacements in time for deadline. Asteroids as well needed a bit of a visual overhaul, so given more time that would have been a priority too (not to mention the asteroid-heavy ring systems that had to be cut because of performance issues). Additionally, we would have liked to have custom made all of the game’s sound effects (as a few are sourced from royalty free website freesound.org).
Bugfixing has also been a fairly significant issue for much of the semester. As it is such a large game (being set in an entire Solar System with a bunch of complex mechanics and a full narrative) I often found during weekly coding updates that the week’s various content implementations had broken the previous weeks, or caused significant bugs with other parts of the game due to the new content conflicting with the already implemented. If there’s one thing I now have as a direct result of developing Fortitude it is a newfound appreciation for quality assurance testers for games, as I see now why they are so important. Just this week alone we have made a significant number of gameplay improvements and bugfixes to the game, and those are just the ones we caught. No doubt there are quite a number of bugs that we have yet to discover (not to mention the Known Issues section of this week’s Patch Notes) and being a game of this size with such a small team (only two of us) we are never going to find them all, no matter how hard we try. Bugs have and likely will continue to be one of Fortitude’s largest issues, as we are still fixing them right now, preparing the game for the upcoming London and Winchester shows. This does also feed into the largest problem we had (time) as Fortitude could do with a bit more polish for sure, and we’ve done as much as we can, but being the large game that it is, we haven’t had the time to do all of it.
On the whole though, I find myself particularly pleased with how Fortitude turned out. I do feel that if there’s one thing that we nailed its the “pushing through the fear of the unknown” theme both in gameplay and narrative design, and this was our biggest priority even right back in the planning stage, so mission accomplished there. Mechanics-wise the game is more or less where we wanted it to be, with flight in particular having been quite well refined throughout development (and being rather fun) and things like remote control and autopilot systems being really cool features that I am rather proud of. Narrative is as I said the thing I am perhaps the most pleased with, as I think each of the game’s various story events both add to the overall theme and are just…fun as a gameplay experience. Environmentally of course I feel is where we fell short, and given more time and perhaps more expertise (a few more team members for example) I feel that we could’ve gotten it where we wanted to be. It’s a shame, but despite this I do think that Fortitude is a good game overall, and I am rather proud of it.
I have also learnt a considerable amount in terms of coding C# and the Unity Engine itself during the game’s development, overall feeling that I am now far more competent with coding now than I was back before development began. I have learned and experienced a tremendous amount not only during this semester but on this course, and in all honesty I wouldn’t have missed it for the world. These past three years have been some of the best of my life, and never in my wildest dreams did I envision that I would actually be able to make something as complex and cool as Fortitude. It has truly been a passion project for both me and Josh, and although there have been times of stress and anxiety during development (many, many times) on the whole, I am quite proud of ourselves.
I think this particular blogpost has gone on long enough. I should probably go and playtest the game for the billionth time, so wish me luck.