Epoche Dev log: 3 The mess before the storm

It has been a while since I've put anything up on my ambitious first game Epoche, the idea of the project being to create a murder mystery where you a detective upon finding a murdered person in your train car must discover who among-st the other handful of passengers committed the act. Those of you who have found the other Epoche blog posts first might remember the brainstormed write up that included things like hunger or intoxication meters along with a diplomatic mechanic where your player must argue their case against the suspect otherwise be accused of being the murder themselves and loosing the suspect in the process, and a bunch of other fun but silly ideas that were bouncing around in the first stages to solidify what the game would be. Well I'm here to say that a good chunk of whatever you first dream a game to be or include, will not make it to the finished product, or even past the halfway point, this is not necessarily a bad thing, this is the sign of a refined design. No design of anything that functions well comes fully formed from that creative brainstorm, none. The most valuable asset to a designer and storytellers in general is the learned ability to distill and refine down the material to it's essentials while maintaining and subsequently enhancing the fundamental experience. Or, as I've heard it better stated in The Elements of Style.

Finding the underlining theme of your game and removing all parts that do not add to the players experience of that will make for that more cohesive game-feel that every design aims for. Easier said than done as that entitles understanding your piece from both a critical and creative perspective, knowing both how and what the game does as it does, something that comes out of years of experience... So don't make my mistake of waiting until your twenties to finally sitting down and working on your game, start now, start small, start making games. 

Start with pen and paper.

 (LOOK AT THE LACK OF QUALITY! LOOK AT IT)

Here we see the start of a pen and paper version of the game. The layout of the five npc's and their interaction cards are formatted and started. As well as a brief write up on how they interact over to the side, and how the tier system of interaction works within each murder. This is how you should start every game. Why? Because you need a physical representation to start really thinking about what all the numbers and mechanics will mean for you on the computer. Had I started just building I'd have a few months of broken code and if it worked in any semblance an unbalanced game by now. On paper when you're deciding how to do a thing and you write it down you don't feel bad about crumpling up that paper and starting over if you don't really like it, but when you've just made those assets or coded that function, or put together that level, you are more likely to let it slide even when you're not happy with it. You just are. You're more likely to tell yourself you'll get back to it later and that this is just the first draft and you can always come back once the game is done, which is more or less true don't get me wrong: but after the game is done you are more likely to not come back and not revise anything you don't need to. 

This isn't coming from personal experience but from every designer or producer I've ever herd interviewed they've always said that no game comes out exactly what the designer wanted, none, they always wanted extra time to come back and tweak or even redo entire levels that they didn't have the time or energy after completing the game to come back to. The amount of time and energy you save when putting hours in finalizing that design before creation rather than redoing build after build, is immeasurable. I say this as someone whose always burnt out of steam after jumping into a project without fully designing it, I convinced myself I have a general idea and a mechanic, but then after I get the mechanic or more often then not I don't get the mechanic working, I don't care. I realize my design was a slap dash toss together of chocolate and peanut butter mechanics that don't lead anywhere and I don't think it's an interesting game, because it's not a game, at that point it's a tech-demo at best. It'd be like randomly throwing foods in a blender, you might accidentally come across a recipe for something, but you've more likely just created nutrition barf that could have been food, there needs to be a plan going into the kitchen or you're not really making anything; you're just playing with the food. When you start with a basic recipe though, you have something in mind, you know how to start, you know what you need, and you save yourself hours upon hours of being in a position of not knowing if your food might kill someone or not. Plus, after you know what you are doing, and you've tweaked it into something you really want to actually create... you've found your path and you're more energized to do it, two of the most valuable positions to be in for a creator. I've worked out the majority of what I need about the mechanics and how the game is/work so I can make good with my attempt to code the first prototype, and while it feels like half the battle is done and everything could literally just fall into place over the next month or so, I don't feel tired with this project at all. I know I don't have every obstacle accounted for in that notebook of scribbles and lines connecting dots and numbers, but I know that I have a solid footing, and I know where the problems will come up and have some ideas of how to remedy them. That is an immeasurable advantage that current me has over the me that first started this project. 

Essentially...

