Progress updates

Ron — Sat, 29 Dec 2007 19:17:00 +0000

Began actual work on the engine. Created a new framework for the engine and game.
Progress on the project is way ahead compared to my designed schedule, altough compared to the amount I have to do (game and engine), its just a fragment of it all.

I was given the outline of the project, speccing the minimum requirements of the work, all are included in the schedule and todos for the game prototype.

As for the work done, I have coded up the Render System. This system simply intiliases OGRE renderer and sets up the window to begin rendering. I stated clearly that the render is very important in controlling the game loop. The AGT render manager only contains one class. Originally it was 2 classes working in the the render system area of the engine as show below:

Both classes have now been melded into one RenderManager class. Here’s the codeblock for this class:——————————————————–



class RenderManager : public Ogre::FrameListener

{

private: // Attributes

Ogre::Root      *m_pRoot;    // Ogre root pointer

Ogre::RenderWindow    *m_pRenderWindow;  // Ogre render window pointer

unsigned long     m_hWnd;     // Handler to the ogre render window

bool       m_bStatsOn;    // Stats display

Ogre::TextureFilterOptions  m_Filtering;   // Texture filtering mode

int        m_iAniso;    // Anisotrophic level

bool       m_ShutDownRequested; // Shutdown call

static RenderManager   *renderMgr;    // Static pointer to self

private: // Functions

RenderManager(void); // private ctor for singleton class

void initialise(void);

void setupResources(void);

void createWindow(void);

bool setup(void);   // Runs through and call all functions initialisations

void createFrameListener(void);

public:

~RenderManager(void);

static RenderManager* getSingleton(void);

void cleanup(void); // Cleans all pointers to render system

void startRendering(void); // Renders frames

bool frameStarted(const Ogre::FrameEvent& evt);



bool frameEnded(const Ogre::FrameEvent& evt);

// accessors

unsigned long getWindowsHandle(void){ return m_hWnd; };

// Returns handle to render window

// Returns ogre root pointer

Ogre::Root* getRoot(void)

{ return m_pRoot; };

Ogre::RenderWindow* getRenderWindow(void)

{ return m_pRenderWindow; }; // Returns render window pointer};

——————————————————–RenderManager has inheritance link to Ogre’s FrameListener. RenderManager is a singleton class. From main this singleton can then be called and by simply calling the ’startRendering’ function, OGRE will provide a program while loop that will quit if you pass the certain functions to the frame listener functions. Virtual functions ‘frameStarted’ and ‘frameEnded’ from the FrameListener class must be implemented in order to do so. Any classes that inherits from the FrameListener will be registered for these functions to be called when update occurs.

Implemented the Object system to a point where I have 2 scenes working and able to switch between them. One of the scene is empty and the other contains a test object, flat textured floor object, done through attaching a test mesh component to the object. I have skipped initial implementation on the state manager, for the sake of testing the object and the rendering system.

Next implementation is to create the input manager for keyboard and mouse, so I can control the camera in one of the scenes, by adding a camera control component to a test player object. X360 gamepad support will be added in a later stage.
For now here’s an image of the code structure in VisualC++:

AGT Engine technical documentation

Ron — Wed, 19 Dec 2007 16:18:00 +0000

The technical documentation of the project is due in this week and I might as well explain some the various aspects of the game and also what’s running the game behind it, the engine.

First of all let me explain the idea behind my game. Title is yet to be assigned to the game but I will eventually get to it.

The story is based on an old 2D RPG I have made long ago, with the RM2k tool kit. The idea was to implement the story to this game, but leave behind the turn-base RPG. I will try and get that game up on my blog when I have the available time.

So yes, its going to be a mixture of rpg and action-adventure with more emphasis on the latter since the idea was influenced through games such as Zelda: Ocarina of Time series.

The game will be third-person perspective(see previous post of what this may look like), in a open roaming world. Though this won’t be just an unlimited landscape, I will be segmenting different parts of the world. The assigment brief I have received today requires a complete game prototype. In the time span available I can guess that I could probably get one or 2 segments of the whole game world into the prototype.
Anyways the list continues – The player will take on the role of a character through this fantasy game. This allows me to add some interesting aspects to the game. One of them is the use of spell system that can then be upgrade by finding better ones or using it various times allowing to gain extra experience.

Within the game the player may encounter amulets that then can be attached to a weapon the player character is using, allowing the player to use its respective spell type. As the player progresses through the game they can gain much more stronger amulets from hard enemies, bosses, finding them, or doing quests. It’s a similar idea to the materia system in Final Fantasy.

Spells in this game will bare the following types:
- Damage spell
- Buff spell (for player and/or sword)
- Debuff spell (single)
- Debuff spell (Area of effect)

Some of these spells can be casted at close or long range.
The limitation is that for each individual weapon the player finds, the number of available slots can vary from 0-4. So at one time the player will be given a maximum of 4 useable spells to cast during combat. These amulets are not totally necessary as the player can go through the game will little use of spell, though when encountering harder enemies, the use of spells could help.
Other note in the spell system was to try to allow each amulet to gain experience depending on the amount of use by the player, thus making each spell much more stronger that the other. This idea may or may not be implemented at the end, as the player and spells will improve the further the progress.

So there will be no stats for the player such as Strength, Stamina, or Agility. The damage a player character can do to an enemy will be static. The health and magic points will begin at a defined amount and can then be upgrade by finding items in the world, your usual Zelda upgrades, where you would regularly search for clues and find these items, many of these items can be gained through doing a number of quests.

The meat of the game is the combat system. Again I stress there is alot of Zelda influence on this game, but I didn’t want to recreate the same systems in just the way Zelda has been doing them.

In each combat the player can lock-on to the target, this way the player may side step around the enemy. The player can attack/defend in 4 different ways. These are the directional attacks.
Examples:
- player can make the character attack the head of the enemy by pressing the forward direction and the attack button.
- Character can attack left side of the enemy by using pressing left direction and attack
etc. The other two are attacking on the right hand side and thrusting towards the body of the enemy(back direction + attack)

Obviously there will be various NPC and object interactions within the world. As I have stated, the areas in the world is free to roam in, so that player can get to various places by jumping there or finding a possible route.

So that’s the basic ideas behind the game. It’s all so far just simple ideas, but I will get to showing the appropriate concepts and designs of the game in due time.

For the engine itself I have research quiet a number of engines. I originally planned to use an object system with various types of manager connected to it, but eventually having read on object-component systems, I thought it would be alot more interesting and better to implement. After looking up on Component-Objects system I stumbled upon OGE (OpenGameEngine). Which uses an Component-Object system similar to that used in Dugeon Keeper.
I have yet to use this engine and mess around with it, but the concepts the developer made in his wiki site got be thinking of the ComponentObject system in the engine. I have used the fundemental designed of the engine systems used in OGE shown below with some changes:

The implementations however are going to be my own, as the various subsystems in the engine will use various types of coded or middleware APIs.
All of these subesections are explained through the game technical documentation, which I will try and post after submission in the end of this week.

RonEnix » design

Progress updates

AGT Engine technical documentation