Apologies for the lateness of this weekly walkthrough – the reason for this will become apparent though as I talk through this week, so – enjoy I guess.
After the hand-in for semester one, we had a good week of taking a much needed break (and doing pretty much nothing as a result) before then diving straight into development at the start of week eighteen. On Monday, Josh and I sat down together and had a brief discussion regarding development of DELTA-V as a whole as well as what each of us would be getting on with during this week. We used the rough schedule created for the Design Document as a bit of an outline, and the result was this; for the month of February, I would be creating new prototypes and getting the main mechanics of the game nailed down, and Josh would be creating new designs for each of the explorable planets and moons featured in the game. Our discussion then drew to a close, and without further ado I officially began coding-based development on DELTA-V.
I started with a Unity project entitled Prototype 0.1. In terms of naming conventions, I decided to call the Unity files in this period of development prototypes, as they will primarily be introductions and testings of various game mechanics as well as placeholder environmental testing zones, and so they wouldn’t actually be the final Unity project for DELTA-V. Once mechanics are nailed down (post February) the various scripts will then be transferred to another Unity project that will be the official DELTA-V project, and the era of prototypes will be over.
This week, I decided to focus on the Fortitude, the fully controllable spaceship in the game. I began with adding basic outer space-style movement to the ship, which didn’t take particularly long as I took most of the movement code from the “NASA Space Game” prototype from Semester 1. Looking through the Design Document, I then decided to look into our idea of how ship health would work. In our plans, we had decided not to have a “health bar” in the game, and instead the player would be aware of the ship’s current physical condition via a series of visual prompts (i.e. bits coming off, sparks etc.). With this in mind, I started working on basic ship destruction mechanics. I then requested that Josh separate various elements of the Fortitude’s asset into different image files (i.e. separating the thrusters and various equipment from the main body) and then added them individually to the Unity project.
With the various elements of the Fortitude separated, I added a collision-based mechanic where if a part of the Fortitude collides with an object in space at a relatively high velocity, said part will become detached from the ship. As an example, if the left thruster clipped an asteroid while the ship was on its way past, it would come off and the ship would begin spinning counter-clockwise as the forward momentum generated by the thrusters would be out of balance. I then added a counter mechanic where the player can regain lost parts of the ship if they come into close proximity to them (i.e. “magnetising” them back to the hull). This was all a bit of a mechanics-based experiment (as this lose/recall mechanic was not part of our initial design document ideas) but it ended up actually being a pretty fun and rather interesting mechanic, so Josh and I decided to keep it in the game (for now at least). This mechanic also forms the basis of the game’s health system, a mechanic that was further expanded on in Prototype 0.2, but we’ll talk about that later.
Prototype 0.1 – Behind the scenes
One issue that we ran into pretty quickly that week though was asset size. As the game is going to be pretty realistic, the planets and the way they move (i.e. orbits, gravity etc.) will be as close to how they behave in real life as possible. This also means however that the planets will need to be well…planet sized – at least in comparison to the Fortitude ship, which means that they will need to be considerable in terms of asset size. We made the Fortitude in the Unity project as small as possible (without needing to resort to multiple decimal places with movement mechanics) and Josh then set about making the planet assets as large as possible. He began with a 40,000 by 40,000 pixel canvas, but neither Adobe Illustrator nor Unity were particularly pleased with this – protesting with multiple crashes and a lot of freezing, to the point where Josh had to use university computers as his laptop simply could not handle the strain. With no real choice, he had to reduce the canvas size considerably to 5,000 by 5,000 pixels – but this meant that the planets looked kind of blurry when planet-sized next to the Fortitude.
A planet sized asset next to the Fortitude & various asteroids – note the blur
As of right now (the end of Week Nineteen) this issue is still ongoing, though not quite as serious as it was before – canvas size experimentation is making the planets less and less blurry, and they are looking better in Unity with each day that goes by.
It was then Tuesday of Week Eighteen, and it was here that things went badly wrong. I rather unfortunately came down with a bad case of the flu, and found myself practically bedridden until the Sunday of that week. Due to a complete lack of the ability to concentrate or honestly really do anything (and I did try – several times), development on DELTA-V from a coding perspective pretty much ground to a halt.
Things then resumed with a vengeance on Sunday, and I finished up development of Prototype 0.1 with some bugfixes and general improvements, and then created Patch Notes and a Coding Walkthrough. This is something I will continue to do for each version of the game, as the patch notes makes it easier to see what changes have been made during development as well as showing me exactly what work has been done with each week, and the coding walkthroughs help with showing me how certain scripts or lines of code work if I forget (which will probably happen – this is going to be a rather large game after all). And with that, Week Eighteen drew to a close.
Reflection On The Week
Things this week started out really well, and then quickly spiraled downwards as I came down with a rather unfortunate illness. The development of Prototype 0.1 pretty much went without a hitch (there were various bugs and things – which you can see by reading the Patch Notes for 0.1 linked in the menu at the top of the blog) and we now have a pretty good coding baseline for further development of the game. The asset size issues are still currently ongoing, but things are getting better and with a bit of luck the issue will be sorted within the next week or so. Other than my illness, things on the development front are going pretty well, and Prototype 0.2 is on the horizon – it will see the introduction of several planned mechanics including the Fuel System and basic game HUD, and hopefully these will integrate well with the game as a whole. 0.2 is essentially my plan for next week, so I’d better get started.