Official development blog

Roguelike Celebration 2016, the Experience

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!

Posted in Uncategorized | Tagged , , | 2 Responses

Ability/Effect Systems and Scripted Content

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

The Alpha Release Cycle: Running a Successful EA Program

Just last week I put out Cogmind’s tenth alpha release, and as we speed towards the end of the open alpha period, now is a good opportunity to look back at the very deliberate pattern behind the development of each release, a repeating cycle that has continued for over a year now.

And not just development itself, either--I’ll also be describing how I use social media in parallel with this process, because that outreach and interaction with the community is important to growing and maintaining the audience necessary to drive a successful indie game (i.e. anything not backed by advertising dollars where you can basically just pay for your potential audience).

Hopefully by sharing my approach here, other game devs might learn something useful, and players will better understand what goes on behind the scenes while waiting around for a new major version to drop :D

One Month

Assuming no special circumstances or interference from external factors, I aim for one major alpha release every month.*

I’ve found that interest tends to wane when letting players wait too much longer than one month for new content and features. I’m sure the appropriate length of time here varies by game--for example something driven more by community content could easily go longer between releases.

A shorter two-week cycle (or even less) could work, but presents its own problems. It means that each release will naturally be less substantial, and therefore less impressive, and fewer people talk about things lacking impressiveness :P

So for marketing purposes it’s better to turn each one into a somewhat larger production, while doing so also increases the likelihood that players will feel that each new release is worthwhile, since it’s enough development time to address multiple facets of progress, namely work on a sizeable chunk of new content, make adjustments to existing mechanics and content based on player experiences, and provide fixes for any previously discovered issues.

As a full-time solo indie there are also residual tasks to deal with (e.g. community stuff) for each new release, and those are better to spread out than trying to maintain some unsustainable breakneck pace (it’s easy to be overwhelmed!), whipping back and forth between front-facing promotional efforts and internal dev work.

Thus a one-month cycle strikes a balance between making just enough progress to be considered significant, while not keeping players waiting. My cycle is divided into three distinct phases, each of which I’ll walk through in detail below.

cogmind_alpha_release_cycle_graph

At its simplest the cycle looks like this, but there are a lot of details in there.

*One month is the ideal, anyway. Looking back at Cogmind’s previous release dates, the true numbers show an average between 5-6 weeks. This is due to said special circumstances and external factors, including a multi-week community event, a recent vacation, and a detour to build the technical foundation for a large unique part of the world. I also write at least several blog posts and other articles per month (like this one :P), and the time to do that has to be edged in there somewhere.

Phase 1: New Content

Half of the cycle, the first two weeks, is devoted almost purely to completing the majority of the release-to-be’s new content. For Cogmind that means working on new maps and the lore, NPCs, dialogue, plot elements, and sometimes new items that go along with them.

So I’ll generally spend the first day of a new cycle sketching map layouts on paper, followed by figuring out what parameters my mapgen utility needs to meet that criteria.

cogmind_mapgen_composite

Working on a variety of maps in Cogmind’s mapgen utility. I’ve written a lot about map generation before.

I also write up a text file for each new map that describes its layout, inhabitants, special encounters, and summarizes its gameplay value in terms of challenges and how it could fit into a player’s long-term strategy. Here is an example of such a file for the Recycling map, one of the less involved areas but it still gives you a clearer idea (warning: minor spoilers if you haven’t played! This is also why I can’t really show files for other/better maps--the spoilers are much worse :P).

All of the above is a pretty organic process because sometimes the map might do a better job of informing the text, and sometimes the opposite is true, leading to a bit of back and forth adjustments between them until they align.

When the map is generating within expectations and will likely play as desired, all the other details start to go in, like prefabs and the other content listed before--everything that combines to make a map come alive.

