Official development blog

Weaving Narratives into Procedural Worlds, Part 3: Methods

By Kyzrati | Published: November 10, 2016

With Part 1 (Value) and Part 2 (Characteristics) of this series as a background, it’s time to examine the variety of methods Cogmind uses to achieve those goals, which are important considerations every step of the way. This is also what is meant by “weaving,” because there are quite a few individual components working together to reinforce the narrative, and reflect it.

Structure

When creating a roguelike in which a story can thrive, I believe the most fundamentally important decisions involve the world layout and how the player traverses it. For a non-linear story experience, it makes sense to have multiple available destinations at once, be it presented as some kind of open world, or maps connected in some sort of network. Cogmind uses the latter, dividing the world into areas which belong to either the central complex, or branches linked from there but which eventually lead back to the complex. (I talked about this and several related topics in the World of Robots post last year.)

cogmind_world_composition_compact

A simplified breakdown of Cogmind’s world.

An important distinction between the two types of areas is that the story is confined to the branches, meaning the player can spend the majority of their time on the direct route to the surface/end and never even come in contact with story. There are no NPCs or dialogue along that route, and before long anyone who wants story will know where to find it.

Branches are structured such that the more story-oriented ones are generally deeper, and there is a quicker way to loop back into the main complex before seeing much, if again the player is not interested (or too weak, since story areas are more challenging!). Overall this structure is key to the “optional” characteristic discussed last time--players aren’t required to engage with the story,

Most players do at some point start to develop an interest in the story, but it happens gradually, which is beneficial as it keeps the world simpler for new players, while opening up new options for more experienced players. In fact, for better players who may still be unaware of the story, the additional strategic options that stem from integrating story elements with gameplay are one of the primary hooks driving them to explore. For example there are the “manual hacking codes” which often link otherwise unrelated areas by having a code obtained in one area provide some kind of benefits in another.

cogmind_manual_hacking_codes_machines

Using the manual hacking code assist feature added in Alpha 10, listing where and who originally provided each code. (Also works for robot hacking.)

That the player cannot backtrack to earlier areas is crucial here. Taking one route naturally closes off one or more others. Cogmind would be quite a different experience if it were open world, or even just possible to return to previous maps!

cogmind_world_map_concept_final_full.png

Sample in-game world map tracing the player’s path from deep underground towards the surface.

There is a huge amount of design freedom enabled by forcing the player forward, allowing for greater developer control which in turns makes it easier to maintain a more focused and fun experience. Good balance is important in a roguelike, but so is overall flow (not so much in sandbox roguelikes, where players are responsible for their own flow).

Note that all branches are accessible in every world, though the impossibility of visiting them all in a single run presents the player with interesting choices, choices that continue to expand as they learn more about its structure and get closer to the end.

Lore & Dialogue

There is quite a lot of lore in Cogmind, appearing in various forms to provide multiple different channels for the player to explore the story.

Games will naturally embed their lore, essentially the backbone of the story, wherever appropriate for the theme and setting. e.g. books, tombstones, travelogues, etc. At the extreme there are cRPGs which allow you to read inscriptions and text from just about any object, though traditional roguelike environments are only so rich and a systematic/streamlined approach is more appropriate, suggesting that we limit lore to a handful of easily recognizable sources.

One of Cogmind’s primary gateways to lore are terminal records (definitely not an uncommon practice in sci-fi games :P). Terminals can be hacked for background information on various topics, organized so that the closer to the surface/end, the further into the story those topics are sourced. Most of the records are written from one of the factions’ point of view, while records on terminals found in outlying areas might provide other points of view.

All pieces of lore are not created equal, either. Some are more mundane and generally available, while others are designed to be found in special areas, so uncovering the full set of lore and figuring out the story is somewhat of a puzzle that takes time--many runs (and a good enough player to piece together). The content of records may also link to other records, which can in turn be hacked directly from there, giving the lore a web-like form that always entices the player with yet more topics to explore :)

cogmind_terminal_record_lore

Terminal record lore hacking, both via direct links and manually.

If players don’t want to hack the terminal records for whatever reason (and it’s easy not to because terminals have so many other useful functions), then the story doesn’t even come into play there.

Lore is also embedded in “robot analysis” records, which provide a real benefit to players who hack them (accuracy and dodge modifiers against that type of foe), but also describe their components and maybe a bit of story-relevant fluff about each robot’s purpose or history.

Probably the lore feature most unexpectedly absent from Cogmind is item descriptions. Even many games without an emphasis on story (or any story at all) might have flavor text for item descriptions, using that to set the tone. In Cogmind this would be a massive amount of work--so many items!--and more importantly I don’t think having that kind of fluff immediately available for items fits the theme. It wouldn’t be able to do the best job an item description could do without muddying the idea that the player is a robot, and not actually playing a robot. There’s also not enough room to display that kind of info without putting it in a separate window :P. (Note, however, that dozens of items do have lore in the form of terminal records, so it’s not non-existent, just not ubiquitous.)

Dialogue

Lore can also be obtained by listening to NPCs, usually by bumping into them, but sometimes by simply coming into visual range. The content is often just fluff and tidbits from different viewpoints to reinforce the lore, as well as the occasional general tip or strategic or tactical suggestion. For those I try to write them in a way that feels like a logical thing the NPC might say (to a stranger or in whatever the given situation/location is), as opposed to an overt “I am NPC #23 and I exist solely to tell you this out-of-context piece of information.”

cogmind_dialogue_msg_sample.png

Sample dialogue text in the message log.

As mentioned earlier all of these NPCs are off the beaten path to the end, but even there they and their dialogue are very unintrusive, simply appearing as text in the message log, and for a short duration at the bottom of the map view.

