Child objects vs data

untune

Member
Hi all,

I've just been pondering something and I'm curious what the approach would be for other people.

I've been coding an input system that takes care of input devices and bindings, and has lots of little features to make things easier to deal with. I did a bit of research with Messhof's InputDog library a while ago just to get a few ideas for structure etc.

That one uses a single "manager" parent object containing practically all of the creation and step code, but is then instantiated by use of separate child objects (InputForPlayer1, InputForPlayer2, InputForPlayer3, InputForPlayer4... etc) which inherit everything from the manager, but have a single user event triggered in the manager create event that just adds the actions (i.e the controls) for that player. It seems a little strange to me to have a completely unique child object per player - I'm wondering what the benefit of doing this might be? I'm thinking of managing players, devices and controls mappings using lists or grids stored in the manager, or at the very least have a single child object which is instantiated multiple times for each possible player.

Can anybody offer any ideas to the benefits of each implementation?

Cheers
 
Last edited:

jo-thijs

Member
Hi all,

I've just been pondering something and I'm curious what the approach would be for other people.

I've been coding an input system that takes care of input devices and bindings, and has lots of little features to make things easier to deal with. I did a bit of research with Messhof's InputDog library a while ago just to get a few ideas for structure etc.

That one uses a single "manager" parent object containing practically all of the creation and step code, but is then instantiated by use of seperate child objects (InputForPlayer1, InputForPlayer2, InputForPlayer3, InputForPlayer4... etc) which inherit everything from the manager, but have a single user event triggered in the manager create event that just adds the actions (i.e the controls) for that player. It seems a little strange to me to have a completely unique child object per player - I'm wondering what the benefit of doing this might be? I'm thinking of managing players, devices and controls mappings using lists or grids stored in the manager, or at the very least have a single child object which is instantiated multiple times for each possible player.

Can anybody offer any ideas to the benefits of each implementation?

Cheers
Hi and welcome to the GMC!

I would personally not create a different child object for every possible player (although it depends on the kind of game).
I would have 1 child object represent all human players and either have the instance that creates them set their controls,
either set their controls in the creation codes (not to be confused with create events)
or either give them an index with which they can access some global variables to find their controls.

The approach you described has some benefits however when a player can be multiple characters or when you want to implement AI.

In the user event, you could instead of doing initialization, calculate input per step.
You can then have a player child object that checks which buttons are pressed and set input variables accordingly.
You can then also have a CPU child object that performs a bunch of calculations to eventually decide on its input.
This way, you now have a simple system that guarantees the CPU can only do as much as a human.

For dealing with a bunch of characters, you can initialize properties per character in the child object.

Overall, there's not much difference between the 2 methods you propose.
The biggest difference is where you would look up controls and how easy it is to change controls statically or dynamically (at run time).
It will be easier to do it dynamically with the second method you posted.
The other stuff will be pretty similar.
 

NicoFIDI

Member
Well as i always say when it comes to design.
It depends on the problem.
- Lets supose an assimetric play (where not every player see the same or handle the same UI)
I whould make child controls to have non related controls into non related players
- But let's guess you have a fighting game, where you could plug a joistick, use WASD for one ARROWS for the other and MOUSE for the last (BTW i have no idea how you make the mouse act as arrows XD)
Then i whould do separate objects for the inputs but make a generic player take data only from one of it

And so on, theres more cases and more solutions, you only have to ask yourself,
Does this solve my problem?
 

untune

Member
Hi and welcome to the GMC!
Thanks for the kind welcome :) Interesting points, this has got me thinking about how it interacts with AI aswell. The system I'm designing for the moment is purely for processing human input (mouse, keyboard, gamepad etc) and passing the intents onwards to wherever they're required. I hadn't considered that I could potentially tie computer controlled players into it - food for thought, although I'll probably code a separate system to control that.

I think the idea of a single "human player" child object which can be instantiated multiple times (so if you want 2 or 4 or 10 local players, you can assuming you have enough devices) is a good one. It seems much tidier to have a single template for a player rather than lots of unique ones; I can see it getting a bit unmanageable when you're referring to obj_InputForPlayer17 :D

Well as i always say when it comes to design.
It depends on the problem.
This is very true. Since I'm approaching it from a catch-all angle and trying to make something robust and transferable rather than trying to fix a specific problem, I'm trying to implement a broad solution. Likelihood is that I won't even have multiplayer on the project I have in mind - but it's good to plan ahead so that if things do change, I don't end up tearing the code to pieces.

