What goes in/should go in/shouldn't go in the data files?

[loyalj]

This isn't a specific idea or comment yet. Just a reminder about the issue.

[etlgfx]

So yea, I think the selection manager is a really good example of a talking point for this ticket.

Maybe the line we draw is behavior vs data. It's a bit of a vague line, but the selection manager defines a behavior of how to handle clicks, it's a very generic one, but I think there could be several different types of selection managers in the game depending on what game state you're in. menu / game / whatever.

So having an engaged flag that is set by the data file probably won't cut it too much. I'm thinking of that particular component to be exposed somewhat to external logics, so that you can attach a particular selection manager when you need it.

e.g. loadScene('game').attachSelectionManager(instance / callback);

[loyalj]

While the data file may not be the right spot to engage... I dunno about the multiple selection manager idea. The selection manager isn't actually about game play or part of the game rules any more than Scene is related.. we don't have custom scenes/event handlers per game so why have that for a sub-section of scene/event handling? Selection manager is only there to handle events in relation to the objects in scene and notify those objects their status in the scene has changed.

[etlgfx]

well, in a menu you could for example make multiple selection only happen with shift button, while in game, maybe multiple select only happens with dragging? i'm just saying there are different ways to handle selection depending on the UI you're looking at. No?

[etlgfx]

For the same reason though, one game could use a selection model closer to mushroom wars, while another could be closer to c&c, do we wanna implement all sorts of extra logic on top of the selection manager, or do we wanna have custom selection managers that take care of that logic for us.

[loyalj]

I don't want to put more than is necessary in the selection manager. I kinda wanna take somethings out right now. I don't think leaving it entirely up to the games/objects is workable either. The distinction I had in mind while building version 1 of selection manager was okay but I think I would recode one thing now... which probably brings it all in line with what you're saying and what I'm saying and great.

The reason the selection manager shouldn't be left to the game and belongs close to or in scene manager is the same reason that the scene manager knows about the concept of coordinates and hit detection. There are certain things that, for these rts games, we are building into the fabric of the universe, like rectangular shaped objects or two-dimensional space. Sure, some RTS games have the concept of three dimensional units and polygon-based collision detection.. but not us!

To some degree we need to encode our game universe in a way that also makes it simple to build. Like how having hit detection in the scene manager makes the task of "check an arbitrary number of objects for collision with this x, y" is way easier than making hit detection something each object must implement.

It should be noted that even now... if an object wanted to do something like pixel perfect collision against a sprite mask.. or something like that... it could do so within its click event handle.

My thinking is that like the hit detection the "now which objects are selected from the scene manager" is also something that can be done more effectively en mass than implementing per game. Like in the case of having, say, ten objects selected and then you select one new object, unselecting the rest. It seems much more complicated to have each object know about how to send out notices to the other objects. Have the scene manager handle the select and unselect notices.

[loyalj]

also, maybe if the game had a before filter or post filter or both for the selection manager that could solve the issue with putting the data in the data file.

Although.. I personally still don't see an issue with putting state configuration into the state files. To me each state is like a mini game almost.. so if it has some init info that changes the engine switches.. cool beans. :panda_face:

[etlgfx]

Yea, I'm not arguing against putting state in the data files, I'm arguing against behaviors in data files

[loyalj]

huh? There's a TODO comment about removing the on/off state portion of the selection manager and it was that flag in the data file that started the conversation. The way the selection manager behaves is defined entirely in the code, The flag is just turn this on and filter events or don't and let objects handle the click event only. The way the objects respond to events is still in the objects, now they just have a more verbose set of events to consume.

[etlgfx]

haha yea. That TODO is about setting it up as an event handler as opposed to a fixed thing that's always there. That way we can avoid code like if sectionmanager.enabled == true do X.

I'm just thinking big picture too much like we've been saying the past couple messages. Just ignore all those TODOs for now.