New content comes first in the cycle because it’s the largest component of a new release, with the most moving parts, and it can be more difficult to accurately predict what its full implementation will entail. Maybe a new area needs a new mechanic to go along with it? Or an existing system needs to be expanded? If a release deadline approaches, little tasks can always be postponed to a future release, but a new major alpha release without complete new content defeats the purpose :P. Therefore it’s safest to get this out of the way early on, which has the added benefit of allowing further development to proceed with peace of mind.

On the Outside

When it comes to promoting Cogmind, my goal is to always have at least one image/gif to show for each week (if not more), which makes this first phase the most difficult in that regard since it is centered around either internal development of non-visual elements or content that I don’t like to spoil. Sometimes there’s just nothing to share!

To avoid breaking that rule, I might spend Friday instead working on some quick UI/visible feature that I can show, just to be able to keep putting something out there. It’s motivating to interact with players and followers over some new development, and from everyone else’s perspective they can see that, yes, progress is being made. Keeping that flow of information going is important.

Whatever I do have, I generally share to Twitter first, and sometimes other forums where Cogmind gets a lot of attention (Bay 12, TIGS), depending on what it is.

cogmind_FOV_testing

This sometimes includes development shots, since those following a game in alpha development are likely interested in the process itself. Above is the FOV transition detection test visualization.

At the end of each week, I also share whatever I’ve been doing to /r/roguelikedev’s Sharing Saturday, usually taking anything I’ve posted to Twitter and using that as the foundation for a post, adding to it notes on whatever else happened, e.g. blog posts, release details, plans.

By the end of this phase, it’s about time to do a progress report for the forums and /r/Cogmind, summarizing recent developments. Again, keeping players in the loop is crucial to maintaining interest, not to mention the responsible thing to do once the very first player has given money to support alpha development. They have a right to know, and it’s not very difficult to post a few words to update everyone on its status! For reference, here are the progress updates for the latest alpha: 7/21, 7/28.

Phase 2: New Features

The next phase is shorter, a week devoted to some bigger feature (or maybe two), either mechanics or UI-related, which is chosen by analyzing and weighing what’s most important to address, what’s most requested, and what’s most feasible at the time.

For Alpha 10 it was the lore collection UI and evasion stat summary window, Alpha 9 was the interactive machine overhaul, Alpha 8 was real-time FOV updating, and so on.

cogmind_evasion_UI

Cogmind evasion readout in action.

Regarding the feasibility aspect, it wouldn’t have been as efficient to implement the lore UI early on, since a good portion of what it was designed to access wasn’t added until Alphas 8 and 9. If implemented before that, it may have been necessary to go back and make adjustments later, meaning wasted effort! I never choose what to work on based on what I want to be doing, but rather what I should be doing at the time, after all factors are taken into consideration.

Developments in this phase are a good pair with Phase 1 because they are generally features that all players can experience. It’s nice to ensure with each release that there’s something new for everyone, especially those who may not yet have the knowledge or skill required to reach all the new content/maps (particularly in recent releases, as those areas are further and further from the beginning of the game).

On the Outside

This phase is much easier to share than the first because it doesn’t contain spoilers and the results are generally worth showing and very recordable (GIFs!). Anything big produced from Phase 2 is shared to all of the places mentioned earlier. Around the end of this week it’s also time for another progress update.

Phase 3: The Little Stuff

In the run up to release, the last week (or more often just 3-4 days) gets a lot more exciting. Accelerating progress is always exciting :).

Phase 3 starts with a review of the TODO list. I primarily organize development through a single text file containing everything from high priority plans, feature requests, known bugs, mechanic tweaks that came out of playtesting or reading about alpha players’ experiences, random thoughts of what can be improved, all the way down to low-priority long-term “maybe” stuff. Any dev time outside Phase 3, this list tends to get out of priority order as new items are thrown in (usually at the top), and priorities can also change with each release depending on the results of the previous release, among other factors.

Thus the first order of business here is to take the top section of that list, a realistic number of tasks to complete that would be nice to include in the next release, and reorder them based on priority.

While the previous phases focus only on the new, this one includes all three components of development: simple new features, changes to existing content/features, and bug fixes.

