Progress

Over the last two weeks or so things have been moving ahead.

New Team Members
We recruited some awesome artists recently who have started working on some models to replace the programmer art we're currently using for the fighters, bombers and motherships.

Engine Refactoring
We're currently about halfway into our conversion from a hierarchical engine into a component-based engine, which should help clean up a lot of bits and pieces and allow us to do some really neat data driven things. In addition we're going through and cleaning up a lot of the leftover stuff from our previous project which have persisted in our engine so far.

We have some interesting ideas with this component based engine once we get it up and running. We're also looking into using Awesomium to rewrite our GUI code.

Some Outtakes

This emerged when we were trying to stress test our engine to find a polygon budget, but the initial attempt to make a cylinder got the winding order wrong for every other face, resulting in what looked like "sound" waves.



Since our test shapes looked like sandwich cookies, we decided to go all out with that until we get actual art assets. Technically its a usability improvement since its easier to distinguish friend from foe now...

C++ Prototype First Look

Here's a few videos of the C++ side of our prototyping process. It's the more technical side, where we test out various features and mechanics, although it's a lot less pretty than Unity.

Combat

Drone combat is the more active fast paced side of Star Chronicles. Here's a look at what we've got for it so far. The beginning of the video shows the dust effect for a sense of motion and the camera zooming effect for a sense of speed. We then return to the battlefield to give a view of the scope of the combat. Finally we really enter the battle itself and try to take out some enemy ships.

Mothership View

Here we demonstrate what the battle looks like as a whole. From the mothership you can get an overview of the battle and see everything that's going on. We give a quick look around the battlefield to see it just as it's beginning and then move in for the action as it starts. Moving out again gives glimpse of just how epic the game is supposed to feel. Just imagine how it'll look when the fleets are full sized!

Mothership Orders


From the mothership you want to be able to do more than just look around. Commanding your ships is important and you'll want more agency than controlling a single one. This is where the squadron orders come in. Each squadron you control can be assigned to a different task, and of varying specificity. This video shows a quick battle and some task assignment by the player.

Other Features
There's a few other things you may notice in these videos. Ships can kamikaze dealing more damage than any standard weapon, but of course at a high price: the drone itself. In the drone combat video the player is actually destroyed at one point. However, when this happens the player is immediately granted control over another drone in their squadron. This drone becomes the new squadron leader and the rest will continue to follow the player around. When testing this can become problematic however, so we added in some cheats. The player activates god mode at the end of the video and turns completely white.

Unity as a Prototyping Tool

During the initial design phase of our game, we ended up with many questions about how over-scoped certain features were and if those features were to be kept, how to implement them. We also needed a better way of presenting our ideas than text and hastily created drawings to demonstrate how our game would actually function - both for outsiders looking to critique our ideas, and to give ourselves a common focus for how the end game would look and play. At this point, prototyping became our number one focus.

We wanted a prototype that would allow us to explore spaceflight mechanics, so 3D capability was a must. This ruled out simple paper prototyping, as well as ActionScript3/Flash(no one on our team is experienced with the 3D Molehill API, so that wasn't a time-friendly option). We also wanted a way to keep some of our prototyping code for insertion into the final product, with or without some minor language translation. At this point we became torn on whether to go ahead and start restructuring our engine from a previous quarter's class to use for the prototype, or use Unity as a prototyping tool. The former option could prove more time consuming and fall short of giving a good look and feel for how we wanted our end game to look like, but the capability for code reuse is very high. The latter option allows for fast prototyping with an easy way to express end look and feel using Unity's built in shaders, but no one on the team had much experience in using Unity.

We ended up taking a hybrid approach: two of us chose to prototype the main gameplay mechanics using the existing 3D engine architecture while one of us (me) recreated the parts of the game that would most benefit from a look and feel demonstration and/or fast iteration of feature designs. This includes portrayal of ships using primitive geometric shapes with glowy textures on them (cubes mostly), weapon control schemes, weapon visual styles, and interface design for both the drone and mothership views. There is also experimentation with positional awareness within a 3D space void (what backgrounds to use, having a particle field to give a sense of movement, planet placement, etc...), and iterative experimentation with ship upgrade schemes.

Flying within the starfield - the player is the blue ship, enemies are yellow ships. The orange trails are gunshots from enemy ships. Minimap textures taken from Starcraft II and Heroes of Newarth.

Flying over a mothership - orange cubes are hard points that are especially vulnerable to enemy attack.

From my experience with Unity so far, I can definitely say that this is a fantastic tool for the entire development process, from prototyping to final product. Even without any prior experience with Unity and after being away from C# for several months, it took very little time to get an environment up and running. The documentation and community are fairly good resources for learning how to do things, and the entire system has a very intuitive feel to it. There are two main problems I've run into that may detract from its usefulness as a full blown development tool: 1. External version control is a pain (though I hear this is going to be fixed in an upcoming patch) and 2. The GUI capabilities are rather limited (for example, not being able to simply rotate a screen aligned texture).

Shooting basic lasers using the mouse to aim.

For our particular group, creating two nearly mirrored copies of our game in two different environments is a waste of time and unfortunately, most of the scripted code from Unity cannot be easily moved into our existing engine without a fair amount of tweaking either. However, the Unity project remains an excellent tool for playing with visual effects and control schemes. I plan on reverting to working on our C++ engine full time within a few weeks after the initial look and feel prototyping is mostly complete, but will be keeping the Unity project for quickly playing with design ideas as they come about throughout the development process.

Next steps: more prototyping and playtesting, some code refactoring of our engine from a previous class, and  hopefully a clearer vision of how to implement game features.