cogmind_map_dialogue.gif

An NPC talking as the player moves around.

Similarly, there are a few examples (it’s an underused system…) whereby a short description of some scene may also pop up at the edge like that.

Slightly more intrusive are the modal dialogue boxes used for major NPCs and encounters in some special areas, though the frequency of those is kept to a minimum. It’s quick and easy for the player to simply hit Escape or close the window for those they’re already familiar with (or not initiate them in the first place).

See this earlier post for more talk about the dialogue UI.

Update 170428: I’ve written a more in-depth look at the uses of dialogue in Cogmind here.

Lore Collection

Now that most of the lore is completed and in game, not too long ago a new and valuable feature was added: the lore collection interface. This is a central repository for all the lore the player has encountered throughout all of their runs, where “lore” includes most NPC conversations and terminal records. The contents are categorized by location and ordered alphabetically, where players can skip to a section by simply pressing the first letter of the entry they’re looking for, or scroll around the list to autoload text.

cogmind_lore_UI

Interacting with the lore collection UI (here filled with junk because spoilers :P).

To facilitate lore collection, terminal records the player has never read before are marked with a ‘!’ directly in the terminals from where they are available. And beyond the reference value of having all this info conveniently in one place, the percent bar there at the bottom reveals some of the system’s other benefits.

Players can know just how much of the information about the world they have or haven’t discovered, which tends to encourage them to learn more about the world, a strong incentive to explore when combined with the (correct) assumption that these unexplored areas likely also contain lots of interesting gameplay possibilities!

Players are now comparing each others’ “percentage of lore collected” (a bit of competition), and more importantly can watch their own meta progress in the new scorehistory.txt which also records the cumulative lore value at the end of each new run. It’s nice to have progress meters aside from score alone.

Encounters

Another aspect of Cogmind that fills out the world with story-related content, albeit in a piecemeal fashion rather than any kind of linear narrative experience, is the encounter system. These “mini-experiences” created with scripts and handcrafted map pieces, sometimes with heavy randomization, again reinforce the lore at various points.

cogmind_encounter_sample_TES_firing_range

An example prefab encounter as seen in REXPaint, the program I use to “draw” most of Cogmind’s encounters. One faction is testing the effectiveness of their prototype robot and new weaponry, and what better target than a couple of their sworn enemies? (disabled, of course) There are a variety of things that can happen with this single scenario. A quick-thinking (and moving!) player could blast through the southeastern wall, which is likely along a corridor, and rewire the allies through the new entrance to immediately fight back. Or if the player is spotted and reported not far from this room, regardless of the state of the tests, said prototype robot will likely be dispatched in defense. Or the player may want to attack first and later rescue the allies, or do it to loot the room of its experimental weapons. Or ignore the room completely and stay out of trouble :P

Of course some of these experiences are pure fluff, though many have other implications as well. And while handcrafted, when placed near one another, or when players encounter them in various unique situations, emergent results make them somewhat unique each time. That’s the beauty of mixing handcrafted content into procedural generation algorithms--it’s possible to get the best of both worlds :D

I’ve written more about encounters before in articles on Map Composition and Generating and Populating Caves, though I haven’t shown a distribution sample for any corridor-based maps before, so here’s a new image:

cogmind_tunnel_map_encounters

Procedurally distributed encounters, colored by type.

Localized environmental storytelling is easy to do like this. For example some scrap and broken down robots from two opposing factions strewn across a cave, or an abandoned partially-destroyed base that might still contain a terminal with bits of info as to what happened. This isn’t commonly done in many roguelikes due to the traditional de-emphasis of terrain and props.

Yet More Elements

There are still other features that work to increase the appeal of story in roguelikes, though these don’t constitute entire systems on their own so I’ll cover them together here at the end.

  • Once a game includes NPCs, it’s helpful to include a town of sorts, lore permitting. Cogmind has something like this located in an out-of-the-way area, and it’s a great dumping ground for a lot of those tidbits of lore and knowledge mentioned earlier. Even better, the available dialogue for each run is selected from a larger pool, increasing replayability for a time. I’ve also seen a number of players appreciate the change of pace that such a location brings. Suddenly there’s no fighting, no fleeing, just walking around enjoying the scenery and talking.
  • Secrets! Some topic mentioned in passing in one area might have some implication for another area. Or talking to one NPC might trigger some event elsewhere (or a chain of events!). Secrets drive exploration, and lore is a great place to sneak them in rather than in a purely environmental sense (e.g. “what’s behind that door?” or “what if I attack this non-hostile actor…”).
  • Multiple endings. Cogmind will have more than one ending, some of which reflect the extra difficulty of different approaches to the story elements, while others are simply different due to choices made. Unique endings reward the player for exploring alternative challenges, and are also an opportunity to tell a little more of the story, too. (Note: Cogmind does not yet include multiple endings--we’re coming up on that soon, though currently a win is already rewarded with a somewhat different ending screen.)

Conclusion

This whole approach to telling a story with a roguelike boils down to the game being “story-backed” rather than necessarily “story-driven.” Revealing the story piecemeal through many different means, where the most interesting parts are the hardest to reach, is a good design to follow since it provides incremental incentives and is more rewarding in the long run. It’s actually easier to win a run of Cogmind than it is to discover the full story, making the latter a potentially even more rewarding experience for some players!

Either way, don’t simply dump the story on the player--that’s the boring method which gets repetitive fast. There are plenty of other options :)

Posted in Dev Series: Story in Roguelikes | Tagged , , , , , , , , , | 6 Responses

