Tag Info

Hot answers tagged

33

This is an expansion of my comment to a full answer, as suggested. Yes, plain and simple. Communication needs to happen and while there are situations where 'Are we there yet?'-type polling is required, having things check to see if they should be doing something else generally wastes time. You could instead have them react to things they are told to do. ...


18

(This is based on my answer for a similar question on Stack Overflow.) It sounds like you're asking for a more flexible way of specifying the probability of each event. For that, you can use a simple weighing algorithm: simply decide how common each event should be and assign it a weight that is appropriate compared to the other weights. For example, if you ...


16

It depends on the requirements of your game and hardware. Most games are usually interested in changes to input state, i.e. user presses the fire key and their weapon starts firing, user releases the fire key and their weapon stops firing, user presses the move key and starts moving, releases the move key and stops moving, etc., so an event-driven input ...


14

A better question is, what alternatives are there? In such a complex system with properly divided modules for physics, AI, etc., how else can you orchestrate these systems? Message passing does seem to be the "best" solution to this problem. I can't think of alternatives right now. But there are plenty of examples of message passing in practice. In fact, ...


12

You should have a very well-defined set of interfaces that are allowed to transmit or receive messages -- giving them a reference to a EventScheduler should be trivial. If it isn't, or if you feel like that would involve passing the event scheduler to "too many" distinct types, then you might have a larger design problem on your hands (a promiscuous ...


11

Messages generally work well when: The thing sending the message doesn't care if it gets received. The sender does not need to get an immediate response back from the receiver. There may be multiple receivers listening to a single sender. Messages will be sent infrequently or unpredictably. (In other words, if every object needs to get an "update" message ...


11

TL;DR The author is not suggesting you implement this in your game. He's telling you that the precision will be slow changing, but bad. This means the float you're using to track your game time would start at 2^32. Because setting the number that large to start with, whatever you add on to it in the next 136 years, won't change the exponent. Though, the ...


10

We used a state system, as you mentioned before. We would create a map that would contain all the keys for a specific state with a flag that would allow pass through of previously mapped keys or not. When we changed states the new map would be pushed on or a previous map would be popped off. Quick simple example of input states would be Default, In-Menu ...


10

An SDL_KEYDOWN event is only sent when the key is first pressed. You will receive an SDL_KEYUP event when it's released. You'll want to handle moving in code which gets called every frame, not in response to an event. Inside Avatar::handle_input, you'll instead want to set variables to tell you whether each key is up or down, and update those variables as ...


8

I'm a full believer in necessity being the mother of invention. I do not like to code anything unless its need is clear and well-defined. I think that if you start your project by setting up an event messaging system, you're doing it wrong. I believe that only once you've created and tested your infrastructure and have all the pieces to your project as ...


8

two options: if "nested input" cases are at most three, four, I'd just use flags. "Holding an object? Can't fire." Anything else is overengineering it. Otherwise, you can keep a per-input-key stack of event handlers. Actions.Empty = () => { return; }; if(IsPressed(Keys.E)) { keyEventHandlers[Keys.E].Push(Actions.Empty); ...


7

I think you're comparing apples and oranges here. Polymorphism isn't replaced by messaging at all. You would probably want events/messaging to connect loosely coupled components. Eg. to send a message from an entity when a collision occurs, to update the player score or maybe to trigger a sound-effect. So that these individual classes don't know the other ...


7

The code in your question is fine. The problem must be in the code above it, perhaps you are doing something like this: // ... if (ks.IsKeyDown(Keys.Down)) { /* ... */ } else if (ks.IsKeyDown(Keys.Down) && (ks.IsKeyDown(Keys.Left))) { /* ... */ } // ... In which case the first condition will trigger and the second will not (due to else). Here is ...


7

I recommend separating input events from game objects so you can quickly change/upgrade input methodologies without having to edit and debug 10 object classes. Examples being shifting over from keyboard-only controls to mouse+keyboard, or simply reassigning keys. Instead of tightly coupling input to the individual game objects, call only one method per ...