All bugs are immediately prioritized to the top, since I won’t release until all of them are fixed (there usually aren’t too many, and nothing serious). By leaving this for the end of the alpha cycle, all the bugs in the previous release will have been found (most I find myself while playing, since I know how everything is intended to work and can spot them relatively easily), so all of them can be solved at once.

Remaining items are prioritized according to the same factors considered in Phase 2, in addition to how long each might take to implement.

cogmind_TODO_excerpt

An excerpt of what a post-prioritized list looked like for Alpha 10 (click for full size). This file is actually named changelog.txt, because it also includes the current and all previous changelogs, with earlier versions at the bottom, the current one at the top, and all the TODO items in the middle, where completed TODO items can be immediately reworded and shifted right up to the changelog.

Notice that a given listed topic may also have a link to a forum thread, some other web location, or even a player’s name. Whenever applicable I’ll save links to any relevant discussion on that topic, often useful for reference once I’ve inevitably forgotten the details (way too much to keep track of!). There some of the reasoning will have already been done--usually including my own opinions at the time--thereby shortening the implementation process and offering different points of view against which to compare my more recent thoughts.

As mentioned earlier, this list can be cut short as necessary if release day is approaching, which is why it’s saved for last. I’ll just keep chipping away at it until I run out of time, and anything that’s not done continues to survive on in the list for future release work.

My workload for this phase is not purely time-based, however. Just as important as fleshing out the “something for everyone” aspect of a release as begun in Phase 2 is the desire to ensure the changelog reaches a certain length. Yes, length as in number of lines :P. Examined closely, changelog length is a poor metric for the quality of a release; after all, a single item may take as little as a few minutes to implement, while another line may represent an entire day’s worth of work, if not more! Regardless, appearances are important, so if a release is imminent and the changelog hasn’t yet reached my prescribed length, I may choose to promote a few easier tasks to fill it out.

Besides, we already know that the release is a good one from an experience standpoint, because that’s what the first several weeks were spent ensuring :D

On the Outside

This is by far the most outwardly prolific phase, and as such there is no shortage of images to share. Release day is also not far away, so towards the end of this phase I screenshot features and record gifs (LICEcap is great for that, and I optimize the results with gifsicle), and collect them all into an “Upcoming Features” post in lieu of a standard progress update. Here‘s an example from Alpha 10. And 9. (They’re cross-posted to the subreddit, too.)

cogmind_preview_image_list_alpha10

List of images collected to demo Alpha 10 features.

This is also generally when and where I’ll imply that the public release will be coming within the week, though I never announce specific dates because anything could go wrong and there’s no sense in making a promise that might be broken.

There are also enough images here that I’ll be able to share them intermittently on Twitter, and often save one for the #screenshotsaturday hashtag on Twitter to maybe have a better chance of exposing someone new to the game.

Testing

Pre-release testing is important, but there isn’t all that much of it to do shortly before release given my approach to feature and content development. Each element added to the game undergoes extensive testing based on a list of potential problems prepared both prior to and during implementation, as different considerations are thought of at each stage. Whether brainstorming, designing, or coding, in the background I’m constantly asking “what could go wrong here?”, and jot all those possibilities down so that once the feature is presumably complete, every single condition on that list (which may be dozens of items long) is explicitly tested. It’s essentially a QA job, only in this case my deep familiarity with the source and systems makes it easier to think up hypothetical issues. Integrating this process closely with development of a single feature also increases efficiency, taking advantage of peak understanding of the new system and code behind it.

Before testing a feature, anything in the list which might affect other test items is shifted to the top, and nearly every change to the source is immediately compiled into a new build for testing before moving on to the next item. Compiling is quite fast, as is testing on the game side with the help of debug mode, where it’s easy to teleport around, spawn objects, reveal maps, and basically control any aspect of the game necessary to confirm or disprove issues. Finding bugs before they reach players is a worthy goal, and a good debug mode is essential for quickly setting up test scenarios to stay as efficient as possible.

