First Implementation

For this first implementation loop I started with the map setup and control of the ship. I'm using temporary assets here for the sake of quick iteration. The ship comes from a FreshEngine PSP sample I did a while back.

Levels

I'm testing first on a city setting, simply because it is modular by nature and will help me defining the game constraints. I choose to use a 1 unit for a bloc of the city. So I can quickly and easily build large cities. I built 2 buildings blocs and one ground bloc in Maya and then exported them as static objects.

In Tiled, I created a test map using small 64x64 pixels icons for each of the tile. I export the map in the CSV format (Coma Separated Values).

I then wrote a small xml parser in lua to extract the values and generate the map in a lua table with each tile index.

At load time, I load the CSV file (a few kilobytes), generate the table and simply instanciate my static objects depending on the index in the table, and voila the map is generated in a few miliseconds.

Control

My first implementation of the ship control was in Lua so I could validate the functionnality. Now it's all in C++ and is much faster.

I'm using constraints to drive the ship so I can introduce some delay by simply changing the strength of the constraints on each axis. The camera is also constraint to the ship (using aim and position constraints).

Controling an object in camera space requires to take care of a few things.

In order to control the ship at even speed whatever the camera view, I need first to project the camera front vector onto the XZ plane otherwise the speed of the ship would vary depending on the camera pitch.

As my camera will not roll, I can take the camera Right vector as is.

Then I can modulate the stick vector by these projected camera vectors.

Next I need to check for the length of the vector not being greater than 1. It can happen when the stick is in diagonal because the diagonal is longer than each separate stick axis. If that's the case, I need to limit the length to 1.

To switch altitude, I simply change the altitude of the position constraint of the ship and the engine smoothly interpolates (weights inependently set on each axis) the ship position.

Here are some screenshot from the PSP version:
This is when flying at the upper altitude (1 unit). So the ship can fly above the buildings.

And now, when pressing the altitude switch button, it goes to the lowest level (.3 units):

Notice how the camera is now almost vertical to allow a better readout of the situation and enable the player to easily fly around the buildings.

I also change the camera field of view (FOV) so the view gets almost orthogonal when the ship is at the lowest altitude. This completely change the perception of the game and makes you fell more involved in this view. It will be useful when interacting with ground objects.

The shadow really helps to read the flying altitude. I don't have the shadow yet on the PC and PS3 versions since I need to write some Cg shaders first. On PSP the shadows is managed by the engine and doesn't require writing shaders since it's all fixed pipeline. I'll do that later.

Next post, shooting, collisions and bonuses.

Story and Mechanics

As I'm planning to develop a personal specific universe for this game (as opposed to using the Zaxxon one) I need to develop a story around my game.

My story summary for now is the following:


'A week ago, invaders attacked the earth. Given their supperior technology, they defeated coalition forces in no time. They made all human prisonners, but one guy escaped. During his escape he found some special weapon. Now he wants to fight the aliens back and free earth from their hold.'


Let's first give a tentative name to the game (I need it for my project folder anyway). I need to convey the spirit of the game which I'd like to be somewhat tongue-in-cheek and kitch.

Key words I've assembled are: Invaders, aliens, revenge, aftermath, fight back, conflict, universe, galaxy, space, star, battlefield, earth, attack, freedom, mankind, unwelcomed, the clearout, species, roswell, area 51, armageddon.


Another important thing is to comme up with a name that is unique and has not been used anywhere else. Some google search will help, but generally the longer the name, typically with a subtitle, the least chance you have to get sued.


So I came up with this:


'Invasion Aftermath, Mankind's Revenge.'


Note this could be read as 'I'AM Revenge'.


Let's now talk a little about the game mecanics.


My planned process it to iterate around a prototype to remove risks and validate mecanics.

Here's my first process loop (essentially focussing around the 'toy'):

• Is my control pleasant and intuitive?
• Can the player easily understand the height of the ship?
• Is it intuitive and easy to shoot static objectives on ground and in mid air?
• Same for moving objectives?
• I'm quite fluent with Lua, but can I implement and integrate custom functionnalities in C++ when I need higher performance ?
• Do I have a fully functionnal and convenient pipeline for quickly building dozens of levels?

The first mecanics I'll implement are the ship control and the camera.


I'm a huge fan of SuperStardustHD (developped by Housemarque), and although my camera will be in perspective (as opposed to top-down in SDD) I do like the screen-space control scheme. It's a well acknowledged way of controling a character and it has been there since Mario64.


So to move the ship, you use Left analog stick. Relative to the screen.


