[UML] Engine

[uzurpator]

Well - this should go to the Coding forum, but nontheless - I post it here for the sake of completeness, and for all the folks not in the coding group.

Basic idea:

The engine should only provide an enviroment to code certain aspects of the game. There should be standard measures of getting meshes, textures, functions and alike to work. Engine should encapsulate APIs used.

For example none of the actual game logic should call

Code: Select all

glTriangle3f(float, float, float)

. It should operate on

Code: Select all

::Renderer::draw(&meshObject)

So I anticipate something like this:

This is the rough sketch of the engine architecture written as an UML class diagram.

The idea is as such:

core - the basic part of the game, responsible for dispatching 'functionality' threads. Also passes all messages between various objects.

core works with several players by sending them all the info they need. Core runs the game's logic.

network - uplink between player and core objects. Usually with use of TCP/IP, but other protocols are also possible.

player - this class is responsible for dispatch of "game content" classes and manages gui and other client side multimedia trivia

gui - for displaying windows, widgets and such

viewport - this class is the 'camera' - eg whatever it sees, modifies it etc. A player can have several cameras looking at several places.

renderer - this class is used for display of game graphical content. Either using openGL, d3d, software or some other rendering pipe.

now two most important classes.

functionality - this class is a prototype of the classes that implement certain game aspects. each of these objects is a _thread_ of execution. functionality classes can talk to each other via "message" interface, but cannot read/write to each other. This is to assure thread safety.

gameContent - this class is a prototype of the classes that implement _collections of game content_ that being models, textures etc. Each of these is a _thread_ of execution.

functionality and gameContent classes work with each other. eg - each functionality class should have an accompying gameContent class.

The second diagram is more complicated - so if you have questions - go for it.

[Steve]

This certainly does need thinking about, but sadly I'm not going to understand those diagrams in this kind if situation without hurting my brain.

If we can split it up and approach it in sections however...

[eis_os]

Some sitenote, I would call the player viewer, or client, as it's not the game player/company as such... But the one who interact with the game. For a network game or if you manage a other company the player isn't necessary bind to one company. Or as obsever on a network game, it's not a player at all..

[uzurpator]

Eis_Os

the player class is polymorphic - it may mean player, spectator, someone with a console to look at the game passage. Player = human interacting somehow with the game. What kind of interaction is not within our scope now.

Surely

1. Core-Player architecture (client-server)

This is easy. Core does something and Player does something. Since they need to exchange data - they do so with the help of the network.

Each of the core and player have a Network interface wich are used to establish connection.

Player side network establishes connection to a Core side network and from then Player and Core can exchange packets of data without worrying about connection problems.

As for the diagram - it means that the Core may have several clients and that network classes can talk to each other.

[uzurpator]

Ok - since now we have the basics behind us.

Core and Player don't just sit there and exchange hellos They actually forward messages between Functionality and Content classes.

Functionality nad Content are a tandem - they implement a part of the game (be it say: trains).

Functionality of trains will cover the movement and all the trivia associated (since the trains functions) and content will associate multimedia associated with it and will cover things like the bits of graphical interface etc.

If the functionality needs to talk to content, or vice versa, they send a Message through the core/network/player (or player/network/core) to the target.

Functionalities can talk to each other by sending themselves a message (so Trains class can Load at Stations class).

More to come - sorry for double posting

[Hellfire]

For your information, here's the UML diagram of the code in the CVS. It's not entirely up to date, but it contains the bigger picture I had in mind while writing the code.

[uzurpator]

Now we're talking

BTW - can we agree on the CASE tool we shall use?

EDIT - for some reason, the pdf is mostly empty :/

[Hellfire]

I've used Visio in the past. It kinda grew on me. I've also used ArgoUML before. Both will suffice for this project, I think.

[Steve]

EDIT - for some reason, the pdf is mostly empty :/

Do the other files have more in them?

[XeryusTC]

I don't understand much of UML, but AFAICS; functionallity inherets itself. I don't know where all the different types of arrows stand for as I have long forgotten them when I read through the UML section of my C++ book.

[Hellfire]

EDIT - for some reason, the pdf is mostly empty :/

Yes, that's true. I also noticed that. The PDF is meant for people who don't have or want to have MS Visio installed.

I'll try to make a more descriptive document this week.

[uzurpator]

Xeryus:

Functionality does not inherit itsself. The arrow pointing at it means that it can message ittself (obviously) and other classes of this type.

Anyhow - now for part 3-4 and 5 of the engine architecture explanation (uzurpator style).

Excuse multi posting

Core architecture.

As you may have noticed - the core has a crServices class attached. This class is responsible for providing Functionality classes certain data required by them to work. This data is guaranteed to work and be concurrent and thread safe (as required by the fact that each Functionality is a thread).

For now I can identify such service classes:

Clock this class provides general time functions - such as current unix time stamp, timers (if a timer expires a SIGNAL is sent to the functionality that triggered it) and such.

Console programmed maybe in nCurses - basic textual console. Each functionality will provide a set of parameters and respective commands (as well as Core will do so) and paging console will provide this data to the adminstrator of the core (note - remote console might be possible).

Collisions a class resposible for detecting collisions between objects governed by the Functionality classes. Eg - if a truck collides (as in: is in the same space) with a train - this class will find it out.

These are service classes - the special par about them is that they use actual API to do their voodoo - freeing the authors of Functionalities from the burden of knowing the messy details. Also - once we choose to change a given api - we just change/enrich the service class, leaving rest of the game untouched.

Functionality there are OFC Functionality classes which govern the game.

coreContent this class is responsible for storing the encessary data bits for the functionalities it provides a parser to read the data and matrix - which provides an interface to rotate/move/scale etc the object in the 3d space.

[uzurpator]

Player architecture.

