Week Twenty – Walkthrough & Reflection

Week Twenty has been a particularly busy time for Josh and myself, but as a result the newly-named Fortitude has taken major steps forward in its development.

Having previously completed development on Prototype 0.2 (the Fuel System and “Mark 42” mechanic) I began Monday by starting work on the next update for Fortitude; Prototype 0.3. The loose plan for this update (which can also be viewed on our Trello board – link in the semester 2 menu above) was to add the “On Foot” elements of the game – consisting primarily of a playable astronaut character who can get in and out (and control) the Fortitude spaceship that was previously implemented into the game. Much of Monday was spent on the creation of said character and coding in its movement mechanics, as well as shifting the camera’s primary perspective from the Fortitude ship to said astronaut. This all went largely without a hitch, and it was only as code was changed and the ship was treated as a vehicle rather than a character that bugs began to appear.

Tuesday saw the brunt of these bugs, and much of the day was spent implementing, smoothing, refining and bugfixing the “getting in and out of the ship” mechanic. It took a while, but eventually we had the transition locked down and functioning according to how it should (well, mostly anyway). The reason why it had caused the amount of issues that it did was due to the massive change in gameplay – namely moving the Fortitude ship to one side, turning it into a vehicle and making the new astronaut character the primary focus of gameplay. This quite radically shifted the focus of the game’s code, which of course created many a bug. After a good few hours though, Unity was largely OK with the new implementation, and so development continued.

scren1

The new “Astronaut” playable character next to the Fortitude

It was at this point where I had (what I thought anyway) was a pretty good idea; what if the astronaut does the refueling instead of the ship? I reckoned that it would be a hell of a lot scarier for the player if in order to refuel, they had to leave the relatively safe confines of their spaceship and head out into the unknown (and dangers!) of space in order to manually refuel the ship from the outside. I suggested this idea to Josh, and he agreed that it would indeed add to the fear factor of the game, and that we should give it a try in-code and see how it feels.

Transferring control of the Fuel System from ship to astronaut was a little trickier and took a little longer than expected, but after an hour or so the new mechanic was ready. Josh and I then both tested it in comparison to the older ship-refuel mechanic, and the winner was quite clear; being the tiny astronaut in space refueling the ship amongst all kinds of danger was scarier by far than sitting in the ship and doing it. It added a fair amount of fear to an otherwise fairly mundane aspect of the game (refueling has never been exactly fun) and Josh and I both agreed that it added to the overall tone of the game considerably.

With this mechanic now cemented into the game, I began Wednesday with a series of playtests to iron out bugs and thoroughly experiment with the new mechanics. Playing as the newly playable astronaut, one thing that became apparent rather quickly was that losing the Fortitude might become a bit of a problem. If the ship was floating in one direction and the astronaut powering off in another, it was quite easy to lose sight of the vessel completely, and so lose the one thing in the Solar System keeping you alive. To combat this, I experimented with the idea of using a “Tether” to essentially tie the playable astronaut to the Fortitude ship. The result however was somewhat problematic; not only was the rope itself incredibly glitchy without the use of Unity’s gravity to give it weight, but it also massively limited the player’s out-of-ship movement and abilities.

scren2

The experimental tether tying the astronaut to the ship

Josh and I both gameplay tested the tether, and after a while agreed that it just didn’t work as a mechanic. The glitches would take a while to fix, and even if we fixed them the rope limited the player’s freedom significantly, which goes against some of the fundamental tonal elements of the game. It was at this point as well that we came up with a much better idea to combat the ship loss issue, so with all these things in mind we decided to scrap the tether mechanic, at least for now. The new idea came about when we started thinking; if the player loses the ship, how could they get it back? Josh and I then both rather liked the resulting mechanic idea; ship remote control. Essentially, the thought was that if the player is outside and far away from the Fortitude, they could press a series of keys and subsequently remote pilot the ship back towards the astronaut, whom they could then “pick up”. Said mechanic would of course use Fuel, so ideally it would only be used when the player is in danger.

Coding this idea into the game was initially quite simple, although it did then presented a series of bugs and issues that of course had to be ironed out. After this, Josh and I then thoroughly tested and fiddled with our new mechanic, and after testing and asking around for opinions on the new mechanic the answers to our questions were clear; the new mechanic not only worked well in terms of fixing the lost ship issue, but it was also quite a fun addition to the game. Remote piloting a spacecraft and moving in to rescue the pilot was a rather exciting and enjoyable adventure, and as a result of this and the views of others the remote control mechanic has now become part of Fortitude.

It was then Thursday, and we began the day with a particularly insightful lecture from a member of Sennep Games, Stuart. His talk was centered around portfolios and how we present ourselves to potential employers via our work. He walked us through a series of example email cover letters as well as a few standout portfolios, and explained the do’s and don’t’s of applying to art-based jobs from his point of view. Afterwards Josh and I then met up with him in the studio and talked him through our game, showing him the prototype so far as well as the Design Document and talking about various ideas that we had for the game’s developmental future. The discussion then led to talking about our asset size issue that we had in Week Eighteen (see the Weekly Walkthrough for more information) and Stuart explained that he and Sennep had a similar issue with the development of one of their mobile apps, and they got around it by having a series of transitions as they zoomed in/out that masked the quality of the sprites at high zoom levels.

