Hello, we apologize but forum registrations are non-functional at this time. This issue should be fixed around mid-December. Until then, please stop by our Discord channel if you'd like to get in touch with the team. Thanks!

Game mode common manager?

For discussion of the code running behind the game

Moderator: Staff

Post Reply
User avatar
Roots
Dictator
Posts: 8669
Joined: Wed Jun 16, 2004 12:07 pm
Location: Austin TX
Contact:

Game mode common manager?

Post by Roots » Thu Jan 03, 2013 10:58 pm

One of the things that Bertram did with VT that I initially disagreed with was to pull out some of the engine code and put it in some miscellaneous classes that manage certain effects (like light overlays) for each active game mode. The reason I was opposed to this practice was I thought that any graphics code should be contained within the graphics engine, for example. However, I'm now on the other side of the argument, and I think it might be for the best. Here's a list of reasons why.

1) It eliminates some odd engine interdepencies.

For example, the lightning effect is a mixture of both visual and audio data. So currently the video engine depends on the audio engine to process this effect, which I do not particularly like.

2) The components that were stripped out of the video engine were not tied to the graphics library

AFAIK, nothing that was taken out of the video engine actually performed any OpenGL or image library calls. In fact, all this code did was to build upon the basic video engine API (specifically, images) and use them in certain specific ways. For example, basic lighting is nothing more than creating an empty image filled with a certain color and drawing that image over the entire screen. Anything that would make GL calls I would expressly disapprove of removing from the video engine.

3) Some management needs to be done for certain components

For example, light halos. You create a halo by loading in an image file, pointing that image to a certain area of the screen, and drawing it. This requires the video engine to track every halo image that is loaded, so any modes that need to use a number of halos will also have to remember to remove those halos when the mode exits. This seems error-prone, as many modes may forget to remove their halos, leading to growth in memory for unused data. It would be nice to have something that allows you to add a halo or other light source, activate/deactive it at will, automatically draw it in the correct position when it is visible, and auto-cleanup when the mode is finished. To do this all in the video engine would be impossible (especially the auto cleanup), because the video engine would have to manage a pointer to active game modes and be notified whenever a game mode destructor is called. It just seems like a lot to add to this engine.


Basically, my argument boils down to: "this sounds like code that does not necessarily belongs in an engine, but is useful to have available to any game modes that wish to use it". Which is exactly what src/common is supposed to hold. So I'm thinking that perhaps we could create a new class for this. I'm not sure what design would work best. Maybe just a new manager class where it uses pointers to GameMode objects to determine what objects belong to what game mode, and cleans them up when it sees that the mode no longer exists on the game stack. Bertram looks like he created two managers: one for visual effects and one for some sort of script management assistant.

But the implementation details are kind of moot until we decide whether we want to do this or not. I'm still not entirely certain about the proposition, which is why I'm bringing it up here for others to share their opinions. My biggest concern is that we are going to have graphics code that is effectively not a part of the video engine, which may make it confusing to the user (ie, is this video setting something I set in the engine, or something in the common manager class?). I'm going to continue brooding over this for now, and I have no intention of getting started on this anytime soon. But it's food for though.
Image
User avatar
gorzuate
Developer
Posts: 2575
Joined: Wed Jun 16, 2004 9:03 pm
Location: Hermosa Beach, CA
Contact:

Re: Game mode common manager?

Post by gorzuate » Fri Jan 04, 2013 12:44 pm

It seems to me that Bertram had the right idea with the visual effects manager. The video engine should not be dependent on the audio engine, and vice versa. They should be completely oblivious to one another. So it would make sense to have something like an effect manager, that could create a lightning effect (for example) by invoking the correct calls from both the video engine and audio engine together.

However, I do agree with your following statement:
Roots wrote: My biggest concern is that we are going to have graphics code that is effectively not a part of the video engine, which may make it confusing to the user (ie, is this video setting something I set in the engine, or something in the common manager class?).
User avatar
Roots
Dictator
Posts: 8669
Joined: Wed Jun 16, 2004 12:07 pm
Location: Austin TX
Contact:

Re: Game mode common manager?

Post by Roots » Fri Jan 04, 2013 2:45 pm

Maybe we can keep the "core" code in the video engine, but add a layer of abstraction for the common effects manager that wraps around those engine calls? For example, the "DrawHalo" function would still exist in the engine and take an image, x, and y coordinate as it's arguments. The common manager would allow modes to "add" a light halo at a position on the map, and would make the appropriate calls to the video engine automatically. That way the engines will still maintain the "raw" parts of the code, and the effects manager is simply there to make using it a little bit easier for game modes.


I think I really like that idea. Assuming that we go with it, what would we call this class? I don't really like "EffectsSupevisor", because that's too specific (I can imagine we can use this manager for more than just visual effects). I have no idea what a good name would be for it right now. Maybe CommonModeAssistant? :shrug: One thing we could add to this class would be code that creates animated images from a Lua file. Bertram did this in VT (a Lua file exists for just about every animated image). We could add functions to process common script formats in general, such as ones that construct dialogues.
Image
Post Reply