Game Diary – Cinematic Storyboards

As Skazka moves closer to having playable levels, I’ve been working on some of the non-gameplay systems, like cinematic triggers and playback. Triggers are invisible things in the game that activate events. In this case, that means swapping the camera to “cinematic mode” so it can play a video for the players.

Below is is an example of a cinematic trigger and camera. The red sphere is the trigger, and it activates when a character enters its volume. Each trigger contains information on which cinematic to play, which is passed to the cinematic camera and projection screen (seen above the trigger) for playback. This way multiple triggers in a level can all use the same cinematic camera and projection screen. When the cinematic ends, players either return to the level, or move to the next level.

An example of a cinematic trigger and camera in a Skazka level


Yet even in this relatively simple use-case of cinematics, a number of design questions arise from the multiplayer context. For example, if networked, can one of the players skip a cinematic, and if so, what should they do while waiting for the other player? The same issues come up in terms of pausing playback. So far we haven’t discovered an obvious solution to these issues, but it’s a really big consideration for the whole team. We firmly desire to provide a positive play experience while both mitigating the possibility of boredom and avoiding trolling, and those are really challenging things to design around.

But at least in the short term, our current focus is on local play, which alleviates a lot of these problems by virtue of both players being in the same room. Thus we can focus on the more story-driven challenges of game narrative, which is creating a cool play experience with engaging storytelling.

To that purpose, I’ve been storyboarding some potential cut scenes to see how effective the “fairy tale” style of narrative is in the context of the game. I’ve had a number of volunteers for this initial round of focus testing, and I’ll be extremely interested (and nervous!) to see how they react to what’s there.

As a teaser, here’s some of the storyboarded art:


For these early-stage purposes, I just tossed these and the other pencil-drawn images into iMovie and created a rough idea of the order, time displayed, and potential panning/zooming. For the final product we’d like to add small animations to the characters and backgrounds, but that level of polish is unnecessary this early in the process.

As always please send questions or comments to!

Game Diary – White-boxing update!

This past month, a handful of people having been asking about this blog, why the lack of updates, and what’s happening with Skazka. The answers are 1) it’s getting revived to have shorter, more regular posts, 2) I’ve been really busy working on Skazka as well as several outside programs, and 3) Skazka‘s core mechanics are (loosely) in place so it’s almost to a playable state! This means we should be ready for an initial round of external playtesters by the end of the month, which is both exciting and scary!

Exciting because we now have a chance to test out a couple complete levels to see what works and what doesn’t work, and scary because the game is still in an extremely white-boxed state. White-boxing means getting the core mechanics and ideas in place without any of the nice graphics. It also means there are a lot of known (and unknown) bugs.  In Skazka‘s case, the game currently looks something like this:

Birch forest level’s white-boxed state.

The background and environment appearances are placeholders, as are the character assets. This is of course very different from the target style below, but for white-boxing purposes that’s totally okay.

Birch forest environmental concept art…obviously we have a long way to go getting this into the game!

White-boxing isn’t about visuals — it’s about core functionality and design.  How do the controls feel? What do players do when placed in this world? Is the most bare-bones peek into this world compelling or fun in some way?

As much as it’s tempting to make the game better and more polished — to fix all the known bugs and iterate on the user-experience in the comfort of my own workspace — it’s also important to get fresh, outside eyes on the unfinished product as early as possible. This means we have a better chance of fixing fundamental problems before they become integrated in core features (at which point they can be very difficult to rework).

So again, both exciting and scary!

Next week I’ll be talking about some of the changes to character mechanics and how that’s influenced the puzzle design we’re currently prototyping.  Thoughts and comments are welcome as always at!

Game Diary – Storytelling and Writing

In very good news, a friend from way back is working on Skazka to help with the writing! Patrick shares my love of Russian fairy tales, plucky girl protagonists, and grumpy wolves, so I think it’s a great fit — especially since programming the actual game is occupying most of my time.

I already had an overview of every in-game cinematic, which will ultimately be an illustration with limited animation plus a page of dialogue (concept shown below), but I didn’t have a script written out for more than a handful of scenes. Some of the optional scenes were even more placeholder with no more explanation than “Katya and Volk do something cute.”

Storyboard sketch of how the dialogue and story will be displayed in in-game cinematics.


So when Patrick offered to help, I jumped at the chance to collaborate!  He’s currently providing all scripts associated with the cinematics, and this has already proven fruitful (and quite a bit of fun). The notes I made for each cinematic don’t include a lot of “emotional” information — they’re more like stage directions that describe the scene and actions (intended to guide the illustrative process) but without dialogue.

