Week Twenty One – Walkthrough & Reflection

Week Twenty One has been a bit of a rollercoaster in terms of game development – there have been some highs, and unfortunately a few lows. Development is currently still more-or-less progressing on schedule, though we have suffered a setback or two.

The end of last week saw the successful completion of Prototype 0.3, and so the full implementation of a playable astronaut into the game as well as the ability to get in and out of the Fortitude ship and pilot it around as an actual vehicle. The plan for this week (and Prototype 0.4) was to implement the next major mechanic into the game, and something I had actually been dreading doing; gravity. I wasn’t particularly looking forward to coding this in, primarily because of the unpredictable nature of physical forces and the inordinate amount of fine tuning that the mechanic would cause. It would be a lot of work, and I knew before I had even began that it would likely take more than the week to get it all under control. In hindsight, I was definitely right about that.

Josh and I began the week (on Monday) by discussing how planetary orbits should work in the game. He reckoned that we should just put planets on a rotation-based “rail” of sorts, rotating around the Sun in a pre-programmed path. I however wanted to keep the game as close to realistic as possible, so posited that the planets should use real gravitational forces to actually orbit the Sun i.e. in the same manner that it works in real life. Josh’s method has several fairly large pros; it’s far easier to code, far simpler to control the planets and much less difficult to get them into stable orbits. My method has none of those pros, but it does adhere to realistic physics and so is more akin to the overall theme of the game. After much discussion, I decided to try realistic gravitational forces first, and if I could not get the planets to work the way I wanted them to by the end of the week, then I would go with Josh’s “rail” based method.

And so, the coding began.

I started by gathering all of Josh’s brand new (and fantastic-looking) planet and moon assets that he had designed over the past few weeks, and importing them into the Unity project. This took quite a long time (as they are rather large files) but eventually they were in and ready to go. Not knowing a whole lot about the specifics behind the mathematics of gravity, I consulted many a Unity forum page and YouTube video to gather code-based research on how I might go about implementing the forces into Fortitude.

One of the more helpful Unity gravity tutorials that I found on YouTube.

Over the course of the rest of Monday there was a great deal of trial and error (mostly error). Using my own knowledge of coding in Unity combined with all my new forces research, I constructed an “OrbitSystem” script – one that took the various variables of the GameObjects involved (mass, velocity etc.) and applied an AddForce that continuously pulled the objects towards the new (placeholder) gigantic Sun GameObject that I had recently placed in the game. The trial and error then came, mostly in the form of applying various velocities and different gravitational intensities to each of the newly-implemented planets in order to try and get them to arc around and begin orbiting the Sun. Some worlds obeyed, others (Rika was a particularly stubborn one) chose to fly off into the dark depths of space, unfazed by the lure of the Sun. Eventually though, I had each planet in a reasonably stable orbit around the star.

Playing about in the large brand new world, I then found that while floating about on foot I kept losing the Fortitude ship. To combat this, I re-implemented a previously disabled mechanic; the tether. This new tether however had no physical effects on the player or the Fortitude, and instead just served as a pointer, guiding the astronaut in the direction of the ship when toggled on. It worked as a pretty great fix for the problem as I never lost the ship again, and it also looked rather cool.

0.4

Implementing Josh’s planets into Fortitude

It was then Tuesday, and time to show off the game’s brand new gravity to Josh and the rest of my Games Design peers. The reception was thankfully positive, and so I set about beginning the next task of the week; the cursed vector prediction mechanic. As you might recall, it became something of a problem in the first semester (see the Weekly Walkthrough for Week Eleven if you don’t) as it was an incredibly complex and difficult mechanic to code, and so as you can imagine I wasn’t particularly looking forward to revisiting it again this week. Still, I knew the game needed it, so on I went. Luckily, I also had James (our resident coder) to assist, and so I spent much of the morning of Tuesday sat down with him while he went through various methods of approaching the mechanic.