Weaving Narratives into Procedural Worlds, Part 2: Characteristics

By Kyzrati | Published: November 2, 2016

In Part 1 I shared several areas where I believe roguelikes can benefit from the inclusion of story elements. Then comes the hard part: actually doing it :)

Because there are certainly a number of ways story can worsen a roguelike experience, the next step is to identify the characteristics of a good roguelike narrative, to show that permadeath and a procedurally generated world don’t have to be completely incompatible with a rich story.

The Story

Of course, at the foundation here is the need to have a compelling story in the first place! That’s kind of the whole point--if it’s going to be a boring, generic story, then the game may as well get by on the merits of roguelike gameplay alone. Having that strong focus is good, but it would be really nice to tap into some of that value mentioned before. What type of story can achieve those goals?

As in all things game design, consistency is key. A story that makes sense due to its consistent internal logic reinforces the whole world building aspect (Part 1). With only partial familiarity, an observant player begins to intuit things, like where to find some object or actor, what impact a particular course of action may have, etc. by filling gaps in their knowledge with what seems reasonable. They may not always be right, but at least that path is available, and it’s an enjoyable process for some. Plus being wrong is fun, too. Because surprises :)

So the most useful story in this regard will be one which makes heavy use of cross-references between the game’s different forms of content and NPC dialogue, attitudes, behavior, everything… to strengthen player intuition and general understanding. Just like solid mechanics anchor the gameplay, so can a solid story anchor the content.

Cross-referencing also makes it easier to avoid one of the bigger pitfalls that can detract from the value of story: linearity. Unless it’s somehow part of an intentional underlying theme for the game, a linear story is almost certainly bad for a roguelike. It works against the freshness of each playthrough intended by the use of procedural generation (not to mention the annoyance of having to repeatedly face the exact same story content on each death!). Instead, make sure the story is easily split up into smaller chunks that can just as well be experienced independently of one another and still be interesting and meaningful (more on that below).

A complex plot with multiple interconnected threads will also naturally be a lot more replayable.

cogmind_major_NPC_encounter_visualization

Abstract visualization of Cogmind’s potential plot-related encounters with major NPCs, colored by faction. The beginning of the game is at the left, and it progresses to completion at the far side. Many of these encounters have implications for later encounters, for the player, or for the world in general.

Notice that the story plays a lesser role in the early game, which as the most commonly replayed segment could grate on the player if there were too heavy an emphasis on static elements. This especially makes sense for Cogmind because there is no initial character generation phase, though other games could even attempt to use the very beginning to introduce a wider array of story-related options.

Story-Gameplay Integration

Story encounters shouldn’t simply be meaningful in a lore sense, but have real implications for the rest of the game, basically giving the player’s actions consequences on a higher level. Most roguelikes have a relatively short feedback loop--fight a battle, rest up, maybe raise a level, then explore until the next battle. Story elements large and small can be integrated into the gameplay itself, adding a unique kind of replay value by being elements the player can choose to engage with as part of a long-term strategy. Depending on what the player decides to do, the plot might affect later events in a significant way, have no impact at all, something in between, or maybe just cause some immediate effect. As the player becomes aware of static elements within the plot, on future runs they may or may not want to trigger certain events depending on their plans, condition, and where they happen to be.

So the story is not there simply for story’s sake, serving as the basis for additional long-term feedback loops. For this reason I try to ensure many aspects of Cogmind’s story have useful (or at least interesting) consequences for the player. This extra dimension to the world creates gameplay deeper than the average pure dungeon crawler, and despite the static elements the approach has proven resilient in the face of many replays. Plus there’s always room to expand the number of options! Even a modest number of interactive elements can lead to a large variety of combinations and outcomes.

cogmind_major_NPC_encounter_visualization_longterm_impact

The same major NPC encounter visualization from earlier, showing those with a direct effect on some later encounter (arrows), as well as those with a relatively significant long-term impact on gameplay (bracketed length).

It’s Optional!

Despite everything said so far in this series, one of the most important characteristics of Cogmind’s story is that it is completely optional.

The game should be enjoyable without requiring that the player make sense of the story to progress, or pay any attention to it at all. Players new to the game can go from beginning to end on no more than the idea that “okay, I’m a robot and there are robots out to kill me… dakka dakka boom.” In fact, every single dot in the diagrams above can be avoided or ignored.

Not shoving the story in the player’s face helps decrease the tension between those static elements and the procedural world, giving the latter plenty of room to breath. Many people enjoy roguelikes purely for the gameplay, or prefer to do their own procedural storytelling, and there’s no need to take that space away. One of Cogmind’s best players played for over a year without interacting with the story, though more recently said he gained a new appreciation for the game after beginning to dig deeper.

At the same time there are other players who from the outset put the most effort into uncovering every bit of the story, lore, and secrets they could find. For the vast majority of the lore and story elements, the player has to actually be curious enough to seek them out, and keeping it optional accommodates two very different types of players.

From a content perspective, technically Cogmind’s narrative is not centered on the player, making it much easier to be optional. This is probably an important factor when developing a rogeulike with story, as it doesn’t need to be annoyingly pervasive if the player holds some lesser role.

Another important characteristic is that the player is spoken to but never says anything in return (no obvious dialogue choices, either). Conversations are short one-way affairs, outside of which the player can simply express their intent through actions and by where they travel. Design-wise this can be a rather limiting factor, but besides keeping the experience streamlined (and easily ignorable!), design restrictions tend to lead to more creative solutions, so I’ve enjoyed working with it.