Player architecture follows the same principles as core architecture, but has much more classes in it.

Generally - plServices are services the Player provides for the Content classes. They are:

Viewport a class(es) governing the Frustum (http://en.wikipedia.org/wiki/Frustum) eg - the part of 3d space the player sees. Several viewports can be invoked with their own interface display etc.

inputs the class governing keyboard and mouse support

keyBindings a class containing a set of translations "keystroke - command" for the player class to invoke proper commands on the Contents.

gui a class governing the display of the graphical interface (connected to a GUI api - such as GTK or QT). Content classes provide a prototype widgets for this class to display (read - the scheme of the interface for this class).

renderer a class governing the display of all the goodness. Working with a 3Dapi (be it OpenGL, direct3d, software or something else). Content, Viewport and gui classes pass here graphical objects which the class displays.

playback a class governing playing of sounds and music - it works with some sort of sfx API. Content class passes here sfx objects to get played.

So much for services. Now the kingpin here.

Content the master class here - it works with a tandem of a Functionality classes, gives responses to the interface calls (collisions of the interface with the game world - read: when a player clicks on a train) and so on.

[uzurpator]

Content Class.

The last of the classes here.

Content is special as it governs the multimedia content. Several standard objects are avalible for it to free the coders from the pain of implementing say - *.png or *.wav support for each Content class. The standarized objects are:

Texture a filter for the textures. Constructor of this class can parse multitude of graphical formats and converts them into the "TeTexture" which can be freely used on all 3d objects, interfaces etc.

Mesh likewise texture this class is a standard storage for meshes loaded into the game. Can pass multitude of formats and after being loaded into the Renderer a handle is passed for the VBO this mesh corresponds to. Mesh can be texturized using Texture.

We can provide some standard meshes for some standard effects - like smoke.

matrix is a class used for operations in 3d for the mesh (three will be needed scale, rotation and position).

Shader a small program that can be invoked on a texture(s) (pixel shader) or meshes (vertex shader) that modifies them during runtime. program shader is a shader invoked _before_ an object is passed to the renderer. Can be considered a _static_ shader.

We can provide some standard shaders - like grass or sand for prodecural texturing.

sound is a class to hold sounds used by the content

looping is a special sound subclass for music.

This concludes TE Engine presentation (uzu style) - any questions?

[Hellfire]

As promised, the more descriptive images of the UML diagrams. I totally rebuilt these from scratch, to make them mimic the code that is in the CVS.

I'll use one post per package, to keep things tidy. First off, in this post, I present the top view. If you'd look into the src/ directory of the "tempire" module in the CVS, you'll see four subdirectories. They correspond with these packages.

I won't treat the RakNet subsystem, as it is simply a standard component I'm using.

[Hellfire]

Common

The Common subsystem contains functionality shared between the Client and the Server. Here, you'll find stuff like network packet types, map data types, etc.

Currently, the central class in this subsystem is the Packet class. This abstract class contains logic to send itself to the server or to a client. It needs a pointer to a RakNet Server or Client object to do this.

Packets are created by the PacketFactory class. This class is only useful when rebuilding serialized Packet objects, recieved over the network.

Packet currently has four subclasses:

MapChunkPacket objects can be used to send data on a piece of the Map to a client.

MapRequestPacket objects are used by the client to request a piece of the map at the server. This class is deprecated! RegisterPacket objects should be used instead.

RegisterPacket objects register clients for updates of a piece of the map. Imagine a player viewing a piece of the map. If something changes at the server side, the client side must be updated. Updating the entire map will lead to unnecessary CPU and Network usage. So, we notify the server of the piece of the map the user is looking at and the server will only send updates on that piece.

When only a single tile is modified, then we can send it to the client using a TileUpdatePacket object. This can only contain information on one tile.

Other classes:

Registration contains a request for updates on a piece of the game data.

Map A collection of Tiles.

Tile Those square things that make up a map.

[Hellfire]

Now, on to the easy parts. (Yes, the common functionality is most complex at the moment...)

Server

Central in this subsystem is the Server class. This class is created at startup and initializes and runs the server application. To do this, it creates four objects:

RakServerInterface RakNet's equivalent of a server socket.

ServerRegistrar Stores Registrations. This class is queried by the ServerUpdateManager, whenever something changes in the game state.

ServerUpdateManager Whenever something changes in the game state, this class is notified of the change. It queries the ServerRegistrar for clients that have registered for the changed data and sends updates to the clients.

Map See common.

[Hellfire]

Client

Similar to the server, the Client class is central in this subsystem. This class initializes and runs the client application. To do this, three objects are created:

RakClientInterface RakNet's equivalent of a client socket[/b]

CachedMap A subclass of Map, with some restrictions of Map taken away. For example, CachedMap can store empty (null) tiles, whereas Map cannot. This object will be used by the UI to present the game to the user.

ClientRegistrar This class doesn't do much, except for distributing and keeping track of RegistrationID's (type: unsigned int). Also, it can send RegisterPackets to the server.

[Hellfire]

So that's basically what I've made sofar.

As for your (uzurpator's) e-mail, I hope you don't mind that I quote some parts of it here:

How about we synchronise our efforts to get the project going?

[...] I suspect that until some sort of working kode (as in code being ready to get the stuff added) nobody will join.

I think we should try to come to an agreement on the engine architecture and then simply start doing what needs doing. Once we have a ready engine - people should join in.

I totally agree on what you say here. How much have you written sofar? I assume you've seen the roadmap I've posted here earlier, which starts off with your taks list (which has mysteriously been deleted ), but is then extended with things I made myself do.

So let's just start with two simple questions:
1. Where is overlap?
2. Where are differences?

[Hyronymus]

You wrote code, uzurpator? Is it me or is this the first time you unveil this?!