7

In Stendhal we solved the performance issue by adding game events to a queue and then processing them asynchronously in the background. In our case the events are not just records but objects which have a little bit of logic because in some cases we need to do two inserts with a link between them. For example the first time a item is handled in game, it ...


7

I see no reason that you cannot do both, and get the best of both worlds. Input Events are generated by polling (at some level the driver polls the hardware to see what state its in), and since your main loop polls all input devices, you can easily implement your own. Something simple like below is what I've used in the past. mouseInput = GetMouse(); ...


7

The only reason against using event in a game is that creating a delegate to attach to the event handler creates a heap object that can cause a garbage collection which can cause a frame-rate hiccup on on Xbox 360 (and possibly WP7, haven't tested it). In general, this should not be relevant to a game UI that you set-up once and simply let run. Also, ...


7

An event dispatcher is one of those cases where a singleton isn't the worst idea in the world, but I applaud you for trying to avoid it. You might find some ideas here.


7

Most games have a function that calculates the current time -- perhaps using QueryPerformanceCounter(), perhaps using GetTickCount64(), perhaps using something else. Normally this function is designed so that it initially returns zero, and then gradually returns larger numbers. What the author is saying (and I can be definitive about this because I am the ...


6

I recommend the MVC approach. In MVC the game objects only have to worry about modeling the game system, and provide a high level interface like move_left. Then have a controller object that worries about mapping input to model calls. Not only does it allow for easy change of controls, it gives a good interface for AI they are just another controller. ...


6

See this document: How to: Publish Events that Conform to .NET Framework Guidelines (C# Programming Guide). Ignore it. There is no compelling reason to follow those guidelines when you are making a game. Make your own delegate type that takes appropriate types (either existing object references or value types): public delegate void ...


6

This can be as simple as you want. for each object in the subscriber list: object.notify(this event) // (or 'HandleEvent' if you prefer) Don't try and work out what an event manager 'should' do - work out what you need it to do. The rest should follow from there, or at the least, should suggest some more specific questions.


6

Just separate the events from the drawing. The normal method is to redraw all the time, not to wait for something to change. Normally your loop should be like this: while loop: check events: # find routes, block path, whatever update things: # change the state of the game draw() You shouldn't be thinking in terms of drawing one ...


6

The general solution to this problem is to have an update function with a completely fixed timestep. Unity calls this FixedUpdate, in physics engines you can run the simulation several times before updating the world, etc. but it's all the same concept. While this fixed update function will always be slightly out of sync with everything else in your world, ...


5

Use GetPressedKeys() to get all of the currently pressed keys and iterate through them doing what you want. If you're moving the player or something, create an initial Vector3 at the beginning and add modifier values to it and add it to the player position after the input checking has completed. Something like this: Vector3 positionToAdd = Vector3.Zero; ...


5

Michael's solution is perfect if you want a single table of possible events. Let's say you want to build a random insult generator, though. In this case, a series of tables would work best. You'd start with a table that has a list of general patterns. For example, Your [RELATIVE] [RELATION] [ANIMAL]! Go [VERB] [NOUN] in your [ORIFICE]! Now say the random ...


5

Events system are powerful, and can be made very fast. They also allow you to modulise sections of code in a very loose coupling structure. They let you job batch things and thread off tasks. The work well with multi-core and asynchronous functions. Physics - Collision Callbacks, Activate or Rest Objects translate well to events. Networking - As much as ...


5

What I'd do is use the observer pattern and have an input class that maintains a list of callbacks or input handling objects. Other objects can register themselves with the input system to be notified when certain things happen. There are different types of callbacks you could register, based on the type of input events observers would like to be notified ...


5

1) What Kimau said about compensating for controller lag/perceptional differences is important. While a lot of people get the basic rhythm, just translating it into a keypress might mean they're slightly off. If you can, give them exact feedback where their press occurred. (I.e. display a marker relative to the real beat, or something similar) 2) relative ...



Only top voted, non community-wiki answers of a minimum length are eligible