Saturday, January 28, 2012

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.

Monday, January 16, 2012

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.

Tuesday, January 10, 2012

Space Chronicles (Working Title) Dev Blog

This blog is an account of the upcoming RIT 2012 Graduate Capstone game Space Chronicles 2142 (working title) - a game that combines the fast-paced action of the first person shooter genre with the mental workout of tactical strategy games. We are currently a 3-person team of programmers looking to recruit willing artists and programmers over the next few weeks for creation of art assets as well as increased manpower in engine, AI, and gameplay subsystems. 

The game is set in outer space, with the player facing waves of enemy space fleets consisting of large, hulking motherships and small, fast drone ships, all hellbent on the player's destruction. The player's own fleet consists of a similar composition. During gameplay, the player has the option of taking the view of either the high level commander, able to see the entire battle from afar, or an individual drone ship within the thick of battle. 

In commander view, the player will be able to view the ongoing battle from a zoomed out perspective, as well as give high level orders for squadrons of drone ships to carry out against the enemy mothership - for example, one squadron may be ordered to attack the enemy mothership's engine, while another squadron may be ordered to flank the enemy mothership from either side to take out its anti-drone turrets. In drone view, the player will be able to aim and shoot at opposing drone ships and motherships in a way similar to Starfox 64. This will allow a greater feeling of destructive control for the player, who may choose to offensively attack specific hard points of the opposing mothership directly or simply attack opposing drones to defend the player's mothership.

The player will be able to fight fleet after fleet of enemy ships with increasing difficulty, with the option to upgrade their ships over time. The player loses when they have become completely overwhelmed by the enemy's forces and have no remaining drone ships nor mothership.

While the combination of several genres is not unique in the game industry, our market research has shown that there are not many modern 3D space shooter games with our proposed combination of gameplay styles. We also hope to enhance the traditional visual styles of space games with a heavy emphasis on visual effects, including generous use of brightly colored particles, glowy auras, and lots and lots of explosions. We also plan to use models consisting primarily of primitive shapes (cubes, cones, cylinders, etc) - an extension of the recently popular voxelized art styles of Minecraft, 3D Dot Game Heroes, and Voxatron. 

Our team is currently in prototyping phase, which may give rise to several changes in the game's mechanics and/or direction - updates and more detailed posts will follow!