Learn You a Game Jam - Day 9 Recap

Share this post:

Little slower progress than I'd thought I'd make, but I accomplished two major tasks so I shouldn't be so hard on myself because they were a little tricky.

The first was I got the GameManager Character and Item Lists going, refreshing my memory on how Dictionaries and their references and loops work. Now the GM keeps a running list of all the Characters and Items and their relevant information to the other Characters in the game - with the nodeID of the object as the index.

Next I need to build a Personal Character List into each type that polls the GM's list and generates a sub list of calculations relevant the that character - specifically Friend or Foe using their respective Affiliations, and Distance from that character to start. Same for items, although only Guildies will poll items from the GM list because only Guildies can pick them up. Eventually other types will have the option to switch to a new item as well, so we are building that into the game, but that's down the road. Future Flexibility!

The other major accomplishment - A character made the first decision! My Lottery based behavior system works!!!!

It took a while though, and its where most of my frustration came it. The main issue was getting a function into an array so that I could pick one at random with the Array pick_random method (very handy!). It took a long time of trying, and it still sort of hacked together. I had to learn about Callables.

Callables are basically functions that are stored as a variable. Which sounds simple, but it gets complicated for two reasons:

1) Functions want to give a RETURN. When you reference a function (say in an IF statement) you get the RETURN of that's function's calculation, even if its void.

2) Functions sometimes have ARGUMENTS, and you don't know how many.

So to get my character to decide what to do here are the steps:

1) Empty the lottery_hopper array. This is an array that will store a list of TICKETS, an array made up of two components - a callable function and its arguments (a THRID array! NESTING!!!!).

2) Run a series of functions that add TICKETS to the lottery_hopper. This is the core of the behavior engine. These functions pole LISTS we made above to decide how many and what kind of TICKETS to add to the hopper.

3) Pick a random element from the lottery_hopper array, call the first part of this element (a callable function) and use the element in the second part (an Array of various types or null) as its arguments.

Hold on to this info for later, we will clear the hopper on the next process cycle.

So, the first decision made in the game by a character was for the Guildie to either Go To The MainTank (have not built the rally system yet) or Hesitate. I had a tough time getting the callable syntax correct between never having done that before and the extra complication of pulling the callable out of an array with other arrays with it as argument. I have an ACTION_go_to_node(node, stop_distance): function, but I couldn't get the arguments to pass, so I hacked a hard code ACTION_go_to_main_tank(): along with ACTION_hesitate(): so that I could test the lottery without using the arguments, and...

IT WORKED... mostly!

I had to tweak the hesitate animation and I still have some work to do on it. I need to rework how the accepting_input flag gets set so it can be used more flexibly. Right now I'm setting it mostly in the CharacterAnimation player, but I think it should have an independent Timer for flexibility and simplicity.

But for now there are two hesitations that can happen when ACTION_hesitate(): is called - an unlikely (1/100 ) 1 second idle animation pause, and (99/100) it just doesn't do anything this frame and passes. I call them Long Hesitation and Micro Hesitation. This was because always doing the 1 second one when Hesitation was picked meant I had to add 1000 Go To MainTanks tics for every 1 Hesitatiion... not a good baseline. So I added a mini-lottery in the Hesitation. The micro doesn't even interrupt current animation, it just stutters a bit in position and moves on to the next lottery next frame.

Now our boy will head towards out MainTank as before, but everyone once in a while you see him stutter step a bit, and even more rarely (every 10-30 seconds) he will just chill a second in idle.

BEHAVIOR ENGINE FUNCTIONAL!

I used the ACTION naming convention for any function that is going in the hopper, it also helps to clearly identify them because only these functions should have a move_and_slide() call in them and you should only call one of these a frame.

So for Day 10 I have to rework the Lottery Hopper so I can actually pass arguments.

Then create a new ACTION_Pick_Up_Item function to go to an ITEM and when it gets there put it as a child in the Guildies' Item Slot and remove it from the GM's list so no other Guildies will try to pick it up this frame.

This will get our basic Guildie finished. I will add a very weak attack and some protective behavior when it is low in health, but other than that its main function it to detect and pick up items.

Then, on the the first.. uh... Item Transformed Non-MainTank Guildie (how about THAT for some qualification!) the PRIEST!

Our Priest will do the same three basic functions that the Guildie does - Rally, Hesitate, and an Action.

The Action in this case will be Heal - Poll the GM and Personal Character lists. Find all the FRIEND characters that have Health less than Max_Health amd add tickets for ACTION_Heal_Character to the Hopper for each. How many is modified by 1) distance from the healer, 2) what % of health they are at (it could be modified down to zero, for distance for example). It can be further modified by other factors, but this will work for a basic heal.

Because we added arguments to the hopper with the function we can do things like add TICKETS to the hopper for each Friend Character needs healing and the ticket will tell the character which friend was chosen as well as what to do with it (walk towards it or run heal animations while increasing the target Health if close enough). This impulse needs to be magnitudes stronger than the other tickets so that it will, more often than not, heal SOMEONE when people are damaged rather than rally or hesitate.

We also need to use the "accepting_input" timer when a long term action is happening like this so they don't walk towards 10 different targets in 10 different frames. If I'm "Healing Bob" across the screen, I want at least 5 seconds to do it before I decide to do something else.

This is also a good time to implement a simple rally system. I'd like to have more specific rally locations for each character so it won't just be clumps of Archer, Priests, and Guildies, but it will do for now.

Speaking of which, once the Priest is able to pick from a list of Friends and heal one, we need Archers to do the same with Attacking Foes. I think I will actually implement a Melee Unit before this using the Armored Axeman sprites. This seems fairly easy to do at this point (once the above updates are made), and I think building Archers from this template might be easier behavior wise. Besides, I'd like to get an offensive unit created quickly.

I also don't ...exactly... know how I'm going to implement the arrows. I'm pretty sure I'm not going to have too much trouble getting them to instantiate and move towards the target and then remove themselves while doing damage properly, but then its hard to tell until I'm doing it. If worst comes to worst I can just Hit Scan them like the priest heal as a back up, but an unsatisfying one.

Almost to the point where I am able to churn out new items/units and improve behaviors and general character feel. I have a lot of animations for Guildies and Monsters to use, but I don't think it will be hard to make novel enough behavior for each to fill them out pretty quickly. The lottery behavior system is so flexible and additive, just adding in a few new ACTION functions or even just modifying the ones that exist for different criteria will give a lot of different behavior pattens.