Implementing Game Controls

[jacquesr]

Hi everyone,

since I love babylon which I currently use for an industry related project, I started to write the code base for my first ever game that might come out in 2050 since I don't have too much time for it... Great announcement, right?

Well, I didn't know where in the forum I should really post this but since I am working in babylon, I just put it here since suggestions might include framework specific things that I can use.

So the first things I wrote are entities and their subclasses (movable objects, controllable objects, sub classes that become more specific like projectiles, tanks, choppers, etc, which will play a role in the game) and a controls system.

What I am looking for is an open discussion about how I am implementing the controls system and whether or not you have suggestions about how it can be improved / uncoupled (since I really hate coupling things too tight together from an architectural point of view).

I have defined a controls input class. It is closely bound to the things that are possible with a standard xbox (like) controller. The controls input holds all properties (axes values, button presses). Then, I have a controls translation class. It is bound to the controllable entity which can define easing and duration for translating input to output. That's for adding inertia to the input. That could be relevant for smoothing inputs, especially when the input comes from the keyboard instead of a controller.

Then, I have a controls output class. It holds the values that are the result of input + translation.

The translation class allows for setting easing function references and durations for the different axes or even for button presses.

Then, I want to use the output as the base for controlling the entity. I am thinking about routing the output through another translater which then produces the actual movements, since there can be additional  limitations (e. g. a tank or chopper has its own inertia for the steering thats uncoupled from the controller output)

So: What do you think about this approach? How do you do this?

[OMAR]

Well 1st, if you are going to write classes and subclasses  then using Typescript instead of Javascript might come in handy.

Second, I don't really think you need to write your own controller classes, Babylon has already got pre-defined class that deal with input

Gamepads: http://doc.babylonjs.com/classes/2.3/Gamepad

Xbox gamepad: http://doc.babylonjs.com/classes/2.3/Xbox360Pad

Camera designed specifically to be used with gamepads: http://doc.babylonjs.com/classes/2.3/GamepadCamera

For controlling gamepads: http://doc.babylonjs.com/classes/2.3/Gamepads

If you're going to implement input, then it is preferred to write those functions in the classes that need it. For example Player class needs input so you can write functions that deal with input there (and of course all of your easing and additional implements will go here too). Another way could be creating interfaces for input and then implementing these interfaces to the classes that need input, this way your code will be more organized.

For limitations, you can basically define function declarations in interfaces and then you can extend them in your classes in a way you desire.

Another useful tip: Try to put your classes in separate files and put only 1 class in each file. This one helped me a lot in my projects and this is also a philosophy Babylon follows.

[jacquesr]

Hi Omar,

thank you for your feedback. First of all, it might have been useful if I said I am using typescript. And I also follow the common 1-file-1-class paradigm.

So apart from my own gamepad things, I read that I actually do the things as you mentioned (my translations are in a class of which instances are created in the controllable entity classes).

It pretty much backs up my approach which sounds good. Thank you for your post.

[Wingnut]

Hi guys.  I agree (like that matters).  J... you will likely want to detach your controls input class, and just attach the BJS gamepad input. 

Your controls output class, (+translationsManager)... that will need to be target/route-able, right?  Sometimes the user is moving the camera, sometimes a mesh, sometimes a light, and sometimes even attaching to live-actions, such as live-changing the emitRate on a particleSystem, or varying a parameter in a shader.

The structure of your flow... sounds cool.  Have you thought about this router of which I speaketh?    It is going to need a "scaler", too, I think.  Sometimes a mesh will want HUGE movements, sometimes a light will want fine-grained movements, and when routing to "live" values/properties, you will need to turn off SOME axes, and somehow determine what value-range to allow, etc, etc.  FUN!  The Ranger - your one stop for ALL of your value-ranging needs! 

By the way, I sort of started a strange type of "keyboard" device, that could reside on the same layer as a BJS gamepad device.

http://www.html5gamedevs.com/topic/2571-the-wingnut-chronicles/?do=findComment&comment=122613

I'm NOT a coder.  I'm a child with power tools, matches, blow torch, and a box of dynamite.    But still... SOMETHING is drawing me toward having a babylon "keyboard" class and joystick class... available at the same layer as gamepad class.  I'm not sure what a keyboard and joystick class would LOOK-like, though.  I guess I'd start by cloning a gamepad class, and start modifying.  *shrug*  You're free to use my keymaster... but... be warned.  I WROTE IT, so it is almost sure to be full of dangerous disease and germs, and might even have begun as a bad initial idea.  HARD HAT ZONE! 

[fenomas]

I'm no expert, but in my game I have:

• An input module that wrangles mouse/key events into game actions (forward, jump, fire, etc). This module handles stuff like, if you bind two different keys to the same action, and release one while the other is pressed, the game won't get confused about the input state.
• A movement module that takes an entity and a set of action states (i.e. which actions are currently being pressed), and applies the necessary physics rules to the entity
• An intermediary bit that connects the key input and the player entity to the movement part.

This idea is, firstly because of the intermediary bit it's easy to point the inputs at a different entity, or record inputs, replace them with recorded actions, etc. Also, it lets you drive NPCs via the same system - they just get their action states from an AI module that emulates key inputs, but the output of the AI module gets passed along with the NPC id to the movement bit, and everything winds up moving according to the same rules.