# Game World structure in classes

I am developing 2D game in java, and I want some basic in-game scripting (spawn enemy, spawn item, change enemies properties).

What I don't know is, how to divide the game world, to easily work with it.

I need enemies (have health, basic AI) of different types, item classes (can be picked by player), tile map with different blocks. Whats the best solution to maintain the whole world and to what classes should I divide it, to easily extend?

• So tl;dr is how can I organize my game world architecture? – The Communist Duck Apr 27 '11 at 17:05

I guess I'll post my answer here to...

I usually have a layout similar to this.

GameObject has functions such as Draw() and Move(). Then Enemy sets up some more functions and variables for implementing Artificial Intelligence in Goblin and Unicorn. Player contains all the stuff for moving the player in Move().

Thats just a general idea of what I would do. Its different for every game, depending on what type of game it is and how you play it.

• Unicorn as enemies? What, do you hate happiness? – octal9 Apr 27 '11 at 20:13
• ever played overlord?... unicorns are evil man – youri Apr 28 '11 at 10:38

I think it is also highly dependent on how your overall application is structured. You should ideally separate functionality as much as possible.

Naturally we all want to see a code example, so I'll give it my best shot. Though to be honest, this all means nothing without being related to your own specific examples. Perhaps just do some basic prototypes, and when it gets clunky (and it probably will), re-factor. Iterative design accomplishes so much more than if you try to plan it all at once; in which case you meet constant mental blocks; and may even lose motivation.

class Renderer;

class Mesh {
Vertex Data etc;
}

class WorldObject {
Position, Rotation
}

class Movable {
Velocity, Acceleration;
}

class Terrain {
WorldObject;
Mesh;

draw() { Renderer.draw(Mesh, WorldObject); }
}

class Entity {
WorldObject;
Mesh;
Movable;

draw() { Renderer.draw(Mesh, WorldObject); }
update() {
// update position based on velocity/accelerate
}
}

class World {
Terrain;
Entities;

draw() {
Terrain.draw();
foreach Entities
{
entity.draw();
}
}
update() {
foreach Entities
{
entity.update();
}
}
}

class Animation {
Animation data etc;
}

class AnimatedEntity : Entity {
Animations;
}

class Health;
class Gear;

class Character {
AnimatedEntity;
Health;
Gear;
}

class Situation {
Entities enemies;
Entities obstacles;
Position;
}

class AI {
Brain;

React(Character, Situation) { ... }
}

class NPC {
Character;
AI;
}


This could go on forever; the implementation of functions you described (spawn enemy etc), are just methods you can write that create these objects with particular properties, or modify them.

Obvious points, avoid code duplication, but don't go inheritance crazy, otherwise you will run into pitfalls really quickly because of cross-tree dependencies. I have greatly avoided inheritance here, simply to make a point, but if you find it appropriate it, I'm sure you can implement it differently.

dont know if i'll be bashed for posting my answer twice .... but well... didnt see this one and this is kindof more appropriate place

game world basics to me are about finding common grounds.

the world going forward in time. so are all active elements (player, dropped items, enemies, npc's) but all passive elements are not (block of stone, tree, house) therefor i'd use 2 interfaces ActiveElement and PassiveElement. the active element could have a stepintime() function which is called by the game world each time itself steps in time. both elements could have a render() function which draws the element whenever the gameworld is drawn on a canvas.

then all enemies should call their ai to determine their next step in time as well as checking collision with any other objects and whatever that means (trees bullets players etc) same goes basically for every other element.

this is to me the most basic architecture in gameworlds.

then there's the issue of performance where it might be better to put certain things in their own threads and let them run (enemy ai that is checking the position and status of his avatar each cycle and makes input which is read with each step in time) but there i dont have enough experience in to elaborate. then you should go to a gamedev site (eg as karim79 said).

implemented elements can have their own attributes then and is easy to expand(health, stats) and write an interpreter that reads simpel scripts that communicates with the gameworld adding enemies etc.

ciao