Official development blog

A Simple Approach to Player-Designed Robots

I like the idea of designing robots, putting together builds for a particular purpose or with particular capabilities in mind. As I’ve stated many times before, my first influence for Cogmind was the original BattleTech board game, where my friends and I wouldn’t just take stock mechs, but designed our own based on the rules, selecting the right combo of weapons, heat sinks, armor, and special tech.

battletech_mech_sheet_sample

A BattleTech loadout sheet. Sadly all my old BT books and records are at a relative’s house right now, otherwise I might go through them and share a thing or two :)

 

mwo_mech_loadout_sample

A Mechwarrior Online build. I also played all the early PC BT games, and later MW spinoffs and related games, all the way up to MWO (though had to stop some years into it because for some reason my new computer kept glitching out on it, but it’s probably for the best :P).

Even more than being a tactical roguelike, Cogmind is a strategic game about engaging in a dynamic form of this process, repeatedly replacing and upgrading components as you go. And based on the current situation, or plans for what’s to come, you can even pivot your whole build at one point or another.

So if bot-building is a main feature, and players of Cogmind therefore most likely enjoy bot-building, then perhaps there are other areas we could apply this activity? What about designing robots other than yourself?

Actually Player 2 mode sort of has this quality to it, since even if your opinionated ally is technically responsible for putting themselves together, they can only do so using parts they have access to, which like in your case are acquired entirely from their surroundings. If you can control what they get their hands on (e.g. by destroying or stealing whatever you don’t want them to have), you can indirectly control what they are more likely to build. And when they need parts to complete or improve their build, you can also drop stuff nearby and see if they’re interested in it. It’s not quite reliably building your own robot from scratch, but you can influence the outcome, so there’s that.

cogmind_player2_loadout_samples

Player 2 builds shared by various players over the years.

Some players have been known to take Player 2 sculpting to the next level and even try to carve specific parts off their friend (chop ’em up!) in order to force them to use alternatives, either from their inventory or provided by Cogmind.

But yeah, clearly still not the same thing :P

How else could we add robot construction? Well I don’t really want* to go as far as creating a full-blown in-game design system with a dedicated interactive UI like you might find in some sort of RTS or games with a vehicle design element. That’d be fun, but overboard.

*Oh no, on the heels of my previous post about special modes and their experimental test bed nature, I realize that yes I do actually want to try that, and some forms of this could make for a very interesting event xD

It’s got to be simpler than that… How about simply dropping a bunch of parts on the ground and telling them to be a robot?

The Botcube

Say hello to the Botcube, and the new friend it will create for you, or more specifically the new friend you will create with it.

cogmind_botcube_art

It’s a cube. It makes a bot.

Usage is indeed quite simple: Drop the Botcube on the ground and interact with it in the normal way (‘>’ or left-click) and it will start the creation process, turning itself into a brand new robot. Hopefully by that time you’ve prepared a collection of suitable parts for it to use, lying around on the ground within range (or maybe are just dropping Botcube in a pile of post-battle wreckage to see what happens?).

Every couple turns it will suck up a new part and merge with it, until either all potential slots are full or there are no more compatible parts nearby. Then beep boop your new friend will self-activate.

cogmind_botcube_building_tiles

Creating a Botcube mutant. In this test recording, a robot created by the Botcube is represented with a Mutant tile, but will have their own once released.

Your history log will conveniently record the feat.

cogmind_botcube_history_log_sample

The history log also includes some basic information about what kind of Botcube friend you created.

Don’t forget to inspect your formidable new ally!

cogmind_botcube_building_ascii_with_info

Inspecting the Mutated Botcube’s final stats. Its core attributes are static, though as with most robots the majority of their capabilities are defined by their loadout.

Implementation of this feature was somewhat quicker than it otherwise would have been because I already had a template for the process of building a bot from nearby parts, originally used in Abominations, one of the advantages I wrote about in the previous post.

Complementary QoL

As a player what do you need most to facilitate using this sort of tech? At least some way to tell which parts the Botcube is compatible with. The answer is most, but there are a few exceptions, generally including things that AI-controlled bots can’t really use, or aren’t suitable for certain types of allies from an architectural standpoint.

In order to help out with that, while standing on the Botcube (the only position from which to activate it) all nearby compatible parts will intermittently flash. Anything not flashing will be ignored.

cogmind_botcube_compatible_part_highlighting

Botcube compatibility highlighting demo.

This also coincidentally makes it obvious which items are within range to be utilized--double QoL!

Ancient History and Distant Future

In implementing this feature, I’m reminded of one of the times Cogmind was written about in Rock Paper Shotgun years ago, where the author assumed you would also be “building your own allies” in the game. Anyone who’s played in the years since will know that’s not really much of a thing aside from fabricating bots based on existing designs, at least not in the sense implied by the original assumption (designing them as well), but I guess we can have some of that now :)

I bet there will be a range of new theorycrafting discussions to go along with this mechanic as well. Really looking forward to what people do with this one.

On that note, one area of concern here is that Cogmind’s allies are notoriously disposable, by design. You put effort into collecting a few parts you want to see merged into one bot, or even *gasp* take time to plan one with care, only to have it gunned down by the next squad. Yeah that would suck.

We can’t exactly make them invincible, either, but to at least protect against rapid death they’re given high EM resistance, a decent amount of core integrity, and low-ish exposure. With your level of control you can of course also choose to armor them for better coverage, or improve other stats you think will help them survive, or aid you in your situation. They’re essentially akin to a customized Hero of Zion.

