Sunday, 8 January 2017


As a new year's resolution I have started to find solutions to difficult problems which are often left to be "done later". One of those was traps that had the trap effect and mechanism in the same class. For a long time I planned to create separate classes for those and currently implementing it.

The new Gadget class is the visible part of the trap, like pressure plate or holes on ground. Gadgets are not always traps, the pressure plate can open a nearby door for example. Traps can be also attached to other items than gadgets. This was the reason I had to move traps from game object system to a composite class. The procedure or refactoring is anything but simple. I don't think there is a nice, clean way to determine which gadgets or target objects can be attached to which traps. It's probably going to be a manual list of traps for each type of game object which simply means I have to forget data-driven approach in this case.

With a gadget or other host mechanism the traps could be changed to more abstract form such as gases, spikes, falling objects etc. so for example you could have a classic water bucket placed on top of a door.