Forgot to submit last night. I spent a couple hours starting to implement an npc for this example quest. It was enlightening. There are still many many npc path and ai bugs that I need to either find nice workarounds for or fix properly. My goal was to have a simple dialog tree that ended with the npc walking off and hanging out in a specified area.
The behavior tree nodes setup for pathing feel much more complicated than I think they need to be, and I am pretty limited in the kinds of behavior I can easily implement. I didn't have a pre-defined behavior handy, and trying to come up with a "hanging out" behavior was taxing my brain. Editing behavior trees is hard, because I always have to remember what all of the nodes mean, which means either better naming or an editor may be in order.
I also still have a weird disconnect between the dialog system and events. I think I have talked about this before, and it's possible I need to redesign the whole thing. To implement this simple situation, I have to:
Last night I basically stopped when I got to that last step. I couldn't really think of The first set of steps took about an hour. Not terrible but not great either. There are some fairly well behaviors that are defined now that make some things easy. Picking up or doing something with an item takes only a few lines (once I remember how to do it). But anything else is a bit confusing. I think an editor would help a lot. But I think I need to redesign how behaviors, conversations, and events work in a wholistic way, because this isn't going to scale. It would be really nice if I could just open a new file, and put all of those things together line by line in a simple way:
"I'm going to go off by myself now"
char1 behavior =
if char1.distance(region(x)) < 500:
char1.movetoward(region(x))Definitely need to spend some time creating a more cohesive and complete grammar for everything before I can get to something clean like that. But it will help so much in experimenting with such highly experimental gameplay!
I also had a bug with the response interface where the player chooses what to say. After getting fed up with behaviors, I tried to fix this and couldn't narrow down why it wasn't working, so I went to bed frustrated. I hate going to bed frustrated!
I found the AI had some trouble navigating the interior of the house. I had to use half-tile collisions due to how the art is drawn, which is less than ideal, and still (after ~3 years of knowing my engine has this problem) can't navigate around them correctly. We'll do more with the npc a little later. So instead for today's update I did something a little more frivolous:
I quickly hacked up some intro text that fades in. I can have different intro text pop up for each scene, and I could trigger similar text from an event whenever necessary. I like it because it doesn't stop you from messing about if you just want to get going (a golden rule of Erik is to remove control from the player as little as possible). I'm sure the aesthetics could be improved. Version 2.
Finding the key to the cellar. I haven't built multi-map scenes in a while so I had to remember how to do it. It's a little more finicky than I would like. The inside and outside of the house are separate maps, and I have to position the doors, the warp trigger zone, and the destination zones very carefully. The front door of the house is actually replicated on the inside house map - I may need to link the object somehow. This is just a test scene, but this scenario will eventually need to have an ai character inside the house that goes outside eventually.
Next milestone - trick an ai to go in the basement, and then lock him in?
Went to a writing meetup for some social pressure. It worked out pretty well - I did some more in depth worldbuilding for Erik's starting village, and answered most of the questions I still had at least on the main quest chain that happens there. Two of the quests I originally planned ended up being merged. And there are some side events that can have a stronger time component. I feel like it was ver productive, and am going to try to make it every week. Maybe next week I can use it to write some dialog?
Doing some map editing to build the quest where Erik, should he choose to, can attempt to break into the basement of his neighbors house.
The GoG connector for mybacklog is broken again - now they have a recaptcha for signing in. Ugh. If I want to keep that functionality I will have to implement a browser module to allow the user to sign in when the cookie lapses. I wish they would just make an api already.
I also did some light planning scoping out one of the erik quests - one about breaking into someones basement.
Minor bugfixing and more planning/
Started a new outline. Covers the first 2 chapters. Another attempt to at least consider the scope of the game so that my efforts will actually be directed toward some sort of game coming out the other end at some point.
Each chapter has 8 quests, which seems about right. On a given playthrough, the player will likely be only doing a handful of them. It's hard to calculate, as there is not really a golden path (optimal way through the game). The player can do zero quests, sit in the corner, and it will progress. But there are important quests, if you want a decent story, you will want to at least attempt roughly 3-5 of the 8 I have outlined. At 5-10 minutes per quest, a conservative estimate for the two chapters is 45 minutes.
I'm aiming for 3 acts, although due to the nature of the story I can add on to that if I think it's reasonable to. So I currently have a ~3 hour game, although I have hopes that people will want to play through at least twice. I've seen plenty of people spend money for 2-3 hours of gameplay, but few are completely happy with that. And for something that at least looks like a traditional rpg I think reactions will be pretty poor. If it's free, maybe it fares a little better. If the core gameplay is actually interesting in any way!
I do expect Acts 2 and 3 to be a bit more dense than this first act though.
Edit: Oh and I just realized that my calculation in terms of quest time is quite underrepresenting overall time. There will be non quest-related time, intros and outros to the chapters, exploration, travel between areas when not on a quest, and time spent figuring out what to do next. So that's like the speedrun time :)
Another thing. This is just a first pass, and at a glance very few of the quests I've outlined have a significant timed component. Even worse, at almost no point are the quests running alongside each other, where doing one of them prevents doing the other. This may be something I am subconsciously doing intentionally, in easing the player into the timed element of Erik. On the other hand, I may just not be quite comfortable with that element yet. I'm definitely going to play with this outline quite a bit more before I set it in stone and start gearing my dev time to matching it.
Journal interface pagination. It's not pretty but it's functional. Move on.
Some design work. I've been playing daggerfall and thinking about it's skills system. There really is very little going on in that game, but since everything ties into skills you are rarely in want for something to mess around with. Erik is pretty lacking in anything resembling core gameplay at the moment. I'd really like to change that by the end of the year.
Doing some refactoring of the interface code. Mostly so I can easily add the journal interface, but I know there will be some other custom interfaces needed later.
Later today I will be either worldbuilding or working on a design document.
I've done a little bit of worldbuilding for erik. I have a wiki and I was cleaning it up and adding a few references. I'm actually using a world I've used for other content before (a game and a book), and it's eventually going to be my expanded universe where most of the things I create take place. So most of the things I was adding in the wiki were more about this connection than erik specifically.
I also got my gearvr inputs to read, although it's not quite what I was intending. I can detect a swipe on the touchpad, but it only moves the view in one step, rather than being able to hold a direction on the touchpad to move in a direction. It's close though, and for the game I'm actually making, I think I only need to detect taps, rather than swipes. Next is handling the view ray and getting the proper handler in so that you can actually use the back button to go out of the game and back to the main gearvr menu. Right now the only way to quit is to yank the phone out of the headset lol.
Began refactoring the twisted thread of "say" function logic.
I was looking through some of my earliest entries, and saw where I had wondered what to do about slow readers. My solution is to keep a journal that at any time you can go back and review what someone said. Of course this is important even if you are able to keep up with the text, to keep track of what's going on, and remember who is trying to trick who into falling in love with who so that you can appropriately mess things up by readdressing the love letter to someone who will be really offended so that they will go get in a fight with the original character and keep them from making it to the party where you will be able to do something else since they aren't there to stop you... or something :)
I started by trying to figure out how to record the lines that the player sees, which is more complicated than you would think. First, every spoken line is spoken independently by the npc who is talking. I have to actually figure out which one of these independent dialog boxes is the one that's on the screen to record that, and pass the message into a global variable somewhere. Secondly, the code that launches the dialog boxes and the code that obscures the letters if the player is out of earshot are in different places. So while the more natural place to record the journal does not know which letters were obscured.
I did hack together something that kind of works, minus the obscured letters; and put the journal into a menu for now.
Le sigh. I think some refactoring is in my future.
I've been experimenting with building a planner for the AI. For now, the idea is to be able to dynamically generate a behavior tree for acquiring a specific item. Now that we have a rudimentary crafting system that the player can interact with, I thought it might be a good idea to see if the AI characters could interact with it as well. This isn't just to give me something to tinker with - one of the earliest ideas I had for a puzzle in the game involves slipping some poison into the castle kitchen at a point in the process where it will go undetected. At that time it would have been a very scripted event, but now that I am moving towards simulation something more reactive and flexible makes more sense.
So I wrote a function called get_item_tree, which basically walks through all of the recipes, and builds a tree to acquire that item. At each level of the tree, we first determine if we already have the item or can just pick it up somewhere. If not, we recursively search for the ingredients that make up the item, and call get_item_tree on those.
Here's an example of one of these generated trees:
{
"type": "P",
"name": "Get item from combo",
"children": [
{
"btf": "_interact_object",
"type": "SUB",
"args": {
"action": "get",
"object": "poisoned_meat",
"dist": 50
}
},
{
"type": "S",
"name": "Collect ingredients",
"children": [
{
"type": "P",
"name": "Get item from combo",
"children": [
{
"btf": "_interact_object",
"type": "SUB",
"args": {
"action": "get",
"object": "meat",
"dist": 50
}
}
]
},
{
"type": "P",
"name": "Get item from combo",
"children": [
{
"btf": "_interact_object",
"type": "SUB",
"args": {
"action": "get",
"object": "poison",
"dist": 50
}
},
{
"type": "S",
"name": "Collect ingredients",
"children": [
{
"type": "P",
"name": "Get item from combo",
"children": [
{
"btf": "_interact_object",
"type": "SUB",
"args": {
"action": "get",
"object": "poisonberry",
"dist": 50
}
}
]
},
{
"type": "P",
"name": "Get item from combo",
"children": [
{
"btf": "_interact_object",
"type": "SUB",
"args": {
"action": "get",
"object": "masher",
"dist": 50
}
}
]
},
{
"items": "poisonberry,masher",
"type": "COMBINE_ACTION"
}
]
}
]
},
{
"items": "meat,poison",
"type": "COMBINE_ACTION"
}
]
}
]
}Note that we first try to get "poisoned_meat", which if that fails we search for both meat and poison. At the end of all the searching, we make a call to combine the meat and the poison (which will access the crafting function). I can build as complicated a crafting tree as I want (though I probably won't go very deep with it in the actual game) and I can easily set up scenarios where npcs are involved in a crafting process of some kind.
I haven't actually tested the generated tree in-game yet, so there's still quite a bit to do here. Also missing is that most npc crafting will be much better for the player if you can actually see the crafting happen. Weaponsmiths will need anvils to work on, cooks will need an oven to cook meat over, weavers will need a loom, etc. I will need a much more descriptive list of recipes for npcs which includes not just the items used but the device needed, and whatever resource that device needs to function (i.e. coal for a furnace/stove).
For the player I have so far just been hardcoding these actions, such as stoking the firepit with logs. So I'll need to decide if the extra crafting info npcs need is just a markup for their benefit, or if I want to change how the player actions are coded as well to generate them from the same data. Making things more data oriented would be very cool I think.
I started taking a look at how the datafiles are organized. I'm making it a little bit more flexible, allowing me to organize the triggers, conversations, and characters into subfolders for each scene or map. We'll see what layout I end up with! But we've grown a bit beyond where one giant list of keys will do the trick.
Experimenting with collisions and ladders, probably not going to use any of it.
Added a trigger type to maps to change the draw layer of the character who passes it. Will be useful for ladders or ledges which you can walk behind but also in front of. Will probably NOT be defining walkable areas on top of each other (say a bridge that you can cross over another path) to avoid having to add that to the pathfinding/ai. Mostly just cosmetic.
No one is safe.
I've realized a slight downside to the gradiation in eavesdropping - I can't really rely on the game remembering what info the player has learned. It wouldn't be fair if you see a word like m_rd_r; and then are not given the option to inform your superior about the murder plot when it's obvious to the player what that word is. Similarly, if you only saw ___d__ and then WERE given that option, you would wonder why. That may be OK for the game I'm making, but another example of something that is really simple to build initially but increases complexity by several factors.
Being able to move around during conversation is another one of these "features". It's actually easier to allow the player to move during dialog than not. But those constraints are a standard in most games for a reason. They cut down on bugs and the possibilities for the player to attempt to do things that the designer did not factor into their creation.
Older games often had less well-defined restrictions for the player. Sometimes this made for some very cruel situations. There are many situations in the King's Quest games where the player can do something wrong, or miss something that they need and cross over to a new area they cannot escape from, and be stuck with no way to find a solution anymore. One example is in King's Quest 5, you get a pie very early on, that you are allowed to eat. But you need this pie later, so if you eat it, you cannot complete the game. Most modern games attempt to make these sorts of things impossible.
I want to allow them as much as possible - but without allowing the players early decisions to prevent the game from being completed. It just may not be the most satisfactory ending.
But in loosening constraints, even just a little, the potential for bugs, confusing situations, and players getting frustrated because they try something that SHOULD work but does not, increases. As I take a second look at this project I may want to add some constraints back in. It's a difficult balance indeed.
Oh, I should write an actual dev update... I added the fading back to dialog so that once you are outside of even eavesdropping range the text actually goes away.
I worked on the conversation system a bit. I'm not really happy with it both in concept or code - I might redesign how it works. Until then, alongside fixing some bugs where the npc ai would take over in the middle of a conversation; I've modified how eavesdropping works. Before, I was modifying the opacity of the textbox as you got further away from the center of the conversation. It worked well enough, but I felt like fading it out wasn't quite appropriate.
First, it's not always that clear whether it's fading as part of the normal animation of the textbox, or whether it's because you are too far away. Second, even if the text has faded a lot, as a player it is still possible to read the complete content of the dialog! That's not quite what I want. I would like there to be situations where either for stealth reasons, or because of the way the environment is situated, as a player you can pick up some of the dialog but not all of it.
So I've switched it to a letter replacement system. As you get further away from the conversation, more of the letters are replaced. At a certain distance, you will see no letters at all. You had better sneak a little closer if you want to pick up that important bit of information...
I've been on a cruise and focusing on other things for a bit, but came back for at least a day to poke around!
I managed to complete some small infrastructure refactoring. My map loading code is pretty crufty so I am working on cleaning that up. There was a small design flaw in that npcs had a hard coded layer on which they were rendered. I ran into the bug when I was adding some detail to the map and wanted to add a few more ground layers. With the hard coded player layer (say that three times fast!), these new layers were being displayed on top of the player instead of underneath. I'm now assigning the layer assigned in the tiled map file - whatever layer the player spawn object is on is the layer the player will be set to; and when using a map transition, the player will be set to the layer the map destination object is on.
Got to hang out with my lovely game developer peers today - including a couple of our fellow streakers ;) It was fun until the thunderstorm trapped us in the cafe - but the extra time was productive for some of us.
I spent most of my time staring at a blank map in tiled trying to figure out what to do with the starting area and how to build the town. I think I may have reached the limits of the free tilesets I'm using. They just aren't inspiring. It's OK when creating completely canned test environments to work on code, but fall short when actually trying to build a real area. I need to force myself to just put together some of the beginning scenarios and block out the key story beats but... it's just hard to be inspired when the art is so far off.
It may be something that I just need to lock myself in a room for a while and force myself to get a handle on it. A couple of the guys were treating their projects with a game jam mentality, with strict deadlines and scope management. I started this project because I was tired of game jams... but it might be time for some of that methodology to come in again. We'll see.
Just to make SOME progress I took another one of the easy tasks off the list and implemented doors you can lock/unlock (if you have the key) and open/close (if unlocked). It will open up a few more gameplay opportunities for sure, along with some new avenues to chew on the ai code.
Went down a weird side path.
Added a very basic "crafting" system. You can combine items in your inventory, and if I have set up a recipe for that combo, it will create a new item. Example: poison + meat = poisoned meat.
Edit: also saved us from having 3 zero days in a row! Anyone else still in?
