What Went Well
I went through 3 different major platform iterations DarkBasic back in late 90s, ImpactJS 2000s, and then finally after lots of recommendations — I committed to doing the game in Unity version 4.
I was able to implement the WASD movement, and tweak the basic ship combat parameters (speed in various directions, for example), and I was able to switch the weapons to being gimbals to point at the mouse for easy mouse aiming.
I also went much deeper into developing a back story for Luna Nova, including hiring multiple styles of artist to mock our character's portraits and create some cover images, as well as hiring voice actors and then personally composing a large number and wide variety of tracks for the various segments of the planned game.
I also built and ran a Kickstarter for the game and learned all of the ins and outs of that crowd funding platform to then help many other artists and game developers build and run campaigns after this game.
What Didn't Go So Well
Once I settled into Unity as my platform of choice, I had no experience with Unity nor did I know c#. I also had the conflict that my day job career was growing beyond just running a team of system engineers which ran servers into needing to learn how to build and automate platforms and cloud migrations that dwarfed everything I had done previously in my career in both complexity and scale.
So for many days, I was coming home after 8 hours of learning and working with one very daunting technology stack and hoping to become fully immersed into Unity and C#.
The last technology stack choices I made with Luna Nova included an asset for much of the visual effects that expected the particle system from the Unity 4 days, so as soon as I attempted to upgrade the game platform to Unity 5, I realized that the amount of work it was going to take to bring the game up to standards with the new particle system was much more than I had the skill at the time to do.
Lastly, and as a side note — though running my first Kickstarter taught me a tremendous amount about what I needed to prepare to get a game out to an audience — it also taught me that I needed to have a reasonably excited and engaged audience already before launching the crowd funding campaign, and as I did not have that previous to my campaign, I was not able to raise enough to quick my day job and focus exclusively on the tech stack and game design.
What Did I Learn From It
Build your audience both before and as you are building your game. Use every tool available to capture interest so that you can communicate directly with them. You will need them for crowd funding, for early sales, and for word of mouth to skip paying for a giant marketing push when you go to launch your game.
Don't spend too much time writing a back story and music for your own game. Identify the highest risk aspects of the game first. Make sure that both your tech stack and your team's abilities are ready to build the hardest and riskiest parts of your game first.
In the first 3 months, every line of code, every piece of art, and every game mechanic you build should be in the service of derisking your highest risk hypothesis about your game.
Highest risk Hypothesis are:
- Game Loops that haven't been proven to get people to keep playing a game are high risk.
- If you are mixing the best parts of two of your favorite games, that mix hasn't been proven that means that it is a part of the high risk.
- The art style, the story, and the game mode all tie into risk.
- The target platform (mobile, desktop, console, AR/VR) are all very different audiences. If your type of game hasn't already been a provable success on those platforms, it should be tested.
This is the first project where it was clear to me that less features but more polish was a very important part of shipping your first launch of the game. More particle effects, feedback such as screen shakes, and punchy sounds all make a huge improvement on the overall feel of your game. Most players wont even know the features you cut from your 1.0 launch plans to get that extra polish in.
Fully engaged combat, with flat UI in the upper left for upgrading the ship
Very simple Unity 3D platform, but with 2D planes configured for UI and game behavior as this was before Unity completely integrated 2D into their workflows.
The upgrade menu where you can apply new weapons and upgrade core systems in your ship.
As I mentioned in the things that went well in this project — I, as a casual composer, decided to write my own sound track for many parts of the game (file that under the things that didn't go well). I enjoyed writing my own soundtrack, but spending the time and energy tweaking things to match the rest of the game level of quality was going to take much longer than I had in my "free time".
These songs jumped around in both style and timbre, but I wanted to capture everything that came to me as worked on the game and bring it into the game as an asset with the assumption that I would eventually prune many of the songs before I did a final mix and master of them.
Below is the raw list of everything that made it into the project.
Luna Nova - 1: (Composed by: Mark McCorkle)
Luna Nova - 2: (Composed by: Mark McCorkle)
Luna Nova - 3: (Composed by: Mark McCorkle)
Luna Nova - 4: (Composed by: Mark McCorkle)
Changers — Mid-Chapter story telling background music (Composed by: Mark McCorkle)
DD-3 — Closing Credits (Composed by: Mark McCorkle)
HID — Pause Menu (Composed by: Mark McCorkle)
RJ - 1: (Composed by: Mark McCorkle)
RJ - 2: (Composed by: Mark McCorkle)
The Mark I (composed by: Mark McCorkle)
Dangerous Groups (composed by: Mark McCorkle)
Dreamland Isn't Here any More (composed by: Mark McCorkle)
Finally, I wanted to include the evolution of the two main protagonists in the game — Dragon the AI and Michael, the revived test pilot.
The first color head shot for the prototype AI in direct control of the player ships. Her code name is Dragon. All future AIs developed after her are dragon type AIs, as they were all modeled after her initially very promising successes. See the link below for the entire visual evolution of her character.
After the second treatment of the story, we realized that the AI character that was piloting the ship would need a foil to act with in the cut scenes, as the human playing the game wouldn't be able to react how the game expected and we needed to have clear behaviors and motivations for the drastic shifts in tone throughout the game.
Thus, Michael, the test pilot, was born. Michael had served as an experimental test pilot for the military over 10 years ago, but has been in cryo sleep for a decent amount of time how while doctors worked on a solution to a flaw in the cybernetic enhancements installed in he and others like him. Again, follow the link below to see a few more detailed sketches for Michael. He was never fleshed out as an art asset, but you can see that his tech was the predecessor to Dragon's appearance, which even he notices as strange early on, since he was a human with augmentations, and dragon was an AI designed, initially, to look human.
Game Design Sketches
Thanks to a lot of inspiration coming from all the different media and backgrounds of people that eventually came to the team, there were multiple treatments of the story done. My initial document was 8 pages, 5572 words, and 24426 letters long.
We do not have a test build nor do we have video of the gameplay, and after spending a few hours tinkering, even with my most up to date skills and understanding of the Unity tech stack, I was not able to get the game up and running.
So what we have left are the game design, the scripts, the art, and the music, and a game mechanic that takes the player though an exploration of what it feels like to meet and eventually to completely empathize with someone you considered your enemy.