There are also more possibilities for this tech, which I had actually revisited in my notes a couple years back to specify that it would be appropriate as a piece of primary content within yet another new map that might happen further down the line. But since I do think this mechanic will be fun to play with, and there’s no guarantee that other map will actually happen, I think this is a good opportunity to at least provide a taste of it!

I can also use this opportunity to hint at its origins for the lore.

cogmind_botcube_art_two

:D

This is the fourth post in a series on new item mechanics. I won’t be covering anywhere near everything (or even the coolest mechanics because I don’t like to spoil much :P), but some of these also offer a chance for relevant discussion of the bigger picture:

Posted in Mechanics | Tagged , | 2 Responses

Special Events Give Back, and Perfect Stealth

Cogmind’s “special modes,” timed events with unique mechanics, can in one sense be seen as the experimental test beds of Cogmind. Sometimes ideas come along that are interesting to play with, but may either not be suitable for the regular game, or I don’t feel the effort and architectural requirements to support them are worth it in the bigger picture compared to what they add vs. all the other content options awaiting development. And although I don’t usually go into building such a mode with the intent to test ideas potentially applicable in the regular game, the results often do inspire such features down the line.

One new example of this phenomenon at work is the ID Mask.

Finally, Perfect Stealth

In short, the ID Mask is a new consumable “disguise utility” that allows you to travel completely unnoticed and untracked in Complex 0b10, waltzing right past enemies if you want to.

cogmind_id_mask_info

The holy grail of stealth tech, if you’re not welcome in Complex 0b10.

The ability to disguise oneself like this has been requested by players since Cogmind’s alpha days (shout out to its main proponent, zxc!), but to me it wasn’t the sort of tech that the game was ready for, be it for balance, architectural, or lore reasons. A confluence of factors have contributed to now being the time it’s finally ready to be designed in.

Using an ID Mask is fairly straightforward, just pop it on to start the clock and enjoy your anonymity for as long as it lasts. I’m sure it can save your butt, or enable some sneaky tactics.

cogmind_id_mask_usage

Hm, more Behemoths maybe calls for more masks? :P

These will also fit deeper into the lore, as I prefer any tech does in order to exist, though some of that lore (and more sources to acquire one!) will be coming in future versions beyond the initial inclusion.

Polymind and Other Test Beds

If you played Polymind you’ll probably recognize this ability, which is actually where the architecture comes from in the first place. As special events do, Polymind introduced new mechanics that needed to be built into the system, both showing us that they’re possible, and also allowing everyone to test how they play out.

Several major new features were required for Polymind to work, one of which being the central idea that “0b10 bots can ignore you.” It’s possible there might still be some kinks in there somewhere when it comes to special cases, but it should at least work as well as it did for Polymind, and adjustments or fixes can be made if necessary.

But anyway this is one example of a mechanic originally unique to that mode now becoming embodied in a specific item available in regular Cogmind! Sooner or later the same thing may happen to some of the other Polymind-specific features, but as of now this is the first.

The first from that mode, anyway.

Another feature I’ve added for Cogmind’s next release takes a chunk of code from Player 2, the mode in which you’re accompanied by what is essentially an AI-controlled Cogmind capable of building and maintaining itself from items as you can.

“P2” introduced a number of new mechanics, some of which I’ve always wanted to include in regular Cogmind (after seeing how they work) but haven’t had the chance. And no, the new feature is not a Cogmind-like ally, although that is something I would like to add to the regular game at some point if I get to it. (There are even perfect lore tie-in opportunities!)

Specifically, what I did was adapt Player 2’s contextual dialogue system for… something interesting ;)

nikolayag_player2_decisive_victory_comment_with_scatter_rocket_arrays

Player 2 commenting (at bottom) after letting loose with a ridiculously massive amount of firepower against some targets in the caves (screenshot provided by nikolayAg).

Among other previous event influences, you might notice similarities between Abominations (Halloween 2019) and the Botcube, which I’ll be writing about next time.

Despite having never proactively used special events to test planned Cogmind features, based on my experiences incorporating and adapting ideas from past modes, and liking how they save time on both implementation and design (while not necessarily ever being something that must make it into the regular game), I’ve even started planning to use this approach for future special events, a way to test features I might want to add.

Specifically for the past year or so I’ve had an idea for an event that could tie in pretty well to a future faction, so long as the gameplay works out when it becomes a central focus. It could be one of the potential Merchant systems.

This is the third post in a series on new item mechanics. I won’t be covering anywhere near everything (or even the coolest mechanics because I don’t like to spoil much :P), but some of these also offer a chance for relevant discussion of the bigger picture:

Posted in Design | Tagged , , | Leave a comment

Teleportation Mechanics

Teleportation. It’s cool. You like it. Your enemies maybe not so much.

The ability to teleport across short and/or long distances to instantly arrive at some destination is fairly common throughout the roguelike genre. Although teleportation can be used for tactical repositioning, or to perhaps reach otherwise unreachable areas (especially if the target is controllable), one of its most common applications is as one of many possible “escape” methods.

Sometimes you find yourself in situations where you’re at a significant disadvantage and would really like some sort of “reset” option, a perfect opportunity for teleporting. There might be drawbacks, like ending up in a worse situation than you left because you can’t control the destination, though as in any roguelike gameplay calculation you weigh the potential costs against the benefits.

Cogmind generally has fewer such direct escape options, but teleport mechanics are out there, if an advanced tech not usually available until the late game.

As a general concept teleportation technology exists in quite a few varieties throughout the world of Cogmind, though the player only has access to some of them. I’m going to go ahead and just make this a SPOILER discussion as far as game content goes, so that I can write freely about related mechanics, so maybe don’t read this one if you’re spoiler averse and not familiar with teleporting.

