Learn You a Game Jam - Week 2! (Day 8)

I didn't log my work last night, but I got a lot done.  No time to stop and log...but that's what Work is for amIrightfolks!?

Got a Guildie and up and running, but with very basic behavior.  Everyone is a dumb Slime right now, trudging towards the hard locked Main Tank.   The game will crash if their isn't an MT on the board.  It's simple enough to get testing done, but we need our guys to start making DECISIONS!   These decisions will put them into STATES!  These states will determine what they do and when they can make the next DECISION!  Repeat.

I had a Not a Bug its a Feature moment. The Slime behavior is supposed to go at a certain distance from the target and stop.  It was more or less doing this, except I didn't actually tell it to 0 out its velocity to stop, only stop trying to walk towards the target.  It would keep walking the direction it was going, towards the target but if it didn't hit anything it would keep going.  The Slime would just run into the MT since its stop distance was so short for melee attack.  When the MT dies, the Slimes were doing something weird, the would sort of hover over where the MT was.  The MT was still there, just not visible or detectable (dead).  The Slimes would go the edge of the distance they were supposed to stop at, turnaround and head back towards the MT and repeat.

When the Guildies were added they were going to the spot a few character lengths away from the MT and then they kept going towards the MT... sort of.  I added the Velocity stop to the friendly units, but now I have a good "wander in spot" code.

Fortunately for me I want chaotic but somewhat predicable behavior from my Characters, this is not too hard to achieve.  One of the things that every book on BASIC (yep... I'm OLD) had when I was a kid was a Decide program - a weighted decision matrix calculation.  I thought I might go this route, but I think I might have a better solution - a Lottery!

I think they might be the same mathematically, but I feel like the lottery is easier to implement, especially with so many unknown factors involved.

Once a game loop, if Accepting Input is true, the Type Core will go through all of its ACTION options.  For example, the Slime's "Go towards the MT until you are at a specific distance and stop (sort of)" that we already have would be an ACTION option - more or less the basic attack option for the Slime.  The ACTION itself would have code that would use the game data to determine how many "TICKETS" it gets to add to the...

DECISION LOTTERY!

When all the possible ACTIONS have been cycled through, the Character will then pick a TICKET at random from the lottery pool, and do what the ACTION tells it to.  So every action has two major components - criteria for adding TICKETS and how many, and what to do if your TICKET is picked.

So, right now we have one Guildie ACTION, so it will always "win" the lottery - lets call it "RALLY":

ACTION: RALLY

RALLY_tickets():
If Character > 20 pixels from the Rally Point, add 10 Tickets to the pool for RALLY_action().

RALLY_action():
Walk towards the Guildie Rally Point.

We can add a new ACTION that will need some more information from the game.  The key is to make appropriate levels of INTENSITY (how many TICKETS an ACTION gets) for different actions.  As a default behavior, RALLY should have a low intensity so it wont' take precedent over other important actions (but will still get picked from time to time) .

Our new action, "GET NEAREST AVAILABLE ITEM" should be much more intense, and add many more tickets to the pool, but will only add tickets if there is an Item available for the Guildie to pick up.  It can also be modified by distance, where the closer the guildies is to the item exponentially more tickets get added to the pool to a max.  So a Guildie on the opposite side of the screen is likely to ignore it and RALLY instead, and Guildies near the item will all head towards it until one of them picks it up, taking all the "GET NEAREST AVAILABLE ITEM" TICKETS off the table on the next process loop unless there are other items present.

Then, just repeat for any behavior you want!  I'd add a HESITATION that just has the character idle that is literally always on so there is always a lottery winner and to add variety to the actions.

I was thinking that I would just keep a tally of which actions got how many tickets and then do a calc on just the amount of tickets, but now I'm thinking of building an actual array of tickets that are made up of the appropriate "_action()" function calls with built in arguments when necessary, so that information such as WHICH item this ticket wants you to try to pick up can be encoded on the ticket itself.

But to get there the Guildie has to know there is an item, or a tank, or an enemy or whatever.  They are polling the game directly now, but as things get more complicated I want to have a LISTS that the GameManager generates from game data every frame and that the Characters will pull from to make decisions and even make their OWN LISTS for relative data.

Which is where I left things last night, starting to build the GM Character and Item tables.  Probable a "GameInfo" one as well, but I don't know exactly what I would need for that yet.

Lots to do, still a good amount of coding, but the structure is making it so the problems are containable and solutions that propagate quickly if not automatically once they are found.  I feel like I should be using signals for some of this, but honestly I don't know how to get it to work and time is a big factor.  This is going to be a long term project, but the Game Jam ends in a week. I need it functionally working so I can get building Character Types, Items, Abilities, Behaviors, and then the UI, Environment, Credits, Instructions, Playtesting, Publishing...