Good day!
Currently in my project there are pair of entities united by a common interface
{ Interface to interact with all Transforms bounded to Essences }
IBoundSpriteInterface = interface
['{6777E00A-8110-471E-B6A4-6B0B8C453B55}']
function ReturnMenu: TCastleDesign;
end;
When clicked, they return the corresponding design to the main game scene module as TCastleDesign. After that, I adds player’s hero by another Interface to this TCastleDesign to interaction with game object. For barter with NPC or for the crate looting, as example. I use TCastleDesign as bridge between player and game objects with two interfaces from the two sides.
if Event.IsMouseButton(buttonLeft)
and (EnvironmentViewport.TransformUnderMouse is TBoundImageTransform) then
begin
InterfaceDesign := (EnvironmentViewport.TransformUnderMouse as IBoundSpriteInterface).ReturnMenu;
(InterfaceDesign as IHeroConnector).ConnectHero(PlayableHero);
InsertFront(InterfaceDesign);
end;
This method looked scalable and universal until I made a separate TCastleView for the interiors of buildings. Now I just want to call Container.View for choose building’s TCastleView with interior (when I click to this building sprite, as with characters e.t.c). So, my current interface don’t works.
The questions are:
How optimal is my way of interacting with game objects? Perhaps there is a more elegant and universal alternative?
If I stop at this method, I need to cast all returned objects to some common type to easily output the result of the click? What is better to return by this interface instead of TCastleDesign? I think it will bad way to change TCastleView in the any case…
Or single interface into the complex game is utopia and I best to add if else into the mouse button event?
I don’t ask 100% complete solution, of course, question more about the game patterns.
Thanks!
Hm, I feel I don’t understand your design enough to answer something constructive, sorry
Looking at your code snippet: you check if EnvironmentViewport.TransformUnderMouse is TBoundImageTransform (a class) and then you typecast it to an interface (IBoundSpriteInterface), I understand assuming that IBoundSpriteInterface is implemented by TBoundImageTransform. OK, but then why is IBoundSpriteInterface useful? And what is IHeroConnector?
I’m afraid I do not understand this question either, sorry I don’t understand what you mean by " call Container.View for choose building’s TCastleView with interior".
I’m sorry, I will need more information about your design to answer something intelligent.
In general, using Pascal interfaces is of course OK, and there are many ways to code something like “various selectable components may define a menu”. E.g. you can as well use behaviors (see Behaviors | Manual | Castle Game Engine , tutorial describes them: Tutorial: 3D physics fun (aka "the bad way to play chess") | Castle Game Engine ). I’m not saying that behaviors are a better design in this case – I don’t understand your “problem space” yet properly to advise anything I’m just pointing to various options.
I use this interface because I created three different child classes of the game essences. So, this Interface can create menu for interaction with different things (as TCastleDesign)…
… and, after that, I need to bind this menu with player character. I use another Interface, because I need different procedures to interaction with different things.
I planned use this idea for all game objects. Full algorithm is:
player click on the sprite
sprite is bounded with some game essence. I need Interface, because game don’t know, what this essence is - character, container or something else.
interface realization of this specific essence return TCastleDesign for interaction with it.
In the next step another interface bounds player with this TCastleDesign.
But now I think it is not optimal. For example, I don’t need return some TCastleDesign. For example, I want just change the scene or something else.
@michalis , as I understand, I can add different behaviors to different game essences, but call them in the same procedure (with mouse click on the sprite in my case)?
It seems some close to Interfaces idea - creating the classes composition without the problem of multiple inheritance?
For now I created my current interface method more universal, as procedure.
I made mistake in designing, but for now it is Ok, I think.
Nevertheless I interested is the Behaviors are good alternative to Interfaces in more of cases?..