TR & NEM

So the first and primary form of teleportation is the original alien tech, Transdimensional Reconstructors. These offer very little control over direction, although based on their rules if you’re aware of the surrounding terrain you can possibly get a decent idea of where one might send you given your current position. The High-powered variety has a pretty significant range boost as well.

cogmind_teleport_from_my_stream_200929_warlord_win

Have a clip from my epic September 2020 stream (eventually a Warlord extended win), which was challenged to teleport when things were getting a little iffy, then they got just a little more iffy xD

These were also more recently expanded to support group teleporting--Cogmind and all nearby robots, but it’s only possible to create one of those in a single run (if that), essentially added for a fairly specific use in the extended game.

cogmind_group_teleport

Come one, come all! No wait not like that.

Aside from those, there is the even more chaotic Navigation Efficiency Matrix, which forces unlimited but unpredictable repeat teleporting (basically “teleportitis” in roguelike terms). Like TRs it causes enemies to lose track of your position, which can be great for losing pursuers, but can also make travel quite difficult and if enemy density is high can even repeatedly put you right in their crosshairs while you’re trying to get away.

cogmind_NEM_teleportitis

NEM has a reputation for being annoying, but also has its perks.

Unlike teleportitis in other roguelikes, NEM is “incurable” and stays with you for the remainder of the run, so it’s important to not acquire it unless you have plans to take advantage of the effect. It’s also possible to unintentionally acquire its effect if not careful in a certain area, so those who are aware of NEM’s mechanics might take measures to avoid that possibility, or maybe just risk it :)

The incurability aspect was important for balance, since being able to control the duration or timing of its effect, even broadly, would be far too powerful in Cogmind. While it’s possible to first activate it at a desired time, which affords at least some level of control, the inability to ever turn it off again always looms with the potential to cause regrets…

Limitations

The thing is, in any form (even a random one!), teleporting is a crazy good ability, so we need strong limitations on it to avoid abuse or simply circumventing many of Cogmind’s challenges.

For TR-based teleportation, that limitation is their single-use nature, a pure consumable. It’s a nice hopefully-get-out-of-jail-free card for your inventory, and you can collect as many as you want to fit, though taking up inventory space for each such one-shot opportunity is an obvious drawback, too, so you need to decide just how many it’s worth carrying for your intended goals or play style.

NEM and its chaotic effect is a whole different ball game that can be great for some builds, but there’s always the chance it’ll mess you up, so it takes a special embrace-the-chaos sort of mindset to use. Extreme randomness aside, its primary drawback is the fact that it cannot be stopped once started, leaving even less room for control.

Controlled Teleporting?

What Cogmind doesn’t have is a consistent way to do controlled teleports. Part of the reason such a mechanic was never originally considered is for input reasons--aside from attacks and hacking, which are direct in nature, Cogmind does not have a concept of arbitrary non-FOV targeting input, and I wanted to avoid adding such a method because it starts to suggest all sorts of other indirect targeting abilities, which become new ways to unnecessarily slow the gameplay. By extension teleportation ends up being more of the random variety.

Technically we do already have some teleport control, in fact very precise control, by combining TRs with Dimensional Node Initializers, but that requires having both of the necessary components and also having visited the intended destination beforehand to set up the node. It is a way to make a perfect escape back to a specific location, but obviously that is for preparing specific strategies rather than a general use case.

cogmind_dimensional_node_initializer_explosioin

Oops no that’s the wrong gif, don’t do that.

 

cogmind_dimensional_node_initializer_teleport_use

That’s better, although still not necessarily worth using up these potentially valuable tools, just a random scenario I recorded to demonstrate these items being used together.

Back in NEM’s earlier history when it was still under consideration for more serious mechanical adjustments, among those adjustments I thought about giving it a controllable teleport role, allowing you to stack multiple NEM in order to gain the ability to influence its direction through your prior movements, just still not always doing precisely what you want. I decided against that approach after seeing how others played with the NEM (and trying it myself), which seems to be in an okay spot.

So here we are in 2023 still without a way to manage controlled teleports, what do we do? How about we add one, maybe using this new type of charging mechanism (described towards the end).

In fact I have two new concepts for teleportation tech, which is kinda funny because of how they evolved out of the same idea. Some time ago I wrote some notes on a particular type of derelict likely capable of teleporting. Then more recently while away from those notes, and having forgotten many of the details, I jotted down a few more notes on the subject. When it came time to implement this feature last month, I discovered both sets of notes and realized they were describing two somewhat different systems! Both can fit into the lore rather nicely, though, and in fact be related to one another.

One form of this tech will be introduced now, and the other belongs elsewhere in the lore, a source which I’m not sure whether or when will ever be realized, since as I see it now it’s beyond the 1.0 horizon.

Personal Teleporter v0.10

You may have spotted this little thing among all the art I shared for new items last time:

cogmind_item_art_personal_teleporter

…or not because there was a ton of art samples collected there xD

That is the Personal Teleporter. Clearly an early version of it because it’s not super precise… but it is controlled!

Once fully charged, which takes some time and energy as explained in my deep dive on that mechanic, your next move in any cardinal or diagonal direction will send you off in that general direction, and through any obstacles blocking the way.

cogmind_rough_teleport_sample

A double personal teleport. Normally you’d at most probably have just one, but I’m testing it so I get two ;)

Like with microwarping and spacefolding (also somewhat comparable forms of teleport-like movement!), the interface will warn before your movement command is interpreted as a teleport in case you want to turn it off instead of flying off through the nether and using up your precious charge.

