Advertisement Jump to content
Sign in to follow this  
fir

divide on subsystems

This topic is 1768 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

Do you divide your game project/ sources on subsystems?

I found it usefull to divide my code on some subsystems 

mainly window subsystem and graphics subsystem 

(and game subsystem), that would be the three most logical

but some things i do not know where to put (like camera code,

or math routines)

 

 

 

Share this post


Link to post
Share on other sites
Advertisement

Here are a list of the modules/libs/subsystems in my game:

1. base (math routines, utiles, factories,statemachines,dispatcher )

2. game/ai  (game entities, pathfinding, scanning, steering)

3. script (script engines for ui , behavior, ai)

4. physics engine

5. network

6. rendering

7. audio

8. tools

Share this post


Link to post
Share on other sites

I don't assign math routines to a sub-system; like many other things they give the foundation framework used by the sub-systems.

 

The explicit sub-systems I use are

* Input (to abstract input raw handling, HID, ...)

* Video (to abstract display related stuff: monitor + graphics card)

* Audio (to abstract audio hardare related stuff)

* Graphic (to abstract graphic rendering; implemented in 3 layers)

* Sound (to abstract sound rendering; implemented in 3 layers)

* Storage (for VFS and the like)

* Netz (for networking)

 

There are many more sub-systems that are used to handle aspects of CES; I call this kind of sub-systems "services", e.g. SpatialServices which manages placement, proximity, collision detection, and similar things. Following this, NPC controlling (AI, steering, …), physics, and similar things are implemented as services, too.

Share this post


Link to post
Share on other sites

I used to go crazy with modules, one for graphics, one for mesh and texture databases, one for the animation engine, one for audio, etc.

 

now i keep it simple, one for the audio library (Zaudio), one for the "graphics and everything else" library (Z3d), and one for game-specific code (Caveman, Airships!, SIMSpace, etc.)..

 

the graphics and everything else library is graphics, math, file i/o, timers, dice - pretty much all the generic low level stuff for games, except audio. when i implemented the audio library i made it separate as it seemed the cleaner way to do things. good module separation and all that jazz

Share this post


Link to post
Share on other sites

in my case, my engine is basically divided up somewhat...

 

renderer stuff:

    "lbxgl": high-level renderer, ex: scene/model/animation/materials/...

    "pdgl": low-level renderer, ex: texture loading, OS interfaces (WGL, GLX, ...), various utility stuff.

common:

    "btgecm": lots of stuff needed by both client and server, ex: voxel terrain, map loading, some file-format code, ...

    "bgbbtjpg": graphics library, deals with image loading/saving, video codecs / AVI / ..., compressed-texture formats, ...

    "bgbmid1": audio library, deals with mixing, MIDI, text-to-speech, several audio codecs, ...

client:

    "btgecl": deals with "client side stuff", mostly sending/recieving messages from server, updating the scene-graph, ...

server:

    "btgesv": server-side stuff (game logic, simple "Quake-like" physics, mobs / AI, ...).

    "libbsde": rigid-body physics simulation stuff, largely not used at present in favor of simpler physics.

script / infrastructure (back-end):

    "bgbgc": garbage collector

    "bgbdy": dynamic types, object-system stuff, VFS (virtual filesystem), ...

    "bgbsvm": script VM

    ...

 

generally I had split libraries up when it gets sufficiently big that it is either unwieldy or takes a long time to rebuild.

in the past, this had generally been somewhere around 50 kLOC.

 

this is not always the case, for example, my high-level renderer ("lbxgl") is ~ 111 kLOC and is not split up.

adding up a few renderer related libraries, works out to around 303 kLOC.

 

current project line-count: 879 kLOC.

 

granted, this project has kind of been ongoing for a while...

Share this post


Link to post
Share on other sites

and how you up (asking to all answerers) divide on this subsystems?

 

You make dll, or group in folder, or this is only by some

prefixes?

 

I previously used pfefixes but now Im changing to folders

but yet not sure if im quite happy with that (I always had 

strong problems with name chosing and here my code is all 

clean and good but the module (file) and systems naming and

grouping makes me angry

Share this post


Link to post
Share on other sites

Here are a list of the modules/libs/subsystems in my game:

1. base (math routines, utiles, factories,statemachines,dispatcher )

2. game/ai  (game entities, pathfinding, scanning, steering)

3. script (script engines for ui , behavior, ai)

4. physics engine

5. network

6. rendering

7. audio

8. tools

 

could you maybe say me what you call by dispatcher? 

Also what dou you mean by scanning?

Share this post


Link to post
Share on other sites

I don't assign math routines to a sub-system; like many other things they give the foundation framework used by the sub-systems.

 

The explicit sub-systems I use are

* Input (to abstract input raw handling, HID, ...)

* Video (to abstract display related stuff: monitor + graphics card)

* Audio (to abstract audio hardare related stuff)

* Graphic (to abstract graphic rendering; implemented in 3 layers)

* Sound (to abstract sound rendering; implemented in 3 layers)

* Storage (for VFS and the like)

* Netz (for networking)

 

There are many more sub-systems that are used to handle aspects of CES; I call this kind of sub-systems "services", e.g. SpatialServices which manages placement, proximity, collision detection, and similar things. Following this, NPC controlling (AI, steering, …), physics, and similar things are implemented as services, too.

Could you say how do you make such layers?

Share this post


Link to post
Share on other sites

in my case, my engine is basically divided up somewhat...

 

renderer stuff:

    "lbxgl": high-level renderer, ex: scene/model/animation/materials/...

    "pdgl": low-level renderer, ex: texture loading, OS interfaces (WGL, GLX, ...), various utility stuff.

common:

    "btgecm": lots of stuff needed by both client and server, ex: voxel terrain, map loading, some file-format code, ...

    "bgbbtjpg": graphics library, deals with image loading/saving, video codecs / AVI / ..., compressed-texture formats, ...

    "bgbmid1": audio library, deals with mixing, MIDI, text-to-speech, several audio codecs, ...

client:

    "btgecl": deals with "client side stuff", mostly sending/recieving messages from server, updating the scene-graph, ...

server:

    "btgesv": server-side stuff (game logic, simple "Quake-like" physics, mobs / AI, ...).

    "libbsde": rigid-body physics simulation stuff, largely not used at present in favor of simpler physics.

script / infrastructure (back-end):

    "bgbgc": garbage collector

    "bgbdy": dynamic types, object-system stuff, VFS (virtual filesystem), ...

    "bgbsvm": script VM

    ...

 

generally I had split libraries up when it gets sufficiently big that it is either unwieldy or takes a long time to rebuild.

in the past, this had generally been somewhere around 50 kLOC.

 

this is not always the case, for example, my high-level renderer ("lbxgl") is ~ 111 kLOC and is not split up.

adding up a few renderer related libraries, works out to around 303 kLOC.

 

current project line-count: 879 kLOC.

 

granted, this project has kind of been ongoing for a while...

 

Do you need it such wide and heavy (800k lines is big, my all own personal codes last 5 years framework + prototypes is 100k lines

only) 

Share this post


Link to post
Share on other sites

Here's the solution explorer for a project I'm involved with (blurred due to NDA) - each folder icon is a "module". Cross module dependencies are kept track of and enforced -- if I committed code that makes module A depend on B, while B already depends on A, it would be detected and I'd be told off for being an idiot and breaking the architecture.

fiEsBs1.png

Inside many of those folders, there's internal layers -- e.g. the public cross-platform interface, and several platform-dependent implementations.

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.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!