With that kind of process throughout Phases 1-3, there isn’t as much need for a dedicated testing phase. But in game development, complexity rapidly expands with the number of interacting systems, making it difficult to fully predict the results. A portion of issues will inevitably make it all the way to players. However, testing still plays a vital late-cycle role in preventing the worst problems: crashes or known errors caught by assertions in the code. And there is a pretty good way to keep these out of the release: automated testing.

The goal with automated testing is of course to get maximum coverage, for which I have two main setups.

The first is aimed at map generation, an extremely involved process from building the initial layout to defining its contents with the help of scripts. In this test the game starts normally, loads the first map, chooses a random exit and builds that next map, and continues like that to the end of the game before starting over at the beginning again.

cogmind_autotesting_mapgen

Mapgen auto-test. This one I usually let run for a few hours, directly in the debugger, and that’s enough to feel safe.

The second auto-test is aimed at AI behavior (both central and individual), combat and many of the game’s other mechanics, looking to crash or bug out by repeatedly loading different maps and pitting a wide variety of different opponents against each other. Hundreds of them, in teams. In a game where the world is already pretty alive with robots carrying out their regular duties, this gets pretty chaotic, and chaos is good for testing :).

cogmind_autotesting_coverage

AI/mechanics auto-test. This one is carried out in four separate games running in parallel, all four of which will continue running overnight. If none of them encountered any issues then it’s safe to say it’s ready for release, otherwise any problems are fixed and all four will be run again the next night. Normally the player is automatically teleported to a remote inaccessible location so as to not interfere with the tests (their turn is simply skipped), but if you want to see some of the AIs blasting each other, I recorded that here :D

Testing sometimes overlaps with the latter part of Phase 3 because in a worst case scenario it might be two or three nights before the all clear. And the worst thing that can happen to a player is to have the game crash, so it’s vital that these thousands of runs are played by my laptop first--laptops never complain if the game crashes :P

Release Prep

The day before release it’s time to package it up and get ready to put it out there.

To make sure I don’t forget anything I follow a simple step-by-step checklist:

cogmind_prerelease_checklist

Pre-release checklist (the content is explained below).

Once the game is zipped up, I unzip it and run to confirm a fresh copy is working as expected, and that often evolves into a couple hours of playtesting, mostly for fun (it’s hard to stop :P) but also to be on the lookout for anything glaringly wrong. On average there’s usually one thing that I notice which needs a quick fix, so I do that and slip in a new executable.

Then I pre-write all the release announcements for the next day:

cogmind_release_announcement_prep

Announcements ready!

The first and most important would be the release notes, which give a more in-depth explanation of major features than the changelog can. (Ex: Alpha 10 release notes.) That’s followed by reformatting it for /r/Cogmind, and the simpler versions prepared for other forums.

For each of these announcements I follow a similar format each time (which varies somewhat by channel). It’s nice to have something that works and just follow it, to save time and effort.

I also screenshot the changelog, which will be sent out on Twitter. I always highlight the more noteworthy additions and changes by highlighting them, so the list is easier to parse for those looking to get a general idea. That highlighting carries over to the other forums (and subreddit) where I also post it.

Altogether the prep process can take the better part of a day.

Release Day

Release day itself is almost always a Tuesday or Wednesday, because

  • More people are paying attention to social media around that time, so more likely to hear the news (including non-players who might be hearing about it for the first time).
  • Fewer players will jump on the download right away, meaning I can get in a hotfix (if necessary) before an issue impacts too many players.
  • I wouldn’t want to be dealing with issues over the weekend, which is more likely to be family time.
  • This leaves Monday open to do final prep work, and extra time over the previous weekend to do more auto-testing when I might not otherwise be using my computer for development. (Testing must be done alone, because my dev machine is a five-year-old old cheap laptop :P)

Aiming for specific days of the week is another reason a single alpha cycle might have a few extra days tacked on, as mentioned in the beginning, because I’ll have to wait around for the next window.