That is something very different from Zaxxon, because here you'll be able to move in any direction on the XZ plane. This will allow for some specific gameplay patterns and could potentially allow for exploration mecanics. Great if the levels are potentially huge.


Also I need to control altitude change. In order to reduce complexity, I will assign a button to switch altitude. This way, I can avoid difficult situations where the ship would not be alligned with ennemies or item height. So we have two heights, low and high. I will then be able to design ennemies/traps..etc specifically for each height, and some might also be able to change height just like the player.


As the camera will always look pretty much toward the same direction, I do not plan to give control over the camera. It will be essentially automatic. I need however to give enough room around the ship in order to ensure sufficient visibility for the player. In other word, the camera will be quite distant.


That means I'll need some close-ups during cinematics or whatever, to create some binding between the ship/main character and the player. I think it's important for player 'involvement' and suspention of disbelief. I'll leave that for later, as I focus now on the core mecanics.


Allright, next post first control implementation and screenshots!

Let's get started

According to Schell, the four elements that will form the game are: Aesthetic, Technology, Mecanics and Story.

I recently made a slide for a conference I had at the school that sums it up:

As stated in my first post, I'll do the eye (ear) candy later. So I decide to postpone the aesthetic related decisions a little (including sound and music). I know from my experience I'll be able to handle all those aspects with no difficulties (apart from the immense amount of work to be done).

Let's talk a little about some technology choices I need to make. My goal is to produce the game on as many different platforms as possible. FreshEngine (www.freshengine.net) is cross platform and cross generation, currently supporting PC, PSP, PS3, X360, with Vita in progress and Android and iOS at the blueprint stage.

I however have to plan how to deal with the disparities in performances and graphic capabilities of all those platforms.

Although I know my vision of the game will evolve with time, I need a starting point. That's why I'm using Zaxxon ( http://www.youtube.com/watch?v=toSxQ3QHaTc ) as a reference. That means controling a 'ship' in lage environments with a 3/4 top down perspective, shooting at enemies, avoiding traps, and dealing with 'height'.

As I want the game to feature dozens of levels, I need some effiecient ways of building those levels, with the ability to quickly test a level within the game. I also need an abstract representation so I can edit a level once and automatically deploy it on all the platforms with their respective specialised assets.

For instance, I want to be able to place a building in the map, and automatically deploy a low-def building on PSP and an hi-def building on PC.

Also, to be honest, I have no idea how long making this game will take. Probably 2 or 3 years. Will it make sense to make a PSP version at the time? Probably not. Will it make sense to make a PS4-X720 version? Could be. The truth is I don't know. So I'd better prepare for them all.

Finally, I need this representation to be compact as I plan the game to be distributed via digital distribution only.

The idea is to edit the map using Tiled (http://www.mapeditor.org/), a free to use generic tile map editor. I use the 2d tiles to represent map elements in an abstract way. The map is then exported as xml file containing a reference to each tile and some other infos such as rotation, additionnal objets or items.

At run time, when loading a level, the xml file is parsed and, depending on the platform, each tile is referencing a 3d object instance from a library that has been previously loaded into memory. There is one library for each platform, but it is only loaded in that particular platform, when the game starts.

The libraries are created in Maya, and optimised for each major platform.

Next posts, Mecanics and Story.

Now, where do I start

I've already started working on this project for about 4 month now. I can work on it for about 2 days a week, which is not much but that's better than nothing.

At first I didn't know anything about game design, so my first reaction was to buy some books on the subject and study. I also followed some classes in C++ with my collegue Fabrice Lete to get up to speed with the language.

I must say I've been very impressed so far by the book 'the art of game design' by Jesse Schell. I'm not yet finished but I'm starting to feel like game design is no longer black magic. I'm still not very confident in my choices but I feel at some point I might be able to anticipate and create mecanics and systems that might work.

A few month back I started writing down some pieces of the concept and I'm regularly updating them.

As I'm pretty confident about my art and technical skills, I decided to work on all the other aspects first, design and prototyping, and then iterate until I'm pleased with the result. I'll do the eye candy later.

I first chose to work on a Zaxxon type of game. The render would be 3d, but the gameplay would be on a 2d plane at two different altitudes.

The first step was to put together the project on the various platforms and develop the 'toy'. The 'toy' is the control of the main 'character', a small ship here, along with the camera. Again, with the 'implement and iterate until that feels good' attitude.

I'm using LUA as my main programming language, with some support from C++ for functions that are more CPU intensives. I'm of course using our engine FreshEngine.

As I plan to release the game on as many platforms as possible, I need some abstract way of representing the graphical resources so I can adapt to any GPU easily. More on that later.

That is all for this first post, I'll present the project in more detail in the next one.