Cheers!
 

Xer0botXer0

Senpai
I'd like to suggest that for any project that you want to add multiplayer too, create a notepad or something (I just use a script where I comment everything) and write down which arrays and variables would matter for multiplayer, for example..
Your players are going to have usernames, they're going to have appearances, equipment, inventory, quest logs, coordinates, all that sort of stuff, so in this notepad you want to reference the arrays and variables for those things.
So when you do go to multiplayer you look at this notepad it tells you okay these are the things you want to modify so that the players client receives all this information from the server.

Personally i dont use the parent child method, I'd take a similar approach to Jo-thijs, an object for other players, and then setup the instances.
Then of course for all code that they may share, for example in their create events you'd probably setup dozens of variables arrays ds_* and so on, for that I just put all that into a script, and reference the script. So each instance is going to have all the information, but only use some of it. A better way may be to use a switch statement in the script, depending on a value when creating the instance, it will initialize a specific case within the script for your instance.
 

NicoFIDI

Member
There's something you have to have in mind when developing to dont fall into a neverending loop of code that never reach nothing,
YAGNI (You Aren't Gonna Need It)
This is actually a principle of Extreme Programming (the practice i ilke the most), you can do futher research if you want over YAGNI and why is it good

Of corse this is a personal choise, i dont think theres a good and a bad solution in this case, because the final goal it's blurr.
But if you want to make it generic dont limit the ammount of players you can have.
This means you wont use a child for each player, because you will fix the maximun simultaneous players or full your game with childs that wont be ussed.
 
Last edited:

untune

Member
Thanks again for the responses, much appreciated. I'm still getting used to the way objects and instances interact (and confusing myself with terminology a bit!) as this is the first thing I've coded in quite a while...

@jo-thijs So to clarify: your suggestion would be to have the input manager object (let's call it obj_InputManager), then one object which is a child (obj_PlayerInput) and we have a single instance of obj_PlayerInput which has a list of indices to identify players individually. Is that right?

@Xer0botXer0 So does that suggest as you say, similarly to jo-thijs - one instance of one object to represent all players (i.e. a singleton), or do you mean one template object with a separate instance for each player? But in your case, the object is not a child of the manager? Great suggestion with the notes for multiplayer btw!

The inputdog implementation doesn't instantiate the parent but instead lets those individual child objects (which are all completely unique objects, and not multiple instances of one object) effectively be instances, inheriting all of the code from the manager. It seems to me to be slightly counter-intuitive to have multiple objects, when you can instantiate one object and store all the data for each player in instance variables. A bit like having var1, var2, var3, var4 when you could just have an array. There may be some other reason that I've not picked up on yet - perhaps something to do with persistance between rooms etc. This discussion has also got me thinking about how you might go about being able to switch control of something between a human or computer player on the fly...

@NicoFIDI I agree, it's easy to overengineer solutions to a problem that doesn't exist. But in this instance, I think the extra effort will be worth it because this library will be easy to drop into new projects and it very data driven - at present, I have a nested map structure that is stored in a json file, which can be loaed sand saved to store bindings for keyboard/mouse, gamepad, and can easily be extended to store additional data if it's needed. What's more, I can quickly type up a json file to create new maps in minutes (I'm going to make a tool eventually) and the system can take strings and convert all the bindings/properties to internal constants for use with other functions.
 

jo-thijs

Member
@jo-thijs So to clarify: your suggestion would be to have the input manager object (let's call it obj_InputManager), then one object which is a child (obj_PlayerInput) and we have a single instance of obj_PlayerInput which has a list of indices to identify players individually. Is that right?
If you have multiple players, you would have multiple instances of obj_PlayerInput, but only 1 object for them all.
The array would be a global variable, not an instance variable of obj_PlayerInput, so that some menu to change controls can easily change the array without extra overhead.
Every player instance would then have a variable myIndex that serves as index for that array to find their respective controls.
 

untune

Member
If you have multiple players, you would have multiple instances of obj_PlayerInput, but only 1 object for them all.
The array would be a global variable, not an instance variable of obj_PlayerInput, so that some menu to change controls can easily change the array without extra overhead.
Every player instance would then have a variable myIndex that serves as index for that array to find their respective controls.
Perfect, that's pretty much exactly what I envisioned :) Thanks!
 
Top