Week Twenty Two – Walkthrough & Reflection

Much like the adventure that was last week, Week Twenty Two has had it’s fair share of ups and downs in terms of game development. Mostly downs though, if I’m to be completely honest. Things were achieved, but many a problem was also encountered.

At the end of last week Prototype 0.4 was completed, and it saw the successful (but not entirely sans problems) implementation of gravity into the game, along with fairly functional orbital mechanics, a game map and a simple version of the vector prediction mechanic. The big plan for this week was to begin work on a landing/takeoff mechanic, essentially giving the player the ability to approach and subsequently land on various planets throughout the game map.

With the week’s plan in mind, I began Monday by opening up a brand new version of the game entitled Prototype 0.5, and got cracking on creating the landing/takeoff mechanic. Josh and I had discussed various methods of achieving this through code, and I had eventually settled on a loading-scene method. Essentially, the idea was that upon approaching a planet, the player would collide with an On Trigger Circle Collider in the upper atmosphere of the world, and doing so would then load a brand new scene with the terrain of said world already loaded in and the ship’s Rigidbody2D gravityScale upped beyond 0 (which it is currently set at in the original scene). The reason for a new scene was that the terrain is flat, and the planets in the game are obviously not. The player can also approach the planet from any angle in space, and there was no easy way (or one in my expertise anyway) to orient the terrain with the player’s approach angle. It would be far simpler (or at least I thought) to load a new scene with the terrain already loaded, as that way all the code would have to do would be transition the player between the two scenes.

It was of course, a little more complex than that. While coding the new mechanic, I realised that not only would it have to transition the player between scenes, it would have to take and store various variables (such as player speed and location, planet locations etc.) between scenes and then apply them at particular intervals. The Fortitude ship for example had to have it’s previous position, current velocity, rotational velocity, camera zoom and current timeScale recorded and stored right before it transitioned between scenes. These variables were then applied to the ship in the new scene so that there would be no visible change for players playing the game. From their perspective, the ship has not changed speed or position – they have just entered the atmosphere of a planet. There was a small lag spike that occurred as the player switched between scenes, but otherwise landing worked pretty flawlessly, and I was rather pleased.

Later on Monday, we had our first user testing session for our games. This involved getting various students from around campus to test the games and then gain their feedback in an effort to find mechanics that perhaps aren’t very good or bugs or issues that need ironing out or tweaking. To my surprise, a fair number of people actually showed up to the session, and as a result we had quite a few testers for Prototype 0.5 of Fortitude.

20190225_142102

One of our playtesters, with me guiding them through the controls

Subsequent feedback for the game was rather positive. Players praised the visuals and most elements of the gameplay, along with rather liking the “having to land on the planet” task that we had set them (using our newly implemented Prototype 0.5 landing mechanic) despite it’s high difficulty. We had just over ten players overall, and only two of them managed to successfully land the ship on the planetary surface. One criticism that nearly every single player had however was the sensitivity of the controls, in particular the rotation of the ship. They felt it was overly sensitive, and it became irritating at times. Another similar issue they had was that they found stopping the rotation quite annoying, as there is no specific button to stop rotating – instead the player must counter rotate in the opposite direction of the current rotation. One tester suggested that perhaps pressing the “A” and “D” keys at the same time should counteract all rotation, stopping the ship completely. I rather liked this idea, and made a note of it for potentially adding in a later update.

All the noted feedback from the game’s various playtesters

Overall, I felt that the session was rather useful. We had various elements of the game pointed out to us as annoying or difficult to use that we had not otherwise considered, and since people are going to be playing our game, it is good to try and catch these things early on. I was also rather pleased with the praise we received, as it told me that we were more or less on the right track mechanically, and that our game wasn’t completely awful, which is always nice. After the session, I upped the ship’s Rigidbody2D-based Mass from 1 to 2, essentially slowing down all the controls, and after playtesting it myself and getting Josh to have a go, we both agreed that the slower and less sensitive controls was a better way to go.

It was then Tuesday, and it was here during coding the takeoff part of the landing/takeoff mechanic that problems then arose. Transitioning to the new scene had been fairly simple as the code focused on the ship and bringing it and the necessary variables into the new scene, but transitioning back was a far tougher thing to master. Not only would the code need to take into account the ship’s variables from the new scene, it would also need to take variables from the old scene at the point in time just before the player transitioned from atmosphere to landing. Gathering the player’s variables from pre-landing was fair simple, but I hit the metaphorical “brick wall” with the planetary ones. Each of the planets in the game would need to be in exactly the same positions that they were before landing was initiated, but the problem was capturing that data.