To recap, in my case the ideal roguelike story presents a compelling, consistent narrative linking much of the content, one that has a meaningful impact on the gameplay, but interacting with it is still an optional way to enjoy the game. Other roguelikes with different goals could certainly take an alternative approach to story elements, or leave them out entirely, but I aim to create a deeper experience than “just another dungeon dive,” both in gameplay terms and with regard to telling interesting and meaningful stories. I believe Cogmind has succeeded at that so far, but there’s still more work to do!

Part 3 of this series is coming next week, to talk about concrete methods for integrating a non-procedural story into an otherwise procedural world (of course taking Cogmind as an example!).

Posted in Dev Series: Story in Roguelikes | Tagged , , , | 2 Responses

Weaving Narratives into Procedural Worlds, Part 1: Value

By Kyzrati | Published: October 26, 2016

There’s been very little discussion of Cogmind’s story here on the blog, which belies its informative role and importance throughout the alpha development process. In fact, following the mediocre stock sci-fi back story given to the 7DRL, on rebooting the project in 2013 the very first stretch of Cogmind development was actually devoted solely to fleshing out a unique story in great detail. Everything afterward would serve to support that narrative in one way or another.

Now that said part of the game world has taken shape and nears completion, it’s time to venture into new territory and discuss the whys and hows of integrating story elements into a genre traditionally light on story. This is the first in a three-part series:

Note that this series is specifically about static narratives in procedurally generated worlds, and not generating the stories themselves! There’s quite a distinction between the two :)

(As usual I’ll be avoiding spoilers, although in this case it’ll mean fewer concrete examples until we get into Part 3.)

Why?

Naturally the first question here is why would we want to include a story at all? Roguelikes are not strict RPGs, and rarely put much effort into storytelling. In fact, there is even the danger of story ruining/interfering with what makes roguelikes great in the first place (a point we’ll touch on several times).

However, I’d argue that when used carefully there are quite a few ways in which story elements can enhance the roguelike experience, making them a potentially valuable addition. Let’s look at some of the benefits, which double as goals when designing a new roguelike.

cogmind_story_integration_graph

The value of story elements in a roguelike, an overview.

World Building

Theme and setting define a roguelike’s starting point when it comes to source material, but crafting a story on top of it all (ideally with multiple plot lines) takes it to the next level. A story requires that actors have motives and goals, and the whole world feels much more alive when for the purposes of storytelling actors have goals other than “approach and kill player.” Certainly mechanics and basic content like actor/object descriptions can go a long way towards reflecting the nature and state of the world, but a full-on plot reinforces it all in the strongest way possible: through action.

Seeing the game’s lore in action really brings it to life, giving it added meaning beyond the words. From the beginning this approach has been important for Cogmind in particular because it strengthens the immersion, a focus of the whole player experience I’ve been going for. And on the development side that same desire to bring everything to life drives development to dig deeper. As the game world expands I’ve often asked myself “wouldn’t it be neat if the player could actually visit that place? Or meet so-and-so?” And then suddenly there they are, being written into the game :D. As a result the world has gotten increasingly dense over time, with each new piece reinforcing one or more others.

Meaning & Purpose

Roguelikes infused with story elements also gain additional layers of meaning on top of whatever might happen in the world, contributing to a more “epic feel”--the world is definitely bigger than the player character, who can have a greater purpose beyond being a “murderhobo.” With the 7DRL version a short back story merely provided the premise, good enough for a straightforward dungeon crawl, while I can’t imagine the Cogmind of today without its deep and engaging story. Whole new maps and interactive NPCs were added to allow the player to influence the world in different ways, because it made sense in the context of the greater narrative.

Interactive stories also offer a good source of memorable crafted experiences, which can be even more complex and powerful than standard roguelike encounters because a story is capable of spanning multiple locations and events. For example, in Cogmind the player can visit a certain area where all hell breaks loose, which in turn affects other areas after that, the details of which could depend on other player actions. The story links different locations and actors in numerous ways, supporting a grander scale that few roguelikes attempt to tackle. (Lots of room to innovate here!)

While exploring the resulting web of possibilities, individual steps along the way provide the player with explicit intermediate goals. This means a greater number of “things for the player to do,” generally a nice quality to have in a roguelike wherever it makes sense. These can be rewarding experiences in themselves, experiences that extend beyond simply killing things…

But it’s worth noting that depending on its execution (covered in Part 3), the presence of a story does not have to completely supplant a player’s own narratives, either. I’ve noticed players coming up with their own little stories all the same, just as they do in other roguelikes, based on the danger, unexpected RNG shenanigans, close saves, and deaths that come out of isolated encounters which may have no bearing on the wider plot. This is important because it’s a valuable part of the roguelike experience, and demonstrates that it’s possible to include a story without drowning out the emergent mini-stories made possible by procedural generation.

So aside from moment-to-moment survival and long-term progression strategy, story becomes a third potential target for player enthusiasm and purpose. This advantage works on both an individual and community level…

Generating Interest & Discussion

Exploration is a fundamental part of roguelikes, be it of mechanics, new content, or simply unrevealed procedural map areas. Having a story gives players yet more reason to care about (or justify) events in the game world, along with hooks which in turn drive exploration to find answers and/or uncover secrets. Not that the extra incentive is required for the game to be enjoyable, but it’s nice to have one more channel through which players may connect with the world.

This feature also works on a wider level, from two people playing alongside one another to the community at large. Story elements become common points of reference, allowing players of an otherwise single-player game to share experiences in the same way they can talk about mechanics and strategy. Lore, locations, NPCs, motives, factions and more all become part of the “common language” that players internalize as they explore the world and what is happening in it. For anyone following along with the latest release, or who isn’t spoiling themselves with the wiki, there’s plenty of speculation to go around. From my perspective, it’s been fun to watch the community puzzling out what’s going on :D