TopTierScience

James’ work of art – describing the mathematics behind vector prediction

Armed with a bunch of ideas and James’ handy graph, I then set about trying to create our vector prediction mechanic. I spent the rest of Tuesday trying to figure out, unfortunately though to little success. In our discussion, James had talked about method where you use a LineRenderer that takes various variables into account, and so draws a line accordingly. The variables I knew we needed it to consider were velocity (how fast the player is going), direction (where they are going) and gravity (depending on how close they are to a planetary body this could be high or low). However, in order for the game to draw a prediction line, it needed to know what these various variables were…in the future, and this was the bit I was stuck on. How could I get the game to find these variables when they wouldn’t even exist until a later point in time? For Tuesday this royally stumped me, so I settled on building a simpler velocity-based prediction mechanic instead for the moment. It was like the vector prediction one but less complex, drawing a straight line in front of the player showing their current movement direction instead of where gravity might take them.

However, while playtesting both I and Josh found the new mechanic extremely useful, despite its simplicity. Due to the blackness of space as well as how outer space movement works (i.e. things don’t really move in relation to your location due to the sheer size of stars, planets etc. – they do move but so infinitesimally that you can’t really see it) it is quite difficult to see what direction you are moving in at any given point. This new velocity prediction mechanic actually provided a pretty useful solution to that issue, so a small victory was gained that day.

Wednesday then rolled around, and I spent much of it learning about LineRenderers. This element of Unity formed a major part of James’ solution to the vector prediction problem, and so I thought that perhaps if I got to grips with them they could then provide a potential solution to the coding-based problem. It took a little while (and a lot of Unity API consultations) but I eventually figured them out, and implemented them into the velocity prediction mechanic instead of the DrawLine Gizmos I had been using. Armed with my new knowledge, I then put a few of my maths-based theoretical solutions to the vector prediction predicament to the test. The most promising theory I had was this; gravity was the most important variable, so I figured that if I created a separate script that calculated the gravitational pull at various positions ahead of the player, I could then plug these calculations into the velocity prediction script which would then hopefully cause the LineRenderer to bend according to gravitational pull. After many an hour and line of code, I added these to the velocity prediction script and crossed my fingers.

It didn’t work.

This was a frustrating setback, but the day hadn’t entirely been for nothing. The addition of the LineRenderers to the velocity prediction script had made the mechanic a lot less glitchy, as well as making the drawn line far smoother. While I unfortunately didn’t have the bending-for-gravity line I wanted, I did have a highly refined velocity prediction mechanic that if nothing else helped to show the player where they were heading. Still, I was particularly dissuaded by this defeat, so I called it a day.

Thursday.

Our weekly talk was sadly cancelled, so I decided to spend the day at home, hunkering down on coding Fortitude. For the time being I had decided to give up on the vector prediction mechanic, as it was costing too much coding time and wasn’t worth said time, and it was starting to really frustrate me to the point where I just didn’t want to work on it any more. As a result, I decided to talk to James again on the Tuesday of Week Twenty Two for more help, and spend the remainder of Week Twenty One on refining and bugfixing the new physics of Prototype 0.4. Much of Thursday was then spent on Discord voice chat with Josh, talking about various things and generally enjoying eachother’s company.

He was working on fixing the Fortitude (as it was oddly distorting when the ship rotated in-game, and Adam had suggested that it could be the thin vertices causing the problems – something called the Moire Effect) and I focused on gravitational piddling. I also added Josh’s Moon assets to the game, and they became a problem rather quickly as they simply would not obey the laws of physics. They would drop out of orbiting their various planets as they pleased, and generally were just a nuisance. After a little persuasion from Josh (and a good couple hours of fiddling with their gravity) I then decided to put the Moons on orbital “rails”, forcing them on a specific path around the planets. It wasn’t ideal, but it worked.

