Click here to Skip to main content
15,867,308 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
Hi all,

I'm creating a game in UWP. I try to have two simulatenous players from one keyboard (say one uses Arrow keys and the other one ASWD).

In UWP there doesn't seem to be any KeyPress event, but I have tried with KeyDown. The problem is that as soon as a key has been pressed, the previous key becomes forgotten. Thus, the two players compete for the same keydown events. For example, only one can move their player object at a time.

Any ideas to to make this work? Also, it would be nice to have two keys at once for diagonal moves (up and right arrow keys for example).

Thanks!

Petter

What I have tried:

I've tried the KeyDown event, but it only recognizes the last key pressed (as in a Word processor).
Posted
Updated 17-Jun-16 22:20pm

1 solution

Your speculations are invalid. Nothing is forgotten, by one simple reason: you are the one who make the keyboard event data "remembered". The basic architectural paradigm of proper processing is called "dispatching". That's right, you can handle KeyDown and may sometimes need KeyUp, and you never would need KeyPress unless you need to handle the process of text input, say, filter it.

You need to have a layer which handles "row" keyboard event and analyses then. It sits between the control handling the event and "virtual" game elements such as players. The player should be capable of some "semantic-aware" events, such as logical "left", "right", "left-up", and so on. The player class can define its own event instance with its own event argument type, and the above values can be, say, direction vector or even enumeration type. It also should provide a mechanism of accepting the events, which internally invokes those secondary, "semantic" events. The intermediate layer finds out which player instance should invoke which secondary event. It also solves the problem if diagonal keys. This is easy enough: it should keep track of presently pressed keys from the relevant set of keys (and that's why you also need KeyDown. Then, for example, the event detecting that Up is pressed depends on the state of the keys Left and Right. Depending on those states, Up is interpreted as secondary event Up, LeftUp or RightUp.

All this stuff is pretty simple, but you need to design it thoroughly.

One more consideration: in event handling, the queues of events are typical. But they are not suitable in your case: the events should be delivered to the player instances (or elsewhere) immediately and get handled immediately, due to the gaming specifics.

—SA
 
Share this answer
 
Comments
petter2012 18-Jun-16 5:57am    
Thanks so much for taking the time to write such a detailed answer. In my case it's only a onepage game, so working in this manner will be much more work than just using another event handler or so. I'll need to sit down and Think of how I should proceed...
Thanks again.
Sergey Alexandrovich Kryukov 18-Jun-16 9:45am    
You are very welcome.
Agree. And one reason to abstract out even input from the game could be the possibility to migrate the game to the multi-computer program. Then you would have the layer with game data mode, game logic, and input and output would split into different machines.
—SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900