​So I have created a first rendition of an AI(picture of myself), as can be seen in the video below it isn't perfect but works for the most part. It is also surprisingly difficult to escape, largely due to the lack of roads. Currently the AI is running based off of where it is in relation to the player controlled character. It calculates which direction it is farther from the user (x or y) and then attempts to move in the direction. If that exact direction isn't available it then goes through a progression of alternative moves, using a lot of "else if" statements (see image below video). I believe this progression is where it is getting stuck and stuttering. 

It appears that it gets stuck when it is approximately the same distance from the user in both directions. This makes me believe that the way in which it works through the various directions conflict with each other and cause the stuttering effect.

To remedy this I am considering either attempting to alleviate these conflicts or by using a depth first search to attempt to determine a shortest path the the user. If I go with the latter I will likely have it set to recalculate after a certain number of "ticks" and between these recalculations to just follow the previous route.

This has been the issue which has piece of the project which has been on my mind since day one, how in the world am I going to keep that character on the road. Well here it is, following the road, it isn't perfect but I will continue to fine tune it as I progress. One particular point of issue was as it got nearer the bottom of the screen my character began appearing slightly off of the road. I believe this is scaling issue probably related to the white bar along the top of the screen. This is another thing that will have to be tweaked.

Now that I have the ability and basic algorithm to keep a character on the road implementing enemy characters should be just a matter of tweaking and altering my algorithms. In addition to creating some sort of "AI" which will control the movement of them.

One issue which I may have to address is the zooming of the map when selecting the location to play. It may become necessary to remove or limit this functionality to allow my algorithms to accurately detect the roads. One idea I have to allow zooming to remain implemented is to scan across the selected area and attempt to determine how wide a road is at the current zoom. This would then go into my algorithm to adjust how is thresholds. I could also just lower the thresholds, which may have other consequences, but would allow for a less zoomed in map. A dynamic solution would probably be much better however.

Over the past several days I have been working on getting everything setup so that the app can successfully follow the roads of the map. The current iteration as seen below is clearly not currently following the roads, this is intentional. Whilst trying to get it moving along the roads I realized my array was not being filled properly so I decided to ignore it and make sure everything else was working properly (directional control, location calculation, updating at specific intervals etc.). It should be noted that all the math currently being used to calculate the location of the character is using the gameArray which will hold data saying if a position is valid or not, it just isn't checking if it is valid. 

The next step is to get the gameArray filled correctly and from there begin to ensure the movement algorithm properly follows the valid locations.

Note: The numbers displayed along the bottom of the screen are temporary and simply display the direction the character is supposed to be moving based off of user swipes.

So the 8 directional input was not quite finished as I believed in the last post. It actually required another 6 hours or so of debugging and maths. First off thanks to John McGorey for his help and expertise in android. Johns help with understanding why my onFling override wasn't being called was crucial in getting this thing to work. Once the onFling was being called I was rather flummoxed as to why my direction was not being calculated correctly and was constantly returning as being a downward swipe. Well someone (me) forgot their programming languages class and wasn't paying attention to the scoping. Hence my variables weren't set and that caused the return to be as such. With that sorted a new problem arose largely coming from my unfamiliarity with Trigonometry, enter Mike Schirger. The way I am calculating the direction of the swipe is by calculating the tangent of the line between the beginning and end of the swipe which gives an answer in radians and then converting that to degrees. I had previously setup my ranges for determining the direction of the swipe based off of an assumption of getting an output from 0-360 degrees. The output instead was actually 90-(90), which obviously caused issues with my algorithm. So the chart below was constructed to alter the degrees I got to fit into my previously created ranges. Thus finishing with a working 8 directional swipe input.

Over the past two weeks I have been working on getting back to where I was pre path failure. The first thing I tackled on the in the new direction was getting my image properly passed onto a new activity (thanks internet for the help). Once that was accomplished my focus shifted to analyzing the map and getting it into a new array which corresponds to the grid that the game will take place on. Whilst working on this I was crashing for awhile which, after hours of debugging, I realized was all being caused by an incorrect variable (so much fun). The algorithm that constructs the array will surely need some tweaking, below is a small scale example of what it does. After getting that sorted I have begun working on the new custom view the game will be played on. I have spent a good amount of time working on the user input which will consist of swipes in 8 directions. This required some deal of math in converting from slopes and radians to degrees, thanks Josh Leach for your guidance on that. The next step is getting this directional input to actually affect the character. 

So, where to begin. Spring break was a nice break, unfortunately I didn't have time to work on this project. Upon my reopening of the project, and attempting to work with paths and get them traced onto the map and being able to have a character follow them, I have found they are much less helpful and more complex to work with than they previously was apparent. One major flaw is that they have no good way to move "backwards" along them, Upon making this discovery I thought, "Surely there must be a way to reverse them or get around this", well so far as I could tell there is no solution which would not result in a horribly complex mess. So there goes however many hours of work and days. 

My new path forward, and perhaps the one I should have been going with from the start, is to simply work with arrays. My first task is to reimagine the map and not have to constantly look at every single pixel for color. To do this I want to break the image I have captured into blocks, potentially 5x5 pixels or so. Then marking these as valid or invalid if the road color, or a certain amount of pixels of the road color, exist within. From there movement will be dictated by user input of 8 directions. By tweaking the size of the blocks and the number of pixels required I believe I should be able to normalize the map to a point where the 8 directions should make the game easy to play. I am also considering attempting to create the algorithm for the movement in such a way that if the character has no blocks to move in the direction it wants and there is only 1 direction, not the previous block, to move it will do so. This could help in solving the curve problem in addition to slightly not straight roads.

One positive to come from the last few days is I was able to create a JSON file to alter how the map design and make it more easily to detect in addition to getting rid of excess labels and such.

Anyway here is a picture of a sunrise from my trip to make life a little better.

Using a matrix and matrix manipulators, postRotate and postTranslate I was able to get an bitmap object moving along a Path. I found some very helpful posts online which were crucial in this endeavor. Below is a video showing a quick rendition of a moth (too small to see) following the path. This upcoming week I will hopefully begin implementing some user controls. 

Today I got a path to be drawn programmatically onto a canvas, and then was able to place a character on said path. The character is not currently moving on the path but I believe I am on the verge of having it do so. Paths appear to be the most promising solution going forward for keeping a character within bounds.

I believe I have successfully created a button to programmatically, however I am not currently able to hide the map to show the screenshot. Or maybe I am looking at the screenshot. I'm unsure but I'm chalking it up as a victory!  

Well, unfortunately this week didn't go quite as planned. I have been otherwise occupied and have not been able to put in as much work on this project as hoped. I have not been able to capture the map through my app as yet. My algorithm to follow the roads has also not made any significant progress. This week I will hopefully capture the map, continue to work and experiment with my algorithm, and if all goes well begin to work on allowing the user to control a character in app. Fingers crossed.