Echoes Stir.

Well it has been a while...Is this blog on. [tapping sounds on a mike]...

I have rewritten my tile prototype and with a small refactor with the animation on an object. I have a workable tile prototype.

Here is a video:

https://www.dropbox.com/s/w4c8dlkhzsp31o8/VID_20140414_221152.3gp

I will type the specs later.

Back up after a needed break

I know it has been a while but I'm back. Work has progressed on the movement system. I will let the video do the talking :) The red box is the screen touch.

The player can detect adjacent zombies and call the player:giveDamage(recipient,damage,time). Tomorrow I will have the first draft of combat. Fingers crossed.

just a quick sketch

no programming today but a quick zombie sketch

                                                 

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.

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.

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. 

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.