As part of this update I also improved the mouse behavior as it works with both this and microwarping, so that it will always immediately take that action on the first step (and highlight the intention as such) rather than moving to a more distant selected target location then warping, as it currently does in Beta 12.

cogmind_microwarp_active_direction_highlight

While the Microwarp Drive is active, you can see the usual one-step highlight of an adjacent cell indicating direction.

Now just while you’re thinking you got off easy, time to hit you with the drawbacks (no, silly, simply needing to charge the PT is not a massive drawback compared to what you get!).

First a little relevant dev note: When creating new item-based mechanics, internally I’ll generally use more generic names for effects. In other words the name “reconstructor” would not be used in the source code, since that’s specifically an item name, which 1) who knows, may change for whatever reason and it’s a public-facing name for that specific instance of a mechanic and 2) multiple different items could use the same ability with different values, so we don’t want an internal name that matches only one or another. The Personal Teleporter’s capability is known as a “rough teleport,” and now you get to find out why it earns that name (or you can stop reading now and find out later? spoilers :P).

The thing is, not everything that goes through this process might make it to the other side, or at least not take the exact same path to the destination area.

Yes if you’re feeling lucky (and are actually lucky :P), everything will go swimmingly and you’ll be on your merry way, but there is also a decent chance that one of your parts will be ripped off and flung over to some other nearby location. Or may simply not make the trip with you at all. Or if you’re really unlucky it could get stuck in subspace forever.

cogmind_personal_teleporter_part_loss_message_log

I didn’t need my reactor anyway.

So a teleport may result in a need to put yourself back together, if you have the luxury, which if you’re teleporting you may not exactly have, yeah? And if your part was left at the origin (not nearly as common, but it happens!), then if it was something really important you might have to try to find a way back, or do without. There are some other nuances in there which I won’t get into, but anyway, “rough” yeah? :)

I can see some people having a lot of fun with this thing, and I imagine it could get tweaked a bit after playtesting, but there are a good number of levers to tweak with this one.

It should also be noted that this cruder form of directional teleporting doesn’t lose any pursuers, unlike other more random teleportation capabilities, though the ability to pass through walls is probably sufficient to escape a lot of trouble when necessary (albeit perhaps at the cost of losing something, though to be honest my guess is the current cost vs. benefit is generally going to lean towards the latter in most cases!).

After the Personal Teleporter I also added a second source of “rough teleports” which is less rough, though quite challenging to find and has another kind of limitation.

cogmind_rough_teleport_item_art_2

Mysterious.

Stats

As part of this expansion, I’ve also updated the scoresheet calculations to include all forms of teleportation for that particular tally, whereas before it was purely TR types. So NEM and/or the new PT could inflate those numbers if and when acquired, which will also be obvious causes noted in the history log. The Subspace Traveler achievement will also be earned through any of these methods. Early on we only had one form of teleportation, so it’s about time to update these other bits in tandem. The Rincewind achievement is still specifically TR use, since that’s a challenge achievement rather than being discovery-oriented, aimed at acquiring that many TRs to begin with.

Happy teleporting!

This is the second post in a series on new item mechanics. I won’t be covering anywhere near everything (or even the coolest mechanics because I don’t like to spoil much :P), but some of these also offer a chance for relevant discussion of the bigger picture:

Posted in Mechanics | Tagged , | Leave a comment

“Post-Balance” Cogmind Item Expansion

Beta 11 was a huge milestone in Cogmind development, having completed a comprehensive review of all items and their stats and mechanics in order to rebalance where necessary, a process I wrote about in detail last year. The results since then have been great, but what comes next?

Fun. Lots and lots of fun.

Beta 12 was a part of that new direction with its expanded Garrisons, new faction interactions, and the Scrap Engine, but the main thrust is still in progress, aiming to bring tons of new items, robots, and maps for them to inhabit. Heck, Kacper‘s on board and there’s even going to be a bunch of new tiles :)

Despite being under full-time development for over 10 years, and certainly adding a fair share of fun secondary mechanics to Cogmind along the edges to keep things extra interesting, most of the work needed to focus on honing the core experience, and therefore the core content. However, aside from procedural generation and the potential unpredictability of unfolding events, special items and rare encounters are where it’s at when the aim is to ensure every run is fresh and exciting.

Well, after Beta 11 that’s where we find ourselves now, switching focus more and more to brand new elements that don’t need to adhere to any sort of core content accessibility requirements. There’s already a ton of core content--many hundreds of hours worth. Now it’s time for the very rare items, the very hard-to-acquire tech, the very difficult optional opponents, and all the implications behind them.

As part of this drive, for months I’ve been creating over 100 new items, most of them including new mechanics. Some individual items take days or even weeks to build. They’re that crazy.

cogmind_ascii_art_beta13_sample_preview_large_more

Sample ASCII art from among the 100 new items.

At the time of the Beta 11 rebalance Cogmind contained about 1,021 items, a number that I’ve increased by 11% so far, the vast majority of which have not been released yet.

Sourcing Ideas

To come up with new items and mechanics, I never just sit down to explicitly think them up. Good ideas do come spontaneously, albeit inspired by random discussions among players, reactions to various situations in game, even playing other games and consuming various non-game media. And I’m always ready to note down these ideas for potential later use, since after all there’s never enough time to implement absolutely everything, not to mention many ideas must wait for just the right opportunity or location to be introduced.

Having done this for many years now, that list has grown quite long, and now that plenty of new space is coming to Cogmind, space for more outlandish stuff, earlier this year I reviewed the entire list for the first time.

It’s not organized at all, being composed of ideas just slipped in at random locations each time a new one popped up, all filed under the heading “post-1.0 items” that was chosen back during alpha when it was first created.