I then spent a bit of time re-implementing a previously taken out mechanic; the game map. It was previously removed in favour of the mouse scroll zoom in/out, but Josh and I both felt that we needed a map too. Re-adding the “M” key, I added a mechanic that zoomed out the camera to a near ridiculous level, and added a GPS-style triangle to represent the player. After the job was done, I felt that the map actually worked really well. It allowed the player to see their location relative to the nearby planets as well as their current movement direction (as I also moved the velocity prediction line to only function while in the map) and overall really helped with the navigational issues that we have been having.

beta

Fortitude’s brand new game map – the triangle is the player

With the end of the week fast approaching, it was then Friday. The morning was spent taking part in a workshop with Mind The Film, who talked to us about the end-of-year documentary we were going to make about our games and how we might go about conducting interviews, recording gameplay etc. They also went through various elements of DSLR’s and how to use them, which was rather informative. Overall, it was a rather interesting talk and I actually quite enjoyed it. In the afternoon, I spent a bit of time working on another suggestion from Josh; planetary trails. He wondered if it would perhaps be easier to add a trail behind planets, rather than predicting where the planets are going to be. It would achieve a similar effect to the vector prediction mechanic, and  also would certainly be far simpler to code, so I decided to give it a go. Surprisingly shortly afterwards, we had our new mechanic:

The trails are the blue lines

Josh and I were very pleased with the above result. The blue lines not only look really nice as part of the game’s map, but also do a really good job of illustrating the various planetary orbital paths. This combined with the velocity prediction line that you can also see in the GIF above gives the player a really good indication of their position relative to nearby worlds, and in playtesting we found it helped massively with attempting to get into the orbit of and subsequently land on the planets themselves. All of a sudden, we had a mechanic that nearly-but-not-quite negated the vector prediction. Playing the prototype with the brand new map elements, I definitely felt; do we really need vector prediction? Are the trails and velocity prediction enough?

We then talked to Adam, and encouraged him to playtest the prototype in order to get an idea of how others felt about the game and its various mechanics. He found orbiting rather difficult (which was expected, due to the harsh realism of our game) but rather liked the look and feel of the map, using it far more than the standard viewpoint of the game. He also expressed that the controls were a tad difficult to use, and that during the user testing sessions (that incidentally begin next week) we should test them further and probably then refine them a bit more. I then asked him whether he felt vector prediction was necessary to navigation in the prototype’s particular scenario, and he felt that it wasn’t really. He then went on to say that it shouldn’t really be a massive priority right now as it’s quite a small part of the game, and more focus should instead be given to refining current mechanics (such as the controls). Overall, he was pleased that the game was coming along relatively well but stressed that there were definitely some elements of the prototype that could do with some refinement.

 

Reflection On The Week

This week initially went quite well, and then took a short fall off a cliff, before slowly then climbing back up. The vector prediction predicament took up much of the week, consuming both a considerable amount of time as well as my soul. The end result was unfortunately semi-failure, although we did end up with an inferior-but-functional velocity prediction mechanic. This combined with Josh’s trail idea then actually worked pretty well as a navigation-based fix to the lack of vector prediction, and it led us to subsequently consider whether actually vector prediction as a mechanic is even worth it.

The remainder of the week then went fairly well, with gravity being more-or-less functional as each of the planets now have a fairly stable orbit around the currently-placeholder Sun. The Moons went less well and unfortunately had to be placed on rails, but visually they now work well, even if they now don’t quite adhere to realism. The new game map was probably the best thing to come out of the week, as the planets and trails look really good and the mechanic overall actually works really well.

Adam’s feedback on the current state of the game on Friday was also useful, as it showed us that some fundamental aspects of the game perhaps needed more refinement, and that my focus on vector prediction might be misplaced. Next week, my plan is to start working on the transitions between outer space and on planet (as that unfortunately had to be pushed back from this week’s prototype due to the vector prediction predicament taking up a lot of time) as well as general refinements to base game mechanics.

Things are going OK, 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