With all the real work having been done the day before, first thing in the morning (which is actually evening in the US where most of the players are, because I’m in Asia) I’ll open up all the targets for pre-written announcements and start filling them in--multiple forums, the subreddit, YMLP, Twitter, Facebook, Rogue Basin, etc.

cogmind_release_announcement_posting

Getting ready to post all release announcements.

So I’m mostly on autopilot, which is good because I’m kinda not entirely “with it” early in the morning, sometimes even more so after staying up too late the night before to make sure everything is in order for a smooth release.

With that ready I’ll upload the latest build to FastSpring, the distribution system, at which point anyone can now get the latest version but technically won’t know about it until the announcements are made.

cogmind_fastspring_product_page

Updating a product in FastSpring.

This is where everything is done very quickly, because it can be confusing for a new player if they buy while I’m in the middle of a version transition, i.e. getting a newer version than has been shared.

As soon as the game files are ready, I’ll immediately upload the server file containing the release news and latest version number, which notifies anyone who starts up the game that a new version is available.

Then I release all the announcements at once.

Post-Release

Then I sit back and relax. Sort of :). Each time it’s a huge relief to have yet another release behind me, and I’m generally pretty tired from the inevitable accelerating pace towards the end of a cycle, but there is always more to do!

I’ve got to update the roadmap on the FAQ:

cogmind_progress_160809

Latest iteration of the roadmap. It’s great to have a place where players can both see how much has been done, and watch progress towards major milestones.

As part of the announcements I send out email notifications to owners, using YMLP, a newsletter service provider I can’t recommend. (MailChimp is presumably better, but they’re more expensive and better for high-volume senders, whereas I don’t send out emails very frequently--nor do I have much money xD) Despite repeated changes to avoid the problem, these days the email is filtered as spam for some users of some email providers. There are so many ways to get the news and many players follow progress one way or another so I’m not worried about players not knowing. But I still keep an eye on the YMLP outgoing email monitor to see what portion of owners are receiving and opening the email.

cogmind_release_YMLP_monitoring

YMLP mail monitor.

I’ll also be monitoring the forums, email, and chat for issues with the new release. Anything serious will get an immediate hotfix, which I’ll usually turn around within an hour, and if it’s still release day I’ll probably do it as a stealth update to the existing version rather than going with a minor version increment, also providing a publicly downloadable patch for anyone who already got the release.

For each release there are feedback threads on the forums (example) where alpha players can discuss the latest release without cluttering up the forums with separate threads (and are more likely to offer feedback when there is an explicit place to do it). These and other forum threads are where the majority of my notes (i.e. the TODO list from earlier) on what to tweak will come from.

More recently I’ve taken to releasing interesting stats and player metrics from the previous version, since the leaderboards are wiped with each major release. For example:

cogmind_stat_summary_alpha9

Alpha 9 stats posted here after the Alpha 10 release.

Players enjoy stats, and developers can also learn something from the metrics:

  • 81% of players use fullscreen (i.e. 19% play windowed)
  • 10% use hjkl for movement
  • 21% prefer ASCII over tiles
  • 27% use only the keyboard, no mouse
  • About half of players stick with the default font, while the rest are divided up among many fonts, but among them Terminus and the older default are the most popular

While I’m at it, some resolution stats, which aren’t too unexpected since we can see similar trends in the Steam survey results: 46% use 1080p, 15% use 768p, 26% use resolutions in between, 12% use resolutions above 1080p.

I also post a different kind of release announcement to IndieDB, one that mixes the changelog with all the preview images collected earlier, but wait until the first Friday after release to do that.

It’s fun to stream the new release, which usually comes with a new weekly seed, though my laptop apparently can’t handle streaming anymore so I’ll get back into that when I finally get a new one :P

Conclusion

Even if other devs don’t use this same pattern, the point is to figure out a cycle that works and stick to it! The details will vary by game and individual, but it’s always nice to maintain a consistency that players can appreciate.

