0.6.0 has a more ‘frame driven’ approach. Meaning, for every time the game was drawing something (a frame) it also was checking for input: “Is this mouse button pressed?” or “has key X or Y been pressed?”. And if so, it acted accordingly.
This code is spread out everywhere; possibly at duplicate branches in code. Pieces can overlap and cause unexpected behavior. Combine this with the lack of having a proper ‘state’ for a mouse to be in, and it becomes a “big ball of mud“.
A better way is to let the game deal with “events“. This means, that there is code that is responsible for figuring out what key is pressed (or released), and mouse inputs that are interesting (mouse moved, button hold/released, etc).
Then, at the places where it is interesting you can “listen” to these events and act upon them. (this is also known as the Observer pattern).
Combine that with a mouse having a “state machine” and you can have the mouse (on the battlefield) be in a different state, upon a mouse click, units selected, or key press. And then have it behave exactly like you want to.
To make it more visual, here is version 0.6.0 (current latest) where you clearly see some unexpected behavior:
Now, compare this with the next upcoming version 0.6.x:
To sum it up, what has been improved/changed:
- you press
Rnow (no need to hold it) to get into a “repair” state, much like you would click a “repair” button. (which will come in the future). Press
Ragain to get out of that state.
- when you have units selected, and place a structure. The units stay put. (and wont get send over to the structure, as you see in video of 0.6.0)
- when you have units selected, then hold
SHIFTand select another bunch of units, the units don’t move. (in video of 0.6.0 the units gets send over to the position when you release mouse button)
All coming in the next version!