search

Enigma-Game / Enigma

Enigma is a puzzle game inspired by Oxyd on the Atari ST and Rock'n'Roll on the Amiga. The object of the game is to find uncover pairs of identically colored Oxyd stones. Simple? Yes. Easy? Certainly not! Hidden traps, vast mazes, laser beams, and, most of all, countless hairy puzzles usually block your direct way to the Oxyd stones …
GNU General Public License v2.0
134 stars 38 forks source link

Actor-specific behaviour or lack thereof: bugs, horses, movement automation etc. #77

Open Taemporus opened 2 years ago

Taemporus commented 2 years ago

To begin with: this is not a bug report, rather a proposal for a feature (or an inquiry about design intent).

Right now, we have two passive, immortal actors — ac_horse and ac_bug — that have few characteristic features or interactions with the player. While it has long been stated in the reference manual that ac_horse was/is planned to be rideable, that has never come to pass, and seemingly the only trace of that is the ability to set a path on which it moves on its own (via attributes like destination). This is indeed a unique feature, but in the current state, it feels arbitrary that only ac_horse should have it.

Let us summarize what these actors do: ac_bug ac_horse
immortal, usually passive immortal, usually passive
small size and mass large size and mass
breaks st_break_bug passes through st_portal_horse
movement can be automated

So aside from the relatively niche interactions in the fourth row, we basically only have the automation capability (where it is unclear why only the horse has it), and in particular ac_bug doesn’t seem to have really found its own place in the game.

One of the most painless ways to remedy this somewhat would be to extend the attributes enabling movement automation (destination, destidx, loop, strength, steady) to certain other actors: this requires basically nothing other than copying a bit of code. In particular, there is no reason why a “bug” should be able to move around on its own any less than a “horse” would. While this would in fact make ac_bug more similar to ac_horse, it would at least have more usability (and it being a smaller, visually distinct analogue with slight quirks is not necessarily a bad thing either for how the overall design looks).

Of course, the question then presents itself whether other actors like ac_killer, ac_marble, or even ac_pearl should likewise have these capabilities (ac_rotor and ac_top almost certainly should not, since they already have an expected behaviour in regards to movement). Right now, in levels where these actors need to move in preset ways (e.g. “Unfair!” and “FizzBuzz”), things such as slopes (hidden or otherwise) need to be utilized. It might make sense to have such on option to control them properly enabled, but if that were to be the case, it would eliminate the main differentiating feature of ac_bug and ac_horse.

In my opinion, the ideal scenario would be to add these attributes (destination etc.) to all actors that aren’t usually active on their own (so anything other than rotors and tops), implement the riding behaviour for ac_horse, and figure out an additional unique feature for ac_bug. However, this would of course be much less trivial of a change than simply adding the already existing functionality to another actor or two.

Also, any part of these proposed changes might conflict with the design goals of the game developers. So mainly, I would like to know their thoughts on this (or that of anyone else interested): what part if any of all this might be worth considering in the short or long term.

alochmann commented 2 years ago

Hi,

the code for automatic movement of ac_horse was implemented by Ronald Lamprecht. I do not quite remember his reasons ... actually, he did not have to state a reason, given that he was the project leader at the time. However, I think his motivation for implementing automatic movement for ac_horse only, might have been:

  1. That's how Oxyd handled it.

  2. ac_horse looks distinct enough for players to assume a different kind of movement behaviour (an argument akin to your reasoning about ac_top and ac_rotor).

  3. If something was faulty in the code, it would affect only a very small aspect of the game, rather than all actors at once.

Personally, I would have implemented automatic movement for all actors from the beginning, including ac_rotor and ac_top (look at "Pac Marble" and you'll know why). However, I do respect Ronald's more conservative decision and would look at a change with more scrutiny than usual.

In my opinion, argument 1 has lost importance in the last 10 years. We are still interested in adding the missing parts of Oxyd emulation in Enigma, including riding, but it's not at the top of our agenda. Argument 3 ... well, if the code were faulty, we should have seen it by now. I guess, Ronald's code is indeed quite stable.

Argument 2 is more difficult to come by. I am a little unhappy about the sheer number of unexpected and surprising interactions in Enigma, as this complicates the game for beginners; then again, this is part of the very core of Enigma. "Unfair!" prepares the player via the initial it_document. "FizzBuzz" uses visible gradients, so the movement is easy to understand for the player as well. And while marbles and pearls are inanimate objects in real life, bugs certainly are not, and autonomous movement can very well be expected.

I am open to a change, in particular regarding ac_bug. I want to discuss this topic with some of the other developers and hear their opinions.

Cheers, Andreas