Made the fox search for food when endurance is low, and he will go pick it up and eat it. I had to add a new behavior node for interacting with items in the inventory vs the world, as trying to simply eat the meat rather than picking it up first was throwing an error. (The eat command involves deleting the item from the characters inventory, if he doesn't pick it up first it's not in there!) I could have worked around this by modifying the eat command to only attempt to remove the item from the inventory and silently continue if it's not there, but... I might as well continue my method of completely grounding the npcs in the world and not giving them special powers. Barring some ui elements, npcs are functionally equivalent to another player, which is what I want.
In a funny twist of fate, it turns out eating meat is currently modeled as a challenged action (where character skill can affect outcome). And the ui for this is not tied to the character using it but just a random ui on the screen. So you can see the interface show up when npcs try to eat, which is a bit odd. Also, you the player are informed that he has eaten poisoned meat :P
Oh hey. I also realized I can now lure the fox into my trap by putting meat down. I wonder if that will work.... hey it did! I didn't explicitly set up that interaction. Hopefully as I add more interactions this kind of emergence will start to multiply.
Added a referencing system to behavior trees to make it easy to replace nodes with other nodes. I created a behavior for being in the bed, which basically does nothing until it's time to wake up. The interaction command for the bed now handles adding that behavior into the tree when he uses the bed; and then when he uses the bed to wake up, it clears that behavior. This will hopefully be one more piece of the puzzle for dynamic interactions that don't grow out of proportion, and while the bed behavior is not attached, none of those nodes have to be processed.
I may change some of the existing subtrees to use this attach-detach mechanism.
Basic patrolling guard routine.
I did a little bit of bonus work after my update last night... and I'm going to let it count for today. I added a bit of code that sends npcs who are at less than 50 endurance to go looking for a bed to sleep in. They sleep there until the endurance is at maximum again, and then they wake up. This was pretty simple to code - 4 lines of python and a copied behavior tree - but there are some issues with multiple conflicting jobs, and the boundary between the python code and the behavior tree. I have all the AI tools I need, but putting them together is a total mess! While sleeping in the bed, the npc is still actually trying to do other things, he just doesn't move because I had programmed the bed to trap you in it when you are sleeping. If someone else is in the bed he still considers it a usable bed and keeps trying to use it. If you are in the bed and an npc wants to drag you somewhere he doesn't know to wake you up first.
All fixable issues, but it's amazing how so few interactions can make the complexity spiral out of control. Do I really want to be having to debug the giant matrix of interactions every time I add a new one? Is there a way I can develop the ai that ensures that it will most likely work with what's already there without endless testing?
Mybacklog
Continued experimenting with tasks data change. Also, tried to import my new copy of grim fandango from steam, and noticed it was not being added to the list. I realized that through all of the recent data conversions I had not updated any of the import functions :( Spent some time cleaning those up. And then played Grim Fandango :P
Erik
Designed some "modules". Little actually written. More in my head, thinking of how I can more easily boil down the gameplay elements. I know there will be some kind of process of: design a module; implement module through: tiled, event, conversation, and possibly a new type of thing; and then tweak it from there. But I haven't narrowed the gap yet. What I'm calling a module is essentially a series of actions a specific npc tries to take when certain conditions are met. Currently, there is a kind of "entry" to the module (when the npc starts attempting this process), then a series of states where a success moves onto the next state. Certain actions by other characters (or player) may either cause a state to fail, or be delayed. And then, sometimes certain conditions will change to a different state, or loop back.
Yup. Certainly looks like a finite state machine to me. This leads me to think it may be a good idea to implement it that way. However, I already have events, conversations, and behavior trees, which are all like their own mini scripting languages. Does it really make sense to implement yet another type of thing? Another option would be to build the modules into the existing behavior trees. Either through ai having separate high-level/low-level BTs (one determines which stage of the module we are in, with the low-level tree handling movement and reactivity); or just having a part of the existing BT check/change module stages.
Will have to think about this more. I'm at the stage where it's less and less useful to just start coding, and it pays to do a bit more up front planning.
Erik
So for Erik, I just focused on the conversations some more. I added commands for characters "entering" and "exiting" the conversation in the middle of it. When the volunteer is chosen to collect firewood, he starts walking off to do his job while the remaining characters continue conversing. I've also inched forward in making the characters appear natural. There was a silly bug where the command to have a character look at a point makes them look AWAY.
I've also made it so characters choose between running and walking depending on their distance to the target. If they are far away but summoned to a conversation they will get there as fast as they can! I'm pretty happy with the system, and less happy with my writing :P
Missing: better smarts about where characters should stand during the conversation - they should pick the nearest available logical slot rather than just randomly picking any x/y in range.
MyBacklog
For my game launcher, I worked on the steam/gog api usability. If there is an error logging into either service, a window pops up to let you check that your account information is input correctly. It feels pretty janky, but it's better than the program crashing if steam is down or you entered your gog password wrong!
Erik
I fixed some bugs from the previous update (actually some of the bugs were older, they just didn't present). I had earlier add a menu that lets you choose which items you wanted to use to fuel the fire. You can use your tent as kindling if you wish for instance (though I wouldn't recommend it). This lead to crashing though now that I had an ai character trying to interact with the campfire - ai characters don't have a menu attached, but otherwise use the same interaction code as the player. This had a simple solution - write a menu handler on into the ai and make sure when passing it a menu to give it enough context to make a decision. For the fuel, I have a list of item types and the order in which he would prefer to burn them, starting with the most obvious, the log. But if he is running his ai routine to top off the campfire and runs out of logs... who knows what might happen :)
Other bugs related to the conversation and event system. In one case, the same conversation was appearing twice, because of an delete-index-while-iterating-a-list error with events when there are two events to be executed on a frame. Luckily, I just happened to have my test conversation keyed to trigger on the same tick as another event, or I may not have caught this one!
MyBacklog
Separately I'm going to throw in updates for another project here occasionally, even forgoing Erik on some updates. For about a year I've been working on my own front end to launch games from. It imports my library from steam and gog, can launch roms in various emulators, and can also just point to any shortcut or exe. It is a unified way for me to launch games and track my playtime, which has become increasingly important to me as my game pile grows out of control. I think that it might be useful to others in the future, but the polish isn't quite there, and it's missing some features that don't bother me too much but will be tougher for others to swallow.
Today I worked on some of those missing features. One issue was that all of the external apis had my own account information and passwords hardcoded. Wouldn't want to send my gog password out in public now would I? I also have not updated how the database stores games in a while. It's... pretty messy as you might expect, with support for so many different sources of game information added haphazardly over a year. I made some tweaks to it and updated my 1200 strong game database to the new data format. Where I used to have something like this:
{"name":"Assassin's Creed IV",
"steamid":"12345",
"icon":"http://steeamicons/bf.jpg",
"gogid":""
}I now have this:
{"name":"Assassin's Creed IV",
"sources":[
{"steam":"12345","icon":"
"}
]
}It's a small change but is a lot easier to expand for the future. In general, I'm trying to make it more expandable, so that if I get feature request or bug reports I can more easily modify the data without end users having to run dangerous conversion scripts that might screw up their data.
Let me know if you are interested in beta testing the software, I'd really like to start with a very tiny group like this one.
No update tomorrow probably :P
Following from yesterday, I worked on a conversation about who should collect firewood, with the conversation system passing along the collect firewood activity to whichever npc is picked. I also generalized the collect firewood activity for any task that involves finding items to go drop off at a location.
Two small changes:
Previously the ai would only walk. I've modified the chase behavior to make them run while it is active. As it uses the same code as the player to do the run, an ai chasing you will eventually run out of energy and slow down. I may need to add some smarts to the ai for when it's a good idea to run, and when it's better to conserve energy. Maybe a genetic function?
I also actually implemented the burning logic in the campfire, so it can burn all the way out. For now it just deletes the campfire item, but it's suitable enough for testing. You can add logs to extend the time it sticks around.
Optimally solving the opening scene will definitely involve getting enough logs to feed the campfire before night, which includes deciding who is the best member of the group to be assigned to collecting the logs. Perhaps I can set up some kind of dichotomy, where some people are more observant to see optimal firewood, but perhaps can't carry as much in one trip - and then others are stronger to carry it but are not as good at finding it. And then set up a vote where - unsurprisingly - the players vote is the deciding one.
Wrote a bit more backstory. I came up with an idea I kind of like, but it's not well integrated at the moment. I'm still trying to figure out the direction and structure of the story. I am pretty sure what is going on with the main character, at least in very general terms, but less sure about the events happening on the periphery, which are actually pretty important. I don't need everything, but I at least want to nail down what is going on right before act 1 starts, so I can write the intro. I plan on nailing the intro tomorrow.
In coding world, I am tweaking the perception of npcs. I had a very basic vision cone down, which would register objects in range instantly, and then it had a slight delay when objects went out of range before it forgot about the object. While testing a stealth-related section, I found it was far too easy for the npcs to see me. They change direction so quickly, and there is no line of sight or objects to hide behind yet, so it is almost random whether you are able to stay out of the cone while the npcs move around during their conversation. I've added a delay to the start of the vision process as well as on the end. It takes a short time after seeing you before they can perceive you - and the longer they have seen you, the longer it takes before they forget where you are.
It's still coming along. Needs line of sight. Might need to rotate it independently to get away from instant directional changes as well.
Finally made it back to the meetup, which was cool. I didn't do much socializing because I was hot on finishing up some of the code changes I've been working on, but let's just say one of the guys there worked on kerbal space program and I sat in the corner with stars in my eyes glancing over at him every few minutes lol.
Anyway, I am still playing with behavior trees to try and get a balance between flexibility and ease of adding stuff. I was able to finish hooking up the drag action as a behavior, but it still had some bugs in that if you move, the guy chasing you goes to where you triggered the chase, rather than where you are now. I used a previous follow behavior, and added some arguments (and ways to set arguments in the behavior tree) so that the drag_to behavior can call into the follow behavior and attach it to the right character. So the guy chasing you will keep trying to get to you, only initiating the drag when he's actually close enough.
I also added arguments to the event which triggers the drag, enabling characters to chase and drag other offenders besides just the player. Force your "friend" to commit a crime just as the guard comes around the corner, and watch him get taken to the prison :)
Sometimes it's like keeping plates spinning, but while challenging they do look cool while they are spinning. Before the ai gets stuck trying to go around a corner and the plates crash to the ground!
For bonus points I also added a tick event to the event system, so I can set events to happen in the future.
I have a lot of tools to create situations, and am still figuring out how I am going to use those tools to create scenarios, puzzles, obstacles, and story.
Worked on organizing some of the hard coded npc actions (specifically the dragging) into their behavior trees. I used to basically have one behavior in the tree that will do whatever action I set on the npc from elsewhere. A generic action; but it allowed me to program new actions easily. Just call npc.do_action(blah). On the downside, with only the ability to give one action at a time to an npc, this made some of the other code a bit more unwieldy than it should be. I could solve this with an action queue (npc.add_next_action(blah)), but that still wouldn't be as flexible as hardcoding the actions into the behavior tree itself.
For instance, even if an authority is in conversation with someone, they should abandon the conversation to go try and stop you if you offend. This is easy to pull off by putting the drag behavior at a slightly higher priority than the conversation. Later tweaks should allow me to adjust priorities - some police unit types may be less inclined to stop what they are doing to do their job than others; and someone running from a bear should pretty much ignore you.
I will table for now what happens after they stop you - do they resume immediately on the next line of conversation, restart the conversation, what?
Hooked up a generic event trigger to item interactions. Now I can listen for people doing things with items. I then made an event where trying to take down the tent makes the field guide annoyed and he comes over to stop you. I thought of actually adding in logic that allows the event response prevent the action from happening, so that if you try to take down the tent with the guide around he actually wont let you. But I thought of a better idea - taking down the tent becomes a task (an action that happens over time), and the drag response I've talked about in prior updates will automatically cancel any running tasks on the target of the drag. So what happens, is you start taking down the tent and see the progress bar, but if he reaches you before you finish, the action wont complete as he drags you away kicking and screaming.
Easier to code, and better for gameplay. You can now judge how long unappreciated tasks take and see if you can complete them before you are thwarted.
Events.json to accomplish this behavior:
{"type":"action","action":"dismantle","npc":"erik","repeat":1,"result":[
["drag_to",{"npc":"trask","target":"erik","location":"away_from_tent"}]
]}
The location of the drag has to be pre-set which is kind of annoying, but I will probably have simple enough scenes to just hard code all of the spots you get pushed to. Later on I can have the guards drag you to a jail cell haha.
Sadly, some of the "improvements" to pathing have made the npcs really bad at it again for some reason. I HATE PATHING! No gif, because I have to set up just the right scenario for the npc to get to me in time to prevent me from taking down the tent :/
I added to the conversation about where to set up the camp. If you reject the first campsite, the npc walks to a different location and asks again if it's a good spot to set up camp. It's not the full on voting that it will be, but I'm just doing the basic flow of the mechanics. Every little thing I add contentwise is still requiring quite a bit of extra coding to be done in either the event system, the conversation system, or the ai system. In this case, I had to add a way to trigger an event from the conversation (when you say "No, this is a bad spot to set up camp"), and a way for the event system to hear events triggered FROM conversation. I already had a way for events to create a new conversation - but they were always centered on a specific npc, and in this case, I needed to generate the conversation elsewhere (the location of the new camp). So I added an argument to the "create_conversation" action which will center it on a tagged location from the map editor.
It sounds more complicated than it is :P But I wonder if I have too many systems.
This is probably par for the course for the start of the game, but the goal is that by either act 2 or 3 I will mainly be adding content to the json files and not spending too much time in code.
The birds now change their draw layer according to their height, and are a little more discerning of what spots they land on.
Hey, I sat down thinking I was just going to twiddle some tickets and ended up adding a bunch of cool things.
I did twiddle some tickets though :)
I added meat you can eat to regain your endurance. The meat uses the tasks interface. You can fail, making it lose you endurance instead :P Not sure if I will keep this, but the main reason I chose to use tasks for it is because it's the best way I have right now for an action to take time, and eating should totally take time.
I added some birds that fly around and don't collide with things. They are basically just flavor. They currently do land on walls which I may change later.
I added a "drop_item" command for npcs so that I can trigger the setting up the camp scene in the act 1 I've been working on. So now, rather than the tents just starting there, the group will have a conversation about the safest place to set up. I can eventually script it so that after there is a consensus, the people who are carrying the tents will go drop them in the right spot. I'm thinking of having the group walk between two or three different potential spots, and then having a vote - where the player will get one vote. It will be split such that the players vote is actually the deciding one :P
That darn fox. He keeps running away from me, I don't want to hurt him! I keep shouting at him not to mind about the bear trap that I so carefully placed next to the cute little pond, but he just keeps using his very poorly but quickly coded "flee" ai routine. I guess the refugees won't be able to eat tonight.
At least the new smooth camera makes my attempt a little more exciting.
I wrote some super hacky code to make the npcs able to enter a tent. How it works: the function that searches for the nearest item of a given type, when it encounters an item that leads to another screen (such as the tent) LIES to the ai and says that the tent IS the droids he is looking for - but that instead of calling the "get_item" function to get it, the npc ought to in fact call the "enter_item" function. Upon being whisked away to the tent screen, the npc realizes that he still does not have the item he is looking for and starts the search again.
Exiting the tent is similar but even simpler (and hackier). While searching for items, if the item can't be found but an exit can, we just pretend the exit is what he is looking for. When he walks over the exit, he will automatically be warped to the other screen by the exit code which has been in my engine for ages. Upon teleporting, his AI state resets (all map changes reset the ai state) so his real search can continue
This is pretty much cheating, but it's a particularly cool kind of cheating. It is in a way similar to how signal broadcasting works The Sims, where almost everything is encoded into the objects themselves without having to explicitly teach the SIM how to use different items. For example, I could use the same signaling I did for the tent to make npcs understand how to get an item out of a chest. Or what about animals who need to eat other animals to get meat? Just make the animal broadcast the signal "I'm meat but you have to use 'attack' instead of 'eat'.
(Note: there are some pathfinding issues going on here, try to ignore them lol.)
Working on building more interactivity into the game. This involved a little bit of refactoring as a lot of my animation code was hardcoded into the characters. And the tents aren't characters. I mean, I guess you could draw a face on it and anthropomorphize it, but that can only get you so far. So making all objects able to animate is the better path.
Oh, and the blue boxes are showing spots the ai will navigate around, so the dynamic collidable objects for pathing is in there now too. (Actually ended up finishing that last night)
I added an animal into my scene, with slightly different behavior than the humans. For one thing, he is a little skittish, moving around a lot more. For another, his movement speed is much higher. The extra fun thing about having a high movement speed is you find bugs you never would have known about. The pathfinding for the fox kind of broke everything, so I've spent a lot of time making the different movement speeds work well together. It's a little painful but it will pay off in the end. I hope.
What does it mean to see? Is what you perceive also perceiving you back? Is the interpretation of the senses that are witnessed on the inside of the cornea truly an accurate depiction of what is actually on the other side?
Philosophical questions aside, my agents now have some rudimentary vision capacity. If they want to catch you, they will head toward you while you are in their visual range, but get lost if you are outside of that range for a long enough time. This will come in handy when you want to sneak into the pantry and witness the maid and the prince getting into trouble while letting slip some very important secrets that you may want to profit from later...
