Thursday, June 20, 2013

I just took a break from the "code"

For anyone who finished a large programming project my hats off to you. I saw the forrest of my doom... regrouped, and formed a frontal attack. I hacked in some combat, mostly finished the anination class. The zombies will attack and destroy doors if they are chasing you. There is no visual cue to show damage being taken and I will need to make some temporary visual for that and I must seperate the movement of the player and the enemies to seperate timers.

I used my first method with varargs for this. So, player:adjustDamage(-1,-5,2) will pass a list{-1,5,2} as an argument to be added by the method function Player:adjustDamage(...). This rocks. A good example of it's use is damage to a zombie standing in fire and being shot while eating flesh. From the previously defined adjust:damage(-1,-5,2) we see the total adjusted damage wound be -1 + -5 + 2 = -4. It makes damage a number to be generated in the weapon class and environmental class. I will not have to write(accept in this example): if fireDamage ~= nil then totalDamage += totalDamage fireDamage end. I need see if I pass in a list will it make a list out of my varargs, or can I just loop through the passed in variables.

I will have a video soon and I will demonstrate some combat.

Friday, June 14, 2013

The need for animation states

I am modifying the animation class adding a nested list of the animation frames with a string labeling the animation name. For example, createAnimation({player,"walk",vec2(1/10,9,10),vec2(2/10,9,10),vec2(3/10,9,10),animationSpeed,
                             isPlaying},
                            {"attack",vec2(4/10,9,10),vec2(5/10,9,10),vec2(6/10,9,10),animationSpeed,
                             isPlaying},
                            {"idle",vec2(4/10,9,10)animationSpeed,isPlaying}})
Each vector2 is one location of the UV map and the string is used for targeting the animation cycle. animationSpeed is pretty obvious and isPlaying is the flag to run the animation. This gets added to the player object, defined as the first argument of the method, for easy reference. It is a bare bones animation system that checks the passed frames for the animation timing. So, an animationSpeed of 30 would be a 1/2 second at 60 fps. Once I have the control of the animation refactored the interface need some love.

I really need to address the interface elements sooner rather than later. I have the square you touch highlight, and if you drag your finger around will snap to the corresponding square under your finger. It has a good feel to it :).    Not enough change to post a video but the it is first interface element I have build and many integration questions have come up. That will need to be another post.

Wednesday, June 12, 2013

The Trouble With Doors

Using a tilemap to generate large maps is awesome, but there are some drawbacks too. The first drawback is doors. My first iteration of the map needed a hall to connect one room to another. This illustration proves this point.


My first pass at a map with a more schematic view introduces the door factor. I am glad I took some time to generate this graphic because now a door can be on any side of the tile.


Each tile can have the potential of a door on any of it's 4 sides. A tile will need to have a door property, up down right left, and will have some logic to determine the players direction going through it. The door, nearest the player is looks similar the the above map accept it only takes 2 tiles instead of 3 tiles to display. An open door will be considered open for shooting Line of Sight and for movement but a closed one will block both. This creates some issues with the pathfinding because now a tile can have a enemy in it and not be passable. Hmmm. I think a second pass checking the property of the current tile and the next tile in the path list, with some condition statements, will fix this. Looking at shared walls more pathfinding issues based on the grid show up. I will need to come back to this or scrap it for this version.  On second thought...doors are OK, and shared walls are out. 

Thinking more about doors and walls I will come back tp both later. I need to keep focused in finishing the the ai, game goals, bug fixing before I change the scope of the astar pathfinding. 

Sunday, June 9, 2013

It was supposed to be just a bug squshing day, but...

I started with the desire to squash some bugs and then worked on some prototye placeholder art for the zombies instead. So, here they are


It took about an hour for them. I am going to integrate them in the game now. I was tired of looking at red Z's all the time.

Here is the first implemention of the zombie tiles.


Now I need to update the Animation class to use more than one animation list of frames

And now there are 2 zombie types.


Friday, June 7, 2013

One last Pathfinding Bug to Fix

The enemies, within a specified distance, will move to the players position. The AI Update searches  every 3 seconds for the player and if the player is not found then they will move a random direction. There are few issues I need to resolve. First, the path finding chooses a path that ends next to the player and not the exact position of the player. This is OK for now because the player and enemies will not occupy the same tile, but needs to be fixed. Secondly the player and enemies move on the same timer causing their movement rates to be the same. Separate timers will give me better control over them. The last thing I need to fix is the AI should not move a random direction if it is within the AI path finding radius or moving toward the player.

Things I need to implement:
I need to think about how sounds will effect the AI
How to have attractors lure the enemies away.
Make enemies and players not walk over each other
The art direction of the game
Combat
Interface
and the actual game play
Here is another video
.