cogmind_story_spoiler_talk_discord

Players talking about secret plot spoilers in public chat :)

Other aspects that contribute to the overall discussion and level of interest, both with regard to those outside the community looking in, and within the community itself:

  • All the minor actors and events that players talk about, some of them quite memorable like “the annoying derelict” as everyone has come to know a certain NPC with no particular name.
  • Story also adds another dimension to seeded runs, where different players may take the same or different approaches to the same set of story-related encounters.
  • Relatively rare events are especially meaningful, including those which rely on a chain of actions. There are a good number of comments along the lines of “I saw…!” and “Have you ever seen?!” Just last week a major plot event added to the game ten months ago was discovered by a player for the first time :P

In all it appears there’s a lot of value in building a roguelike around a good story, assuming it’s done right, but we’ll get to that  :)

Part 2 of this series is coming next week, to talk about the ideal characteristics of a narrative for use in a procedural world.

Posted in Dev Series: Story in Roguelikes | Tagged , , , , , | Leave a comment

Roguelike Celebration 2016, the Experience

By Kyzrati | Published: September 21, 2016

For years I’ve wanted to participate in IRDC, but they’ve always been held in Europe, or as of last year the US East Coast as well. Both destinations are too far away and too expensive for me from here in East Asia, so I definitely paid close attention when news first popped up of a new roguelike event on the West Coast.

Initially the plans for this Roguelike Celebration started out relatively small, however, and as “close” as it was, I couldn’t quite justify the cost in both money and time. It wasn’t until July that the list of attendees started to grow so quickly that I began rethinking my decision to skip it. Even the original creators of Rogue would be there, and Tarn and Zach Adams were coming, too. Clearly this was becoming an opportunity not to be missed, so I contacted the organizers to confirm I could sign up to do a talk (to make the trip extra worthwhile :D) and bought a plane ticket the next day. It helped that my brother lives across the street from the venue, otherwise adding in the costs of accommodation would’ve really pushed the limits of my meager budget since I also needed to arrive several days early to at least somewhat get over the effects of jet lag.

So the stars were apparently aligned and I could finally take part in a roguelike event, and actually the first ever video game-related event I’ve been to.

And the Roguelike Celebration wasn’t just “an event.” As the list of participants snowballed it turned into the largest roguelike gathering in history, one that it felt great to be a part of, and one of the most amazing experiences I’ve ever had as both a developer and fan of roguelikes. I got to spend time chatting with Tarn and Zach Adams (Dwarf Fortress), Brian Bucklew and Jason Grinblat (Caves of Qud / Sproggiwood), Thomas Biskup (ADOM), Jim Shepherd (Dungeonmans), Brian Walker (Brogue), Santiago Zapata (Ananias and a zillion other roguelikes), Sabouts and Rogueliker (Let’s Players), Gabriel Santos (Stone Story), David Craddock (Dungeon Hacks author) and so many others.

At the end of the day we got a group shot of many of the speakers, devs, and organizers:

P1300740

Roguelike Celebration speakers, developers, and organizers. (Click for larger size, or get the full-resolution download here, for all your devious Photoshopping needs. List of those pictured here.)

Not that we took a survey, but it was pretty obvious the average age of the participants (audience and everyone included) was easily in the 30s.

Preparation

Noah Swartz and his co-conspirators did a wonderful job putting everything together over the preceding months, and on the evening of September 16th it was time to check out the venue and prepare it for the next day. This mostly involved moving some tables and chairs around and talking to the volunteers about various tasks to come.

There was no official get-together the evening before, and I wanted to hang out with other roguelike folks if possible, so I planned to wander over there around the time this preparation was likely to happen. Again, it was across the street, so this was quite easy to do :P. Except for the fact that I was also planning to meet up with Sabouts on the way (his hotel was right next door), but the last pic I’d seen of him didn’t involve a big fuzzy beard, so I didn’t recognize him at first and walked right by. (I found him after a few minutes…)

This became a recurring theme at the celebration since many of us had never seen one another (even a picture), and it wasn’t exactly small (~200 people), so even someone that you knew must be there somewhere, was probably not all that easy to find.

P1300586

The main room where Track 1 talks were held, as seen the day before. Track 2 talks were in a smaller corner room with bleacher seating, and several hallways connected both of these to the entrance areas, restrooms, etc. Everyone was not in the same area at the same time.

We saw a group of people waiting outside the venue building, and while I recognized Brian from his frequent Twitter pics, he 1) had no idea what I look like and 2) thought I introduced myself as “John” rather than “Josh” (it was somewhat noisy by the roadside). Shortly after that we had to register at the security desk, and then he realized I was the guy he’d been chatting with for a while online :P. So yeah, things like this happened a lot--the next day there were plenty of “oh you’re [insert familiar name here]!” moments.

Prep also involved Britta and others setting up their atmospheric decorations, including a table covered in NetHack scrolls and many other props,

P1300595

Roguelike shop?

and walls adorned with posters of giant ASCII characters, or the perfect phrases:

P1300619

Mind the stairs.

P1300679

On the main entrance/exit.

P1300602

Eventbrite generously let us use their offices for a day. (This is not a normal public event space.) Curses on these iceboxes were conveniently removed once all the roguelikers dispersed.

Celebration Day

Even having arrived in the US on Tuesday, come Saturday I was still having problems with jet lag, waking up at 3 AM and just kinda waiting until 6:30 to get up xD. No doubt the excitement also played a part there :D

