Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

132 Neutral

About broken_cactus

  • Rank
  1. broken_cactus

    Handling Input

    I'm glad that a few days of back and forths, coupled with hot showers and adequate sleep, has apparently allowed my brain to make some sense of what I've been reading.   Now for a few follow-up questions:   I've seen a few people suggest that key presses be directly mapped to functions like [SPACE] - Attack(). In this case, is Attack() a function in the player object? How does the InputHandler determine which functions keys are mapped to during different contexts (e.g. we don't want to call Attack() when we're in a dialogue bubble)? Also, do game objects generally not process their own input through some kind of player.handleEvent(event) function? What are game objects generally responsible for?   Taking a step back, assuming we're using some kind of EventManager, would it be reasonable to place all events in the same queue? For example,   [SPACE] is pressed and gets mapped to a KeyPress["Attack"] event. This gets passed to the EventManager which puts it into a queue until it's time to handle. [A] is the n pressed and gets mapped to a KeyPress["Jump"] event that is also queued. The queue in EventManager now looks like:   [0] KeyPress["Attack"] [1] KeyPress["Jump"]   We pop this off and pass it to the player object which processes it and sends out a new event for StartAttack, so the queue looks like:   [0] KeyPress["Jump"] [1] StartAttack   We continue on like this until the queue is empty, passing events to appropriate listeners (I'd probably just have different tables in the EventManager that allowed objects to register for different event types [e.g. EventManager.register_audio_listener(player)])
  2. broken_cactus

    Handling Input

    I appreciate the words of encouragement yckx. Maybe I can go over where I am now, and some questions will naturally arise.   EDIT: I've been thinking about this over the last day or two and an idea is starting to bubble up in my mind. Maybe someone can tell me if I'm on the right path or not. It will be easiest if I give you an example.   Ok, so let's say the player presses a key. I capture this in a lua callback function as keypressed, and I push this into some kind of InputManager. The InputManager maps this key press to something more abstract like "AttackPress" depending on the context (still unsure of the best way to do this). It pushes this into a queue (maybe in an EventManager class).   When an update tick rolls around, we're going to go through the queue and push these keypresses to objects that have been registered as listeners. So "AttackPress" gets pushed to the player entity by way of a handleInput(event) function. In this case of "AttackPress", the player entity figures out that it needs to call the Attack() function and the Attack() function does things like set the sprite (maybe this goes into its own manager), set the entity's state to "Attacking", and start a timer so we can ignore repeated presses of the keys until the entity has finished attacking.   We might also then send something to the EventManager like "PlayerStartAttack" and the event manager would push this out to the SoundManager which would take this and play the appropriate sound (rather than having audio code in the game objects). It might also push it out to the AchievementManager which would take this and award an achievment.   Finally, during the update calls, we update any timers, change animation frames, move the object, et cetera.   Does any of that sound remotely reasonable?
  3. broken_cactus

    Handling Input

    Hmm. I understand a little better what you mean. I'll keep trying to find articles or tutorials on how to structure my game code. Many of them are very abstract and don't give concrete examples that just say, "This is how we actually implement the things we've been talking about."
  4. broken_cactus

    Handling Input

    I find your variable names without any explanation to be quite confusing. It seems as though you are capturing the keyboard input, figuring out the state during each tick, and then using that, but I'm really not sure. !m_psmStateMachine->Tick()? I have no idea what this means without explanation.   If the above understanding is mostly correct, then that's already what I've been doing.   I have no idea what keyboard color is.
  5. broken_cactus

    Handling Input

    Well, that only adds more layers of confusion to this for me. English is my first language, but maybe I need a good dictionary because I seriously have no clue what is being talked about when it comes to this stuff.
  6. broken_cactus

    Handling Input

    Thanks for the response.   Does it make sense to me? Eh, sort of. I'm not sure where my particular hangups are, but I'm having trouble seeing it all fit together in my head. In the past I've always had objects updating themselves and checking for whatever input they needed during the update. There are problems with that approach though. This is quite different, so I think it might take me a while before I actually understand what keys I need to press while in my IDE to make the program do what I want...   I'll have to think about it.
  7. broken_cactus

    Handling Input

    Game objects don't necessarily need to handle every keypress, no. I just haven't found any actual examples of it being done other ways. I've actually read that post, but I guess I didn't take much from it. My issue with a lot of resources is that they stick to very high-level language and I never finish reading it actually knowing how to implement anything.   So let's say we map keypressese to actions. A keypress goes into a queue (presumably), some sort of input handler figures out what it maps to (presumably), and we push these actions onto a different queue. Now when we go through the action queue we have things like "AttackButtonPressed" or whatever. I'm still not sure how to handle that in the game objects. And I'm not sure how to reconcile that with the update loop.   I'm not sure what you mean by factory and I'm not sure what registering themselves would be. I'm also not sure, again, how to reconcile that with the update loop and general game logic
  8. broken_cactus

    Handling Input

    Hi. I'm relatively new to more serious game programming, having made some toy stuff in the past using various languages and frameworks, but I'm trying to learn more about game architecture. Right now I'm trying to wrap my head around how input is handled in various games. I realize this may change depending on the game and even hardware being used, but any insight is appreciated.   I'm currently using Love2D and Lua, but the examples I've provided are in Python (for clarity).   When I started writing my game, I was polling for user input during the update interval from each object. So I had something like this:   while True: for object in game.object_list: object.update() I've omitted some things, but I'll add that I'm using a fixed timestep.   There were a few problems with this approach:   1) If the user changed input, such as released a key, mid-update, some objects might react as though the key were pressed while others would not. This effect is even more noticeable when there is more going on in the update loop. 2) It is possible that the user does something like presses and releases a key before input is even checked, in which case that input is essentially lost completely.   The solution to the first problem was to check for input once at the start of the update loop (say by storing it in an array), and then polling that array while updating game objects rather than checking the input directly from each game object.   while True: InputManager.update() for object in game.objects: object.update() This still has the second problem though.   Thus, I started looking at the callback functions more closely. I am giving the following: key_pressed, key_released, mouse_pressed, mouse_released.   After doing some research, it seems the best way to handle input is to push events into a queue when they arise and then empty that queue during fixed update calls. The callback functions fire every time the corresponding event occurs, so I would push events onto the queue from them.   def key_pressed(key): InputManager.queue.push(KeyDownEvent(key)) Now we get to the meat of my question: what do I do with this queue? There are a few ideas that occur to me and none seem correct. E.g.   while True: while InputManager.queue.has_next(): for object in game.objects: object.handle_input(InputManager.queue.next()) for object in game.objects: object.update() I guess my question is: how do I cleanly handle input for my game once I've captured it and pushed it into a queue?
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!