SFML community forums

Help => General => Topic started by: Elias Daler on May 02, 2016, 12:39:23 pm

Title: [SOLVED]Reducing coupling between game code and level editor code?
Post by: Elias Daler on May 02, 2016, 12:39:23 pm
My game has in-game level editor and I've been noticing that sometimes it hurts code readability.
Here's an example: in the level editor class I have bool drawObjects which indicates whether objects are drawn or not. If it's changed I call code like this:
renderingSystem->setDrawObjects(drawObjects)
and in rendering system I have a code like this:
void RenderingSystem::render() {
    ...
    if(drawObjects) {
        ... // draw objects
    }
}
Or suppose that I don't want to draw effects and shadows while in Level editor, I'll have to do this:
void RenderingSystem::render() {
    ...
    if(!isEditingLevel) {
        ... // draw effects
    }

    ...

    if(!isEditingLevel) {
         ... // draw fog
    }
}
As you can see, there's some coupling going on between LevelEditor and RenderingSystem which doesn't feel right. It also hurts readability because rendering code is now polluted with level editor stuff.
The only solution I have in mind is to have two functions: render and renderInLevelEditor but this may produce a lot of code duplication which is even worse.

So, what are some common ways to keep level editor code separate from main game/engine code? (Not only in rendering but everywhere else too). Maybe there are some patterns/cool articles about level editors which I need to read?
Title: Re: Reducing coupling between game code and level editor code?
Post by: Mr_Blame on May 02, 2016, 12:52:22 pm
I would give level editor access to render system, so when you start editing -> level editor calls "disableEffectRendering" and "disableFogRendering".
Rendering doesn't have to know what level editor doing, but level editor must.
Title: Re: Reducing coupling between game code and level editor code?
Post by: eXpl0it3r on May 02, 2016, 01:17:53 pm
Do it the other way around: Let the level editor enable/disable shadows. Meaning you should extend your render's interface, that way your renderer code will exclusively depend on its own variables and all the level editor (and your game) has to do is call the renderer API.
Title: Re: Reducing coupling between game code and level editor code?
Post by: Elias Daler on May 03, 2016, 09:18:05 am
Thanks for suggestions!
I think that there may be lots of different settings for renderer: enable/disable fog/shadows/objects/tile overlays etc.
Having lots of booleans and setters/getters for each of them is very annoying to write so are there any solutions to this? Maybe use some "settings" struct and pass it as a parameter? Or any other solutions?
(Or maybe having 5-10 setters is okay? :D)
Title: Re: Reducing coupling between game code and level editor code?
Post by: eXpl0it3r on May 03, 2016, 09:43:10 am
I'd say it's okay, maybe you could go for a settings struct, but that may generate more code than it's worth (e.g. when you want to change one setting).

In a more general approach one would probably create some more dynamic "pipeline" where you can insert all kinds of different effects etc. (think of Unreal/Unity editors), but that would be overkill. ;D
Title: Re: Reducing coupling between game code and level editor code?
Post by: Mr_Blame on May 03, 2016, 12:53:02 pm
Material system!!! 8) :)
Title: Re: Reducing coupling between game code and level editor code?
Post by: Elias Daler on May 05, 2016, 10:15:32 am
I'd say it's okay, maybe you could go for a settings struct, but that may generate more code than it's worth (e.g. when you want to change one setting).
Yeah, I'll just add a bunch of setters :)

In a more general approach one would probably create some more dynamic "pipeline" where you can insert all kinds of different effects etc. (think of Unreal/Unity editors), but that would be overkill. ;D
Material system!!! 8) :)
Yeah, that's a rotal overkill for me right now :)
Thanks for your help, I think the problem is solved.