I headed over as early as I might be able to get in, and hung out inside with Tarn and Zach while attendees started gradually filling up the entryway.

P1300607

The Roguelike Celebration is about to begin!

There everyone picked up cool shirts, and speakers even got unique shirts:

P1300777

Such an awesome speaker shirt.

Other roguelike items up for grabs included pins and even @ socks!

P1300780_etc

Socks of RNG +10 for everyone. And a challenge coin for speakers.

(Designs by Allison Hughes.)

At sign-in everyone got a lanyard ID, but the low-contrast colors and small size did not really serve as an aid to finding people, seemingly appropriate at a roguelike event :P. But whatever, it looks good and is a nice souvenir.

Fortunately in my case I had my Cogmind shirt so it was nice to be walking around and have some people recognize me from that, and of course in terms of speakers we could finally identify who was who after their talk. There were certainly those I’d missed for much of the day and only later found--Thomas Biskup and I said as much when we traded places on stage. So many roguelike people!

Overall organization was great, with talks proceeding on schedule and no big hiccups, no doubt facilitated in part by the professional AV help. I was mostly focused on listening to talks and meeting as many people as possible rather than taking pictures, but do have a few random shots from the process that I can share here.

P1300627

Noah kicks it off.

P1300646

David Craddock moderating a talk by the creators of Rogue, Michael Toy, Glenn Wichman, and Ken Arnold (left to right). This was the first time they’d all been together in 30 years.

P1300669

Nicholas Feinberg talks about weeding out boring optimal play, among other topics, in the context of DCSS.

P1300697

Jim Shepard covers the importance and methods behind maintaining a focused tone throughout a game.

P1300710

Tarn and Zach Adams pack the room when talking about their early games and inspirations.

P1300730

Thomas Biskup giving an overview of ADOM’s complete development history, from beginning to today.

P1300738

Brian Walker analyzes approaches for creating good gameplay.

All the talks were streamed live (with around 200 online viewers), and later uploaded to YouTube here. Check them out!

My own talk is here. Also, my slides themselves are actually accessible online as well if you just want to look at pretty pictures rather than watch my ugly mug and listen to that voice--I, for one, refuse to listen xD

I was unbelievably nervous, but apparently I felt it a good bit more than it came through, at least according to what others tell me… My mind was almost totally blank as I talked, which felt extremely odd, and I didn’t even reference any of my notes.

It was actually my first ever talk, and I learned a lot in doing it, so I’m pretty sure I could do a much better job next time! Reflecting on it, I should’ve done fewer slides about a slightly tighter topic, and gone a bit more in depth about each part, since the need to fit so many slides into 30 minutes contributed to my nervous rush. That could’ve also left some time for Q&A, which would be more fun and makes sense for a live event. I’m so used to writing long articles and packing in everything I can, heh.

Still, I’ve never been good at talking to crowds unless it’s completely spontaneous, otherwise I tend to put so much thought and planning into it that I end up paralyzing myself. Ack :P

me

Blathering on about something. (Photo courtesy of Santiago.)

The best part of the talk was where I didn’t have to talk at all, and just showed Cogmind’s [now old but still pretty representative] trailer to demonstrate the value of audio, and that went over quite well. I also later heard that the Twitch stream chat got quite active while I presented.

In terms of other content, I took my originally planned talk topic (innovation in roguelikes) and tacked it onto the end of my newer “becoming a developer” topic, giving it an ever-increasing weight until they were about even and essentially became two full talks in one. (I.e. far too much to properly cover.) As important as innovations are, I’ve never shared the full story behind how I became a developer, and knew it could be inspiring considering my non-professional background, so I really wanted to describe that process. Certainly since the talk I’ve heard from quite a few people who have been inspired to make a roguelike, so that much is a success.

That said, either topic would’ve been much better in isolation where I’d have time to provide more explanations, like those found in the notes which I ignored :)

Other results from my talk include several interview requests, and selling about 12 copies of Cogmind that day (much better than the average day, which is like 2). In fact, according to friends in the audience, several people at my talk bought Cogmind while I was talking, which I thought was pretty neat (and unexpected). I also heard that some people who would like to use it learned about my REXPaint tool via the talk, so that was good.

After Party

We ended up having to leave the venue earlier than scheduled. 8pm became 7pm, and 7pm became “let’s try and shift people towards the doors around 6:15 because everyone will stop every few feet to chat” (yes, we did :P). So no time to really play roguelikes or talk much right there after the event ended, but there was an after party at the Thirsty Bear, a bar with a sufficiently RPG-sounding name.

P1300756

We took over one of the larger upstairs spaces.

Unfortunately a number of people had to retire for the evening, but we still had a good turnout at maybe a few dozen. There the majority stayed for at least a couple hours of meandering conversations, and I really enjoyed talking to Thomas (ADOM), Brian (Brogue), Santiago (Ananias) and others.

But it wasn’t entirely roguelike talk. Meeting in person is great for allowing conversations to drift through all manner of related subjects, and they did. On that note, everyone I met throughout the entire event was of course wonderful, as can generally be expected in the roguelike community.

I wasn’t on social media all day since I don’t use a phone (thus being away from my computer thrusts me back to the days of 90s communication), but there was apparently quite a flurry of online activity throughout the event, and it was fun to browse that the next day. Among the discoveries:

roguelike_celebration_dev_sketches_garret_voorhees

Garret Voorhees did some speaker sketches :)

jeremy_mitchell_cogmind_shirt

I brought a shirt for Jeremy Mitchell because the Cogmind logo was changed to its current ASCII form in 2015 at his suggestion. Many thanks for that.

The End?

