Thank you for your donations!   Download the book!   Public source code repository  

No title, just plans

Since my last post I changed Serpent to displace only Pawns, not all of pieces. I deem change necessary, otherwise Serpent would be able to break any formation, not just Pawn fortresses, which would be a little too OP. Breaking Pawn formations is good though, it opens up gameplay, and effectively limits static play.

This goes in as a preparation for another planned change, movement of Serpent should be unrestricted. Currently, there is some arbitrary cap in play, and you already know how I dislike arbitrary designs. So, plan is to remove cap, but also forbid loops. So, Serpent could visit any field, but only once in a ply.

Before you ask, Wave activated by Serpent will stay limited to two initially chosen directions. If I'd allow for such a Wave to move as unrestricted Serpent does, it would have half of a chessboard at its disposal, because Wave is transparent, and does not spend momentum while moving. Which all means, Wave activated by Serpent would be way too OP. So, that restriction has to stay where it is.

As for immediate to-do, I'll change way Shamans get into trance-journey. Currently, I sort-of abused Waves to activate the other Shaman, which can then optionally go into trance-journey. I'll simply relieve Waves from that duty, and have one Shaman directly activate the other one. This all will be done on neighboring fields, i.e the ones which are not step-, not capture-fields of neither light nor dark Shaman, so it'll be very specific, and very special movement.

Reasons for the change, you ask? For one, it provides build-up to trance-journey, and a warning to the other side what a player is up to, and also provides (a little) room to counteract. This is also similar how Shaman captures opponent's pieces; first it has to close a distance to its prey, then in next move it can go capturing. Second, trance-journey is now deliberate move, not optional, mixed with other side-effects. And this also makes it so much easier to figure out in parser, analyzer code; all good in my book B).

One thing that still hasn't clicked the right way is how Starchild is  activated, namely separation between activation on step- and miracle-fields, combined with all the other Starchild rules, and exceptions to them. Sure, it all have logical explanations why they are that way, that doesn't make them right. So, I'll probably have to revisit those, before deciding what to do. One option is to forbid Starchild to be activated at all, that would simplify designs, and since Starchild still has a lot of other own stuff to do, that might not be too much of a loss.

Another thing that I stumbled-upon is a realization that complex mechanisms are not explained properly, i.e. one simple mechanism at a time, and only once. I figured out, I have a tendency to stuff all of mechanics into one example, and then repeat that poorly explained mechanics over-and-over again. No good. I mean, that was main reason why I rewrote Miranda's Veil. This is, of course, completely my fault; such is a price of learning things by doing them.

But now, it left me wondering, what if I revisit all of examples from the very beginning, and rewrite all that needs to be redone? This can be done, and I think I should, since it would make the book so much better. The only problem I see is that it'll take months to finish, quite possibly to the end of a year. Again, this is something that I won't be rushing into, I'll take my time to decide if, and when I want to take the plunge.

Just to clarify, complex should not be confused with complicated; complex things are comprised of a few other, smaller things, all of which are -in, and off itself- simple. Complicated things are just spaghetti-designs, many things arbitrarily bolted on top of each other, without any regard for consequences.

No comments:

Post a Comment