Jump to content
  • Advertisement
Sign in to follow this  
Kris2456

Engine UML Diagram

This topic is 4819 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Here is a UML of an engine i am planning to make. This is only a first draft, so i wanted to ask some people who know this stuff well what they think. Free Image Hosting at www.ImageShack.us Basicly, do you think it will: a) Work b) Work Well/Not so well c) be better if i designed it a different way. Any other comments or suggestions would also be much appreciated. Thanks.

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Trying to show off your UML skillz, eh?

Anyways, i dont think it will work because i see no code. an engine can't do that stuff unless you write code.

Share this post


Link to post
Share on other sites
It could be good - but be warey of creating elaborate uml without any code. When creating an engine it's best to actually have a game in mind you would actually want to use it for, and a modest one at that.

It might sound silly (but this is an XP techique) but writing test code / units of how you would like to use the engine when it's done BEFORE you've actually written anything in the engine will get you to think about it's design from an empowering perspective. You then code your engine to match how you would actually want to use it, plus you end up with a series of automated tests you can run at anytime to make sure a change you've made hasn't broken anything you've already done.

Try getting little bits working at once and work and change your UML diagram as you try and code these bits to suit what you discover about the requirements. If you spend too long on the UML before going to code, you can create something that is more complex then necessary and make unnecessary work for yourself.

It does look like a good start though!

Share this post


Link to post
Share on other sites
... oh and take care with CObject, I think MFC already has dibs on that if your a C++ programmer...

You might want to drop the C prefix too, it just obfiscates the design a bit. And "Object" is not descriptive enough. "RenderableEntity" or something may be?

Also "3DModel" is a bit odd.. surely a player could have a model? Or an Enemy? Or a building?

If it is part of an object remeber to show a diamond on the diagram. Or some kind of cardianlity.

Share this post


Link to post
Share on other sites
Just wondering....what is CEntity? I could be wrong, but it seems a bit superfluous and be collapsed down into just the CObject. *shrug*

The way I'm designing things is to have a World class, which can have certain basic types of objects in the world tree (StaticMesh, DynamicMesh, Light, Camera, etc). Then I have an entity layer on top of that which handles the high level game logic stuff (via python scripts/C++ classes).

eg.

class BigHairyMonsterEntity : public Entity
{

void create()
{
worldObj = world->CreateMesh("meshes/bighairymonster.mesh");
}

void doMonsterRawr()
{
worldObj->PlayAnimation("rawr");
}

WorldObject* worldObj;
}


I like to keep the game logic code and the core world management code kind of separate. Loose coupling == Very Yes :).

So basically in my setup, WorldObject = basic object types and Entity = high level gameplay type.

Also, it could probably be handy to have the Camera as a world object as well, since it also has position and orientation in the world (that way you could use the same code for controlling the camera as any other object, such as moving it along a animated path).

Who handles the rendering? Can the world run without having a renderer started (ie. for a dedicated server)?

Just some questions/observations to help you on your way :).

Share this post


Link to post
Share on other sites
The general idea is that all the rendering happens eventually in the CEngine class.
The reason there is a class called CObject is beacuse all objects player, etc, have some kind of basic physics attached to them, gravity, motion, etc. Then these are inherited into a more advanced physics object, such as a bouncy ball for example. Or they are inherited into a very basic static object, or a player which moves.
The entity thing i got the idea from HL's hammer editor, where an entity was generally a light, sprite, etc.

The 3DModel is a class of which an instance is included in an object. This way, an object would simply call:
Model.Load("models/monster.md2");
And the whole object would then use that model.

btw, sorry if im not making much sense, or being very illogical. My first attempt at making an engine left me with only a few handy classes but no real 'engine', this time im trying to plan it properly from the start to minimize the cock-up factor if possible. Also, im pretty new to things like inheritance. Thanks for the help so far.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Just an FYI. I used C and C++ for many years, even some Java. Now I'm using C#.

One of the features I like about the new .NET environment and C# is the way I can define INTERFACES.

When you say "The reason there is a class called CObject is beacuse all objects player, etc, have some kind of basic physics attached to them, gravity, motion, etc. ..." what I think is not INHERITANCE, but rather INTERFACE.

All kinds of different entities can implement the same interface and yet not have a common " basic object " .

If you think in these terms, you may end up with a better design.

Dave

Share this post


Link to post
Share on other sites
I would take the responsibility of rendering away from the engine class and put it in a seperate Renderer class. All your objects that are to be drawn should register themselves with this class for rendering. The benefit of doing it this way is that you can then have different types of renderers, e.g. OpenGL, DirectX whatever.

Also how is the AI and simulation handled? Is logic and simulation a responsiblity of the actual objects themselves?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!