So Defensive

Yesterday I finally got the backing up thing to work right. Peviously they would just stop for no reason and, gods help me, it looked and worked like ass. Now it's better. I gave the enemies a distance (a modifiable one at that) to back up and a period of time. So, they will back up until they get to a certain distance outside of a range established by the player's location, or for a certain time, whatever comes first.
I also got cute with the Ledge Finding Function and spliced it into the Backing Up code, so the enemies will not fall off of ledges when they back up. I added that because they would back up off of stuff and hillarity would ensue. So that works now. Of note, the Ledge Finding Function works best as a part of a different function, like the walking around or backing up functions. I can skip it for things where I want stuff to fall off. When enemies are hurt for example, they should fall off of stuff, possibly to experience pain/suffering and the unique sensation of falling from a great height.
Moving forward, most of the rest of the AI functions are State Based, and do not have specific actions associated with them. They don't back up, move around or be difficult, they just are. Blocking is just that, Parrying is a stance and so on. The rest should be easy in part.

They are tricky in whole though, which brings me to an idea.

I'm going to have to write down the system so I can build from it. Everything else I've been able to test and tweak until it feels right, but the AI Action Chains are too complicated for that to work. So, I need to write it down.
To that end, I'm going to write that part of what is considered the Design Document (such that it is) and keep it updated as I go. For the sake of you, dear reader(s), I'm going to make the whole process public. So now, in some small way, you can see what actually happens to one of those things through the process of making it work. Generally speaking, the Design Document is the thing for game design and game development. It's like the CIA NOC list, sharing Top Secret clearance with the Source. It's made more important because of all the things in it that don't make it into the game, the secrets that may someday be in other games or projects. Consequently, you never see the Design Doc for a game in development and you rarely see them even after the game is all done.

So, I'm going against the grain here and doing something bordering on stupid. I'll get that up as soon as I write it, probably over there -->

...and there we go. For those of you that have never seen one of those before, you'll notice a few things. There are no pictures. There can be, and often are, but in a part like this, describing some underlying system in detail, pictures are useless. Also, there are no numbers. I use one once as an example to illustrate the concept, but no numbers, no stats. I describe how it should behave, not explicitly how it does it. Programmers (like me) work that out at a code level, Designers (also like me) then go in an tweak the numbers and make modifications to get it to work right and Balance it. Numbers will probably appear later, but at this stage, they are meaningless.
Finally, the language is straight forward and descriptive. You will never see, "And it's the bestest thing in the Universe! Then you press some buttons and you have an orgasm in your brain!" unless of total scrub "rote" it. Simple language carries the day. Use as many words as necessary to convey the idea as cleanly as possible, but try not be verbose. There is a real trick to writing a Design Document and making it so that anybody else on the damn planet can understand what you mean.

You'll also note that there is a Glossary. This is not common for Design Docs, but I like them. I keep it updated with the rest of the paper. Especially if I use specific language in the doc, or frequently reference a common concept. Usually, the Glossary would be larger, but this is a small piece of one. I would also pepper the thing with quick links and so on if it was bigger, to make it easy to get around it and find useful stuff. That's the programmer side of the brain wanting to make stuff work better.

So, that's what it looks like now. I'm a little staggered the piece is so damn long. I wonder how long the TTT document would be if I wrote it out first. When I update it I'll use a different color or something. This also provides me the context to rant about these things. Something new to spew vitriol at is always welcome. This may be interesting.