I can say that Cogmind would have a very hard time being successful without repeatedly reminding everyone it exists through both visual progress updates and meaty version releases.

From time to time I receive emails and PMs from appreciative players, and while I was writing this article a follower posted one of those comments that makes a dev feel all warm and fuzzy inside, and happens to be really on point here, so I’ll temporarily suppress my ego-blocker to reproduce it here:

“Not to needlessly inflate your ego or anything, but you are without a doubt the best solo project developer I’ve ever seen. Your first playable version of the product was shockingly polished. Your steady stream of updates is unmatched. The super low level of bugs per release is actually straight unbelievable. Your dedication to using your own new ideas rather than easy tried and true mechanics is in a league of it’s own.

Following your progress I feel like I’m witnessing the output of a team of veteran programmers under time dilation.

I don’t know how you do it.”

Maybe there’s some value to this approach.

Note: Regarding the subtitled “successful EA program,” there are definitely other aspects to discuss such as the important issue of pricing, but I’ll write about that another day once I have more data to share!

Posted in Gamedev | Tagged , | 2 Responses

Tutorials and Help: Easing Players into the Game

With a generally lower barrier to add content compared to other games, roguelikes have a tendency to be packed with features and mechanics, and while that doesn’t characterize every roguelike out there (notably 7DRLs and other quick hobby projects), there is an important need to help new players overcome the initial barriers to learning a new roguelike. At least if we want those new players to stick around long enough to learn what’s so fun about it :)

Many roguelikes do borrow a portion of their paradigms from prior games in the genre, be they common keyboard commands or ASCII meanings, and that helps lessen the burden to some degree, but there will always be plenty more to learn. So the question is how do we teach it?

Traditionally roguelikes would come with an explanatory text file, and probably a ‘?’ page/window in the game itself, but little to nothing else. Even today some roguelikes still leave it at that. But game design has evolved quite a lot since the early days of roguelikes, and players are familiar with (and often come to expect) many more help-oriented systems, so we’re seeing an increasing number of roguelikes that incorporate them, especially after migrating away from terminal displays and grid-based, ASCII-only graphics.

Some players are more forgiving than others, and will slog through a slow and difficult learning process in the hope there is an interesting and fun game on the other side, but with easy access to a large and growing selection of games these days, player attention spans and willingness for punishment have declined significantly. To reach the most potential fans possible, new roguelikes need lower barriers to entry so that those who might enjoy the game--but not learning it--make it through that first stage.

That was my starting point for designing Cogmind’s help-oriented features, and here I’ll be discussing the most important ones.

Input

First off, the easiest way to help a player is to make it so they don’t actually need help in the first place :P. Obviously that won’t work for all cases, but as a principle should be applied anywhere feasible. This is most easily applied to input, making important actions easy, intuitive, and accessible based on what players expect: Click on self to open status window. / Click somewhere to move there. / Click on an enemy to aim (shows a targeting line), click again to fire. / Right-click on an object for more information. / Drag item from the inventory to equipment list to attach them. / Drag them from the HUD to the map to drop them… Notice the common theme here is that these all involve the mouse. Full mouse support is a must for accessibility. Players can transition to partial or full keyboard use with time, once they have a grasp of the new mechanics and other components to learn. Why force them to learn everything at once if they don’t want to?

cogmind_drag_and_drop_full

Drag-drop example.

For players who do eventually learn to use only the keyboard (or do it right off), which right now is 26% of Cogmind players, because the mechanics don’t have much overlap with other roguelikes there isn’t a whole lot of existing experience to invoke there. In fact, I can list them all here easily: ‘?’ for help, numpad/hjkl/arrows for movement, ‘f’ for fire, and ‘.’ for wait. That’s it. The rest are unique, and there are a ton of them, but in most cases there is a pattern, or they start with the letter of what they represent, which aids the learning process.