cogmind_item_ideas_notes_sample

The current beginning of my random still-unused item ideas list. It’s about 800 lines long :P

Here “post-1.0” essentially implies “after core stuff is done,” so we’re clearly at an appropriate junction to do this :) (regardless of versioning systems and the fact that in reality Cogmind is already far beyond what most people would consider 1.0…)

Anyway, it took a while to filter through everything (on the way even removing a few pieces of tech which had since been implemented without even recalling they were listed there at some point :P), but I did pull out a number of ideas that will no doubt be fun to play with. While none of them are central to the coming Beta releases, any time new maps are added a lot of content is needed to fill them out! Peppering them with cool stuff that you won’t see every run helps keep them from feeling too sparse or repetitive.

Balancing Levers

The idea of “post-balance” from this article’s title doesn’t mean no balance.

On the contrary, as you probably know, Cogmind is big on balance, an emphasis achieved initially through adherence to carefully designed patterns and formulas. But then Cogmind is also always expanding with new content that needs to fit into the existing world, either closer to that core or somewhere out on the fringes.

As far as core items go, simple stats are generally sufficient to enforce balance, but the tradeoffs and drawbacks required to balance more extreme fringe items may necessitate unique approaches. Some of the optional mechanisms to use for this purpose are more generic, such as giving an item limited uses, while others are item-specific, such as the Dirty Datajack being overall pretty awesome if 1) somewhat unpredictable and 2) eventually, inevitably blowing up in your face when it detonates a power source.

Rarity and difficulty of acquisition are in themselves balancing factors which allow us to make some new items even cooler than usual, which is essential one of our primary goals here, but most items still likely need their own balancing factors that come into play once acquired.

I’ve organized an overview of some of Cogmind’s special item balancing mechanisms below.

  • Disposable (limited uses): Interestingly I didn’t want traditional roguelike “consumables” to be an important part of Cogmind’s design from the beginning, and they still aren’t really, but technically all Cogmind items are consumable to a degree (they protect your core and have limited integrity), and later in development as I wanted to introduce more and more truly powerful items this was a good excuse to play the consumable design card. It’s a useful one since it offers really tight control, but I prefer to avoid overusing it if there are any other options available, since it’s kinda boring.
cogmind_CPS_tube

The new CPS Tube, a disposable item. You get two shots because it’s mainly meant to be a one-shot thing, but you might miss and that would be too mean.

  • Disposable-adjacent: Instead of a direct 1-to-1 use counter, an item’s remaining usage is represented in more granular fashion based on other factors, for example the new “ID Mask” item I’ll be introducing in a later post.
  • Item integrity loss on use: This concept is fundamentally similar to the disposable mechanic, although not quite the same thing since usage simultaneously weakens the item itself, making it more vulnerable to destruction, and for the same reason damage to the item directly reduces its remaining uses. The idea was pioneered by Vortex weapons, but you will occasionally see more of it where appropriate.
  • Core integrity loss on use: This one’s pretty cool, although applying it generally requires good enough lore or tech reasons. There’s a lot of room to play with core loss in the design, since it drains something you need to survive, but also tend to have a surplus of at various points on your journey, especially if you’re otherwise doing a good job protecting your core. In this case, saving core indirectly supplies you with resources that can be redirected elsewhere That said, doing so could also be risky since the weaker your core the less resilient you are to later surprises! Balancing factors with deeper implications like this are great. We definitely need more core-eating items ;)
  • Deteriorating: An item could degrade/lose integrity for every turn that it’s active. Although introduced in pre-alpha as a potential balance mechanism, this was only ever used for one item (Dirty Datajack!), and even that one was reworked along with the robot hacking system and deterioration is now a completely unused mechanic. It’s kinda fiddly so I don’t like it, but it technically still exists if needed one day. (There is a particular quest item that degrades over time, but that’s a different mechanic since it can happen anywhere and you don’t even have to attach it.)
cogmind_part_deterioration

An ancient demo image from Cogmind pre-alpha with a deteriorating item state listed on a hypothetical item.

  • Unique resource requirement: Unique resources can be a great balancing mechanic (be it via rarity, storage requirements, or other factors), and lots of roguelikes use them--think ammo types!--though in the past Cogmind hasn’t done much in this area precisely because that most common manifestation was simplified into the amorphous energy/matter system (much more appropriate for a game with a vast array of unique weaponry). We did eventually get the Latent Energy Streamer from the Exiles, which takes unique resources to the extreme by adding a whole new geographical resource layer to the world. Honestly that resource should get more use, and definitely would if Cogmind is developed long enough (there are Plans). Looking ahead, one of the new items to come is powered by… other items.
cogmind_latent_energy_visualization_animation_extended_range

Examining latent energy levels in the area.

Overall the more such levers we can add, the more interesting items and strategic/tactical considerations we can create, branching out into different design and gameplay territories. Everything on the above list has existed in some form or another for a long time, so it’s not often that high-level non-item-specific balancing mechanisms are added, but there’s a new one coming soon: chargeables.

Chargeables

We can already indirectly create “chargeable” items (and have :P) by simply giving them huge energy requirements, enough that only a small number of uses is feasible before having to generate more energy, though this approach is technically a bit of a fuzzy limitation that can be circumvented by storing massive amounts of energy in advance, so such items have to be designed taking that possibility into account.

What about an alternative item-centric approach that also essentially enforces a minimum time limit between uses? This way we know the maximum rate at which such an item can be used, plus this kind of item is likely more accessible to builds that don’t have the capability to supply large bursts of energy at once.

Two different ways to implement the same general concept will be more appropriate for different kinds of applications, further expanding the pool of item design possibilities.

When adding any new feature, or in this case a balancing mechanism, it’s important to ensure the UI can keep up with any needs. No big problems there, as charging is a fairly simple mechanic where you have charging and charged states, and it can only be used once the latter is reached.

While charging an item its charge countdown is shown in an adjacent part label, like so:

cogmind_chargeable_voltaic_drivehammer_charge_label

Tag for an attached chargeable weapon.

In this state the item cannot be activated, of course begging the question of just when and how it’s charged. I originally imagined this to be something you could actively toggle, but that would require utilizing the third item state (overload style), which might have other uses for a chargeable item, so it’s best to avoid that approach. Instead the charging happens automatically, as described in the state context help on the item’s info page:

cogmind_chargeable_item_state_context_help

Different object states have also been getting unique context help relevant to their specific mechanics, rather than a generic description of the stat.

The so-called “charge rate” is specified in the item’s description, which includes a phrase like “Charge rate: 20 energy * 35 turns” or whatever its energy/time requirements are.

When the item is ready to be used it’ll play a charge up sound and you are free to blast away. It will also indicate that state directly in its name, in case you want to charge it up then store it away in your inventory for later.

cogmind_chargeable_voltaic_drivehammer_name_charged

They should be afraid. Very afraid.

That said, chargeable items don’t have to be weapons! This just happens to be the first one I created. I wanted a weapon designed around a particular offensive concept but if made as powerful as planned it would be too ridiculous if used in rapid succession, but I also didn’t want to make it yet another case of disposable weaponry and would prefer it become a long-term tool one could reuse again and again if you keep recharging it.

The other chargeable item I put together after this one, which I’ll be sharing next time while discussing a different topic, is actually a utility.

This whole article started out with a discussion of balance, and while I’m sure this new mechanism has potential, I can’t yet say I’m entirely sure just how the balance will work out with these brand new items. They will likely get some tweaks after playtesting, and purely from a theoretical design standpoint I think it may be necessary to at least require that charged items remain attached to retain their charge. We shall see. It also really depends on how they want to be balanced in the bigger picture, as well as how people abuse, I mean use, them :P

This is the first post in a series on new item mechanics. I won’t be covering anywhere near everything (or even the coolest mechanics because I don’t like to spoil much :P), but some of these also offer a chance for relevant discussion of the bigger picture:

Posted in Design | Tagged , | 1 Response

Roguelike-Discord Integration Using Webhooks

When Cogmind’s first commercial version was released in 2015, I simultaneously opened the brand new Grid Sage Forums as the main gathering point for the community, a way to share stories, provide feedback, and generally discuss the game. Back then forums were still one of the most common ways for game communities to interact, and I also wanted to maintain such an outlet over which I had complete control (i.e. on my own server and with my own settings and design) rather than making a home under the umbrella of some other company where we’d be subject to their whims over the long term.

grid_sage_games_forums

The good old GSG forums!

Well… after a year of navigating Cogmind’s early alpha progress with the community on the forums, which were pretty active over that year, Discord came along and became that “other company” xD

Of course the product is different, and therefore we can easily see why it could do such a thorough job of supplanting the forums--it’s simply better suited to this sort of use, hence the now huge majority of games that use it to build engaging communities. Faster, easier real-time communication with devs and other players alike, together with more natural support for multimedia… I guess forums didn’t stand a chance xD

Interestingly, IRC could have been seen as an alternative, or supporting, possibility for community interaction, and there were some who wanted to do that when Cogmind was first released (I was there, too, for a short while), but we have to admit IRC is just not as good for most people--Discord essentially took IRC and made it more easily accessible to the masses, which is apparently exactly what the masses wanted and needed.

For a while myself and a few other players tried to keep the forums active, but the community drive to relocate to Discord was swift and unstoppable…

The forums are technically not dead dead--they still get used as a more official repository for bug reports, or by someone who wants to post something to a location more permanently and easily accessible to all. It’s also my primary outlet for official announcements (this is noticeable when, for example, my release notes are too long to fit on Steam so I link to the forums where I can share them in their full glory because, again, I control the settings to allow that :P). And we use the forums for the occasional REXPaint feature/help discussion, so yeah they have their uses even now.

Roguelikes Discord

Back in mid-2016 a couple of friends decided to make a new Discord server on the topic of roguelikes, and started asking relevant devs like myself to join. I decided to try it out, and it was kinda neat being able to chat with other roguelike players in real time (oh no, we moved further away from turn-based chatting?!).

The Cogmind community started showing up there pretty fast, draining active participants from other outlets (including the main forums, subreddit, and relevant threads on other forums) since it was just so much more natural and enjoyable to engage others via flowing conversations rather than delayed posting and repeated reloading of web pages.

The server became the home of many traditional roguelike communities (small as they may be), and also the “official” Cogmind server, which I like to keep embedded there with all the other roguelikes.

roguelikes_disord_cogmind_channel_list

Current #cogmind channels on the Roguelikes server. We ended up adding more and more Cogmind channels over the years, though most are hidden from the average server member so it’s not too annoying unless they’re actually there for Cogmind content :P

Seven years later we’re still there, with a lot of the same folks cycling in and out over short or long periods, and veteran players mentoring newer ones. We also often get interested in other roguelikes on the server and play those :)

Anyway, Discord definitely has its drawbacks, but it works well as a primary communication tool for gaming communities so it’s no surprise its use has exploded over the years.

Discord Integration?

When a community is heavily concentrated in any one form of social media, you naturally start to think about leveraging that platform to encourage community interaction and improve the overall experience. Discord itself of course wants to capitalize on this effect and promote related features, so it provides an SDK for doing such things.

