Welcome to The Kingsport Cases:
A horror game you can never really get used to.
Welcome to The Kingsport Cases:
A horror game you can never really get used to.
Everyone says we should start a blog chronicling the rise (and hopefully not the fall) of our indie game company, Machines in Motion. So here it is, the first post.
I'd like to start this off by expressing our surprise that anyone is actually reading this. Good on you. You can say you read this blog before it was cool, or, if you're seeing this in the future, you can tell all of your martian friends that you went all the way back through our archives. Either way, thanks. You're a dedicated fan.
But let's get to the topic at hand:
The Kingsport Cases is a survival horror game centered around unraveling mysteries in an ever-changing world filled with deep characters, environments, and plots. It has fully procedurally-generated everything, allowing for thousands of unique stories, each different from any other, but connected by characters that can recur and remember your interactions with them. Be nice, and they may reward you with information in the future. Almost get them killed though, and you might see them again as a cult leader with a personal vendetta.
The game's technical challenges lie mostly in writing. Creating the sheer quantity of dialogue needed to make hundreds of unique characters across many plot lines is no mean feat, and we'll get to how we're doing that in a later developer post.
Levels are generated using a graph-based system. Each room has a node that can connect to a specific type of other room (such as a hallway or bedroom). Each story archetype has a list of rooms it needs, and the level generation algorithm fills in the rest, throwing rooms, blood-soaked daggers, monster portals, and other bits and pieces in as needed. Levels are additionally optimized to enforce exploration, and vital clues will be placed in disparate parts of the world, forcing players to walk through the entire mansion to get everything they need.
This system poses a problem though: we need a lot of 3D models of environments, especially because we're trying to make the levels unique across many cases that use the same tile set. To this end, we will be making one room model or texture per day, and posting the results here, in addition to our engine work.
Here's the backlog from the past five days (plus a couple bonus models):
Sounds interesting, what tools are you using out of interest?
Hi!
We're using Unity for the real time side of the game. It seemed like the best engine out there for the kind of rapid development we're going for.
As for everything else, we're using Lightwave Modeler, Filter Forge, and Paint.Net for the world art, Reason for music, and some home-made tools (written in C#) to write the procedural dialogue.
Are you using the free version of Unity or the paid one? The free one seemed pretty good but I was just nosing around a bit to see how it worked, I'm not sure how important the paid stuff is for an actual full game.
We're planning on using the free version barring successful fundraising later in the process. The paid one has a few cool features (like real-time shadow calculation) which will be slightly missed, but we don't have the money on hand to get it, and we can do just as well with the indie version for now.