EDIT: Ooh shiny, a featured page under WP’s roguelike tag. Well I’ve got a newer post up here that’s got some changes from this one, if you’re interested.

Next release is up.

Combat is extremely basic at the moment, and not at all where I’d like it, but I have a change of plans. My code has gotten to the point where, although it makes sense from a “I can follow the dots down the line from player input -> game draws to screen” perspective, it seems like each time I make a minor change, the AI’s following behaivor reverts back to doing something odd that I thought I already fixed. Currently here’s the basic game logic loop:

player presses a key (say, a movement key)

Scene.filterkeys() is called

that calls Player.move():
..player.x,player.y, and world coords are set
..generateview() is called -> screen re-establishes what tiles are where and what they look like

enter Scene.update() loop:
player.update() called:
..nothing relevant happens, oddly

tiles update:
..nothing important, just sets up which tiles are dirty for dirty rectangle updates

checkentityvisible() called:
..if entity in list is within bounds of the screen, add to livingspritegroup

set a matrix according to each tile's blocking status within the viewable screen

..do a floodfill of "scent" for collab diffusion followers to hone in on

update livingspriteGroup:
..move according to scentmap/generateview() changes

draw everything

exit update, await next input

Its mainly the latter half of the set, where the miscellaneous functions (scent map, etc) are called is where things get messy. At this point I’m going to get down to finding out how to simplify and unify (and probably rewrite) everything, particularly in terms of collision. “When is collision handled?” is not a very easy question to answer at this point in time.


2 Responses to “0.0.6”

  1. georgek Says:

    hi, I found Graff on WP’s roguelike tag. Your sketch of the logic there is interesting as I’m in the middle of my own beginning programming/roguelike efforts.

    This is what I do:

    1. player presses a key. If it’s the escape key, exit the program, otherwise go to the game.update()

    2. currently, the player always goes first in the update loop (if it’s their ‘turn’ — I use a phase speed system, so the player doesn’t get a turn on every iteration of the main game loop).

    3. the game runs the player’s command; I don’t trap bad input yet (i.e. keys with no associated commands) and right now the only command is movement.

    4. the instance of the Command class checks if the target cell is walkable and doesn’t have a monster in it. If so, the player’s coordinates update to the new position. Therefore collision is always based on what the player currently sees on the screen.

    5. every other thing that acts in the current turn (depending on its speed) then takes its turn. Also whatever handlers are attached to things run their updates. This includes the player.

    This is when I update the player’s field-of-view, and this fov always is updated first. Like you said, this is where things get messy; it doesn’t matter currently as monsters don’t block fov and can’t take any other actions that change fov (like closing doors). The simple fix will be to ensure a player’s fov always is updated last, so it uses the latest information of the monsters’ actions.

    As to the monster’s themselves, I’m just not going to worry about it unless it becomes a problem. If they take their turns in order some of them will act on ‘unseen information’ before the next screen update, but I have a feeling this won’t affect the gameplay a great deal.

    6. draw the screen

    • hahn Says:

      Hey, thanks for checking out this blog. 😀 I’ve got a newer post up that shows a slightly changed game loop in case if you missed it.

      But yeah, FOV and a turn system are probably going to be the things I’ll try to implement soon. As far as the unseen information goes, the way I’ve dealt with that on my end is by using a limited floodfill of the game’s map from the target’s current position. It’s a little slow for now, but essentially the flood fill fills the map with scent values that radiate out from the player, and they stop if they hit an entity–wall,door,tree,etc. That way when it comes time for the monster to update, instead of possibly having unknown information, all it has to do is move to a tile with a higher scent value, and do a collision check to make sure no other entity got in the way first.

      The missing part of this though is target acquisition–it’d be pretty boring if everything in the entire world only worked on chasing the player, and having the player run across a brawl in a town or something could be interesting.

      For your first few parts of the loop, when you check for the escape key, a way how I set it up so that the player doesnt accidentally quit out, is start before the game is initialized by setting some boolean to some value and check it when the player presses escape. IE:

      i = false
      begin game loop:
      if player presses Escape key:
      —if i = false:
      ——i = true

      Then set i to false whenever a key besides escape is pressed to reset it. Then within that I’ve got a text manager set up to handle “Are you sure? Y/N” things and so on so they player doesnt just get confused. Feel free to use the general idea if you want. 🙂

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: