Week Twenty Five – Walkthrough & Reflection

Week Twenty Five has seen a fairly significant leap forward in terms of development for Fortitude, including framerate optimisation, a basic autopilot function for the ship as well as the basic groundwork for a full lighting and sound system. As usual it’s been a rather busy week, but a productive one nonetheless.

The plan for me this week was to create Prototype 0.7, Fortitude’s next quality of life update. Josh would primarily spend the week working on environmental designs for Elcalowda, which would then be fully implemented into the game during the subsequent week (Twenty Six). One of the biggest issues that has arisen with development in recent weeks is the game’s frame rate, as the large amount of physics and scripts running sometimes causes significant lag spikes as well as general FPS drops (sometimes even into the low twenties). As a result, I began Monday by playtesting the game in its current state and at the same time looking at Unity’s inbuilt performance analyser in order to see what the biggest cause of the framerate drops was.


Unity’s performance analyser

As I had previously suspected, the issue lay with the large amount of Asteroids implemented in the previous week’s prototype. As each one of them has scripts attached as well as inbuilt physics, all of them together were causing quite a dip in performance. The other significant effector was the game’s TimeScale changer, a mechanic that was implemented due to the game’s large world size and so rather lengthy and sometimes dull flight trips. Increasing the TimeScale however had a significant effect on the game’s performance due to the fact that if say the Time was increased to 20x normal speed, the computer would have to calculate physics 20x faster than normal, which as you might expect caused some pretty serious performance issues.

In order to combat these FPS drops, I set about trying to minimise the game’s calculated physics at any one time by adding to the newly implemented Optimisations script from Prototype 0.6. Thinking about how to tackle the problem, I considered that the Asteroids are only really going to matter to the player when they are close by. Hypothetically, if they were to be disabled completely when the player gets further than a certain distance away from them, it wouldn’t have much of an impact on gameplay as there is no way to track said asteroids (as they are too small for the map – deliberately so for added danger) and no real reason to follow them around.

With this in mind, I added a few lines of code to the Optimisations script that essentially disabled any Asteroid that was further than a thousand Unity distance units away from the player, and then re-enabled them if the player got closer. This implementation had a pretty significant impact on performance, boosting it from random below-20 drops to a near constant 70FPS. The only issues experienced as a result were when the TimeScale was increased to above 10, at which point the framerate still dipped. Unfortunately though, there isn’t a whole lot we can do about that, other than further limiting how high the TimeScale can go, due to the large amount of physics-based calculations the game will have to do that impact performance.

Tuesday then rolled around, and with game optimisations largely complete and framerates back up to acceptable levels, I decided to try experimenting with the one thing that Fortitude kind of lacks at the moment; atmosphere. Due to the fact that not everything has been implemented yet and the game of course is still in prototype stage, the game currently lacks that “fear” aspect that we had envisioned, and so I decided to spend Tuesday experimenting with trying to implement that, at least on a basic level. I began with sounds, as in previous weeks we had chatted with a composer who suggested that we use sounds (in particular sound effects) to create atmosphere and add to the overall theme of fear in the game.

To start with, a found a “bump” sound effect on YouTube, and then edited it in Audacity to sound muffled – this was because of another suggestion from the composer – as there is no sound in space, any sounds should be heard from the perspective of the ship, so if it bumps into something for example then the player should hear a muffled metallic bang. With this in mind, I added a new script entitled “Sounds” and then wrote a few lines of code that enabled the new sound effect whenever the Fortitude ship collided with something in space. Then I found an engine sound effect and edited it similarly in Audacity, subsequently adding lines of code that enabled the sound whenever the player uses the ship’s thrusters. While later playtesting the new features, both Josh and I noticed a small but definite difference in game atmosphere. For example, the new sound effects made the game a tad scarier as well as making you as the player much more cautious about crashing into other GameObjects as the modified “bump” sound will play. Just from adding two sounds into the game there were some fundamental differences in how we perceived the game.

It was then Wednesday, and I spent much of the day continuing with my atmospheric experimentation, encouraged by the results of the previous day. Having fiddled with the idea of sounds, I decided to try and implement a basic lighting system as well. There is of course a Sun in the Solar System in which Fortitude is set, and so the first thing I did was add a rather large light source onto the currently placeholder star to see the difference it made to the game’s visuals. It of course brightened everything up, as at that point in time the player was positioned near Elcalowda, which is quite close to the Sun.

