Is using static variables for input engine evil?

Started by
12 comments, last by Satharis 10 years, 5 months ago

Yes it is! You're Hitler to me now.


This is actually very useful. Don't worry about something being evil, worry about how it will affect your code down the line and see why it's not good. Statics aren't bad, but they can lead to habits that make the code hard to maintain.

Learn all about my current projects and watch some of the game development videos that I've made.

Squared Programming Home

New Personal Journal

Advertisement

At first, I would pass the input engine over to objects that need it, for example the Player. Every time I create a player, i would pass the input engine over to it, like this:

player1->inputEngine = inputEngine;

You have bigger issues than the use of statics.
People think of input as events because in event-based applications they are.
Games are not event-based (there are of course events in games etc., but they are not event-based like applications are), and input in games is not an event.
You don’t press a key and then directly send that to a character and make it jump.

You collect input events into a queue and then the game manager reads them on each cycle, and then at a specific point inside the game loop you handle inputs and the jumping of the character. Additionally, letting the player character handle its own input is flawed; the character then needs to know more about its surroundings than it otherwise should. For example, if the character is in the air it should not be able to jump again. Now the character class needs to know about the physics engine to get information as to whether or not it is on the ground to decide if jumping is possible.

The character is a slave to the physics engine, not the other way around. Note of course that that does not mean the physics engine knows what a character is, it just understands certain properties that the character has and a higher-level class (such as the engine itself) gets just that data from the character class and feeds it to the physics engine.

Handling input is done at a much higher level than at the character’s level. The higher-level game class knows what characters are and what physics is and what the game rules are (hence it is the game class). I want to reiterate, the game class knows what the game rules are. The game class decides if the character is able to jump in its current situation and it is what contacts the physics engine and possibly other modules (maybe the player can’t jump while a certain light is on or when a sound is playing) before deciding, “Okay, you can jump.”

With your proposed design, the character class would be absolutely monolithic, knowing about the physics engine, world lights, and sound engine, when really all it needs to be is a normal game entity with a health bar.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

At first, I would pass the input engine over to objects that need it, for example the Player. Every time I create a player, i would pass the input engine over to it, like this: player1->inputEngine = inputEngine;

You have bigger issues than the use of statics.People think of input as events because in event-based applications they are.Games are not event-based (there are of course events in games etc., but they are not event-based like applications are), and input in games is not an event.You don’t press a key and then directly send that to a character and make it jump.You collect input events into a queue and then the game manager reads them on each cycle, and then at a specific point inside the game loop you handle inputs and the jumping of the character. Additionally, letting the player character handle its own input is flawed; the character then needs to know more about its surroundings then it otherwise should. For example, if the character is in the air it should not be able to jump again. Now the character class needs to know about the physics engine to get information as to whether or not it is on the ground to decide if jumping is possible.The character is a slave to the physics engine, not the other way around. Note of course that that does not mean the physics engine knows what a character is, it just understands certain properties that the character has and a higher-level class (such as the engine itself) gets just that data from the character class and feeds it to the physics engine.Handling input is done at a much higher level than at the character’s level. The higher-level game class knows what characters are and what physics is and what the game rules are (hence it is the game class). I want to reiterate, the game class knows what the game rules are. The game class decides if the character is able to jump in its current situation and it is what contacts the physics engine and possibly other modules (maybe the player can’t jump while a certain light is on or when a sound is playing) before deciding, “Okay, you can jump.”With your proposed design, the character class would be absolutely monolithic, knowing about the physics engine, world lights, and sound engine, when really all it needs to be is a normal game entity with a health bar.L. Spiro

This is a really good way of handling input.

I will be implementing this from now on in my own games. Thank you.
Static is a perfectly legitimate tool but I notice people tend to always use it for the completely wrong reasons.

Where would you actually use static? Well static essentially has different meanings depending on context, but the general idea is that there is only -one- for the program. Where would you need one of something? Personally I tend to use static only when something belongs to a class and every instance of the class is supposed to share that object. For instance I might have multiple window objects but each window might want to use the same D3D device, or something like that.

I've also used static for things like stringstreams that each instance of a class uses as a utility to format their strings, things like that. The usual wrong way is to make something static just because you think you'll only ever have one, not because there being one is a design decision. Of course there are a few exceptions, loggers are a good example, but that's because they're one of the few objects that every corner of a program will need to have access to and utilize.

This topic is closed to new replies.

Advertisement