Animations + Development

Creating Animations in graphics gale is quick and easy. The frame window is familiar and simple to use. Animations are where the sprites begin to come alive and with little work even the most subtlest of animations can really bring a sprite to life.

Units

We decided on having 3 frames per animation. With an idle animation just for starters. Here is the idle animations for our units:

Gatherer

Heavy

Demo

Soldier

Scout

Some of the .gifs may have a slightly different delay in frame speed from the actual ones running on Hardware but if anything would just be a slight delay of 0.05 seconds at most.

Development

I wanted to go a bit more in depth for development and show exactly how graphics gale works. I wanted to show things I have to look out for such as the pixel sizes, color depth and what kind of alpha is needed depending on each texture.

Essentially just a standard window of Graphics Gale opened. Unfortunately you can't quite make out the writing in the picture and I can't make the image any bigger. Essentially it just says what each window is for. The main window is where you obviously work mostly, in this current screenshot I have a grid enabled which lets you view each pixel individually. Graphics gale is set up just like a lot of other graphics programs are such as Photoshop or gimp. It has layers, can have alpha channels, a palette (which is much more important to take note of when making sprites) and the ability to create frames for animations.

Color depth and Palettes

The sprite opened is a 64 x 64 pixel texture which has a bit depth of 4 (note 64x64 is only used on special occasions, as it is quite large for DS). Essentially the bit depth limits the colours on the palette and reduces the size, which is a big thing to look out for. 2 bit is only two colours, so on this image, we use 4 bit since we can use upto 16 colours (if you didn't pick up it goes up in multiples, 4x4 bit = 16, 8x8 = 32, ect). You can change the color depth at any time, it also interpolates the colors if you have too many as best as it can if you reduce the bit depth and have a texture which exceeds the amount of colours permitted for that bit depth.

Animation

Here I wanted to point out the properties you can set each frame, you can change the delay for each frame to see exactly how fast/slow each frame will go. My animation here is going at 0.25 seconds per frame. There is 3 frames.

Alphas and Saving on Memory

This picture shows a few things. One is that I wanted to show that to save some memory and so that we didn't have to have actual text up on the top screen we just used textures instead. This is for things such as unit abilities, the map name, unit names, unit stats, player stats, ect. This meant also having numbers 00-99 for textures too.

The second thing I wanted to point out, is the difference in alphas. As you can see the units have a white background while all the other textures have a pink background. This is because of the way we handle alphas on the DS. The units read alphas quite differently since opengl takes care of it, you have to actually create an alpha channel in graphics gale. There is different levels of alpha used, one that is 100% clear, 100% alpha'd, and three for in between for drop shadows on the units. The other way to make alphas is using grit, since the UI elements are drawn differently and not in opengl.

This requires each of these textures to have the first palette colour as the alpha, which is pink (255 0 255, RGB).

The grit alphas are mostly just for UI elements, pretty much everything on the top screen and the UI on the bottom such as the dpad and unit slots. Effects, placeable's and units, as well as their animations are all done using opengl alphas.

That about raps up everything I wanted to cover this time. Hopefully you learnt something new!

Units

We have 5 units in total. To create units you select your base and select which one you would like to build. It will take time for this to happen and you also have to take note if you have enough resources in order to build the specified unit. Once they are built, they will spawn just outside your base and you will be able to freely move them across the map.

Gatherer: Finds and gathers resources which can be used to produce new units.

Scout: Fast and has a long attack range. It is able to detect stealthed units.

Demo: Stealthed unit (while not in combat) which can pierce through armor but is limited to close range attacks.

Heavy: Has high armor and attacks cause splash damage.

Soldier: All-rounded unit which is also able to slow down units movement speed on attacks.

Balance and Conflict

Conflict Tree

To make the game balanced we have made it so that every unit can be countered. This way players won't just be building one specific unit in order to win, they will have to strategize and combat what their opponent is building in order to achieve victory.

Development

I thought it might be a good idea to go through the development process of how I create the unit sprites. Before I even started, Chris and myself had to figure out exactly what kind of memory we where able to allocate. This covered the texture size, bit depth, number of colors in a palette, number of units, number of sides of each unit, number of frames we could give for animations per unit, and so on.

In the end we decided that I could work with 32x32 textures and use up to 32 colors on a palette for the units. This included alpha levels also (which was used for drop shadows). Each unit has two sides, a front and a back. They are translated in code to create 4 sides for each unit so that we can save memory. Animations are 3 frames each, which brings a total of 6 textures per unit (at a minimum with just an idle animation).

The program I used to do all sprite work has been in Graphics Gale.

A screenshot of Graphics Gale in action.

Each unit went through a few changes before they ended up being complete. Below I have added a picture of the units as they started out, and how they turned out in the end. Some needed to become smaller to fit the unit characteristics, while others where bland or the biggest one, the units did not translate correctly once they where in-game. Since the grid is in 3D, the angle does not fit for isometric sprites so they had to be tweaked to look right.

Units before/after

That about does it for explaining units in CMD and how they fit in the world. Next time I will go into animations and show the development process I went through.

Programming stuff.

As my first post, I just want to briefly cover some topics related to our programming:

What do we have so far?

At a first look we have OpenGL rendering, with a 2D sprite layer for UI on the bottom screen. On the top screen we have a 2D Background with sprites layered ontop for a UI.

We have a background being drawn in the OpenGL layer, with a map infront of that. The units are able to path around the map.

What problems have we had working on the NDS?

Because I personally am handling all of the "engine" work, that is anything you see on the screen I have had to learn to work within the bounds of the NDS hardware, and the API that the community has right now.

That said, there haven't been so many problems but I have certainly had a learning curve coming into development on the NDS.

The biggest and most obvious difference between working on a similar project on a PC, is the limitations of the NDS hardware, the NDS has a tiny amount of memory available to use (4MB of system memory, and 656KB of video memory, where as a PC might have upwards of 1000MB available system memory, and 128MB+ video memory, depending on your target system)

What the memory limit really means is that we cannot simply go "OK lets add 50 1024x1024 32bit textures to our game" instead we have to have to carefully map our texture memory usage, and stream resources as much as possible.

Furthermore, I minimized our texture usage by using a 8bit texture format which uses 3bits for the alpha information, and 5bits for color - this is for the OpenGL layer, both me and Tom worked out how many colors he needed, and how many potential textures would be in use at once, the a3i5 format came up as the best possible solution while keeping within the bounds of memory.

Also, with these strict texture formats in mind, Tom has done a great job learning the correct pipeline and how to correctly set up textures, keeping my hands doing programming and not stuffing about fixing up artwork.

The NDS also does not have hardware floating point computation, which requires programmers to use fixed number math as much as humanly possible to maximize performance.

The NDS also doesn't come packaged with a i7 processor, so we have to be more careful about our algorithm efficiency than normal.

Enough of this anyway,

What else are you going to do from now?

- Animations

- Sound

- Networking!

- Dynamic UI field creation

- Debugging

- Testing

Anyway, I will post up another time with more information on the programming side of things.

Introduction

Welcome to Steelcats development Blog. Here we will be posting updates on our development for a university project throughout the semester.

The project we are working on is a 3D Real-Time Strategy on the Nintendo DS.

Current Build

Team Members

Our team consists of three members, Chris Berry (Programmer), Patrick Randell (Programmer) and myself, Thomas Johnston (Designer). Chris mainly handles the 2D and 3D Programming, Patrick handles the gameplay programming and I handle the gameplay design and Artwork.

Project Summary

The project is named "CMD" which is pronounced as Command. The theme is based on a representation of the insides of a network, where units you command are malicious software, resources is data from computers and your base is your home computer.

Gameplay Summary

Gameplay is focused mainly on units and moving them across the map. Each player has a base (your computer) and the goal is to destroy your opponents base by creating new units (malicious software) to destroy it. Resources can be collected by certain gathering units and this is done by capturing computer nodes scattered in specified locations on each map. You spend your resources to create more units, while you look for where your enemy is hidden to destroy their base.

Current State and The Future

Currently we have a 2D & 3D API (the engine), basic gameplay for moving /creating units, most art assets are complete and this semester we have aimed at just polishing what we already have, focusing on gameplay, sound/music, effects/animations and overall look.

My next update will go more in depth into units, how we aim to have balance and conflict and later I will go into the sprite creation and show the development process I have to go through from start to finish. This will cover how much memory I have allocated to sprites and how I go about solving limitations whilst working for the DS.

Semester 2 started..

Semester 2 has started;

Making a test post on the blog to test it!