Week Nineteen – Walkthrough & Reflection

Week Nineteen saw the successful creation of the second update for the DELTA-V prototype; version 0.2, as well as a decent jump forward in terms of work organisation and other aspects of development. Overall, a rather busy but good week.

Development for DELTA-V Prototype 0.2 officially began on the Monday of this week. As I mentioned in the previous week’s Weekly Walkthrough, the priority for this prototype was bugfixing and general refinement of the previous prototype’s mechanics, along with the introduction of the Fuel System mechanic and game HUD. I spent much of Monday fixing various issues with and refining elements of the Fortitude’s “destruction” system (a list of which can be found in this week’s Patch Notes). With the mechanics from last week now generally behaving themselves, I spent Tuesday implementing the Fuel System into DELTA-V. It’s described in detail in the game’s Design Document, but essentially it adds ship Fuel into the game. Using the ship’s thrusters, map and manouevring abilities all consume Fuel, which can only be regained by entering a “Fuel Cloud” that the ship will then extract minerals from and convert them into more Fuel. If the ship’s Fuel level reaches 0%, the Fortitude will lose system power and the player will no longer be able to control the ship (i.e. fire the thrusters, rotate the ship etc.)

The game (well, prototype) begins with 100% Fuel, and using each aspect/ability of the ship uses a different amount of said Fuel:

  • Manouevring Thrusters (i.e. rotation) – 0.1% per second
  • Finer Thrusters – 0.2% per second
  • Power Thrusters – 0.5% per second
  • using the Zoom Out/Map function – 1% per second

These are just preliminary and testing numbers, and so of course they will likely be changed multiple times over the course of development as we further build and refine DELTA-V. The creation of this mechanic actually went pretty much without a hitch, with only a couple of bugs and things cropping up as it was coded into the prototype. It now runs rather smoothly in the game, and so the Fortitude now has a fully functional Fuel system where different ship functions use different amounts of Fuel which can then also be regained by “refueling” in a nearby cloud of said substance.

With the Fuel System in place, I then began work on the implementation of a basic HUD into the game. Once again borrowing various lines of code from the “NASA Space Game” prototype from Semester 1, I placed a HUD in the top left hand corner of the player’s screen that displayed forward and rotational velocity. Then – modifying the code ever so slightly – I added the Fuel level to the display as a percentage, so that the player can see their current amount at all times and so respond accordingly. The development of this also went without a hitch (which wasn’t too surprising – the code for it is pretty simple) so I began thinking about other mechanics that could perhaps be implemented (it was only Wednesday after all).

This thinking then led to the creation of the “Mark 42” mechanic.

With the destruction mechanic that I created for Prototype 0.1, there was a pretty large “issue” of sorts that kept cropping up during testing. If the player crashed with considerable force, parts of the ship would of course “break” and detach, but due to physics they would fly off – often out of sight and therefore out of reach. This was a bit of a problem, as it would cost a considerable amount of Fuel to go after the parts, and that is of course assuming that the player saw which direction they flew off in. With this “issue” in mind, I began work on a “Recall” mechanic; if the player holds down the “F” key, the various detached parts of the ship will begin flying back towards the Fortitude, at a considerable Fuel cost (as this mechanic would only be used during an emergency). Once it was finished, this mechanic actually worked really well in the game – it was a great counter to the “issue” that the destruction mechanic presented, and was also a pretty fun mechanic just on its own. If you’re wondering about the name, it’s a direct reference to the movie Iron Man 3, where Tony Stark has an Iron Man suit (the Mark 42) that does a pretty similar thing:

See 1:40 for the “Mark 42” mechanic’s inspiration

This aspect of the movie served as pretty direct inspiration for the mechanic, so I felt it was definitely worth mentioning here (plus, it’s a pretty cool scene).

The implementation of this mechanic had a few various issues and bugs, but overall it went pretty well. It was then Thursday, and to finish up Prototype 0.2, I decided to finish up work on the Health System for the game. The destruction system detaches bits of the ship, but there was no current way for the player to actually die. To combat this, I added a few lines of code that made it so that if the player hits an object in space with the main body of the ship (a surprisingly difficult thing to do given how it is surrounded by detachable extremities such as the thrusters, antenna and “needles”) at a high enough velocity, the ship will be instantly destroyed. I felt that this was a harsh but fair mechanic, as it is pretty difficult to hit something with the main body of the Fortitude due to the detachable elements of the ship forming a “shield” of sorts. The player would essentially have to lose the extremities and then slam into something at high speed again in order to actually die – so this mechanic essentially makes the Fortitude a two hit kill (like the Design Document originally describes), just indirectly.


The Fortitude’s “shield” – each of the green collider circles protects the main body

I then presented this Death System idea to Josh, who agreed that it worked well with our overall idea for what the game should be like i.e. realistic – a spaceship in real life (take the Apollo ones for instance) would be pretty heavily damaged if not completely destroyed by a high velocity asteroid impact. Our game is set a little in the future so it will be a bit tougher (hence the two hit kill) but overall this harsh-but-fair death mechanic fits well with the tone and style of the game.

