My First Go at AI

The main driver my AI routines is the distance the player is from an enemy. The visible board size is 10 tiles now and the total map size will vary from level to level. A distance value of 4 is the starting point for the enemies to activate. It's an arbitrary value an will probably change in the near future after some play testing. The trick here is to balance the timing of the enemy movement with the player movement. Right now they all move at the same speed. See the video below.

This is my first attempt at tracking an object. There are some issues with the AI timer firing while the enemies have a target. For a first pass it is a good starting place.

Everything is going to be event driven. I have 2 timers now. One for the object movement, firing every 2 seconds, and the other one is for the AI to update the movement. Currently the AI has a nasty show stopping bug that I will need to address. When it fires the second time, after a distance check from the player, the Astar start and end values are getting set to nil somewhere. (Print statements here we come). I need to separate the enemy movement out of the object timer and make it independent. The choice I need to make is a hard one. Do I have every object have timed value and a running timer, or several timers at different intervals. I think the latter is less processor intensive and will allow swarms of enemies. A running timer would need to check every object every frame or have a way to register objects and their fire time. Time will tell.

The pathfinding bug is dead...Long live the pathfinding

For the last week I have been sick with a sinus infection and could not concentrate on programming, but yesterday I found the pathfinding bug. It is the small things kill you in programming. When I called the pathfinding method it worked with one object but when I used it on more than one object all hell broke out. Part of it was me and part of it was me and part of it was Codea's debug printouts. The error was with the object using the same path for everythinig. I first thought the list copy function was not working but I was using the same path for everything. A simple change from path = listCopy(path) to v.path = listCopy(path) fixed the error.

The only other bug related to movement is when he map is scrolled the pathfinding checks the wrong cordinates. That should be relatively easy to fix

Fighting a loosig battle with Codea Debugging

If you program for the Ipad with Codea then you are familiar with the print statement. The debug tools is a command line(a good start) and runtime errors that may or may not point to a relative piece of code. As a former Flash programmer I love the flexibility LUA has with data types and functions. I wish I was an uber programmer; to take advantage of coroutines and passing in functions as an argument would rock. But alas, this will not be. I guess the reason for this rant is I hate debugging. It's  probably a sign I'm a smart guy who can program, and not a programmer who is smart. Add in a time based play mechanic that can be real time or fire off timed intervals.

The mantra of every article I have read states, "Build a simple game first". I agree and all, but will I not follow that advice. If i am going to go through this grinder of a process then it had better be worth it.

On the programming front:
debugging the astar pathfinding return value are assigning wrong when called repeatedly.
The aster will not search the correct start and end values when the map is scrolled
Fixed various player movement issues with touch movement.
Decided to not add a mesh pool for dynamic enemy creation.
Enemy AI now knows when you are within 5ish squares of them and call a path to you. then start to move to your location. Still some major bug to squash. Arrrghhhh! So close

Realtime movement is a pain to keep track of

Today I was working AI of the enemies and I have several flags assigned to the player class. Every non-map object is a player and the tileType is keyed off to get see what tile it is. For example,

2 = Player
3 = enemy
4 = open
5 = Point of Interest
...
player = Player(id,tileType,isActive,target,path,pathCount)

The AI checks if the tileType is an enemy and then checks if the the distance to the player is <= the activation distance. The enemy then calls the astar to the position of the player and returns a list of coordinates. This path is assigned to the player.Path list and is updated every enemy clock cycle, currently 2 seconds(enemy speed). When the player/enemy moves path count is updated and the character moves closer to the target. When the target is reached the list is removed. A few bugs not withstanding it works. But when the player moves the enemy AI does not adjust to the new player location. I do not want the enemy to poll the player position every draw call and it would be good to update the pathfinding when an enemy is moved.

I will post a video when I get something working.

Too 3D or Not to 3D

While reading a blog, project zomboid 's I think, there was a discussion on the amount of frames it would take to animate the characters. It was in the thousands. Not even possible on a Ipad. This thought arrived while programming the movement on the game. The current movement is tile based and the character moves the entire width of the tile. See the videos in previous posts. I think I want to have pre-rendered 3d characters, very low poly, and 5 frames of animations per character. It would not be wise to have your first project contain any 3D. Programming is hard and programming 3D, while possible, is harder out of the scope of this project.

I have not written about my background before. I studied fine art at Arizona State University, have programmed Flash professionally and was a professional comic book colorist.  Here is an old portfolio from 2006. http://www.freewebs.com/vidopiac/ My introduction to programming was a Pet CBM learning Fortran and Pascal in the mid 80's. I had a Mac 128 and an Amiga (awesome machine). On the 3D side I am a decent box modeler, and texture artist. I use Modo for 3D and on the 2D side I use Photoshop, Procreate, and Artrage. 

The 3D can be done me, time permitting. 

TO be contiued... Star Trek is calling me.... Phasers on Awesome

More thoughts on movement

This post will be mainly be about player movement. Currently I have the player move when you press to select the player and drag your finger to where you want him to go. This works fine but it leaves your tacticle options at the mercy automatic pathfinding. To fix this I will add the ability to select,an empty tile next to the player, and draw your parth the  player will follow. The tiles will so show they are selected. so you can see the path. To stop the movement early tap the player to stop or maybe drag another path and clear out the old one. It should be easy to implement  and when I get home after work I will try it.

Movement is in with lots of things to fix

It is not as bad as it sounds. I have the Astar pathfinding working with the character and a flag goes off when ever the player walkes over a game object. The idea is every time the game clock fires the enemy will move. The enemies check a random direction to move one square and if that position is a walkable tile then the enemy moves. I need to also check the list of enemies to see they don't walk over themselves or other things that block movement. This is the starting state of an enemy and when they are activated then calculate the astar to the point of interest

I also need to start a thinking about the z sorting of the objects and get rid of some troublesome bugs.
Another video

I speed up the time so you can see them move in the green walkable areas