Patrick asked me what I wanted, but rather than spend a lot of time agonizing, I just set Patrick loose to do as he pleased. This worked out extremely well, even beyond moving Skazka closer to completion. In the process of writing dialogue (and in many cases specific actions), Patrick managed to flesh out the character voices.

One of the things I particularly like in the touches he’s added is how Katya is more of a child and Volk more of a wolf. This in turn has given me better direction for their smaller scale interactions.  For example, I knew I wanted an optional scene where Katya circles an ovoo (a sacred stack of rocks in Mongolian culture), but Patrick brought it to life with Volk’s interaction:

Before them stood an ovoo. Katya began to walk around the shrine, but Volk cocked his head. “What are you doing?” he asked. “Walk around the ovoo thrice,” Katya answered, “And we will be protected on our journey.” Volk seemed doubtful. “Are they not just rocks?” But he joined her a moment later.


At least to me, Volk is quite a bit more charming as seen through Patrick’s eyes than I’ve managed to make him on my own.

Question or comments?  Feel free to post below or email us at!

Game Diary – Coop Networking in UE4

As promised, here’s a little more info about what I’m currently doing for Skazka‘s networking infrastructure! Since Skazka is cooperative, it’s important that both players know where the other one is and what they’re doing. This may seem like a pretty straightforward task, but remember that the server is replicating information to clients.  What a client can directly manipulate is rather limited as you can see below:

Skazka replication on clients and server.


This is what’s called a Dedicated Server model, where the server maintains a “authoritative” view of the world (in Skazka‘s case, dictating the state of interactable objects and NPCs and maintaining a list of all players and characters in a current match up) and the client machine only has direct access to its player’s controller and the character associated with this controller.

The Listen Server model is not much different except one of the players is the “host” of the game — providing both the server functionality and hosting that player’s controller and character.  Although Skazka is currently set up as a Listen Server, the Dedicated model is a little easier to conceptualize and what works on one should work on the other, so we’ll just go with this!

So assuming a Dedicated Server model, any time there’s a player interaction, several things need to happen:

Monitoring actions and replicating animations from client interactions

First, a player provides input, which results in some character action (in this case, Katya’s strike). While we ultimately want the server to handle this input (deciding what she hit and how it will react to this hit), we first need to provide the player with immediate feedback that something has happened. In this case, we play Katya’s strike animation locally (i.e. on the client machine) so the player knows the game is responsive. Only then do we ask the server to handle the player’s input.

In Skazka, I’ve set it up so that a lot of checks happen on the client’s machine (e.g. did a strikeable object get hit at all?) before bothering to send data over to the server, but the server still has its own checks (mostly to prevent player cheating) before it decides how to update the world. Was an enemy hit? Was an object destroyed? These changes will be reflected on the server and then replicated back to the client — at which point the player will see the results of the strike.

The server will replicate these results to all clients, but we also want it to notify the other player about Katya’s change in animation, so that this player will see Katya performing the strike. Otherwise we’d get weird-looking situations, where the other player sees the outcome of the action without seeing the action itself — or if things get wonky, the action might happen after the outcome.

Guy Collins made a cute animation about lag that illustrates how bizarre this decoupling can be, and while the animation is over six years old, it’s (unfortunately) still relevant. Although he’s specifically talking high latency, this will happen in poorly constructed systems as well.

For example, Skazka has a mount ability, which allows Katya to ride on Volk’s back as a team-up move.  If they’re sufficiently far away, the character requesting the mount team-up will instead call out to the other player. This may not seem any different from the earlier strike example, but in this case, the animation that plays is dependent on the client knowing the location of the other player’s character.

If we look back at our initial doodle of the system, this is a big problem, since the client has no information about any other players or characters. Of course the server has this information, but now we need to wait for the server’s response before playing an animation and this is way too long a delay in terms of controller responsiveness.

Fortunately Unreal gives us what we need via GameState and PlayerState — specifically PlayerState in this case. PlayerState represents a particular player and attributes of that player.  Normally that’s the player’s username or their points scored or whatever, but in Skazka, our PlayerState subclass includes things like which character (Katya or Volk) this player is currently controlling. Since each player’s PlayerState is replicated to all clients, we can locally access the other character and therefore that character’s position. The server still needs to update the character state etc, but we can at least play the “Call” or “Mount” animation immediately before having the server update the state of the world.

Questions or comments?  Feel free to leave feedback here or contact us at!

Game Diary – Networking

Making online multiplayer games is a risky, painful, time-consuming endeavor for any studio, but it’s particularly difficult in indie development.  Network functionality isn’t something that can be/should be slapped on at the end of a project, so if you’re going to make that choice — or even want to have the option of adding support later — it’s something you need to think about early in the project’s development.

