JUSTICE : hungry forest [done]

[Ed K]

Oh right, absolutely! (Sounds rather like ant foraging behaviour, which would only be 1-2 iterations off your algorithm)

So yes: Don't get hung up!

[moonmagic]

Taking a step outside the problem though, why do you feel the need to use A*? Is perfect navigation genuinely important to your game, can you fudge something that will do a good enough job? I tend to find that algorithmically 'good' navigation is often a lot less interesting (as a player) than substantially easier (to code) alternatives.

This is a good point. I was actually thinking about this as I was trying to sleep last night: I don't need a human to pick the best path to the nearest tree. I just need to get him out of the town without clipping through a building. A series of adjacent square checks should be fine for these purposes, and a variable that stores the starting location (for "harvesting"). Sometimes I find myself cursed by the desire to write "good" code, and this is amplified by some of the "look what I made while I was messing around!" blogs that I read.

There are several AS3 implementations online. Could be showing my ignorance of Flashpunk here, but whats the problem with taking one of those and using it? If necessary, consider creating a temporary 2D array of ints (or whatever) from the map instead of using the map data directly. It might make it easier to drop in a generic A* implementation.

I've tried to use a number of A* implementations (Doglion's, Dauntless), and I am either foiled by my own limited knowledge as to how arrays work (I know what I want from an array, but not necessarily how to sort and retrieve from one), or the presence of event listeners or reliance on custom node and tile classes that don't always play nice with what I've already done in Flashpunk. It is definitely my issue, and not a lack of AS3 A* stuff; I guess I require a little more handholding than most other people who write AI.

Code: Select all

while man not at tree:
  if man can see trees (can walk to them without navigation) then:
    pick random tree
    walk to tree
  else:
    pick random visible location
    walk to location


It will probably look a bit stupid, but it might do, and if it isn't good enough, it is at least easy to iterate on.

This is probably pretty close to what I'll end up doing. I'll use one of Flashpunk's getType functions and collideLine, and then a series of checks based on the tile's point and the man's point. I'm not worried about it looking stupid; my human sprites are sort of predicated on stupidity, and the player never has to have the frustration of controlling them, so no big deal.

Thanks to everyone who chipped in with advice or encouragement; I was pretty discouraged last night, but now I'm ready to hack something out and move on.

[moonmagic]

DAY FIVE:

Away from the computer today! Made these sprites for the human projectiles:



All attacks in the game will be projectiles, with the exception of animals. Humans will throw axes, torches, or arrows; the forest and marsh tiles will throw tree sprites and mushroom people, respectively. Animals will have melee attacks.

Back to the code tomorrow!

[Jonathan Whiting]

DAY FIVE:
Away from the computer today! Made these sprites for the human projectiles:

Looking nice. As a suggestion (which you might already be planning), I think the axes and torches should spin as they are thrown (cycle the animation).

[moonmagic]

DAY SIX:

VERY DUMB and basic AI is now in place. The red houses make a little man who chooses between two states (IDLE: lots of standing around and kibbitzing, and FORAGE: wandering in the general direction of the forest with brief pauses every once in awhile).

Here is a short video, which I recommend not watching past a certain point because of the eager gentleman who insists on exploring the northwest corner of the map, which is barren and empty:

http://youtu.be/O83sFz50o4A

Next steps will include making them target a forest tile when a minimum range has been closed (code is there, just need to sleep), and adding litter for when they are just hanging out (beer cans?). Also, I need to do something for when more than one person is on a tile. My movement is very grid-based right now; trying to decide whether I want to keep it like this or break it up a bit.

EDIT: I already decided to break up the grid a little bit; now the man checks for a collision a whole square away (like before), but if there isn't one, he can choose between four different increments of travel. I've been watching them run around for awhile, and no one has gone through a building. So it looks like I've got great "wander around" code; now to make it a little more aggressive (sometimes).

[redpesto]

This is coming along really nicely :D

[moonmagic]

Huzzah, they can find the trees!



Here's what I am thinking for the A.I. (A WILD PSEUDO CODE APPROACHES!)

if (IDLE) {if (FOOD > 0) {choose(IDLE, IDLE, FORAGE)} else {FORAGE}}
if (FORAGE) {if (NOTARGET) {"search" for a forest tile until within a minimum range} else {COLLECT}}
if (COLLECT) {if (AXES > 0) {AXE -= 1} else {RETURN}}
if (RETURN) {if (DISTANCETOTOWN > 16) {walk toward nearest town tile} else {IDLE}}

During COLLECT, they will throw axes until they are out. If they chop down a tree (which will spew out a little "wood" icon), they will go get it, which will add to the wood supply when they get back to town. When they have enough wood, they will build a new house.

I refer to food: hunters will go to "cave" tiles to hunt animals, with similar results. The more successful the hunters are, the more idle humans there will be, while they eat the food and talk to each other. While humans are idle, they will scatter bones and beer cans on the ground.

[Jonathan Whiting]

Sounds pretty sensible. You'll almost certainly have to tweak thisonce you've got all the other mechanics and goals in place, but that's fine (just don't get overly attached to specific behaviour too early).

[moonmagic]

The humans now wander towards the forest, throw axes at it until they are out of axes, and then look for the nearest piece of lumber to pick up. I still need to make them carry it back to town.

So far, I've only been working with the axe humans, but the others will be identical to implement. I haven't worked on any other graphics, either, so I apologize as to the sameyness of the screenshots. Roads, overgrowth, cave and marsh tiles, etc. are coming!

[Jasper]

It's so gorgeous. I love the idea of an ecosystem portrayed at this low magnification. Keep it up!

[shouldice]

I love the look of this.

Even the houses look like they are sighing contentedly.

[elegwa]

This looks awesome, the graphics look very nice ^_^. Looking forward to the gameplay!

[moonmagic]

DAY WHATEVER:

Thanks for the kind words, everyone!

I'm nearing the end of the human behavior routines. I spent most of the day on a new class that finds the nearest house, checks the grid around it for available space, and then either sets a tile for humans to build on OR cycles through the map looking for a random open tile (in case you've destroyed all their buildings). Humans now find the nearest forest tile, attack it until they run out of axes, pick up the resulting lumber (most of the time*), find the building site, build a house there** (takes four lumber, currently), and rest for a bit before heading out again. I am REALLY ready to move on to the player structures and interface, but a few nasty bugs popped up when I added the "build" and "return" features:

* 1. Humans don't reliably switch to gathering mode when their forest tile is destroyed.
** 2. The humans are mixing up their target points due to something that has gone wrong in my movement() function (written with OR conditions to save time, and now costing me lots of time, lovely). Sometimes they throw lumber at the wrong spots, attack their home buildings, or just generally spaz out. Also, they don't appear to be setting variables appropriately, and sometimes all act concurrently, DESPITE the absence of static variables.

Bah! The glimpses I've had into the expected behaviors are exciting, but I suspect I will have to scrap a lot of code and rewrite this function, and I am definitely running out of time.

Here's the large herbivore spritesheet for cheerfulness purposes: (4X)



EDIT: I've changed the name of the game to HUNGRY FOREST, because it still sounds bright and happy but also mildly grim.

[Dan Lawrence]

Love the art style for this, looks immediately like a friendly Dwarf Fortress.

[moonmagic]

SOLVED most of the AI issues. They get stuck every once in awhile after building or running out of axes, but I think I know why and I will fix it. Watch them build a house:

http://www.youtube.com/watch?v=QtrnczIboYs