Changes & Updates:
- Started writing more transcripts. I find them a much easier way to get my ideas down, since I don’t have to break my thoughts up into bits of code as I go.
Changes & Updates:
Finished Minecraft Story Mode (Episodes 1-4) today. It’s basically like a Minecraft campaign for Dungeons & Dragons, scripted as a movie. It’s also the first of the Telltale games/interactive movies I’ve played.
Good bits:
Bad bits:
Next up is Tales of the Borderlands, a similar product for the Borderlands game series.
As I transition from engine construction to content creation, I’m finding it a bit cumbersome. Take for example the frequent task of adding small, inconsequential items and scenery, where I just need a name, some accepted identifiers, and a block of descriptive text. Here’s what that process looks like now:
1 | ecs.e('shiny-trinket', ['thing'], { |
I think I can do better with some helper functions/macros. When approaching problems like this, I like to work in reverse: writing the code I want to work, then writing the necessary functions and support structures to make it actually run. The target code I want is something like this:
1 | item('shiny trinket', "A shiny locket, someone's discarded knick-knack. It's empty.") |
This is mostly suitable for barebones items and scenery, where the player doesn’t interact with the entity beyond looking at it and possibly picking it up. Note that the location of the object isn’t specified; the intention is that it’s inferred from context (a bit of a dangerous game, but an idea I’m exploring). The function would work like so:
1 | function item(name, description) { |
This got me thinking, though. For the Rulebook system, I built an ORM-style “query builder” of sorts, which uses method chaining to allow expressive creation of rules. Something similar could work for item creation, and support the above trinket example with added flexibility. See:
1 | item('shiny trinket', "A shiny locket, someone's discarded knick-knack. It's empty.") |
Again, this is mainly intended for simple items. For more complex items and scenery, the current style would be preferred.
Updates & Changes:
Updates & Changes:
Changes & Updates:
Changes & Updates:
Changes & Updates:
Happy New Year! I spent the last 24 hours-ish at an extended LAN party (the first I’ve attended; I’m a late bloomer). Mostly played Borderlands: The Pre-Sequel, with some TF2 and drinks on the side.
Need a new wall calendar.
I’ve been doing this dev journal for just over 6 months. At the start, I had a simple goal: make a post every day, documenting the progress on StupidRPG (my game project). For the most part that goal has been met. This is post #184, and while I’ve had to do a little bit of catch-up here and there, I have a post for every day since I started.
Keeping up with the journal has been difficult, but keeping up with SRPG has been harder. That said, I made some solid progress on the game in 2015, including some serious structural work and a lot of early-game content. It’s more or less at the point where I can focus fully on content creation (rather than engine work).
As expected, the biggest challenges have been overengineering (making complex, flexible systems for handling game logic where more simple, ‘hackish’ solutions would be quicker and arguably better) and procrastination (I’ll explain what that means some other time). Regarding game content, the challenge has been breaking things into bite-sized pieces that can be worked on piecemeal. I usually work on the game for an hour or two at a time, so it’s hard to tackle bigger elements. Most of the content is deeply intertwined (intentionally).
Aside from SRPG, 2015 was a busy/stressful year. I’ve recently been focusing on work/life balance, stress relief, and cultivating a state of mindfulness and balance. I’m feeling optimistic going into 2016.