Finally, I can write about Nova Legacy, which has been a few months in the works and nearing completion for public comercial release!
Nova Legacy is a top-down 2D real-time resource and strategy game. You start as the lone survivor of a post-apocalyptic world-war, and must survive long enough in space to find a new home-world for you and your survivors. You control a single ship that has the ability to collect resources in space, build other ships, and must try to defend yourself against enemy humans or aliens, as well as grow your army through growing your space-base. This project originated from a challenge proposed on Reddit’s r/GameDev subreddit, where the goal was to develop a fully working game in 30 days, much like LudumDare‘s 48-hour game dev. challenge. I wrote about this challenge on my Google+ page, and immediately received some interest from a few fellow Penn State students. After a bit more networking, we had a full team of friends, friends-of-friends, and professionals from all over the United States: three programmers, two artists, a musician, and a writer.
We started the project by developing a general design document. I’m sort of… obsessive when it comes to these documents, so I wrote as much as possible about the general interface, game rules, mechanics, and every possible detail under-the-hood and above. Check out the document here!
After this basic game design document, I wrote out all features and tasks that had to be complete, splitting them into a few categories: Art, User Interfaces, Sound, Marketing, and programming. As of right now, after constant work on refining and developing tasks, we have about 130 tasks. What’s interesting, though nothing new in the software dev. world, is that these tasks constantly evolved over time. Other programmers took complex tasks and split them into more detailed sub-tasks. Artists and our musician did the same, breaking down a request for drawing a ship into drawing multiple states of the ship, ship components, reusable sprites, etc. Check out this task-list document here!
Since I’ve never lead a large group of people with different jobs and different backgrounds (until then, I’ve only worked with fellow programmers), we decided it would be best to do some “basic” management routines: we all introduced each other by email, and met formally through Google+ hang-out system. It was absolutely brilliant! Not one of my people was physically near me (some were in Pennsylvania, some in Virginia and one in South-Carolina, while I’m in Washington state), yet we worked out all of our issues using phone-calls, Skype, and the hang-out system. Frankly yes, it would have been far more effective being in-person in the same area, but using (free, even better!) telecommunication tools really worked well enough to get all of our work and meetings done in our respective schedules. As a manager thought, regardless of our tools and meetings, it was still incredibly hard to pace our work out. Every member either had a full-time job, family, or was looking for a job, (or a combination), so even though we had a great task system and tools, we naturally fell behind in some weeks and jumped forward others. I suppose this is only normal, though to a hopefully less extent, in a regular software dev. job.
Our general software design approach was to develop our game in Unity3D, a powerful 3D engine that allowed entity-model C# scripting. The architecture was, as Unity3D really forces you to develop this was, was a basic entity-model system: all on-screen entities, GUI, graphics, music, etc. were stand-along entity scripts. A script could be launched by another, and could also retain relationships across entities. Though not at all a clean solution, it is the real-world practical solution. Our code became messy at times, but we at least could develop independently of one another and only integrate entities as a whole when we wanted to. We developed some stub code, but quickly realized it was still better to just avoid any sort of code until an entity was strong enough to stang on its own. We did heavily use C#’s inheritance model, since that really helped with under-the-hood entity management, but otherwise any graphics-related work was always pushed off to Unity3D.
A tool we only started using later in our development cycle was Unity3D’s in-game level editor, though it proved to be incredibly time-saving. Before, we had only used text files in special INI-like configuration syntax, but that quickly worked against us as we had to start describing complex properties of entities (such as sprite animation groups, explosion effects, etc.) Related to this issue was the issue of unintentionally re-implementing many built-in features of Unity3D. This error is common when new to a platform, but looking back it was absolutely another issue that worked far too much against us. We ended up re-implementing a sprite engine, thinking it would speed up our performance, but we should of simply treated the world as a true 3D space and used an orthogonal camera to render in a 2D-like view.
As I mentioned at the top, one of our big goals was to do this project in 30-days… and we did it! We developed a fully playable fully working game in exactly four weeks! The problem though is the game we had made didn’t have all the “fun” features we wanted, such as damaged ship animations, or smarter AI (at the time, our AI targeted the closest enemy ship and simply shot at it). Over time from July to September, we had developed all of the features we wanted after our initial 3o-day push: our AI now used some neat motion-control algorithms to fly around targets. We even had cool ship contrails that would swing around based on the ship’s movement. We had a fully-working GUI and level section system, with a story that would pop-up before and after every game session! We got as far as deploying on Android and iOS!
So where’s this game? Great question! Sadly, we failed to talk about business seriously since day one: though we were all willing to invest into the group for software tools or more, none of us were willing to give-up the capital needed to pay for a full copy of Unity3D, which would of ended up as not-so-nice $3.5k. Lesson learned: know your platform and know its licenses before you start writing code. We are now, after a short break, working on porting the game from Unity3D C# to Google’s PlayN Java platform! We’ve got marketing materials, new music, new art, and more all in our release cannon, ready to blow up the indie game universe, but we can’t light the thing until our final efforts of porting are complete.
In the mean time, we are going to do two big things: We’re going to open-source the Unity3D version of the game next year, and we’re now releasing all of our private internal-testing videos to you, immediately! Check them out!