Additionally on Thursday, the class attended a talk conducted by some of the alumni of our Games Design & Art course – a session which actually turned out to be pretty useful. They talked about how development worked for them over the course of their Year 3 Semester 2 game creation, including tips about working as a team as well as correctly scheduling various aspects of development. One aspect of their work which stuck out to me was the use of a Trello board, as it allows you to see the game in progress as well as giving you the tools to properly organise general workflow. With this in mind I set to work on creating a Trello board for DELTA-V’s development, which can be found here as well as in the main menu at the top of the blog.

It was then Friday, and I spent much of the day conducting various bugfixing sessions as well as generally refining all the new mechanics implemented in Prototype 0.2. As a result, we now have a fully completed 0.2 version of the game – one that is ready to move into new developmental territory with update 0.3 next week.

It was at this point in the day however that we ran into a pretty serious problem. Adam had begun talking to us about social media and advertising/promoting our game, and we began looking into domain names for a website for DELTA-V. The main one we were after (deltavgame.com) was mysteriously taken, and a quick visit to said website sadly confirmed why; there is already a space game entitled DELTA-V, one that we had somehow missed during our extensive research into whether somebody else had our game name that we conducted back in December.

This of course threw a massive spanner in the works, as we were going to have to change the name of the game – which really annoyed both Josh and myself as we had already conducted marketing with that name (for a start – the trailer). Not wishing to go right back to the drawing board, we looked back over name generation that we had already conducted, and after a little while settled on Fortitude as the new name. Surprisingly there are no games called that (none that we could find anyway) and the only relatively famous thing with that name is a completely unrelated (in terms of genre and tone) television series from 2016. It also fits rather well with the game, as the word fortitude literally means “courage in pain or adversity” – which is a pretty big aspect of the game. It’s also obviously the name of the game’s ship, so it is relevant in that regard as well. As a result, we decided to settle with Fortitude for now until we either come up with a new name or warm to that one.


The development of Prototype 0.2

We then had a chat with Adam, who talked us through some of his feedback for our semester 1 work as well as going through a few tips and potential issues that he had with our game’s development going forward. He expressed that we should focus heavily on the narrative elements of the game, and particularly the overall theme of “pushing through the fear of the unknown”. We then talked about how development was going, and I expressed that mechanics-based design was going well so far which meant that hopefully a great deal of time will be spent working on the narrative and thematic aspects of the game in the coming months.

One rather interesting point that Adam then raised was that the “fear” aspect of planetary exploration was in the landing, and as a result we might not actually need the actual “On Foot” exploration of planets as a mechanic – as it’s not massively necessary to the narrative or getting across the major themes of the game. Abandoning said aspect would also free up a great deal of time (as planetary environment design currently is going to take up an entire month if not more) that could be spent focusing on really nailing the fear aspect of the game or really fine tuning the mechanics.

Adam’s point also reflected something that I had been thinking about for a while; the planetary exploration in the game is a tad boring. All the player does is collect samples and explore, and while these sound good on paper they likely will be a bit dull during actual gameplay. This was something I thought we could tackle later on, but this idea of perhaps doing away with planetary exploration altogether stuck with me, and after a brief discussion Josh and I agreed to seriously consider it going forward. Most of the narrative elements could be reworked to operate in space or in atmosphere (as planetary landing will still be a thing) so the game could actually work quite well without this mechanic. However, as it is a pretty major decision that affects one of the fundamental aspects of the game, we will not make said decision right now, but going forward it will be something we are going to consider quite heavily.

It was then the end of Week Eighteen. Next week I plan on adding the “On Foot” playable character into the game, as well as the ability to get in and out of the “Fortitude”. This mechanic could still be useful (out in space, for example) despite the possibility that planetary exploration may be cut, so it will still be developed for the game. Depending on how long this coding then takes, I may or may not then add other mechanics to the Prototype 0.3 update as well.


Reflection On The Week

Week Nineteen has had its ups and downs. Coding-based development has gone really well, with Prototype 0.2 seeing the successful implementation of several major game mechanics, including the Fuel System, a game HUD (albeit a placeholder one), Death System and a rather fun detached ship parts “Mark 42” recall system. All these new mechanics work pretty well with one another (other than the odd bug or glitch) and overall the game is coming along just fine. Josh is progressing well with the development of the planets and moons, and the creation of the game overall is currently going well and right on schedule.

There were a few unfortunate events that occurred this week (majorly the loss of our lovely game name DELTA-V) and the asset size issue that presented itself in Week Eighteen is sadly still ongoing. Fortitude is not the ideal name for our game (we just lost the ideal one) but it does work rather well, so Josh and I aren’t entirely unhappy with it. Adam’s suggestion to perhaps do away with planetary exploration altogether is something we are going to seriously consider going forward as cutting it would allow us to focus more on more important aspects of Fortitude (such as the narrative and overall “pushing through the fear of the unknown” theme) as it would lighten our workload considerably.

Until next time.

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