Jump to content
  • Advertisement
  • entries
  • comments
  • views

Zoom + Combat

Sign in to follow this  


  • Implemented dumb AI for zombie
  • Implemented "combat"
  • Added zoom ability


    map is probably a bit too dark I should light it up a bit.

    Zombie AI

    The zombies move towards the player if they can see the player. If the player goes out of view they move towards the tile they last saw the player on. After 20 turns of not seeing the player they "forget" about the player and revert to random walking. Zombie brain code below. I am hoping I can keep the entity AI code fairly concise and highlevel with the bulk of work being deferred to lower level methods, such as Entity::MoveTowards(Tile), Entity::IsVisible(Entity) I have used below.

    Tile lastSighting=null;
    int memory = 0;
    //called when it's the zombies turn
    public override double Update()
    //if can see the player move towards player
    if (IsVisible(RpgGame.Player))
    //remember this sighting of the player
    lastSighting = RpgGame.Player.Tile;
    memory = 20; //fresh memory of seeing the player
    //move towards the player. This becomes an attack if the zombie attempts to move into the player's tile
    return MoveTowards(RpgGame.Player.Tile);
    //zombie cannot see the player
    //if the zombie can remember where it last saw the player move towards that location and wait there
    if (memory > 0)
    memory--; //zombies are forgetful
    return MoveTowards(lastSighting);
    //zombie cannot see the player and cannot remember ever seeing the player
    //default behavior is to move about in random direction
    return Move(Map.GenerateRandomCompassPoint());

    One TODO above is that I have the player set as static so all the zombies can look for the player. Really though the zombies and all other creatures should scan the tiles around them and spot the player (and anything else) rather than having it hard-coded like this.

    Also the MoveTowards(Tile) method happens to be flawed and needs fixing as zombies easily get stuck on walls.

    AI should probably be handled by a separate class so that similar behavior can be shared by different creatures. I imagine a lot of creatures will have a brain like a zombie.


    It's not really combat, entities start with health, if an entity moves into a hostile entity it does damage to that entity (so the zombie AI which moves towards the player covers this). When an entities health reaches zero it dies. Dead entities de-register from the timeline (they aren't given anymore turns) and become part of the tile's floor items rather than being the tile's occupant. This allows other creatures, including the player, to occupy the same tile as a dead zombie. Floor items are drawn behind the tile occupant. Big flaw at the moment is you can't see damage being done, or even see that the zombies are hitting the player.

    Zoom ability

    So far the camera has been fixed 10 units away from the screen, the FOV is 45 degrees and the resolution is 800x480 (yes that's a bit weird I should correct that - at the moment it's running in windowed mode not full screen). This meant the screen could only fit an approximately 15x10 tile area. That's a bit restrictive. Now that I am being chased by zombies it's useful to see a larger field. So I added the ability to pull the camera backwards and forwards. It's a bit jumpy because it moves it back and forth in discrete units. Ultimately it might be better to have different zoom levels, eg near, medium and far where far would be a kind of distant "map view" that isn't really playable.

    I immediately discovered that when I zoomed out the map was still only being drawn as a 15x9 tile area and there was a large gap at the edge of the screen where nothing was being drawn. Idiot, I forgot I had hard-coded the 15x9 area. Now I had to calculate the amount of tiles that need to be drawn on the screen at different zoom levels. If I need to draw a 15x9 tile area when the camera is 10 units away from the screen, how many do I need to draw when it is 15 units from the screen?

    I could trial and error and hard code more values, but then I thought what if I change the screen resolution or want to change the FOV? I figured I needed calculate how many tiles are on the screen from the screen resolution and FOV and camera distance.

    So take this example. 10 units away from the screen with a 45 degree FOV is a triangle like this.
    After relearning trigonometry yet again (why can't I just remember that stuff?) I worked out that half of 'w' is the tangent of 22.5 degrees multiplied by 10.

    So w here is 8.28. Because a tile on the map is a unit squared this suggested to me at 10 distance the map needed to be drawn as a 8.28 x 8.28 tile area to fit the screen. Well round it up to 9x9. That matches what I found necessary for the height part of the map, but not for the width part. 9 tiles is woefully short of the 15 tiles I found necessary to keep the screen filled.

    It's probably because the screen width is larger than it's height. The resolution is 800x480 right? So I spent a good hour guessing and cursing at how any of my attempts to fit a 800x480 grid into the calculation didn't fix things. I would have read a manual but it's one of these problems where I am not sure what to search for short of taking an entire week reading everything.

    Then I just happened to be looking at the GraphicsDevice.Viewport in intellisense and noticed the property AspectRatio set to 1.66666. This is because 800 divided by 480 is 1.66666...

    So it was obvious. 8.28 times 1.67 = 13.8, which rounding up matches the 14 tiles I found necessary to fill the screen. So I guess the height, being less than the width doesn't have any ratio applied but the width does....

    Then I thought, wow I better write this all down so I don't forget in future. So I opened notepad and began writing a note wondering whereI could put the note so I can find it again. If only I had a central place somewhere where I could write stuff like this down so I can go back and review it in future...some kind of journal...that's idiot x 2 today.

    Things To Do

    Partial list of large pieces of work that are on my mind that need doing. Doesn't include an abundance of stuff I am probably oblivious to.

    • Inventory system. The player and other creatures need to be able to carry stuff, pick stuff up, drop it. Supposedly there are weight restrictions or space restrictions. Then there is wearable stuff, eg armor, which is kind of like a slot-based inventory.
    • HUD. Displaying player stats (health, etc), inventory browser, equipment browser (stuff the player is wearing). Allowing things to be moved between inventory and what the player is wearing. When picking up items from a chest you need an inventory screen displayed for the chest, but also the player's inventory so that things can be transferred. Do you also show the player's equipment screen so they can put stuff on? Screen space will be an issue and messing it up will detract from gameplay.
    • Action feedback. Adding combat highlighted that some kind of feedback is needed. At the moment you can't tell if the player gets hit by an enemy. Their turns are instant and silent. There could be a text log saying "the zombie bites you", but perhaps there needs to be some kind of "animation" like the player's image flashing red. That would require turns to last a little longer in order to display the transition. Also when I set the zombies to move 3 times faster than the player so that they move 3 tiles every time the player moves 1, it looks like they are jumping. There should be a smooth transition so you can see the path they take. Again that requires some kind of delay during the zombie's move so you can see them moving.
    • Some kind of efficient field of vision algorithm for creature AI so they can spot hostiles or other interesting things that come into their field of view. I guess I might as well replace the player's field of view algorithm too.
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!