Is this only the first of many Roguelike Celebrations? Everyone sure hopes so. Whether you’re a player or developer, I highly recommend participating in the future if possible. It’s just so much fun, and an excellent learning experience, to be around so many other people with a shared interest that many of us rarely (if ever) get to share with our everyday IRL friends.

Sure you can still watch the videos, but that misses out on the all the little interactions and conversations that play out through the day. Getting to know existing roguelike internet friends on a somewhat more personal level is also neat.

Many thanks to Noah, Britta, Asheesh, and Allison for putting it together, and Eventbrite for hosting it. Several considerations for next time:

  • The earlier in advance the date and location can be set and announced, the more likely people will be able to attend, especially those of us who are further away.
  • The intermittent notifications/announcements prior to the event could be posted to a news section of the website to see how preparations are progressing, rather than only by email, since a lot of people miss mass emails for whatever reason. (I know I never even received the last one sent out before the Celebration--wasn’t found in spam or anywhere, but I heard from someone else that it existed and what it said.)
  • Depending on the potential turnout, a two-day event would be more appropriate (based on the size this year) so it’s not so rushed and leaves more time for talk and play aside from the talks themselves.

Keep celebrating those roguelikes!

Update: Roguelike Celebration 2018 happened! I spoke there! It was amazing!

Posted in Uncategorized | Tagged , , , , | 2 Responses

Ability/Effect Systems and Scripted Content

By Kyzrati | Published: September 12, 2016

While most roguelikes include basic attack and defense mechanics as a core player activity, the real challenges are introduced when gameplay moves beyond bump-combat and sees the player juggling a more limited amount of unique resources in the form of special abilities, magic, consumables, and other effect-producing items.

Just as they challenge the player, however, the architecture behind these systems often imposes greater challenges on the developer. How do you create a system able to serve up a wide variety of interesting situations for the player without it turning into an unmaintainable, unexpandable mess on the inside?

It’s a common question among newer developers, and there are as many answers as there are roguelikes, worth talking about here because it’s fundamental to creating those interesting interactions that make roguelikes so fun.

An increasing number of roguelikes are based on flexible entity component systems, though being born of a combination between my old 7DRL and an even older project built before I even knew what ECS was, Cogmind’s abilities are each handled by one of two unrelated implementations: hard-coded routines and trigger-condition-effect scripts.

Hard-coded Routines

The first system is dead simple, the kind of thing that you get when starting a game as a 7DRL :P. But, as a result it’s also the kind of thing unlikely to cause problems down the line as long as we don’t ask too much of it. (That was also the point of starting with it, to make sure nothing would go wrong on the technical side of things in the seven days available to create the game.)

In short, there are a set number of hard-coded item abilities, and an item can choose at most a single type of ability, and also assign a single integer to its variable which usually serves to define the degree of that effect. There are 95 such abilities in all:

cogmind_SA_sample_descriptions

Hard-coded effect descriptions, as seen in source, where “effectData” is the integer referred to above. I removed a couple dozen abilities due to huge spoilers! (I rarely hard-code text like this, but here it was easier to build some strings that require formulas, e.g. many of those not shown.)

If you look closely you’ll see that some are essentially identical to others, differing only by a single factor and thus not really providing additional unique behavior. That reveals one of the limitations of this kind of system: it doesn’t well support slight variations on the same behavior without extra code, something that a more complex system could do quite easily.

But once an effect is coded, it is extremely easy to assign it to an item, making ability-based items quick to design and compare.

cogmind_SA_sample_items

List of sample items with their effects (other stats cropped).

So these abilities/effects are each checked for wherever they’re relevant in the game code, be it when an actor is attacked, attacks another actor, scans an enemy, is hit by a thermal weapon, is caught in stasis, or any number of other things happen. Some are simply direct modifiers to a stat, affecting it only while the given item is active (this was another 7DRL decision--values are always referenced by the function that calculates on the fly all factors which can affect them, rather than allowing changes to modify a value which is stored and referenced, since those changes may need to be undone later and that’s… really annoying and complicated).

In terms of behavior it has maximum flexibility since we can code whatever we want :). Examples:

cogmind_source_SA_jam_communications

Testing for the jamming effect.

cogmind_source_SA_attachment_efficiency

Applying matter savings modifier.

cogmind_source_SA_thermal_absorption

Applying thermal absorption effect.

So far I’ve only mentioned items, but there are a smaller number of non-item abilities handled in a similar manner. Instead of ability types they are sourced from what are called “traits,” of which an object can have as many as necessary (but realistically most objects have none, some have one, and a very few have multiple traits).

Traits originally existed as part of the more involved second system I’ll be describing below, but in some cases it was convenient to borrow them in circumventing the old one-effect-per-item rule instated for the 7DRL, and also giving hard-coded abilities to actors and terrain (to which item abilities cannot be applied, but traits can). Despite the name, these aren’t always passive characteristics, and in terms of implementation they’re not really any different from item abilities (defined by way of a type-and-variable pair), so I won’t go into them here.

In addition to being simple to implement, the straightforward nature of this approach somewhat carries over to the player side as well--each ability-capable item can generally be expected to provide one unique benefit, a benefit that only differs from similar items by a single variable, making them easier to analyze and compare (fairly important in a game where you can equip up to 26 items at once :P)

cogmind_weapon_cycler_compare

Comparing the Improved and Advanced versions of the Weapon Cycler. Technically opening the info window isn’t even necessary to do the comparison, since their respective effect values are also displayed in the parts list’s info mode right on the HUD.

Scriptable Ability Objects

The other system is much more powerful, and while it’s still rooted in hard-coded effects, once the necessary code is in place it can be used as the basis for a much wider variety of possibilities.

