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 talktous@akula-games.com!

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 talktous@akula-games.com!

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 talktous@akula-games.com!

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: http://gameaccessibilityguidelines.com/basic.

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 talktous@akula-games.com!  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 talktous@akula-games.com 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 sabraham@akula-games.com.  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 ;).

 

 

Game Thoughts – Last Guardian’s Nest

A new year means a fresh chance at staying on top of this blog!  And while I have a number of exciting projects going on in addition to my day job, one of my goals this year is to prioritize Skazka after I meet some more immediate deadlines.

But before all that, let’s talk about The Last Guardian.  This game seems to be pretty polarizing, but for me, it’s a near perfect synthesis of Ico and Shadow of the Colossus, and as a huge Fumito Ueda fan, I was glad to finally experience his latest vision after nearly a decade of waiting.

I could talk about pretty much any aspect of the game and how perfectly crafted the experience feels.  Even the rougher pieces — the camera issues and occasional halting level flow — actually feed into the ever-present sensation of isolation, vulnerability, and low-level dread.  No other game I’ve played has made me feel so deeply the sense of companionship and inter-reliance that comes from being a small, frail creature caught up in a large, menacing world.

And for now, let’s just focus on that last part: the large, menacing world, so innocuously dappled in gentle sunlight, that is the Nest.

Trico and the boy explore experience the Nest very differently

Trico and the boy experience the Nest’s scale very differently.

The Last Guardian does an exceptional job of conveying scale, and I’d expect no less from the people who created Shadow of the Colossus.  Yet while Shadow presents each Colossus in isolation for the player to experience, Guardian expects the player to navigate this single entity — the Nest — almost as one continuous puzzle.

This sometimes means major backtracking as buildings collapse and the environment changes, but the levels never fail to feel fresh despite this.  For a long time, Metal Gear Solid, was my go-to example of how to create tremendous variety in game experience despite a fairly self-contained world, but The Last Guardian also excels at this.

Part of this comes from the two general modes of play — the boy and Trico.  While you only control the boy directly, when mounted on Trico, the scale of the world changes.  Sections that took you minutes to clamber up take Trico seconds, and conversely, fairly sizeable spaces can get downright claustrophobic when Trico is in them.

The boy and Trico

Expansive walk ways become more modest when riding Trico.

The level design plays with this as well, exploring a number of fantastic and frightening situations, and it leads to some of the most spectacular and cinematic game interactions I’ve encountered since Another World.  One of the Akula Games artists was watching my play-through, and he remarked how seamless the transitions between gameplay and scripted interactions were.  They’re the kind of experience that only happens when a game is allowed to percolate over so many years, and it brings a fresh, indie feel to the scope and graphical intensity of a Triple A title.

But of course, the most important part of The Last Guardian is the relationship between the boy and the creature.  This provides the game’s heart and soul, and it motivates every action within the game.  As fantastic as the Nest is, it wisely plays a support role designed to accommodate this.  Every tower and hallway, every lush gardened terrace and gloomy mining cavity, builds upon the friendship between Trico and the boy, and this masterful unity of art, world, mechanics, and emotion is what gives Guardian‘s ending its transfixing, brutal, bittersweet power.

The Last Guaridan

Game Thoughts – Riding Mechanic in Abzu

Abzu knows the most important features I want in a game are looking at sea life and riding on sea life.  There were animals I knew I wanted to ride like these whale sharks and ones I didn’t realize I wanted to ride like…goblin sharks??  Huh…but sure, totally down with that!

Whale sharks in Abzu.

Whale sharks in Abzu.

One of the interesting things about Abzu‘s riding mechanic is that you truly are just along for the ride.  Most games treat animals like vehicle segments, where the animal is an extension of your (the player’s) will. There’s the Grand Theft Horse style of games like Assassin’s Creed and the slightly more realistic (if sometimes frustrating) controls of Shadow of the Colossus where you coordinate steering Agro while shooting arrows at majestic giants, but in both cases, the animal is something that can be trusted.  It’s a known quantity.

Abzu‘s animals are wild.  They have their own will, and their reactions to you grabbing them range from tolerant, like with the whale sharks, to annoyed, as with the goblin sharks.  Regardless, the animals aren’t there to listen to you.

Riding a goblin shark in Abzu.

Riding a goblin shark in Abzu. Yeehaw!

This tiny touch provides a rather interesting layer to the animals’ scripting/AI, and for me, it gives the creatures an immediate feel of sentience.  One of the most notable sequences was the descent with the blue whales.  The scripting provides a cinematic vantage point so that the whales appear bigger and bigger until you start to realize how absolutely enormous a blue whale is.

And at least for me, when it regarded me up close with its huge, self-aware eye, all plans to ride it (temporarily) went away.  In that moment, I didn’t feel that I had the right to ride on such a beautiful, sentient creature.  It was living its own life.  It wasn’t there to be treated as my toy.

Abzu's majestic blue whales.

Abzu’s majestic blue whales.

Which is kind of the beauty of Abzu.  It’s about interacting in a world that’s much larger than you and full of things older and wiser.  There’s still a thrill to riding around on a bunch of amazing sea creatures that I at least grew up loving and researching, but the game’s not about imposing my will on its inhabitants.

We all just happen to live in the same world, and sometimes it’s fun to tag along for a ride.

What a happy sea dog with his nice, shiny teeth!

A happy sea doggie with such nice, shiny teeth!