The first feature some might imagine with regard to using the SDK is at least some form of so-called “Rich Presence,” which is what I considered a long time ago when players asked about that as a possibility. But I didn’t want to bloat the size of the game just for that--didn’t seem worth it.

On the contrary, at the time I realized that I already integrated the Steam SDK by necessity (and it’s a separate build from the DRM-free release, therefore only affecting those using Steam to begin with), so I figured it might be low-hanging fruit without any drawbacks to at least introduce Steam’s Rich Presence as a fun little side project. I did that in 2019 and wrote about the process here.

But integrating with Discord never appealed to me.

Then I learned more about webhooks and had an idea.

Webhooks!

It turns out you can technically do a form of Discord integration without their SDK, using these “webhook” thingies…

Now I’m sure this was obvious to people versed in Discord or even online platforms in general, but even having seen some in action I’d never really known how webhooks work, me being generally ignorant of web dev.

I forget what it was that triggered the realization, but some weeks ago I became aware that 1) without embedding the Discord SDK I could 2) simply have Cogmind send messages to the Discord server, and that was all I needed to know to come up with a potentially cool new feature ;)

Discord’s dev resources cover everything you need to implement webhooks, at least on their end in terms of what you can do and how to format each type of data. On the game side you’ll most fundamentally need a way to make an HTTP POST request to provide the message text. That’ll be handled differently depending on whatever languages or libraries you’re using, so I won’t cover that here.

One important consideration worth mentioning if you plan to send a lot of messages, and want all of those messages to actually be posted: You’ll need to have a way to handle webhook rate limits.

I got my first Cogmind-Discord interface all set up and properly sending messages that appeared on my test server, then I tried to do a bit of stress testing to simulate extreme scenarios only to find… not everything was appearing xD. Okay yeah that makes sense.

roguelikes_discord_cogmind_activity_webhook_stress_test

Me typing to myself in my solo test server as I was building this feature :P

So rather than firing off messages as soon as the game wanted to send them, I had to go back and rewrite it such that 1) there’s a message queue and 2) Discord’s server response is actually checked to see if the last message went through and 3) if not, what’s the requested retry delay and wait that long before continuing with the queue. A little more complex, but good to get that out of the way before releasing this feature to players then having it be an obviously substandard experience!

Fortunately there weren’t many technical hurdles to clear, even for webdev-challenged me. It helped that most of the heavy lifting could simply leverage all the past work on my HTTP interface and multithreading functionality, as I couldn’t see myself wanting to dive into this if I didn’t already have that foundation in place. As is it really was a nice little side project that didn’t suck up a ton of time and could comparatively provide the community with a cool new feature.

Content

Now that we have the ability for the game to post messages, what do we post? What’s relevant for a roguelike? And where does this content go?

First of all, since there could theoretically be a lot of messages coming in, and they could come in at any time, to avoid interrupting normal conversation in the server channels it makes sense to give the output from this thing its own channel. Thus #cogmind-activity was born.

We can still chat there, of course, just generally it would be in response to the info coming in, or even just drop emoji reactions to various events, overall new ways to interact with other players’ runs in progress (or that have recently ended) without them having to actively share any info like a summary or screenshots.

roguelikes_discord_cogmind_activity_icon_scene

Webhooks need an icon to represent the bot, so I threw together a weird, uh, activity scene using random little things my son has collected, alongside my 3D-printed Cogmind from Runia.

I also added a way for the player to manually specify a Discord webhook of their own choosing, in order to redirect all the output from their game to some other server or channel they’ve set up.

As for the meat of the feature, what we’re posting…

Scoresheets

One of the most basic and frequently shared pieces of info about a run is a link to the online scoresheet, which contains a highly detailed summary of pretty much every aspect. I wrote a lot about these scoresheets back when they were further expanded in my Ultimate Roguelike Morgue File series.

This is also the first thing I was thinking with webhook use--players are often sharing these links manually, and the game knows the link, so why not just make it happen automatically for those community members who want to do that?

roguelikes_discord_cogmind_activity_run_summary

A sample run summary output in the wild, including scoresheet links and more.

In addition to the automated link sharing, you can see I also included a short summary of core run data, including final score, difficulty setting and any special event mode, the number of regions visited (good for getting an idea of how long the run really was), and the number of robots destroyed (useful both to show off as well as telling a lot about a run when compared with how many maps they passed through).

Then of course it’s important to know how the run ended, as in whether they were destroyed (and how) or won (and in which way, since there are many win types).

After the links I thought it might also be fun to directly include a printout of their final build state, as taken from the scoresheet itself.

In the above screenshot, notice how the webhook’s name is actually using the player’s name, in this case “szymekc.” This is one of many possible features offered by custom webhook data, and the alternative would’ve been to leave the webhook name static and instead include the player’s name as part of the message itself, but 1) that wastes space and 2) when there are messages from multiple players being posted in close proximity, this approach can make it a little easier to distinguish which run is which (an issue you’ll see come into play soon here).

Achievements

Although each player will only earn each achievement once, there are quite a few in Cogmind (and even more to come!), and many are quite special, so we may as well report on these as well. It’s also the kind of thing players tend to share on their own, having accomplished some significant feat, or even an unexpected or funny minor one, which means another area where automation might be able to contribute to the community.

roguelikes_discord_cogmind_activity_achievement_sample

Achievements appear bracketed and in italics.

History Log… in progress!