To teach any commands that the player hasn’t figured out on their own there are two separate ‘?’ pages, one for beginners and one for experts. This is to avoid overwhelming new players with a page full of commands they won’t need right away anyway (or at all if they’re using just the mouse); instead the basic commands page provides the minimum amount of commands and information a mouse user needs to use and understand the entire interface. By comparison the advanced commands page is packed with every command in the game, including duplicates (some actions are possible via multiple different keys).

cogmind_commands_basic

Basic commands.

 

cogmind_commands_advanced

Advanced commands.

Also notice that window-specific commands are displayed in their relative windows, and certain parts of the interface (for example the top-right HUD area) have descriptions explaining each piece of data.

But input is generally the lesser fraction of what a player has to learn. Mechanics are the bigger issue!

Mechanics

Some mechanics can and will be understood naturally through regular play, but even in these cases it’s possible to speed up the learning process, not to mention the need to teach other mechanics and stats might be too opaque or unclear without additional explanation.

The old go-to in that case would be the manual. Cogmind includes a text manual that fully explains all mechanics and UI features, weighing in at 8,000 words. But to make it easier to reference and put it where players are most likely to need it, the manual can be opened within the game itself in an interactive form.

cogmind_manual

In-game manual example.

Manuals are good when players have a lot of free time and would just like to browse or even thoroughly read through the manual for information they might not already know, and if the topics are arranged sensibly they can also make it easy to seek out information on a given topic in order to answer a specific question. But honestly specific questions are best handled at the point where they’re asked, and that means context help.

In Cogmind this is how the stats are handled, because the status page, robot info page, and item info page are all a combination of data and graphs, the meanings or implications of which won’t always be obvious to the player, and making them search through the manual each time they need to learn something is a terrible and frustrating requirement. So simply clicking on any stat provides an explanation (or for non-mouse users, pressing Up/Down and hitting Enter on an entry).

cogmind_context_help

Context help example.

In general the way to head off player uncertainty is to ensure that obtaining information is as intuitive, automatic, or direct as possible. Thus another way the UI works to help the player:

cogmind_labels_items_robots_auto

Automated map labels, which help players learn the ASCII (or the ASCII-like minimalist tiles) for objects, and even if they forget them, labels are still always available to speed up the recognition process!

Tutorial

The player’s first contact with the interface and mechanics is of course extremely important, so many games these days start out with a tutorial (or at least make it optional and recommend it). I was originally loath to provide a tutorial at all, because I didn’t want to include immersion-breaking elements (like there’s no main/start menu), especially not right at the beginning. But from an audience-building perspective that would be a massive mistake.

So eventually I came up with an “immersive tutorial” that teaches the basics by introducing them step by step in a few short connected rooms. And these rooms are a plausible place for the game to start, so it doesn’t feel out of place.

The tutorial map, basically an alternative version of the first floor of the game that leads normally into the rest of the game, is only shown three times for each player, the first three times they play. I decided to have it repeat more than once so a new player isn’t suddenly thrown into a new and unfamiliar starting area the second time they play (this being a roguelike, the “second run” will probably come pretty quickly :P).

Also, it’s a very short tutorial anyway, and the second and third time through it doesn’t even include the tutorial messages, so it loses even that little bit of tutorial feel. “Tutorial messages” appear in the message log, hot pink and blinking and with a special beep, and still people sometimes miss them after the first few as they’re eager to explore. Oh well.

While the better alternative, modal tutorial messages, are great for forcing players to pay attention, they’re very intrusive and really ruin the immersion I’m trying to create, so I decided against that approach pretty quickly. (It’s a bit of design conflict between accessibility and the theme, which honestly plays out in many more areas than just this one, and is really annoying :P)

Anyway, each tutorial message is only shown once, and most of the important ones are context-triggered, for example telling you to drag-drop an item you just picked up in order to equip it, and they work in tandem with the tutorial map based on how it’s laid out.

