Sorry for the essay lol. This is more for me than you ;)

I made it 30 days. Hooray! Thanks to fellow streakers for all the motivation, @Nico for creating this streak, and especially @leafo for a really brilliant idea to help channel creativity.

I have decided to create a schedule going forward of what it will look like to work on a game long term.

  • 30 days of every day updates
  • one day of reflection
  • break until monday, wherever that 30 days ends

In 30 days I definitely experienced some good days and some bad days. There were days that I felt like giving up, and days that I just could not muster any sort of creative energy to look at my code. But I always had in my mind: "I have to make an update to the streak no matter what". I can't say those days were very productive, but I found that almost every bad day was IMMEDIATELY followed by a very productive day in which I accomplished a lot more than I had intended. There is definitely a value in being persistent.

In 30 days, here is a rough outline of the progress I made on a game that I've essentially been sitting on in 2 years

  1. Story
    1. Narrowed down the world the game takes place in a little better
    2. Changed the location of Act 1 and came up with both gameplay ideas and story that fit
    3. I've written some of the opening dialog
  2. Graphics
    1. Widened the view area so that the game works better in widescreen
    2. Built a smoother more engaging camera system
    3. Completed the switch from pygame (software sdl rendering) to sfml (hardware opengl rendering) for a much smoother feel and better framerate
  3. Gameplay
    1. Added picking up and dropping objects
    2. Added interacting with objects in the world
      1. Putting up and tearing down a tent that you can only go in when it's up
      2. Setting traps that stop npcs who cross its path
    3. The ability to run, which uses a slowly refilling endurance bar
    4. Enemies who you can hide from or animals who are afraid of you and run away
    5. Still not sure the direction the gameplay will head, but I know it will be some mix of stealth, story, and timing
  4. AI
    1. A conversation system that will be used in:
      1. Gameplay: Spying on conversations others are having, making story branch choices, or just getting info from people
      2. Cutscenes: Conversations are robust enough to handle most potential cutscene needs
    2. Created some interesting new ai states
      1. A "chase" state that follows somebody as long as they can be seen, with some memory when the object moves out of view
      2. A "flee" state
    3. Used existing behavior tree system to start integrating the different AI states into a single type. All npc currently use the SAME behavior tree now, where before an npc that runs away used it's own tree. Now they choose the right branches in the tree according to their state
    4. Perfected pathfinding, even around a dynamically changing environment
      1. HAHAHA. Just kidding. I did make a lot of progress on pathfinding though.

All in all, I call this a HUGE success. But it's not all rosy. There are some areas, namely in content creation, that are very sorely lacking. The engine work can be done anytime, but without direction in the way of locking down gameplay and story, the project can't really progress. I'm considering taking the engine as is and making a simpler game with it before coming back to this project. I've been playing a lot of Dragon Quest and Final fantasy and it might be really fun to make something more like that, using all of my own art and just being cheesy. Then again, I've come this far - how much more do I really need to do? I'm not even sure, because I don't have a clear idea in my head of what it looks like. I would really like to get some clear direction so I can start making my own art or find an artist, which would make me more comfortable sharing the game outside of the streak. (ScreenshotSaturday for instance) I really think Erik the Errand Boy could go far, but how to get from where I am to where I want to go still looks like a tough mountain to climb. We'll see.

Break begins now, back to work Monday!

Nico9 years ago

Wow, congratulations! glad its gone so well and glad to see you making such progress, wish I could say the same lol, keep up the good work!:D

Seppi9 years ago

Congrats! Make it 2 months!

More submissions by saluk for Make games.

A submission by saluk for Make games. 328

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:

  • Add the npc to the map in tiled
  • Create a section in characters.json for that npc specifying their name and sprite
  • Add a dialog tag to the end of characters.json that makes the right conversation start when you use the "greet" action on this specific npc
  • Create the conversation script, which ends with launching an event
  • Create the event script which sets the npc behavior
  • Create the behavior and debug it with all of the other behaviors

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!

A submission by saluk for Make games. 326

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.

A submission by saluk for Make games. 325

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?

A submission by saluk for Make games. 324

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?

A submission by saluk for Make games. 323

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.

A submission by saluk for Make games. 322

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.

A submission by saluk for Make games. 321

Minor bugfixing and more planning/

A submission by saluk for Make games. 319

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.

A submission by saluk for Make games. 316

Journal interface pagination. It's not pretty but it's functional. Move on.

A submission by saluk for Make games. 315

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.

A submission by saluk for Make games. 314

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.

A submission by saluk for Make games. 312

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.

A submission by saluk for Make games. 311

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.

A submission by saluk for Make games. 309

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 :)

A submission by saluk for Make games. 300

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 :)

A submission by saluk for Make games. 299

Began refactoring the twisted thread of "say" function logic.

A submission by saluk for Make games. 298

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.

A submission by saluk for Make games. 296

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.

A submission by saluk for Make games. 289

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.

Make games.

Work on some aspect of a game, let's say 5 days a week.

daily from 2015-01-25 to 2016-01-25