The sprites remind me of the original Lemmings game. I'm loving it!
You're the *third* person to tell me that, lol.
I guess there's only so many ways to animate a 7 pixel high character.
The projects looks really cool!
Out of interest, could you explain a little more about how the path finding works? I have never implemented A* before, so I don't know, but would performing A* path finding on 5k entities usually perform poorly?
I ask because I will need to eventually implement some kind of path-finding in my current project and am just now looking into the different options. Are you somehow pre-determining and storing known paths (you mentioned getting rid of extra un-needed data) ..
Best way I can think to explain my pathfinding is:
1. My pathfinding works by storing a ton of 0, 1 and 2s in a 2D byte array that's the height/width of the map. 0 is an unchecked tile, 1 is a tile needing to be checked and 2 is either a blocked, or already checked tile.
2. It runs a large while loop (the biggest resource hog), in that loop, the very first run, it only checks the destination tile
3. When it checks the tile, it then checks the 9 tiles around it and "parents" those tiles to the destination tile (Points an arrow to it, as seen in my visual example above)
4. Stores the coordinates and parent info of each checked tile into a master ArrayList used for later.
5. Then, it checks all 9 tiles *just* checked again, looking at the 9 around it. Any tile that is marked 0 in the byte array then has it's coordinates stored into the temporary ArrayList to be checked on the next cycle.
6. Next cycle runs, it checks all the coordinates stored in the temporary arraylist, and repeats all the steps over and over expanding out it's search pattern. Since it ignores blocked tiles, when you visualize an animation of this process the arrows look like water flowing through the map around walls/cliffs/etc.
7. As soon as at least ONE arrow touches the starting point (remember, we started this from the destination) the while loop stops, and calls that arrow the "shortest route".
then.. it builds the path (using the master ArrayList from step 4)
1. It takes the coordinates in the ArrayList for the path that contacted the other end first, and asks what it's parent coordinates are. Stores the data of the current block in a final ArrayList.
2. Repeats again on the parent coordinates.
3. Repeats over and over until it tracks all the way back to the destination.
4. Takes that ArrayList of coordinates it built, and returns it to whatever class was asking for the path (the entities usually) to be used to actually walk the path in it's own code.
Here's a screenshot of an entity on a really short path, so you can see the start, end, and the "spread" pattern
CLICK HERE FOR FULL SIZE: http://sixtygig.com/junk/InDev-2014-05-09-3.png
The main reasons it's so fast:
- It never has to cycle through the entire map. It just needs to know where the edges are so it doesn't go beyond them.
- It heavily relies on byte[mapHeight][mapWidth] (in this case [256][256]) arrays to track most of the data.
- When it runs the while loop, instead of checking the entire byte[][] array for "checkable points" it only has to check all the points assigned by the temporary arraylist, so there no need to search the byte[][] array at all, it just calls up all the points in the ArrayList and checks them.
- It removes all of A*'s terrain movement cost and basic heuristic data, so I cut out 2 or 3 int[][] arrays in the process to track movement costs. (Movement cost stuff is well explained here, and you can probably imagine how it adds a lot of additional data to check:
https://www.youtube.com/watch?v=KNXfSOx4eEE )
(EDIT: To kinda explain what I mean, if you watch the video, mine parents arrows like in the tutorial but does NOT have the H, G or F costs at all, and still always finds the same path A* would have anyway. Technically A* may be able to do this in less checks, but my checks run so much faster it doesn't matter.)
Also, I'm not sure if you have already implemented these features yet, but it would be good to see some screenshots of how the resources look, are gathered and how they are transported? This game looks like I would enjoy just making stockpiles of items for my village geenration
They're not coded yet, but think Warcraft 2-like.
The plan as of this moment:
With wood for example; Basically the villagers will go from a source building (Like a lumber mill) back and forth from trees, slowly cutting down the forest as they go.
Each villager will also have a mini-inventory, that will store a few items. For example, if you want your villagers to go chop wood, they first have to head to the lumbermill and pickup an axe, and they can only hold a few tools at once. So if you overwork a villager he'll have to waste time putting tools back. Alternatively, your villager may be able to hold a few bandages, healing potions, or something like that in those slots instead if he doesnt fill them up with tools/junk. This could help him if he's attacked, he could chug a potion while he's running away.
As for how they stockpile, I'm not sure yet. I want it to take of physical space on the map (so hording becomes a problem). But I am unsure how at the moment. Maybe a combination of "storage buildings" and allowing you to stack items outside in designated spots.
Moreover, I like the blood-effects most I think, although its unfortunate that all body's remain in one piece
They'll be many more death and "dead body" animations. Right now I just have the basics. Eventually the guys will be able to be blown up, torched, disintegrated, melted, etc. (depending on how the poor guy died)
Sounds and looks great, its the kind of game I love to play: turtle in and slaughter anything that comes!
Thats the idea!