The conversation then moved towards how I was going to tackle the coding task of transitioning between outer space and in planet, and how difficult this was potentially going to be. Now understanding just how big our game was going to be (more than an entire Solar System in design) Stuart began talking about scope, and how we might perhaps consider dropping some elements of the game, as we might not have time to do them and cutting them out would then allow us to concentrate on refining other more important aspects of the game. He then went on to discuss how some elements of games in general are more important than others, and that we should consider this if we find ourselves running out of time. I then mentioned our discussion with Adam in Week Nineteen where we discussed perhaps cutting out Planetary Exploration completely, and Stuart agreed that it was certainly worth entertaining the idea, especially as it would allow us to focus on the more important game aspects i.e. the narrative and the overall “pushing through the fear of the unknown” theme.

Post-discussion, Josh and I then spent half an hour working on a contingency plan for the future. We talked about what planets were important and which were perhaps less so (in terms of narrative primarily), and wrote these down on the studio whiteboard. The Rogue Planet of course needed to stay in the game as it is imperative to the game story, and several other planets included narrative elements (e.g. Elcalowda with its ruins, Diadem with the “Rogue Planet in the sky” event) which would also need to stay. Certain other worlds and their moons however were not entirely necessary to the game, so Josh and I discussed the idea of “landing” the ship in the upper atmosphere of said worlds and “scanning” for interesting objects without actually landing, thereby removing the necessity of creating the worlds to be fully “On Foot” explorable. This idea was a kind of half-and-half from Week Nineteen’s removing the Planetary Exploration idea, as it removes some of the planetary exploration by making some worlds atmosphere-scanning-only (i.e. maybe the ship deems the planet “too dangerous” to land on or something) but keeps the important narrative elements on-planet.

20190208_152309

Our planetary exploration-based whiteboard notes

These were all of course just ideas, as hopefully we won’t need to abandon any game elements. It was definitely worth thinking about though, and it is good to have a contingency plan should things take far longer development-wise than expected. Thinking about this also revealed that some aspects of the gameplay are more relevant-to-the-theme and interesting than others, so in the next few weeks Josh and I will discuss these more and perhaps change some aspects of the game anyway in favour of making it more fun and playable. It’s all to play for, essentially. Since development has begun (just a few weeks ago!) a great many things have changed already, so planetary exploration will likely change too.

Friday then rolled around and I was rather looking forward to it, as a few university student composers were coming in to talk to the class, and perhaps even join some teams to potentially compose music for their games. Being rather a big fan of musical scores in general, I was excited to talk to them and perhaps even persuade one to compose for Fortitude.

We began the day with a talk from the composers, who talked about the use of different types of music to create different moods and atmospheres in films and games, and discussed the major differences between composing for film and for games – namely making the player feel part of the story rather than just standing by and watching it happen. Afterwards, Josh and I then began talking to the lead composer, starting with explaining what our game was and the musical styles that we had considered (minimal, ambient – details are in the Design Document) and then showing him the DELTA-V Trailer that we had created for the semester one presentation.

20190215_144706

The notes from the composer’s discussion with us

The composer liked our musical choices, but went on to say that perhaps we should consider having little or no music at all. Playing our prototype, he talked about how outer space and being in it is actually quite scary, giving film-based examples like Gravity and 2001: A Space Odyssey, and how adding atmospheric music might actually take away from that. Having little or no music at all might actually be more effective in terms of getting across our overall “fear of the unknown” element of our game theme, as quiet is in of itself very scary. He then talked about Sound Design, and how certain space movies used sound effects such as breathing or mechanical noises rather than music to create atmosphere, and that perhaps we should apply that idea to our game. Josh and I both agreed that the focus on sound effects rather than music was actually a pretty good idea, and decided to experiment with the idea heavily in the near future. Absence of sound was something we had previously considered with sound effects, but absence of music was not, and the more we thought about it the more we liked the idea.

The day (and the week) then drew to a close, and we have a great deal to think about.

 

Reflection On The Week

Week Twenty has been a rather busy one, and as a team we have had a fair amount of discussion both within ourselves and with outside influences that have led us to seriously reconsider certain elements of Fortitude as well as adding some things that we previously had not thought of. Coding-based development is going relatively well (slowly but surely) as is asset development.

The removal of planetary exploration is something that has been suggested to us twice now, and as a result Josh and I are teetering on the edge of its removal from the game. However, so far development (both coding and asset-wise) has gone really well, so we are reluctant to cut down the game right now as things are progressing just as we wanted them to. As Josh said to me earlier this week, we don’t want to start cutting things out until we hit a brick wall – so that’s the current plan. Keep going until we hit problems, and if we do then perhaps cut out certain game elements. Of course, if we create them and they end up being detrimental to the game we will cut them out anyway, but we aren’t there yet.

Next week, my plan is to begin tackling one of the biggest predicted coding-based tasks of the game’s development; orbital mechanics and the transitions between outer space and in planet. If we are going to encounter coding issues, it will be here.

Hopefully though, things will continue going as well as they have. So far, so good.

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