Technical Design

About This Document

Status

Work in progress.

Scope

This document covers technical design aspects of Necromania.

Conventions

New terms are emphasised upon definition.

Authors

Brasse (brasse@ludd.luth.se).

Elemel (z94lind@mtek.chalmers.se).

Introduction

Necromania is a side-scrolling dungeon hack platform game, all in glorious 2D. At a first glance, the graphics we will use might look a bit simplistic, as seen in this piece of concept art, but we will spice that up with rigid body physics, spectacular animations and amazing gameplay. What we want to do is to build a game with simple graphics and focus on making that graphic bahave in an interesting and realistic way. For the animations, we will focus on the movement of the characters rather than realistic-looking characters. The world that these characters will interact with and move around in will be simulated using a 2D rigid body model. This will give us lots of interesting and exciting options when it comes to the actual gameplay.

Graphics API

At the lowest level of the graphics system we will have some cross-platform library such as SDL or GLUT. Which library this will be is not entirely decided, altough we are leaning towards GLUT. We do not want to have to depend too much on what the underlying library is, if GLUT turns out to be unsatisfactory we want to be able to switch to another library easily. To do this we will define the API that Necromania will use to handle graphics and window related tasks, and implement the glue that tie this API to GLUT (or some other library). Switching to another library should then only consist of the simple (you wish!) task of creating the glue to tie our API to that other library.

Our API should provide us with functionality to do (at least) the following:

• Open a window on the users desktop in which Necromania will live. One should be able to define the size in screen coordinates and the color depth.
• Define the viewport to the game world. This might be done by setting the coordinates for the top left corner, width and height for the viewport (all of this in world coordinates and world length units).
• One specific thing we want is to make the ground shake when heavy monsters stomp their feet. This and other things might be done with something we shall call viewport effects. Such an effect could for example rotate the viewport or shake it when a monster stomps it's feet on the ground.
• Adding geometry to the game world. This will probably be points, lines and polygons.
• Setting rotation, transaltion and scale factor of our geometries.

In some higher-level API, we will define things like animation functionality.

Rigid Body Physics

On top of the graphics API we will have a physics simulations layer, more specificaly a 2D rigid body physics layer. We will use this in order to make the objects in or game world to behave in a realistic way.

The physics API should provide this functionality:

• Adding objects to the simulation. The objects will be arbitrary polygons with a specified mass and moment of inertia.
• Defining different kinds of forces to act on the objects. This will be things like gravity, point attractors and repellers and drag.
• Define relationships between objects and forces so that we can have a number of different groups of objects being influenced by different forces. Two of these groups might be spirits, subject to spiritual gravity; and normal objects, subject to normal gravity.
• Define optimal orientation for objects with respect to air resistance. This mechanism lets arrows and other missiles assume appropriate orientations during flight. The optimal orientation is stored as a vector, thus including direction as well as magnitude. An object not optimally oriented in flight has an increased air resistance, depending on the difference in orientation, and possibly the magnitude of the optimal orientation vector. The difference in orientation also creates a torque that attempts to rotate the missile toward its optimal orientation.

Animation System

Future Extensions