This system was actually inherited from X@COM, where it enabled me to turn the X-COM world and ruleset into a fantasy game complete with classes, unique special abilities, dozens of spells and special items, etc, all in a few weeks. And that was purely via scripting--no code at all! (Around that time, other non-coder types were also able to use it to create interesting behaviors for their own mods.)

So with that as a background, let’s look at the underlying system that makes it possible…

“Abilities,” or really anything that might affect something else, are a type of (C++) object that can be created and assigned to one of the game’s primary object types (Entity, Item, Prop). The assignment occurs manually in external data files, and, more importantly for a dynamic system, at runtime by other abilities as the game is played.

Abilities themselves are defined in their own data file, by listing the trigger, conditions, and effects of each. Those individual components are all defined in source code, and work as follows:

Triggers

An ability first specifies what causes it to take effect. Only one such “trigger” is allowed per ability, and at relevant points in the code the engine explicitly checks for applicable triggers. Example triggers include being hit by a projectile, moving next to a prop, a robot exploding, seeing another robot… dozens of them.

Effects

A single ability may have any number of effects, or multiple effects from which only one or some are chosen (the list can be weighted if desired). Example effects include dialogue, explosions, modify AI behavior, spawn an object, convert one object into another… again dozens of available possibilities.

Conditions

The key to making the whole system dynamic is conditional application of triggers and effects. Those which only happen under certain conditions allow for much more interesting possibilities, as well as more complex relationships and behaviors. Thus both triggers and effects may be controlled by any number of conditions. Examples include a random roll, robot stat values, distance from player, what faction a robot belongs to, how long the ability itself has been in existence… (once again, many dozens :P).

Multiple conditions can be combined on the same element with the syntax A|B|C, and there is even syntax for more complex conditionals, like “A|[B|C]” is “A and either B or C”. Effects with conditions can also use the “contingency” system, so that a certain effect might only take effect if an earlier effect from the same ability did not occur for whatever reason (one of its conditions failed), or all previous effects failed, or all succeeded, or basically whatever :)

To demonstrate all the primary components working together, I’ll dissect a single “ability,” in this case really an event, that can occur early in the game when you visit the mines:

cogmind_SA_sample_script

The MIN_Helper_Spawn script.

This particular ability is assigned to an invisible prop used to facilitate location-based events. PROP_INTERVAL is a trigger checked once every turn for any prop that has one, but in this case there are conditions: it won’t be triggered unless P_PLAYER_RANGE is within 10 cells, and its position is also visible to the player (the “(1)”, as opposed to (0)). When the player approaches and successfully triggers it, as per the SPAWN_ENT effect it will create a new entity (robot), but only if the effect’s conditions also pass, which in this case requires that the player not already have a Mining Laser in their possession. This effect, like many others, must specify a number of additional details describing the result, here the NUMBER and type of ENTITY to spawn, its FACTION, and optional values that tell it to FOLLOW the PLAYER and assign it another ability to define future behavior (Min_Helper_Helps1). When this entity appears it also says a line of DIALOG.

cogmind_SA_sample_script_result

The same script in action.

All components (triggers/conditions/effects) might have various data parameters that help specify more about its behavior, such as AI details for spawning actors, the shape of an effect area, how to treat various special cases, and more. There are also generic data values applicable to most all components, allowing any of them to create log messages, particle effects, etc.

On that note, the system is fully hooked into the code-external sound effect and particle systems, so composite content can be created without touching the code at all.

It’s also tied into a system of global world state variables, to control the plot and other situations stemming from that--useful for conditions! For example, there is one NPC encounter that only occurs if you destroy a certain group of robots, but you have to get them all, so each one destroyed adds to the global counter, and later when you reach the NPC’s location one of its SPAWN_ENT conditions is that counter which must have reached the required number.

Effects may also mark objects with traits (mentioned earlier) that appear in conditional expressions, allowing even more complex relationships that can evolve over time. This application of traits would be more appropriately named “markers” given how they’re most commonly used. For example, there are a few special places in the world where an entire section of wall opens up when the player simply approaches. When created, as per its prefab definition each of those positions is marked with a specific trait. Nearby on the ground is an invisible “ability” object that triggers when the player passes by, and the effect is to send out an invisible explosion which checks for that trait on any walls that it hits, which are then “opened” using a particle effect while the original walls themselves are destroyed/converted into floor. Hm, can’t demo any of these here because they’re all secret :P

Even more interesting are abilities that actuaflly assign abilities to other objects, like the Molecular Deconstructor, but details on that bad boy are classified.

If absolutely necessary, for extra special cases the ability system can also hook into unique hard-coded behavior via the SPECIAL effect. When developing the original system for X@COM, I avoided relying on this one since the goal was to allow ability scripts to be able to define just about anything the game was capable of without access to the source (to empower modders), but with Cogmind the more important goal has been to finish the game, while some of the special events have so many wide-reaching consequences that it was deemed too much effort to make the necessary abstractions to further expand the system. Better to hard code and move on. Still, only a tiny percentage of effects are hard-coded, averaging about one per map (compared to hundreds of text-scripted effects associated with objects).

At heart it’s really a pretty simple system, but you can imagine the number of possible combinations here is massive, even with only a modest number of components of any one type. So with the right hooks into the code, and a script parser to make sense of a list of triggers, conditions, and effects, this can be used to create some cool stuff :D

A shorter version of this post previously appeared on /r/roguelikedev under the FAQ Friday by the same title, where you can also see how other roguelike developers approach this same topic.

Posted in Mechanics | Tagged , , | Leave a comment