While I’m only adding the networking skeleton now (and intending to hire on a networking programmer should Skazka prove successful as a local multiplayer), even building out that skeleton is a big task that has long-term ramifications on the viability of online aspects in the future.

Skazka is built around interacting with the other player character and game environment, and networking requires a consistent model between clients and server, so that everyone sees and interacts with the same world state.  For security reasons, non-player objects generally only exist on the server, so when a player interacts with another player’s character (or something in the environment), that interaction must be handled by the server, which determines if the interaction happened and how to update the state of the world to reflect this.

This requires a really good mental model of what you’re wanting to accomplish in addition to a lot of low-level understanding, and I built Skazka in Unreal Engine specifically to take advantage of their networking infrastructure.  While I still need a good mental model, UE4 handles many of the gory details of replication (the consistent model between server and clients) as well as provides the framework for handling input validation (e.g. to prevent cheating) among other things.  This is a good overview of their system!

Another thing UE4 directly provides is the CharacterMovementComponent class, which handles replication of the player character’s position/orientation/etc between server and clients.  That is, when a player moves their character, that movement needs to happen clientside (so the player can see an immediate update), and serverside (so the server can maintain a consistent model of all characters and notify other clients about these changes).  The CharacterMovementComponent handles all movement requests from clients to server by considering the order of input and movement timestamps.  The server takes this information to create a “definitive” view of the world (which is then replicated to the clients — potentially adjusting what a client sees locally).

As you can imagine, this can get very complex and is essential for providing a functional networked game.  Here is a tutorial Zachary Burke provided on extending the CharacterMovementComponent class for replication, since Epic’s documentation only lightly touches upon it :P.

I’ll try to make more detailed blog posts on what I do in Skazka specifically, but networking is such a big topic, I just wanted to point you to some great resources for now ;).  Comments and questions are always welcome at!

Designing for Disability in Indie Games

I’ve been thinking about designing for disability a lot lately, because the reality is, for all that indie games feature more inclusive content, the play itself is often far less accessible to people with disabilities than mainstream games. There are many reasons for this (time and money being the big ones), but it remains a fact — and for me, at least, an uncomfortable one!

Before I go any further, the tl;dr is this: consider some of these basic problems a person with a disability might encounter in your game genre, and incorporate the recommended solutions as you plan out your game and development milestones:

The longer discussion is a bit more complicated, of course.  Indie games are made by small teams, yet they’re increasingly expected to put out products that feel as full-featured and compelling as a (short) mainstream experience.  This is an enormous challenge for a team of six or eight, and downright insane for a team of one or two.  As someone in the second category, my coping strategy is primarily not thinking about it too much (and not giving up my day job), but I recognize these are not always options for developers.

And yet I still think it’s important for us, as a community of developers, to address (or at the very least acknowledge) this issue.  1 in 12 males are colorblind, and 20% of casual video game players have a disability.  For people with chronic illness and health problems, games may be a primary source of entertainment — even more critical because they don’t have the option of other hobbies.  And while the casual and Triple A space seems to be shifting to accommodate these players (given the statistics, it just makes financial sense!), the indie space remains a crapshoot.

For example, flickering lights are an issue in the indie space, and I specifically bring it up, because I’ve had to “playtest” indie games for a photosensitive friend, and many games fail this accessibility test.  Perhaps this love of flickering lights is nostalgia for retro games, but let’s not forget those had issues, even back then (most spectacularly the Pokemon cartoon seizure incident of 1997).  And while these games are some of the most amazing experiences to date, I personally don’t think the ability to trigger epileptic seizures is the reason we love them.

So even if we as developers don’t have the time, money, or inclination to change our designs, at the very least, warnings and labels are easy enough to slap on (saving disabled people both money and potential physical backlash). But if you do take fifteen minutes or so to read through Game Accessibility’s basic guidelines, you’ll notice that many accommodations require minimal changes (particularly for players with visual and auditory disabilities), and many of the requested features (things like readable fonts, subtitles/captions, and remappable controls) are things able-bodied players will want anyway.

My point is not that we as developers will always be able to accommodate everyone.  My point is, as people who received comfort and validation from games and therefore seek to “give back” to the community with our own visions and ideas, we should be aware that the design decisions we make now may keep our games from reaching the people who need them the most.

As always, feel free to comment here or send e-mail to!  I’m currently making a list of things to consider for Skazka to make it as accessible as possible, but if you are a disabled gamer and have particular thoughts on this issue, I’d love to hear them!

Game Diary – Birch Forest Backgrounds

Here’s some of the line art for Skazka’s birch forest backgrounds to test style and tiling.  The forest’s make-up is primarily birch and aspen with some alder and larch.  As the game moves into “deep forest” (i.e. the taiga), coniferous trees begin to dominate.

