Lemur FunctionId design question

User Code & Projects lemur
1

Hi

Paul do you think it would be better to have a setter method for String group; in FunctionId class ?
So if we are doing delegation internally in our Systems (AppState) we can yet let the user/game to change the group for that delegation as he wishes.

2

Group is application defined. It’s part of the ID, basically. I don’t know why the user would want to change that. It would be like changing the function ID at runtime, everything else about your game might break.

Groups are a way of doing two things:

  1. grouping functions together so that you might have similar IDs that do different things.
  2. mainly, so your app can turn entire groups on/off as the game state changes. (For example, turning off all player movement input while they have their inventory screen open.)

I don’t see why the player or game logic would want to change these things. It doesn’t make sense.

3

For example I have

public class EditorState extends CompositeAppState {

    public static final String SYSTEM_ID = "editor";
    public static final FunctionId F_EDITOR = new FunctionId("Group ?","Editor");

EditorState is a separate module in core, and I thought it is not neat to define the group name here (I may be wrong) ,

instead I define them in my actual game app like :

public class MainGameFunctions {

    public static final String IN_GAME = "In Game";

    ...
    
    public static void initializeDefaultMappings( InputMapper inputMapper ) {


        EditorState.F_EDITOR.setGroup(IN_GAME);
        inputMapper.map(EditorState.F_EDITOR, KeyInput.KEY_F4);

    }
}

And I thought i should be able to define group here putting it in group “In_GAME” or something else.
I thought it gives me benefit I can put bunch of my different systems (which have not relation to each other) to get activate/deactivate together.

4

Don’t group your groups just to make activation/deactivation convenient. Group them logically and then use something else to generally sync your game state with your group state.

Trying to make game state and group state the same is going to get you into a bunch of trouble. They aren’t the same things.

5

Okay, got that, will do as you said.

Some times when I push my self to do something flexible and more convenient I do get the wrong way. :wink:

Thanks for correcting me.

6

It’s hard in this case but I only know because I’ve done it the wrong way a few times already. :slight_smile:

In Mythruna, at some point I ended up with a “mode” manager that simply tracks what the current game mode is… then during transitions listeners can enable/disable states, groups, whatever. (This is why I sometimes shy away from putting key activation right into my general app states).

In my mode manager, there are convenience methods for linking app state and input group activation to modes. (Internally creating mode change listeners.)

1 Like
7

But because I just remembered it… the classic example of why it’s bad to link group state to game state… is the case where you want some set of keys active during two different game states but still not some others.

1 Like