1
\$\begingroup\$

Just a quick one really, as I can't find anything definative.

Started developing in Java, to learn and take on a bit of Game Dev. Have a PHP background, and I'm a massive sucker for best practices, etc.

Basically in my Game::update() method I can handle keyboard input and move the Player, this is what I want to avoid.

So should my Keyboard class have a dependancy of Player, or the other way around? Also would the Keyboard class handle the management of Player states or would the Player class handle that itself.

OR...

Should I look into introducing an Event System to the Game Engine?

This is a very broad question and down to opinion. I'd just rather do things the right way, than end up with a steaming pile of mess.

| improve this question | |
\$\endgroup\$
  • \$\begingroup\$ Hey Benny, welcome to game dev! Opinion seeking questions like this are probably best to ask in the game dev chat room. \$\endgroup\$ – MichaelHouse♦ Aug 29 '13 at 16:06
  • \$\begingroup\$ Didn't even realise that existed! Cheers for directing me there @Byte56 \$\endgroup\$ – Ben Aug 29 '13 at 16:09
  • \$\begingroup\$ Personally I like to make a separate PlayerInput class. The input class grabs input from the keyboard and then tells the player how to behave. By doing this you very easily create an AI class that controls other player objects. But this is just my personal preference and not necessarily the best practice (I'm not exactly sure it is viewed by others). \$\endgroup\$ – Benjamin Danger Johnson Aug 29 '13 at 20:25
  • 1
    \$\begingroup\$ -1 since this is just design paralysis and totally opinion based. The "right way" comes about with experience. Make it work first, then refactor into something better when you see and feel the problems with your original design. \$\endgroup\$ – Tetrad Aug 29 '13 at 22:53
3
\$\begingroup\$

I like to use a callback based input manager. The Player class calls the static register method of the input manager with the input to register (either some hard coded values like W or an alias like Forward) and a method to call back when the event happens.

In Java this will probably be programmed with an anonymous overloaded object of a callback class, or a lambda function.

This has the benefit of being a very flexible system, as the player does not control itself but rather is controlled by the input.

| improve this answer | |
\$\endgroup\$
1
\$\begingroup\$

This is entirely subjective to the design requirements of your game but, generally speaking, usually most systems use an event-based system where objects register for events. It allows for a pretty flexible system where you can design anything from HID input to timers to trigger events.

If you would like to see a pretty strong example of how this can be done in a managed language, check out the source code for the Delta Engine. It's in c# but c# is incredibly easy to interpret in a java sense.

Delta Engine Source code

| improve this answer | |
\$\endgroup\$
0
\$\begingroup\$

I think that the Player should have a dependency on keyboard. Image some of the meta-tasks like Player creation / managing multiple Players for a single user, finding servers, or configuring graphics and sound. None of these things should be routing all keyboard events through a single Player.

There is an extra concern. What if your game is on a tablet or PS3/XBOX/...? No keyboard. The user input system should still not be tied to a single instance of Player; however, it's not a keyboard.

| improve this answer | |
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.