Fun fact: the taiga is the world’s largest land biome, spanning both the Eurasian and North American continents.

Game Thoughts – The Language of Night in the Woods

I haven’t yet completed Night in the Woods, but it’s been a joy to start playing after many years of anticipation.  One of the most obviously brilliant aspects of the game is the writing, which is snappy, dark, funny, and sweet, but when I say the “language” of Night in the Woods, I’m talking about more than just words.

While dialogue is one way to convey information to a player (and particularly important in a story-driven game like NitW), it’s generally not a good idea to trust the player to pay attention or be fully invested in the story or characters — no matter how good or central to the experience.  Also the way people read or notice information will vary, so it never hurts to tell players twice…or thrice…or…you get the idea.

Consider the platforming mechanic in Night in the Woods.  Early on, the game forces players to jump into trees and along wires (I mean, you are a cat, right?), which helps train players to look for platformable objects throughout later levels.  That said, part of the game’s visual charm is its picture-book aesthetic.  Looks great, but makes it hard to tell what’s interactable and what’s just pretty.

For many of the “adventure game” objectives, icons will pop up notifying the player of dialogue options, entrances and exits, and interactable objects, but there are no such icons when Mae is near platformable surfaces.  This is good, because it encourages exploration and experimentation (and keeps the screen less cluttered), but the game is careful to remind the player to look for platformable areas with various visual cues.

Squirrels routinely jump on mailboxes suggesting they are not just decoration.

One early cue are the squirrels, which run along trees and powerlines.  They also make their way into trees by jumping on mailboxes.  Thus the game shows, rather than tells, us that mailboxes are walkable (and make a pretty satisfying crunch when you do jump on them!)

Mae being a hooligan.

There are additional dialogue cues like when you talk to a repairman, who complains how kids run along the power lines.  His request for you not to jump on them results in a charming bit of dialogue, but it also reinforces to players that they should run along the power lines whenever possible.

This hard-working rat’s grumpy request that you not jump on the power lines is a great reminder for players to jump on the power lines.

To digress a bit, I’m always fascinated by the psychology of what games tell you to do or not do.  For Night in the Woods, players are likely to be genre savvy, and Mae is a naturally rebellious and contrary individual, so doing what authority figures tell you not to do works on several levels.

Other games handle it differently, of course.  In Spec Ops: The Line, your support team tells you not to do things, but the flow of the game forces you to do them — and then punishes you for doing them.  But a central theme of SOtL is the meta conversation and expectation between player and game, so no surprises there.   (Far Cry 4 does something similar with this back and forth between telling players what to do and knowing what players will do, but a little less brutally, I think!).

In contrast to these games, Yo-kai Watch is geared toward younger audiences, and it reminds players to stay safe.  This includes waiting for the crosswalk sign at intersections.  Ignoring these reminders results in rather startling but thematically appropriate events, but again, this game is for younger players, so the “rules” are laid out explicitly.

Basically it’s not nice to trick kids, but it’s acceptable (and encouraged!) to mess with older gamers :).

Returning to Night in the Woods, though, the point is that the game provides at minimum three separate reminders for where and when to platform.  One is an enforced puzzle, one is dialogue-based, and one is visual.  Note that none of these reminders come across as overt or heavy-handed.  It’s just intentional design and carefully crafted polish working together to make a fantastic game experience.

Have other examples of games that use different types of communication to inform the player?  I picked some of my favorite examples, but please comment here or e-mail us at with your favorites!

UE4 Hitbox Demo

I’ve talked previously about hit boxes and strike systems in this blog, but I created a little project to demonstrate this functionality within a larger game system for an EGaDS workshop.  You can find the code base here, which includes steps for running on Windows and halfway running on Mac, as well as some suggestions for where to extend this project’s functionality (which is only partially implemented in many places).

This project also shows my preferred style of working in UE4, which is building out most functionality in C++ but exposing the knob twiddling via Blueprints (as seen below).

Basic strike functionality for startup, hits, and cooldown as exposed to Blueprints.

If you do check it out, please send any feedback to  I always love learning about other people’s approaches to these types of software engineering problems!

Game Diary – Concept Art and Gameplay Footage

I learned about the SXSW Gaming Pitch Competition earlier this week, so the past couple days have been a dash to throw some promo material together.  Along those lines, this week’s blog post features the launching of the official Skazka site along with our first pitch video!


As you can see, the mechanics and graphics are still quite rough, but capturing gameplay proved quite a bit of fun, so I’m excited for where it’ll be after the next few months, when we start applying polish.

This video also teases a super-secret song by Lauren the Flute that’s going to be in Skazka‘s soundtrack, so enjoy the tiny bit that’s posted — it’s going to be a while before you hear the rest ;).