Geeks With Blogs

News

Google My Blog

Catch me at: The List!


My InstallScript Utility Belt My Amazon Wishlist
My Standard Disclaimer


Archives
Chris G. Williams Beware: I mix tech and personal interests here.

If you're too lazy to type in a name when creating a character in HA! I give you one randomly chosen from a list. Sometimes it's the name of a friend, like Robin, or it's androgynous, like Pat. Sometimes it's just silly, like TinkyWinky or IneedaName.

So lately, in an effort to test and refine the autowalk feature, I've been creating a lot of characters that I didn't care much about. As with most manual testing, you often discover stuff along the way, while focusing on something else entirely. I've discovered a number of things while banging on the autowalk code.

  1. I need a longer list of lazy names.
  2. the game is too damn hard for 78% of the character classes available. Technically I knew this, but dying 3 times out of 4, before even getting a chance to TRY autowalking really drove the point home.
  3. I had started implementing "corner" tiletypes, but hadn't finished it. I found this by occasionally seeing a message that said "Thud! You run into the " instead of "Thud! You run into the wall." That's been corrected.
  4. The action order (initiative) doesn't make good sense, and won't scale well. Like most turn-based games, nothing happens unless the player provides input (by pressing a key.) We have a basic initiative system where the character takes turns with the monsters, some faster than others. Currently the moster initiative is recalculated POST player move, every turn. As the game matures, it is inevitable that some creatures will be significantly faster (or slower) than the hero, and this method will no longer work as intended. I need to refactor this so the hero is presented a turn at the appropriate point or points DURING the initiative cycle, not before it.
  5. coming up with the autowalking code is frickin hard!! There's a lot going on. More on this below.

The first challenge was injecting autowalk commands into the loop without requiring additional input from the player. Since nothing happens without input from the player, I have to simulate that input. The easiest way to do this was to provide a keybound command ('w') that prompts the player for a direction. (This is based on the standard numeric keypad with 123 at the bottom.)

Once a general direction is determined, the fun part starts. Since we want the auto actions to behave the same way as if a player had actually pressed the key, we need to trick the loop into thinking that's what happened. The easiest way I could think of to do this was to set a flag, wrap the player input code with a conditional statement that checks that flag and then bypass the player input, assigning my own values (more on that in a moment) to the variable that would normally hold the player input... then the game processes that input as normal... in theory.

Actually that's almost all there is to it, if you just want the hero to walk infinitely in the direction indicated. In my case, I expected a bit more of my surrogate player. Some of the behaviors I require are below. The hero should:

  1. stop just short (adjacent) of colliding with an obstacle (like a wall or closed door)
  2. stop one step back from an intersection or open door (anywhere a choice should be made)
  3. stop two steps back from any hostile encounter (this means monsters, NPCs, etc)
  4. stop just short (adjacent) of any nonhostile encounter (townspeople, nonhostile creatures)

  5. if in a room, continue in direction indicated until any of the above occur
  6. if in a passage, follow passage regardless of direction until any of above occur (requires changing direction as needed)
  7. if autosearch or autoget are enabled, those behaviors will be observed too
  8. if a key is pressed during an autowalk sequence, control is returned to the player.

This involves a lot more than you would think from such a short list. There already exists logic to handle collisions with inanimate objects such as walls and closed doors, and of course running into a monster initiates combat. What I didn't have, was logic to detect things like corners, turns, intersections, etc. I didn't NEED to detect these, since the player could plainly see them onscreen and choose how to interact with them.

The first thing I tackled was detecting pending collisions. I say pending, because I didn't want the hero to actually walk into a wall and then stop. That would be silly, and it would also generate a "Thud!" message and take up a turn. None of these are desirable. Instead, I used the same routine to detect if a hero actually walked into an obstacle, only I called it before the pending automove instead of after. If the next step would cause an impact, I simply stop the autowalk loop. No "Thud!" message or extra turn. At this point, control returns to the player.

Now that the hero can stroll across an empty room, or down the straight section of a hallway, we can check off the first one. The next thing I worked on was a little trickier. Basically I needed to detect an opening near me, based on a specific configuration of walls. For example, walking down a hallway that ends in an open door was easy. I simply checked to see if the tile directly ahead of me was open (passable), and the tiles on either side of it, and me, were not. If this was the case, it indicated the end of a hallway and I stopped moving the hero, returning control to the player. This gets a lot more complicated when the wall configuration is less predictable. For example, if the hero is moving through a room, alongside a wall, and comes to an opening, the same rules no longer apply. By the same example, if the hero is crossing an L-shaped room, there is yet another set of criteria.

I've found, at times like this, you need two things: 1. a LOT of patience for debugging the various configurations and 2. a spiral-bound graph paper notebook to quickly illustrate each configuration as you discover it and code it in the detection routine. You would be amazed how much the second one helps.

Ok ok, so I'm still working on the second one, and will be for some time. It's an ongoing process of refinement. Skipping down to the third item on the list, this one was fairly easy. Using a similar concept to detecting walls, I look at a different property of the maptile and see if there is a monster in a given location. Using the hero's current X,Y location on the map array, I can look two cells in every direction to se if there is a monster. If I find one in ANY direction, I stop the autowalk loop. There are a couple noteworthy things here: 1. I look two squares out, checking BOTH squares, not just the outer one, in case a monster somehow slips past it for whatever reason (the monsters move too, ya know) and 2. I also look "behind" me and to the sides, in case something faster than me comes up behind me, or an incorporeal creature steps out of a wall somewhere. Stopping the autowalk before combat ensues give the player a chance to make a choice about how to (or not) approach what might be a significantly stronger creature.

I haven't started the fourth item in the list yet, because there aren't any nonhostile creatures or townspeople yet. So we'll revisit this one later.

and that's enough for this time... I'll have more of a progress report (and maybe even a build) next time around. Posted on Sunday, March 18, 2007 10:25 PM Game Development , General Interest , Heroic Adventure! | Back to top



Comments on this post: TinkyWinky takes a walk... (aka AutoWalk part 2)

# re: TinkyWinky takes a walk... (aka AutoWalk part 2)
Requesting Gravatar...
Wow! That was an awesome write up. Made me want to go play around with auto-walk and all it's accompanying logic.

Looking forward to seeing how you finish this feature up.
Left by George on Mar 19, 2007 9:26 AM

# re: TinkyWinky takes a walk... (aka AutoWalk part 2)
Requesting Gravatar...
Sounds great boss. I bet that piece to detect the open spaces will be a HUGE pain in the bottom to get right. Autowalk will be an excellent feature...until I run into a trap....

:-S
Left by INeedaName (Theo) on Mar 19, 2007 9:42 AM

# re: TinkyWinky takes a walk... (aka AutoWalk part 2)
Requesting Gravatar...
Well when the game's creator says it is too damn hard, then I don't feel so lame that I kept dying when I was testing it out a while back :) And here I thought my RPG-Fu was lacking...
Left by Lou on Mar 19, 2007 2:35 PM

Your comment:
 (will show your gravatar)


Copyright © Chris G. Williams | Powered by: GeeksWithBlogs.net