Best practices cast control

General Discussion
1

wiki says you should cast controls when you need to grab them from a spatial,

public class MyNewControl extends AbstractControl {
    private MyControl myControl;

    @override
    public void setSpatial(Spatial spatial) {
        super.setSpatial(spatial)
        if (spatial != null) {
            myControl = spatial.getControl(MyControl.class);
        } else {
            ....
        }
    }
}

When doing it like this the spatial may not be null but the MyControl may be because it’s not yet added to the spatial. Not to much of a problem if you have a few controls and they only rely on one or maybe two other controls, you just add them in the proper order. The problem is the more controls you add the more convoluted this becomes.

My java brain tells me create a getter when grabbing a control instead since it wont be called until the controls are done being added anyway.

private MyControl getMyControl() {
    return spatial.getControl(MyControl.class);
}

Will this make that much of a difference in a game?

2

No, probably not!

However, what’s the reason why your controls depend on each other so much?
If possible each control should not have any dependencies on other controls (in my opinion). Sometimes it can happen, though.

You also might think about using AppStates instead of Controls.

Best regards
Domenic

3

Yeah… will probably result in unmaintainable heap at some point. Maybe advisable to revisit your design…

4

An example is keyboard control when using 3rd person, and AI for pathfinding.

I try to keep everything related to keyboard in one control.

I access the ChaseCam control for the spatial which uses arrow keys for rotaion.
I access the BetterCharacterControl to make it jump with spacebar.
I access the the AI control when picking to pass vector to AI.

I could put the listeners in their respective controls but then things get spread out. Seems easier knowing if there’s a keyboard issue I know right where to look.

Each is only referenced 1 time.

5

Rather sounds like the task of an app state to me…

6

It works both ways. That’s the problem with keyboard. 3/4 of it requires spatial methods, 1/4 AppState methods.

Cleaner to use control though…

7

I don’t know if I got your situation correctly, but I would write an app state for the camera. Another one for the player and again another one for the AI.

The PlayerAppState for example would then listen for “SPACE” input and would call the jump() method of the BetterCharacterControl.

Please tell me if I understood you wrong.

8

I use AppState to create player and initialize the ChaseCam, the head, for that palyer.

AI is pure control, i.e uses only spatial methods to work,

I had Keyboard in AppState but moved it to control.

In multiplayer wouldn’t it be better in a control then AppState?

Seems more natural to add a keyboard control to a player upon login.

9

It is difficult to answer…
Of course it is fine to have controls for your player. But I would not connect your PlayerMovementControl with an ActionListener or something like that. I rather would have an app state which listens for user input which are relevant for the player movement and then I would call a method of your PlayerMovementControl.

By doing this this way you decouple your player control and input a little. This becomes handy when you want to make your game to be played in multiplayer because then you don’t receive the input from your own listener but from the server (of course that depends on the application/game).

1 Like
10

From another perspective, there is only one keyboard so it’s more logical to have only one keyboard app state and not a hundred different keyboard controls.

App states are global… like a keyboard.

Anyway, I think part of the problem is the common one of treating spatials like game objects instead of just visual state. It’s kind of like strapping a JTextField right to a database field. Convenient today but will cause tons of issues every other day.

11

I haven’t learned networking yet so I was trying to guess how Keyboard should work since there will be moderators with different access levels. Cart before the horse kinda thing.

12

Well, there are no spatials or controls at all on the server unless your design is all messed up… no keyboards either except the one at the server console.