EverEnding DevBlog 136: Foretold


I started working on all of the behavioral programming stuff, then I got completely sidetracked for a couple of days when I realized that I didn’t have any centralized document with all of my story content in plain language. Up until now I’d gotten by pretty much keeping all that stuff in my head, and occasionally writing down bits and pieces of it, more often than not in the form of stories which were more metaphorical than accurate to the reality of what’s supposed to be going on in the story. This, I realized, was making it difficult to append to the story and to plan out how I was going to tell it, because I had no centralized resource to refer back to to make sure I wasn’t contradicting myself. It took me several hours to write it all down and it ended up being more than 3,000 words, which is a pretty good sign I should have done it sooner. It’s still somewhat subject to revision, but revisions should be more along the lines of expanding and going into more detail about unclear concepts than changing the specifics (unless I come up with a really good idea, of course).

After that I went back to programming the behavior of these entities, and I found that both my production planning using Trello and the detailed story breakdown of the last week or so of work came in very handy, since I immediately found myself breaking down all of the behavioral specifics that had been confounding me into a set of relatively easy-to-manage behavioral states. Thus, rather than trying to think of the behavior of these enemy types as an impenetrable wall of if-then statements, I can parse this behavior much more readily as a set of simpler behaviors that switch to other simple behaviors based on the input. So, for instance, I can have a patrol state that does nothing except walk forward, and then have it switch to either an idle action state at random intervals, a turn around and patrol the other direction state if it hits a wall or the edge of its patrol radius, or a pursuit state if it sees the player. At that point, all I have to do is write the 5 or 6 lines of code that control each state and the entity should work.

I have the basic version almost up and running, but the code to handle when and how to attack is still a bit tricky since it deals with the specifics of positioning which vary from attack to attack. All of the movement stuff is pretty much there, though it will inevitably require some debugging, and I still need to generate the timing info for things which rely on a timer (attack recovery, patrol delays, alert time, etc.) I think I can finish up the basic behaviors tomorrow, at which point I go back and do all the prototype animations needed to fully animate those behaviors – after that, I go back in and add all the code in for another version of this enemy, such as the scout or rider variants, and then I make the animations for them – and so on, and so forth, until they’re all done.

Making future enemies should be quite a bit easier after this, since I think these will be by far the most complex of any non-boss enemy in the game. Even for cases as intricate as this, in the future I’ll have these guys as a template to work from, so I expect any future problems to be quite a bit more approachable.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: