[UML] Engine

[Hellfire]

Yes, he has. Unfortunately, the topic in which he reports on his progress has disappeared.

[Hyronymus]

Really? Hmm, that's interesting because it means someone moderated it or uzurpator was the only poster in that topic and deleted it himself. I cannot believe either scenario actually .

[Hellfire]

Correct me if I'm wrong, but I think that uzurpator has moderating rights in the Coding forum.

Anyway, it doesn't really matter any more. I still have a (broken) link to the original task list.

[uzurpator]

Yes - I have moderating rights to the Coding forum (and the rest of TE fora as well) - and yes - I made a certain cleanup there.

Hellfire:

I understaind your architecture - and I think, that you're trying to be too specific here. Ferinstance specifying the packets for the each part of the game functionality will probably make the code difficult to manage. Also - you are trying to embed the game structure (map handling) into the engine.

What I was trying to come up with.

The game would be built on the Mediator design pattern. The mediator is the "core-network-player" axis sending packets between sender and reciever objects - whichever they may be.

Once this axis is functioning we can begin writing "engine" objects - eg those that will provide the facade for the various APIs we are going to use. Also we can provide standard engine data types such as textures (textures ferinstance can come out of a texture factory class).

The facades should be pure virtual providing just interfaces with implementations for various APIs hidden beneath it - being pretty much builder

Now - once this is "ready" (as in "workable") we can add game logic - that is maps, trains, trees etc.

If you tie the game logic into the engine - then IMHO it is a straight road to nightmare.

Anyhow - this does follow MVC but further descreets the parts of the engine.

[Hyronymus]

I know it's not 100% on topic but when you say you did some clean-up, do you mean you deleted posts?

[Hellfire]

Also - you are trying to embed the game structure (map handling) into the engine.

Could you please define the word "engine" here? If you mean the graphical core that will display _a_ game, then that's not what I've been making.

The way I approached it, I tried to build a "model" of the game, including maps, objects, vehicles, tracks, etc. Also, I tried to include client/server communication right from the start. The way I'm handling packets might not be the best way, but at least the client/server architecture parts are there.

[uzurpator]

Well - yes, but the "model" is not a monolith.

Anyhow - the model can be divided into two parts:

logic - what the game does
engine - a set of services that allows the logic to do what it needs to do

if we have , say, a locomotive. Its behavior is governed by the logic, but the display, sound playback is handled by the engine.

But that is not what I want to point here.

You are, as far as I understand, trying to embed too much of knowledge into one object. Like this:

Network sent "map request message" from something, the server knows this is a map request, so it invokes "map" object, asks for information and sends it back. The server "knows" the answer.

Consider this:

Code: Select all

typedef unsigned int uint;

class packet {
uint recieverID;
auto_ptr<data> request;
}

class data {
virtual void serialize(std::stringstream& to) = 0;
virtual void unserialize(const std::stringstream& from) = 0;
};

}

now - if a class implementing something wants anything from another class, it simply:

defines a request inheriting from data of the type the reciever can accept (forcing it to implement serialization - important for network code); constructs a packet with a pointer to its data.

demands

Code: Select all

::mediator.send(packet& pac);

and the server will simply forward the packet to the recieving class, which in turn may reply in the same manner. The mediator will simply call the implementing object recieve method and pass it the packet.

Code: Select all

objects[packet.getReciever()].recieve(packet& pac);

This way the packeting is standardized, easy to make it thread safe (the safety is embedded in the class implementing given services, not the server itsself).

Also - if we choose to add anything to the game we do not need to change the server or any of the classes already there - frankly using this scheme we can have a working game and some other functionality in the background.

[Hellfire]

Anyhow - the model can be divided into two parts:

logic - what the game does
engine - a set of services that allows the logic to do what it needs to do

if we have , say, a locomotive. Its behavior is governed by the logic, but the display, sound playback is handled by the engine.

In that case, I've been working on the logic.

But that is not what I want to point here.

You are, as far as I understand, trying to embed too much of knowledge into one object.

Perhaps I am. I never said I made the right choices. I just made the choices and if they're off, then we can always refactor later.

Like this:

Network sent "map request message" from something, the server knows this is a map request, so it invokes "map" object, asks for information and sends it back. The server "knows" the answer.

Yes, that's just a temporary "solution" to make it work. It will be delegated to another class in the future.

Consider this:

Code: Select all

typedef unsigned int uint;

class packet {
uint recieverID;
auto_ptr<data> request;
}

class data {
virtual void serialize(std::stringstream& to) = 0;
virtual void unserialize(const std::stringstream& from) = 0;
};

}

now - if a class implementing something wants anything from another class, it simply:

defines a request inheriting from data of the type the reciever can accept (forcing it to implement serialization - important for network code); constructs a packet with a pointer to its data.

The Packet class does exactly that: forcing serialization and deserialization. Also, it abstracts away from (some of) the details of RakNet and provides a simple way to send packets. (e.g. Packet::Send)

demands

Code: Select all

::mediator.send(packet& pac);

and the server will simply forward the packet to the recieving class, which in turn may reply in the same manner. The mediator will simply call the implementing object recieve method and pass it the packet.

Code: Select all

objects[packet.getReciever()].recieve(packet& pac);

This way the packeting is standardized, easy to make it thread safe (the safety is embedded in the class implementing given services, not the server itsself).

Also - if we choose to add anything to the game we do not need to change the server or any of the classes already there - frankly using this scheme we can have a working game and some other functionality in the background.

I guess you're right there.

So besides the fact that there is too much logic in some classes (which a subjective measure, by the way), is the code I wrote useful?

[uzurpator]

The code is always useful - unless it is completely not related to the subject of matter

Anyhoo - In about 2 weeks I'll have more free time to use on TE, hopefully I will use my resources for TE devel

[Hellfire]

I'll be on a holiday from July 31 'till August 14. That means that there will be one week that we both have a sufficient amount of free time to work together.

Locked until the DD discussion arrives at this issue.