A lot of thought went into the layout of the tutorial map which, unlike much of the rest of the procedurally generated world, is completely static. It’s only four rooms total, and the idea is that the player encounters elements in a very specific order, without simultaneously seeing other elements that would distract them from what it is they’re supposed to be learning at that time (despite how small the area is).

cogmind_tutorial_breakdown

Tutorial map layout with explanation (click for full size).

In those four rooms the player learns pretty much everything they need to have a good time, which is the best way to start any roguelike :D. Sure there is plenty more to learn, but that can all come with time. Also, for comparison check out the regular non-tutorial start area:

cogmind_quick_start_layout_sample

Standard Cogmind starting area. There are only two rooms, where the player starts with more options for gear--all in the immediate vicinity--and then can head over to the next room and leave right away.

Independent of the tutorial map, later in the game as new elements are encountered, there are some tutorial messages to explain features that might be incredibly important but not necessarily obvious--for example bumping into machine control panels to interact with them. At various timed points there are also other more general non-context reminders, telling the player about the manual, or how to save and exit, etc.

cogmind_source_tutorial_message_turns

Turn counts on which time-based tutorial messages are shown.

Meta

Sometimes players like to seek help outside the game, and that’s where having a community comes in handy.

Letting individual groups of players spring up in their own forum threads wherever they may be is nice, and that will happen regardless, but it’s still worth having dedicated forums these days, so I did that and love the community interaction it brings. When players ask questions in a public forum dedicated to a single game, the answer can in turn help anyone else who comes looking for similar help.

I set up /r/Cogmind for a similar purpose, but Reddit is a pretty terrible format for a long-term community that can benefit from preservation of information and more convenient search functionality, so it’s more of a communication channel than a great source of help.

In either case, though, communities have advantage of providing a type of help that isn’t usually provided by the game: strategies. This is something a manual won’t cover, and while in Cogmind there are NPCs who give tips for survival, that can only cover a small portion of the potential useful advice… So player guides are another valuable form of third-party help :)

Many roguelikes of significant size and following also end up with a wiki. In my case rather than wait for someone to create one on some free site with ads and that we don’t have as much control over, shortly after releasing I set one up on my site. It’s almost entirely run by players.

Hopefully all these features (and who knows maybe more to come?) will be enough when Cogmind reaches the hands of even more players in the future!

Posted in Design | Tagged , , , | 7 Responses

Roguelike Celebration--See you in San Francisco?

I’ve always wanted to go to an IRDC (International Roguelike Developers Conference), but they’ve always been in Europe, not easy for me to reach from way out here in East Asia. More recently IRDC has also made its way into the US, but always out on the East Coast, so still not quite within my means.

Then I noticed a number of other developers signing on to this “Roguelike Celebration” event being hosted by genre enthusiasts Noah, Britta, and Asheesh in San Francisco for a day of activities aimed at both players and developers. My brother happens to live right down the road from the venue, only about 10 hours by plane from me, and I figured this is the best opportunity I could hope for short of hosting an event myself, so San Francisco it is! :D

I’ll not only get to meet some Cogmind players who I already know will be there (maybe you, too?), but also a number of other developers, several of which I’ve known only online for some time now.

And I’m not just going as a spectator--I’ll be giving a talk alongside a great cast of other speakers, including devs from Dwarf Fortress, DCSS, Brogue, Caves of Qud, and… the original Rogue :P

You can see the complete list of speakers and topics here.

I haven’t prepared my own talk yet, but I did settle on a topic, which is kind of a summary of the entirety of Cogmind development: “Taking Traditional Roguelikes Mainstream.” So I’ll be explaining a wide range of design elements across the interface, presentation, sound design, and more that work to broaden Cogmind’s appeal beyond the core roguelike audience.

I hope you’re interested, and I hope to see you there! If you can make it, I suggest getting a ticket as soon as possible, because the price will be reportedly be going up after this Wednesday (7/20). (The cost is just to cover event expenses.)

cogmind_30missile_fun

Come celebrate with us!

Posted in Meta | Tagged , , | 2 Responses