What began with one or two bugs in 0.6.0 eventually ended up in rewriting the way D2TM deals with input. Basically because it was one of the oldest pieces of code and it was a mess.

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 R now (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 R again 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 SHIFT and 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!

Comments are closed

Want to support? Please consider donating via Kofi.

Path finding progress demo... made it so I use a priority_queue, did X4 speedup. Nice! https://dune2themaker.fundynamic.com/video/new_pathfinder_02.mp4 #indiedev #gamedev #d2tm #dune2

Path finding testing is done on a map (64x64) where only 1 possible path exists between two corners of the map. I also found a bug in the heuristic function - it would evaluate too many cells. With that sped up greatly, but still needs to be faster.

Spent more hours on path finding. Still too slow! (100/200ms for 1 unit, finding 1 path is SUPER SLOW (on complex map)). Need to shave off more milliseconds.

It is not so hard to implement a new pathfinding algorithm. The harder part is to make it perform properly. Especially when you send over groups of units. #indiedev #gamedev #dune2 #d2tm #remake

Load More...