While I was then tinkering with the brightness and range of the light source, I then noticed something rather interesting. Changing the brightness levels or moving the player away from the Sun made the game very dark (rather obviously) but it was in the darkness that things got particularly interesting. During actual gameplay, the asteroids implemented in Prototype 0.6 were suddenly barely visible, and due to the fact that they move around, suddenly the game became a hell of a lot scarier. The idea that there were things moving about in the darkness that you could not see as you flew the ship around was a particularly frightening concept, and so I decided to capitalise on it even further. I added a small but powerful spotlight onto the front of the ship, so that anything in front of the Fortitude was lit up. This made playing the game a lot more atmospheric, as having to search for nearby moving asteroids as you carefully navigate a large field of them was made a lot more interesting with only a small cone of light to guide you forwards. This new lighting in combination with the sound system I created on Tuesday had suddenly given Fortitude an atmosphere, as well as massively increasing the overall “fear” theme of the game. This was of course only a small amount of progress, but it was exciting nonetheless.

A video of some of the antics that arose from the new game mechanics

Thursday was then spent refining the new sound and lighting systems, as well as generally adding various quality of life things that needed to be implemented before bigger mechanics could then be added into the game. One of these was a simple autopilot function for the ship, with the idea that it would be used during refueling. Since refueling takes place within the outer atmosphere of gas giants and can only be done while the player is outside of the ship, one issue that we quickly faced was the planet’s gravity. Essentially – if you get out of the ship, it will float away quite quickly. To combat this, the new autopilot function makes it so that upon pressing the Q key the ship takes the current velocity and angular velocity of itself, and then applies an equally opposite force to it, essentially slowly coming to a stop and then keeping itself there, despite any gravitational forces pulling on it. This function of course uses a significant amount of Fuel and leaves the ship rather vulnerable to nearby dangers, so the player will need to be a quick refueler in order to survive.

To accompany this new mechanic, I then spent some time on a second attempt to implement a tether rope into the game – one that ties the astronaut and the Fortitude ship together. This had previously been attempted a few weeks ago, but it had been a rather buggy and glitchy endeavor and so it had been abandoned quite early on. This time however I had consulted several YouTube tutorials and was confident that it could be done, so I set about constructing it. This time around it actually worked quite well, successfully holding both the astronaut and the ship together in a rope-like fashion. It was still kind of buggy, and due to the fact that there’s no gravity in space, the rope did behave a little erratically (this is realistic though, see movie Gravity for why ropes in space are an unfun idea) but overall the mechanic worked as intended. The idea behind it was that the ship using its autopilot function could stay in one spot while in the atmosphere of a gas giant, and by successfully tethering the astronaut to the ship it would prevent them from flying off as well, enabling a successful refueling adventure. As of right now the Tether is disabled as it still needs to be refined and the bugs ironed out, but overall it works quite well, and so refueling as an event just got a lot more interesting.


The new “Tether” mechanic and lighting systems

It was then Friday, and I spent the day generally refining the various mechanics from the week as well as fixing up optimisations and polishing the prototype. Next Monday we have another playtesting session, so I was keen to get the game as playable as possible in time for that. With the game’s new atmosphere being closer than ever before to the overall “fear” theme as a result of the newly implemented sound and lighting systems, I felt it was high time to kick the excitement up a notch or so for the playtesters. Adding in a few asteroids as well as fiddling a bit with some of the orbiting scripts, I added the game’s first “event” into the prototype. After about a minute or so after starting the game, a large group of asteroids now ploughs into the asteroid field at high speed, causing much destruction and mayhem. This in combination with the new mechanics and general gameplay improvements since the last playtesting session should hopefully make the prototype quite an experience for the players of next Monday.

The rest of the day was spent talking with Josh about the environmental designs for the game, in particular looking at the scale of the worlds in comparison to the size of the ship and astronaut. As Josh finishes up the designs and they are implemented into the game, scale is going to be something that will need to be continually tested and refined until it works well with gameplay and most importantly interacting with the game’s overall theme. Environmental designs are about to take centre stage in the creation of game prototypes, and so development is likely going to take significant strides forward as a result.


Reflection On The Week

Week Twenty Five has been a highly productive and interesting one overall. As per the plan from the end of last week, the game has been successfully optimised and refined to the point where stable 70+ FPS is more or less constant, with the framerate stutters and dips from previous prototypes pretty much eliminated. As a result of this early success, I spent much of the week experimenting and tinkering with early sound and lighting systems, and met much success as Josh and I both felt that they significantly added to the overall tone and atmosphere of the game as well as taking the largest leap forward so far in implementing the “fear” theme into Fortitude.

Next week, Josh will have finished up the surfaces designs for Elcalowda, so the main plan for the week is to fully implement them into the game, and so by the end of the week we’ll hopefully have the first fully designed and explorable planetary surface in the game. As per usual, various bugfixes and improvements will likely occur, and once again I will attempt to put James’ vector prediction mechanic in the game, hopefully with his help as a lot of the code is beyond my mathematical expertise.

Things are going quite well at the moment, so long may that continue.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s