Development returned in full force this week, and by the end a fully functional Prototype 0.6 had emerged. Like usual with this game however, it didn’t go without a hitch.
Monday kicked off the week (as it usually does) and I and I imagine most of Year 3 spent it finishing up the Reflective Journal option module. For me, Harvard referencing all of my various sources for the module took up the bulk of the day, but I did manage to hand in on time, so victory was indeed achieved.
As a result, it was Tuesday that finally saw the full and triumphant return of Fortitude‘s development. The original plan that I came up with in Week Twenty Two (which was scheduled for completion in Twenty Three but Reflective Journal got in the way) was to create Prototype 0.6, the first “quality of life” update for Fortitude. Essentially, it would add all of the requested features and fixes from the playtesting sessions as well as generally refining mechanics and adding missing assets and gameplay elements. It would be more of a “bugfixing and optimisation” update than adding major mechanics, but this was necessary due to the high volume of unrefined mechanics added to the game in the past two months, as some optimisation and coordination needed to be implemented.
With this in mind, on Tuesday I set about creating Prototype 0.6. When the orbital and landing/takeoff mechanics were added in Prototypes 0.4 and 0.5.5, only a select few of Josh’s fully designed planets and moons were actually implemented into the game, as some were not created yet and I wanted to keep the mechanics as simple as possible until I had fully implemented and refined them. Now though (in 0.6) it was time to fully add the remaining worlds and complete the initial environmental design. I tackled the Rogue Planet (Karkarus) first, adding in its various textures and then fiddling with the “orbital rails” script in order to make its orbit a bit wackier than the other planets. The remaining Moons and worlds were then added in standard orbits, and the whole thing went pretty much without a hitch.
In Week Twenty, Josh and I had come up with a plan to significantly reduce the amount of environmental designs we would have to do, by making a few of the game’s worlds un-landable for various narrative reasons (i.e. dangerous atmospheres, toxic elements etc.) so that we wouldn’t have to design the surfaces for those worlds (as it takes a great deal of time). The removed planets were not really necessary to either the narrative or game, so in terms of impacting gameplay this plan made little overall difference really. Additionally, the plan would allow us to focus on designing the world surfaces that mattered (such as the Rogue Planet Event’s one) and overall would give us more time to make the game as good as we could make it. We had decided at the time to not implement the plan yet as we had yet to run into developmental problems, but now in Week Twenty Four, Josh and I decided to go with it. We are currently just over two weeks behind schedule with environmental designs, and the proposed removal of some planetary surfaces doesn’t have a massive impact on the game overall, so we decided to do it.
The proposed “plan” for cutting game elements from Week Twenty
With this fully implemented, the number of necessary planetary surfaces was down to four; Elcalowda (for the ancient ruins), Rika’s second Moon (the ice moon with the oceans and “sea monster”), Estabahn’s moon (the volcano moon which would just be nightmarish for a player to explore, so adding to the overall “fear” theme) and Karkarus’ Moon (for the sentient bacteria narrative event). Each area is necessary for narrative and thematic elements in the game, with the cut ones being much less so (Diadem for example is a barren Moon-like rock, so little is gained by having it explorable in the game). As a result, I spent the remainder of Tuesday making each of these four planetary bodies “landable”, using copies of the placeholder surface for Elcalowda in different colours as each world’s surface. Implementing them also went largely without a hitch, as it was mainly a case of adding to the landing/takeoff mechanic code already created for Prototype 0.5.5.
It was at this point in the day when we discovered that James (the course’s coding expert and our second year tutor) had a bit of a surprise for us. He had been working on our vector prediction problem in secret, and had actually managed to get it working, to an extent anyway. He had it so that a GameObject would point at another using the curving line that we had envisioned in our plans from Semester 1, and so the base code for the mechanic was now actually working – solving a problem that had been plaguing us for quite some time. The specifics of following velocity and gravity still needed implementing, but that was of course down to me to fiddle with. After playtesting James’ creation, Josh and I were simply overjoyed. Immensely grateful to James, we retreated back to Studio 16 with code-in-hand, and I decided to try implementation right after I had finished up Prototype 0.6.
James’ basic but fully functional vector prediction prototype
Wednesday then rolled around, and it was here that development ran into a rather large problem. A few weeks ago, Josh and I had been playtesting the game, and after an unfortunate encounter with the game’s Sun the ship was slingshotted into the far reaches of space at incredibly high speeds. This event caused the ship itself to visually distort quite significantly, which Josh and I found quite entertaining, and we attributed it to the ridiculously high speeds that the ship had been subjected to, and left it at that. Unfortunately, this week I discovered that the high speeds was not the cause of this visual distortion; it was the distance. Gameplay-wise, even though they were fully implemented and had been for a few weeks, I had not ventured all the way out to where Estabahn and Rika were orbiting in the game, as I had not yet had a reason to playtest that far out in the world of Fortitude. This week however I decided to explore outwards just to test out the orbits of the newly-added Moons, and discovered that the further out the ship went, the more it started to visually distort – in the same way that it did during the Sun encounter a few weeks prior. At Unity coordinates over 100,000 (around where Rika orbits) the ship became nearly unrecognisable, and almost uncontrollable. This was a bit of a problem. so I set about trying to fix it.
After a bit of research, I discovered that Unity didn’t particularly like it when you travelled beyond 100,000 coordinates, so I theorized that perhaps that might be the cause of the ship’s distortion. I then spoke to Josh, and proposed a rather radical solution; making the game a lot smaller. The planets had to be a certain distance apart because it’s a Solar System, so I proposed that we reduce the size of every asset by a factor of 10; including the ship and planets. Visually, the game wouldn’t look any different as the camera would be zoomed in to compensate, but it would mean that instead of being at 100,000, Rika would be at 10,000 due to the entire game being scaled down, which would hopefully solve the visual distortion problem. It took a fair chunk of Wednesday, but I managed to complete the task, and made everything smaller. The question was, did it work?
No, of course it didn’t.
It was the most bizarre problem. When the game had been at original size, the ship had begun distorting at coordinates 25,000 and continued to increase in intensity until becoming near unrecognisable at 100,000. With the scaled down version, the ship instead began distorting at 2500 and became unrecognisable at 10,000. The problem had scaled down with the game. At the time I was bewildered and truly stumped, confused beyond belief as to what was causing the issue. I even opened a brand new Unity project and imported various assets (some from the game, some not) and moved them to 100,000 coordinates to see if they distorted, which they did. Scaling and fiddling with settings changed nothing, so I was truly at a loss of what to do.
The visual distortion problem
On Thursday, I had a chat with Dean (our resident expert coder) to see if he knew anything about the issue, but he seemed as stumped as I was. He did however recommend fiddling with all of the import setting for assets to see if that made any difference, as well as importing other types of images to see if that changed anything. After a good hour or so of fiddling with the problem, I then randomly added a JPEG I found on the internet to test the problem, and discovered to my shock that it did not distort as the others did at 100,000. After adding a couple more JPEG’s, I then found that particular file type did not distort as PNGs did. This then led me to theorise that it must be an import problem, so I decided to go through each and every one of Unity’s asset importation settings until something changed. It took a while, but eventually I found the setting that solved the problem; changing the Mesh Type from Tight to Full Rect. I have absolutely no idea what the setting is or does, but it somehow solved the distortion problem, and now the ship doesn’t distort at all no matter how far it travels. Overall, it was a bizarre problem with an even more bizarre solution, and I was just glad it was over.
After that, we had a lecture by Matteo, the V&A Artist in residence, which was rather insightful. Afterwards, Josh and I had an opportunity to chat with him about our game, and he had a few suggestions and ideas that were actually quite interesting. We talked about how we were going to implement the game’s overall theme of “fear” and “fear of the unknown” into actual gameplay, and he suggested looking into real human effects of fear, such as adrenaline rushes and “tunnel vision”, where your eyes focus on the problem and concentrate only on it, which gave us a couple ideas about how we might use the game’s camera in times of peril. We also talked about the game’s narrative and how it ends (with the mysterious “alien” saving the player) and he told us to be wary of using the unknown too much, as making something too far beyond the understanding of people might cause a disconnect between player and game, which won’t so much cause fear as it will confusion. He also suggested perhaps having the ship go wrong at some point in the game and taking control of it away from the player, either in part or completely as loss of control and an inability to control what’s going on is a big cause of fear. The sentient bacteria event does this already to a degree, but it was a good idea to we decided to consider it nonetheless. Overall it was quite a useful discussion, and Matteo gave us a few good ideas that are definitely worth considering for gameplay.
It was then Friday, and I spent much of the day polishing off Prototype 0.6. One of the biggest criticisms from the playtesting sessions was that the rotation of the ship was irritating at times, as it tended to spin out of control and was a tad sensitive, rotating slightly even if the player wanted to stop the ship from moving. Having solved the sensitivity issue last week by bumping up the ship’s Rigidbody2D-based Mass so that the controls were slower, I spent a little while on Friday solving the constant rotation problem. My solution was to code in a small mechanic that made it so that when the A and D keys were held together, the ship would slow its rotation and eventually come to a complete stop, essentially solving that criticism from playtesting. It was a rather simple mechanic, but after testing it Josh and I both agreed that it was a great addition to the game as overall it made space flight much less annoying as ship rotation was now much more controllable.
With the new mechanic implemented, I decided to try and give it a thorough testing by adding a full asteroid field into the game for the first time. These were environmental elements that had been planned from the beginning but had not been added yet, and so I felt it was high time we had them. The subsequent playtesting of navigating through the asteroids and many a ship destruction as a result proved rather fun (not to mention quite scary) and after handing over the reins to Josh for a bit to see what he thought, we both agreed that it was a good addition to the game. We also found that the implementation of the asteroid field also changed the gameplay of the prototype quite dramatically, as we were used to flying fast and recklessly to reach other worlds without fear of danger, and the now rather large danger of asteroid fields potentially in the way (which incidentally can’t be seen via the map as they are too small) not only made space flight quite nerve-racking at times, but also severely reduced the speeds that we were comfortable flying at. For the first time, fear became a rather prominent factor in gameplay.
A nerve-racking navigation through an asteroid field
The remainder of the day was then spent finishing up the prototype and generally fixing bugs and polishing certain mechanics. As of right now, Prototype 0.6 is stable (mostly) though due to the high number of asteroids the game is now experiencing some framerate drops, so optimisation might be needed sooner rather than later.
Reflection On The Week
Overall, Week Twenty Four has been a particularly progressive week. It has seen the successful completion of Fortitude’s first quality of life update (otherwise known as Prototype 0.6) and so the game overall is more stable than it has ever been before. There are of course still a lot of things that need to be improved upon or refined (it is still in development after all) but the game overall functions far better both gameplay and coding-wise after this week.
Next week, my plan is to work on Prototype 0.7, which will be Fortitude’s second quality of life update – including FPS optimisation, refinement of mechanics and general bugfixing. We are now well into the scheduled environmental design month, but work on it has been delayed by the Reflective Journal option module so we are behind on it at the moment, but we intend to catch up as fast as we can. Josh and I spent a little while on Friday discussing the game’s environmental designs, and we decided that he will work on creating the surface and assets for Elcalowda next week, which will then be fully implemented into the game during the week after (Week Twenty Six). The weeks that follow will then be spent on continuing to fully design and implement the game’s environment.
Development is now fully back-on-track, and the game now inches ever closer to completion.