One of the major new scoresheet features described at length in part 4 of my Morgue series, Cogmind’s “history log” is meant to read as a sort of story-like summary of an entire run, highlighting special events, important accomplishments or changes, or otherwise potentially interesting or informative bits about the run.

It indeed works out as a pretty nice written review of what transpired, outside what typical numerical data and lists can show, though as is it’s of course something the player, or others, would read after a run is completed (or I guess it’s possible during the run, too, via mid-run stat dumps).

You can see where this is going. Once I got to thinking about what more could be offered via the webhook beyond the normal go-tos, the history log really popped out as an enticing option. We already have the power to describe much of what’s going on in words, let’s use it! So instead of just appearing in the post-run log, now each history message is pumped to the #cogmind-activity channel as it happens in real time.

roguelikes_discord_cogmind_activity_history_logging_sample1

Sample reporting of runs in progress from the latest build currently in prerelease testing.

 

roguelikes_discord_cogmind_activity_history_logging_sample2

Another history logging sample from #cogmind-activity.

Already we’ve already seen plenty of commenting on particular points during runs, whether from the player themself, or others in the community following the runs, posing questions or making observations. It’s also an alternative way to intermittently follow runs in progress when someone is streaming via Twitch or voice chat, when maybe there’s not enough time (or large enough display on hand :P) to watch the full stream.

As part of this update, I made it possible to set exceptions for some history log messages that I didn’t think needed to be reflected on Discord as well, somewhat less meaningful ones or those that could otherwise seem spammy. It’s not necessarily one single run we’re seeing, after all, but potentially multiple or even numerous runs that could be threaded together, so cutting away a bit of the excess is desirable.

Who knows, maybe seeing the history log output in this format and context might even lead to further adjustments and improvements to its content, now that we have even more direct contact with it, and in a communal space. Either way, there are certainly different thresholds for what we want to include in different environments.

Improvements

This whole feature has only just been added for the latest Beta 13 build released for playtesting among patrons, and being a relatively small side project it didn’t exactly go through the complete process of what all can we do with this newfound power?! As such, there are improvements I’m still considering, as well as some that were considered but left out (for now, pending indirect feedback).

Spoilers

One of the biggest dilemmas during the design of this integration was what to do about spoilers. Cogmind being a game that lends itself to long-term exploration and discovery, sharing and discussion between players is stratified into a few distinct levels of spoilers that the community does a good job of maintaining to respect the desires of many players to remain unspoiled until they discover content on their own.

In that light, it would make sense to, for example, apply Discord’s spoiler tags to all relevant content shared via the webhook to #cogmind-activity, making it so that anyone could hang out there without fear of being spoiled.

Unfortunately that would be a fair bit more work to achieve, and could also get kind of annoying with all the spoiler tags, so for now I decided the channel is basically full redacted content, no-spoilers-barred territory. Basically it’s read at your own risk, indicated in the channel description, which might cut down on participation there, but I think it’s the most realistic option for now.

Color

Another factor I considered while building it, and again revisited after it was released and I could see it in action with multiple players, was how to better differentiate runs when more than one is happening at the same time.

It seemed like color could be a potentially useful differentiator, where each player has their own randomly selected color for their run (from among reasonable/readable options :P), and all messages from that run appear in their color.

Unfortunately Discord does not support colored text via any sort of easy inline markup. There are several workarounds to apply color to text, namely by using code blocks and their associated syntax highlighting, or the newer colored ansi feature, or you can even get creative and insert some color before the text with embeds, but none of these approaches were meant for such a purpose, so of course they don’t do it well.

roguelikes_discord_cogmind_activity_colored_mockup

Using ansi color codes, which also forces fixed width code blocks, just takes up so much room… meh.

An embed-like approach with a simple color before each line of text could be a nice non-intrusive solution (if such a feature existed), since then entire text doesn’t have to assume that color and potentially be harder to read…

Actually, on that note, what about emoji? Oh my, the possibilities. Now that I think about it, it might be fun to allow players to optionally specify an emoji to represent themselves, which would appear before every webhook-delivered message of theirs and make it just a little easier to follow runs when they are overlapping, not to mention just being fun to play with/customize how your run appears.

At the simplest level, instead of picking their emoji maybe we can assign one randomly to each player for their run (which could of course be entertaining in itself, including for the player :P).

And how many types of colored blocks do we have access to? Since those could be an alternative to the embed idea, prefixing run-specific lines with simply an associated color. Accessibility concerns of course imply we should do this with full emoji rather than just color, considering we presumably have access to the full array. Imma go test this because it sounds cool…

roguelikes_discord_cogmind_activity_emoji_test

Emoji test. Yes… YES!

Okay I think we might be seeing more of that later :)

Other Supported Features

Discord webhooks are surprisingly powerful, and based on the API docs it appears there are additional possibilities we can tap into, like theoretically uploading game screenshots. To that end, perhaps there’s a way for the player to enter commands that control the webhook, such as when they want to manually send images or other info. Definitely more complicated, but interesting to think about.

The webhook’s avatar could also be modified for each player, doubling as a form of run differentiator, though this is only useful to those users displaying avatars, so maybe not ideal since it’s not universal, and could also get a bit confusing for some people when actual users show up to chat about runs and get mixed in. In that case it’s probably better if the webhook maintains a consistent icon, since its name is already changing, after all.

Another idea I experimented with was using code blocks to draw ASCII art that could make for fun viewing, like at the end of a run or to otherwise highlight interesting events, but while it’s neat I didn’t feel like the amount of effort required would really be worth it in the end.

While there’s more adjustments likely to come, at this point I think it’s safe to say mission accomplished, welcome to another cool community feature :D

Posted in Gamedev | Tagged , | Leave a comment