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 have two in progress mario maker levels. I mario'ed it up a bit on the first one, a field of challenging vertical jumping areas.

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.

Quitting game development to exclusively create Mario Maker levels.

(No not really, but it's pretty fun!)

Unity is publishing to my android phone, test cube scene is running in GearVR with headtracking. I'm having trouble figuring out how to get the inputs hooked up to use the touchpad though. The documentation is not very user friendly. The test scene doesn't seem to want to load in the version of Unity I'm using, so I can't see how things are actually wired up and where to put the scripts that came with the integration package. I saw some GearVR inputs in the standard unity input window, but using the standard Input class to access those axis values is not having any effect. And I don't have a clue how to debug when I have a giant headset strapped to my face (and I have to disconnect the phone from the computer to stick it in the slot!)

This is fun :)

Spent some time trying to get unity upgraded and update my gearvr dev environment. The gear just officially came out yesterday and seems like it might do pretty well for a phone add-on. I've been messing with this vr stuff since the first Oculus devkit. It's fun for a developer, because it's a new frontier, and very little has been solved or defined yet. But I keep going back to my long project that may never be finished rather than finding a small one I can complete. Maybe this one will stick haha. Ideally, I would work on a small game or app for 3-6 months at a time while also continuing to progress the larger one.

We all know it's unlikely :)

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.