store

Unity code – storing the variables for the journey to the planet’s surface

As the Fortitude exists in both scenes, Unity was fine with transferring code, but because the planets only exist in one (to save space and performance) it threw a code-based hissy fit, refusing to acknowledge that the GameObjects had previously existed, did not currently but would again in the future when the old scene was reloaded. It was late on Tuesday afternoon when I realised that this particular method of coding the landing/takeoff mechanic simply would not work, or at least not without a considerable amount of re-coding which would take a particularly long time, and time is something we are rather short of at the moment (due to our rather large game and strict schedule as a result). The outcome it seemed was obvious, but rather unfortunate; Prototype 0.5 would have to be abandoned, and a new method of coding the mechanic needed devising. It was with a heavy heart that I did this on Wednesday morning, but thankfully after some thinking and a chat with Josh, I had another method idea.

This time, instead of loading a brand new scene when entering the On Trigger Circle Collider, I coded a script that just transported the player (via the transform.position function) to a faraway location within the game’s map that contained the (currently placeholder) planetary surface that the player could then land on. The script also enabled the ship’s gravityScale, but only while they were within the tagged “atmosphere” encompassing the surface GameObject. Finally, the code also disabled said GameObject while the player was not there, as it is rather a large object and is a bit of a kicker to performance – this being the major reason why I didn’t use this method first instead of the loading a new scene one, as performance has been an increasing issue recently. I spent all of Wednesday and the morning of Thursday working on this mechanic, but at long last it was done, and unlike the previous method, it actually worked. Thus, Prototype 0.5.5. was born. However, there was still something…missing.

One of the major criticisms that Josh and a few others had about the game during testing on Monday was that the transition between planetary approach and landing was too fast – they felt it took away from the overall “fear” experience that the game needs to have. With the new landing mechanic in the game, I began to think about this, and decided to try and do something about their feedback.

I began by fiddling about with the gravity mechanic, testing different variables including upping the size of the gravitational force as well as increasing and decreasing the masses of both planet and ship. Neither had much of an impact though, so I decided to step things up even further. Taking the planet Elcalowda as a test subject (as it had been the test subject for the landing/takeoff mechanics already) I increased its physical size in the game by a factor of 10, making it only just a smidge smaller than the game’s Sun. I then attempted to approach and initiate the landing mechanic. Subsequently, I found that the difference was quite astounding.

size

The new Elcalowda – note the size difference between it and other worlds

Because of it’s massive new size, Elcalowda suddenly became a lot more of a challenge. It’s gravity was up because of its new mass, but instead of it just introducing wacky forces like upping the gravity earlier it had done, because of its new size it actually allowed the player to orbit the world, if they were up for the challenge that is. The forces were suddenly a lot stronger, and as the player I felt the gravitational pull of the world a lot further away than before.

Using up valuable fuel, I swept around the right side of the planet and arced the ship around, forcing it into a somewhat-wacky orbital path around the world. In order to successfully land and not be instantly destroyed on impact, the ship’s velocity had to be lower then 10 metres per second, so slowing down was my first priority. Manouevring the ship around, I burned a few more seconds of Fuel facing away from the planet, desperately trying to slow down. The planet’s gravity then began to claw ever harder, desperate to pull the ship down into the atmosphere. 50 m/s, 45 m/s, 40 m/s…I watched the numbers fearfully, willing them downwards before I was inevitably plunged into the world. Upon reflection I had most certainly approached the world too fast, allowing the gravity to grab me too early before I had a chance to slow. This was something I starting thinking carefully about as the planet pulled the ship down into the atmosphere and smashed it onto the surface below, at a speed of 35 m/s. The Fortitude of course, did not survive.

That was fun, was my first thought as I emerged from the playtest. It had been exhilarating, scary even – the gameplay of landing had completely changed, just from upping the size of the world. The now massive Elcalowda was suddenly a lot more intimidating, even viewed on the map. The new gravity and sudden emphasis on orbiting before landing also made the landing mechanic much longer, not to mention tougher, which was exactly what Josh had been concerned about. Turning to him (as he was sat next to me in the studio at the time) I invited him to playtest the new landing mechanic. Afterwards, he felt largely the same as me, noting the marked improvement from before as well as the intensity and fear he felt as he tried to land the ship (and unfortunately, failed too). Overall, he and I were rather pleased with the new mechanic, as that coupled together with the gravitational alterations had introduced the first fearful thematic elements into the development of Fortitude.