This is the sketch in class I made when I figured out the games name and premise, a moment of, YES I NEED TO MAKE THAT.

I keep this old (what the game box art might look like) sketch with me and everything because I want to remember exactly what that dream image was like and how it felt when the idea for this game popped into my head. There were five different art-styles fighting in my minds eye and at least three different color pallets I've seen in other games, plus a ridiculous number of supposedly connected and dramatically important mechanics I wanted to put into the game at that point, but underneath all of this competing forms of expression the game idea was trying to make one experience the main point, a game that made the player second guess themselves. That sounds really weird, actually kinda lame out loud, but that's what I want to do. I want to make a hard boiled mystery game that keeps the player guessing, not just until the plot twist or even until the end of their first play-through (don't know if I could write something that good) but throughout the whole game, every time they play it. Like with Agatha Christie's 'And Then There Were None if you refuse to read the epilogue and you simply sit there, reading the book over and over again trying to figure out who was committing all of those murders. Like how in games like Dragon Age or any of the other games where dialogue is interactive and meaningful, where that feeling of importance and connection to the characters matters; what if you could make a game where you're judgement of the characters always matters? I wanted to remember how much that feeling excited me to start this, that little idea is what I'm going to hold onto throughout this project. Well see how it comes out.

Epoche Development Talk 2, Procedurally Generated and Narrative

Epoche Talk 2, Procedurally Generated and Narrative 

First read, 

Exposition and Micro-Ludo-Nurrative

and

Game Focalization and Narrative


First I'm going to give a quick update of my progress. The pixel art program I'll be using for this project is freeware, which can be found here http://www.virtualuna.de/wiki.php?lang=eng&page=PixelStudioC. I'm reading into verbcoin now because I need to have a full grasp of how to code my algorithm. With this art program I'm going to sketch up some placeholder art and start the framework of the game. Which means the simplest version of the algorithm. Breaking a many scenario system down to the simplest wheels in a way that it will be instantly playable, but code in a way where the next iterations will fall into place easily (or as easily as possible), is proving to more difficult than said. Particularly with the dialogue section.

(image and a good read found here)

BREAKING IT DOWN
So, what do we always do when we hit a rut? We go around, but we keep digging. Everything in a generated game is connected, but it all stems from a simple set of mechanics. So those mechanics are what I will be working on. The gameplay in each match will be broken down into five stages.

1st, the characters, the game will have to randomly generate characters fleshed out with distinguishing features, stats, and personalized inventories. Setting up a test room and test figures will be my first, and most important, challenge. The quality of the game's mysteries (as currently designed) are dependent on this stage of generation working.

2nd  The basic AI movement of characters through the train cars will be directly linked to their stats. I don't have the luxury of making their movements a scripted pattern as the murders both need to have clue states and as must occur out of opportunity. When hungry the characters will go to the bar cart for a sandwich, which will be added to their inventory, which could leave crumbs on their hands, or the hands of a thief going through their pockets. The stats are a basic excuse for variables within the timeframe of each match, this effectively diversifying the instances of each match. Also by making npc's movements less predictable in later builds the player becomes more reliable on the testimony of the passengers(passive targeting and dialogue farther down). This adds suspense and strategy as the player must diplomat with --potentially-- the killer and put themselves in greater risk.

3rd, the first murder state. The combination of the stat effected movement simulation and targeting's system this is the second make or break point. Making the characters' passive/active targeting will be very very difficult.. for me. As the title implies the targeting code is how the murder selects their victim, this section will work off an expanded build of the first mechanics, expanding the stat and other variables so the game simulates the nature of the murder and the state of the crime scene. This section will eventually decide things like opportunity, weapons available, if there was a struggle, the number of clues left behind, and most importantly the imprint those instances left on the other characters. Which brings us to...

4h, claim dialogue, or better named, claim and counter claim instances. Here is where things get tricky and where my abilities with verbcoin make or break the game, each of the characters will have to have a storage system, exposure to fact states(clues) will allot them with a build of claims. Which with their passive/active targeting will organize how the AI responds to player input. This is the real meat and potatoes of the game. As the player picks up clues dialogue options are opened and they are able to 'build a case' against the npcs to decide which one they think is the murder. But dependent on the clues the npcs will be exposed to a different set of possible 'cases' and possibly against different characters, even yourself. I'm going to have to figure it so that the AI knows to respond, shifting blame(active targeting) to the claim that npc has unlocked and discrediting the claims of those it hasn't come to trust (passive targeting). This is going to be all very complicated, and in this early stage very imbalanced, broken. Which is why I'm going to need more effecting how the npc's make their decisions, how they notice features and build their clue/claim database.

5th, narrative dialogue or essentially randomized characterization/narration, is what I'm calling the extra dialogue I'll need to create. Where claim dialogue is tied to the active targeting, leading to the claims and win or fail states: the narrative dialogue is tied to the passive targeting and will result in the majority of the game's characterization. The passive targeting is essentially how a npc feels about another npc or the player, like a relationship meter, the modification here is that it is modified by the rest of the passengers. What happens is that because of the social situation the npc will assign each character a value from least to greatest (liked) and, dependent on the frequency of positive to negative responses from each character to the npc, assign biases towards those characters. This both effects how the npc will respond to the player's requests but if the npc will 'believe' the player. Certain npcs with a higher rating of the player will need less proof to be convinced of the player's claim dialogue, if that claim dialogue is proven wrong that rated will go down though. The importance of the narrative dialogue is... well the narrative. This passive targeting as an underlying feature that effects the active targeting simulates most of the mystery elements in the game. Not only through what amounts to diplomacy and cunning wit in questioning and organizing the group, but on the side of the murder it'll simulate motive and manipulation. The murders active and passive targeting act the same but as to manipulate the groups understanding of the crimes away from himself, and when the opportunity arises it simulates a murder of opportunity. This, of course, is in much later builds. And currently beyond me, but if the character creations work, and the AI movements work then half the work is done.


Tha'rrs the game plan. The five stages as currently designed, each building on previous iterations, slowly building to the more complete project. I don't have a timeline for the entire thing, I have no way of knowing how quickly I'll learn and be able to implement the code into each build, much less work out the bugs, with all of school and work. But it's definitely possible so I'm going to do it

Next time more news on code and art, maybe even some screenshots. Till then, have a good day everyone, and good luck on your projects.

And here we go. Epoche talk 1

Here's the teaser for that project I was talking about... Alright I lied. This, as what happens with most of my projects on the drawing board. This is the cut down, hybrid, mutated, then twisted version of the inspiration of what the last project was. Simply because this one had less assets, less artwork, but more coding... Because I'm okay at the art but bad at coding... So.. for the first project I'm going to finish, I've given myself less room to work on the stuff I 'm good at, but challenged myself much more on the stuff I should start easy on... This first beta can only end poorly. But that's okay, that's what game development is.  So without further adieu, I'm going to talk about Epoche.

Epoche is a procedurally generated murder mystery set on a train. Picture the novel And Then There Were None meets the board game Clue, but set in a verb coin point and click.

(if you haven't you should really watch this film adaptation)

 

 

 

PLOT

 

The player starts out taking a trip, after walking around and chatting with a few of the other patrons the characters in the last three train cars realize the lock on the door has been broken and they are trapped to these last three cars. Soon after this the train goes through a tunnel and in the darkness one of the passengers on the train is murdered. From there it is a game of deduction and diplomacy to figure out who the killer is and have a solid enough argument to convince the rest of the passengers on the train. The catch is that each passenger will claim innocence, and you have to disprove their alibi to the majority of the passengers otherwise they might think you are the guilty party trying to shift blame. If you're just not convincing enough than the passengers will ignore you, the killer though, will probably take you out next. After that it doesn't matter if the passengers believe you. You have to figure out the crime within a certain time. You have roughly three murders to find enough clues at the crime scenes and from questioning the passengers before.. say he kills you. 

 

ALGORITHM

 

So the hard part of an Algorithm.. is the algorithm. I've got a list of features and what I have to do now is decide what I absolutely need to make this a functioning game. With a generated murder mystery it comes down to a balance of having clues that lead with necessity to the murder but not obviously, and leaving enough room for the player to doubt what they've found as happenstance, or even as a red haring planted by the murder to confuse him.