Friday then arrived, and it was here that I had to make another rather difficult decision. The orbital paths of each of the planets has been a bit of a thorn in the game’s side since the implementation of gravity in Prototype 0.4, simply because of how wacky and odd said orbits are. Using actual real gravity to get the planets to orbit the game’s Sun resulted in a bit of a trial and error session, dropping the planets in at various positions and velocities and trying to get the Sun to “catch” them and pull them into orbit. Some attempts caused the planets to sail right past the Sun, some were captured and then slingshotted into the depths of space, and some were just “eaten” by the Sun. It was a difficult process, but towards the end of last week I thought I had gotten each world into a semi-stable orbit. I was as it turns out, unfortunately wrong.

Josh and I had left the game running for quite a long time, as we had been playtesting but were now discussing where the game would go from here, and things like that. After a while, I glanced back at my laptop (still running the game) and noticed that half the planets were missing from the game map. Where had they gone? What had happened unfortunately, was that some of the planets had actually had non-visibly decaying orbits, and with each orbital rotation they were moving further and further away from the Sun until eventually escaping its gravitational pull. This was a major problem, as playtesting for an eventual orbital escape would take a considerable amount of time, and I was already getting sick of the “trial and error” orbital mechanics as it was.

As a result, I decided to heed Josh’s advice from last week, and just put the planets on orbital “rails” instead. Now they rotate around the Sun in an orbital-like fashion without issue, but are unfortunately no longer using gravity to do so (rather a transform.RotateAround function) so the realistic element there has sadly been lost. It was a particularly difficult decision as I had really wanted the game to be entirely realistic, but practicality came into the fold here, and both Josh and I felt that it was far better in terms of time conservation and actual gameplay mechanics that the planets have stable, non-realistic orbits than realistic, broken ones.

orbit

The newer and far more stable planetary orbits

With the end of the week fast approaching, it was then time for our weekly chat with Adam. He was particularly keen on playtesting the game, so we sat down with him and played through it in its current state, guiding him through the new planetary landing mechanic as well as talking about the playtesting session on Monday and the things we had and were going to implement as a result of that. He seemed rather pleased with the state of the game overall, with his only major concern being the rather dull game UI in the top left corner, as he felt that it was high time it got replaced with something a little more eye catching. Afterwards Josh and I had a brief chat about it, and both agreed to look into it in the weeks going forward.

 

Reflection On The Week

Week Twenty Two had been a particularly long one, and certain parts of it were more difficult than others. In terms of game development, Fortitude has made significant steps forward in this week particularly, with Prototype 0.5.5 not only seeing planetary landings and takeoffs implemented into the game, but also various quality of life and mechanics-based changes that have improved gameplay quite significantly, these mostly owing their thanks to the rather useful playtesting session that we hosted on Monday. The setback that was Prototype 0.5’s failed scene-based landing mechanics was unfortunate, but thankfully I decided to abandon it when I did in favour of (as it turns out anyway) a much better and far less complex and broken method of coding said mechanic.

Taking away the realistic side to the planetary orbit systems was also a difficult decision, but both Josh and I feel that it’s for the best. It allows us to concentrate more on the important aspects of development rather than continuously fiddling with gravitational pulls that honestly might not ever work the way we want them to. The planets orbiting realistically also doesn’t have a particularly important role in the game, as the player just needs to travel to them, which they can do just fine with the planets being on “rails”.

Next week, the plan for myself, Josh and I’m sure a great many of my classmates is to concentrate significantly on this semester’s other module, the Reflective Journal – which is due in just under a week and a half now. We have neglected creating it primarily because of the sheer amount of attention developing Fortitude requires, but now we must focus on it, and so put the development of the game on the back-burner for now. It will only be for a few days though, so hopefully we’ll get back to development before the end of the week. My plan for Prototype 0.6 is essentially a quality of life update, adding in various gameplay suggestions and coding optimisations in preparation for adding the full game environment this month (planets, surfaces and all). Looking into designing some proper UI for the game is also a priority, though for now quality of life is our main focus.

We’re a tad behind schedule, but things are still going well…mostly.

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