Cogmind now comes equipped with an official tileset!
Originally we were aiming for two tilesets, one symbolic and the other realistic, but despite the promising concepts provided for the symbolic set, the artist unfortunately turned out not quite suitable for the position. With that we are down to a single tileset, though one with which I’m extremely satisfied.
Kacper has done an incredible job on the realistic set, going above and beyond simply following the specifications by coming up with a number of great ideas and suggestions that have improved tile mode’s overall visual quality while keeping within our limits. It’s been a pleasure working with someone who’s as into the game as I am :)
Position filled, credits page updated :D
Symbolism vs. Realism
We showed pre-development tileset concepts in a number of different places, and a majority of responses were in support of the more abstract “symbolic” tileset, essentially taking the essence of ASCII and putting it into tileset form.
It’s too bad we won’t see that tileset come to fruition (at least not for now), though there is some consolation to be found in various other factors for consideration:
- More than one of the prospective artists I consulted with during the hiring process made a valid observation, stating that “some of the symbolic sprites don’t clearly represent anything.” Ignoring the fact that this is in some ways the very definition of symbolic, it’s true that in an unfamiliar fictional world it is sometimes necessary to create unfamiliar new symbols that the player then associates with new objects. In a complex enough world and at small enough sizes, these symbols can begin to seem arbitrary and opaque, making interpreting them somewhat difficult for the same category of player that has trouble with the highly symbolic nature of ASCII in the first place.
- The question as to which tileset concept is superior was directed mostly at audiences already familiar with ASCII and traditional roguelikes. Players at the edge of or outside that circle generally preferred one of the non-symbolic concepts.
- All early feedback was also based on rough concepts created by artists with minimal guidance. Any of the concepts could become much more than their original form, as you’ll see below.
- A portion of the players preferring a more efficient symbolic approach to the map can simply use ASCII (as many will). I’m confident that Cogmind is, after all, the most accessible ASCII game ever with a vast array of UI features to aid usability, among them auto-labeling. Objects are also represented using very uncomplicated symbol conventions and a relatively small number of glyphs--common objects use only 9 punctuation marks and 24 letter glyphs (counting upper and lower case as separate glyphs).
Against this background it would seem that the ideal tileset should be as different from ASCII as possible--non-symbolic, detailed, realistic.
For me as the designer, however, this exaggerates a problem I’ve been dealing with every time I think about Cogmind having a tileset: any pixel art representation runs counter to the intended look and feel of the game. As regular readers know, Cogmind’s entire aesthetic and theme embraces the ASCII rather than using it as a makeshift crutch. You are the Cogmind, and that’s how you see and experience the world. Many of the map and UI special effects rely heavily on ASCII, and the intro, inter-level animations (still WIP) and ending (WIP) are rendered entirely in ASCII as well.
Sure it’s a game, but as part of the design philosophy I’ve made an effort to avoid anything that overtly gamifies the experience. I didn’t even want the game to have a title screen--as it turns out there’s still no start menu (nor will there ever be one), but I did finally cave on the title screen part…
I know, the game has both ASCII and tiles mode, so why fret? I’m sure it’s a bigger issue to myself than anyone reading this blog, because as players most of you see Cogmind as a game. To me it’s art. I have a vision for this piece of art, and feel like I’m sacrificing part of that vision to expand the appeal of the underlying game.
Of course a number of players out there also subscribe to the game-as-art-form mentality, especially in the indie world, and the appreciation of art is always a very personal thing once it’s released into the world, anyway. By providing a tileset I suppose I’m simply giving the audience another tool with which to appreciate it, even if it does significantly affect the intended expression.
While in the future this dilemma will always exist whenever I have to decide how to prefer to present Cogmind, I can at least say that after some days playtesting with this new tileset, it’s awesome, and certainly doesn’t reduce the game component’s awesomeness :D
Style
The non-symbolic representation of map objects should have both meaningful detail and a consistent look, and given the limitations this tileset does a wonderful job of both.
A sample scene showing the tileset at its smallest (12×12 cells) and largest (24×24 cells).
Kacper has squeezed an amazing amount of detail into a tiny area. Robot compositions highlight their primary features and functionality; item forms reflect their categories and subtypes while remaining distinguishable from one another when necessary. How does he do it?
Before getting into analysis of specific object types further below, the short answer is by focusing on a simple shading scheme. At the small sizes required, softening tiles with excessive shading costs too much space that can otherwise be used to define details (an even more significant limitation without multicolored tiles). By contrast, this tileset uses a mere three shades:
Grayscale ramp from Cogmind’s tileset. The detail!
As you’ll see with the robots and items, these shades aren’t used to create any kind of gradient, instead being assigned as a primary color vs. detail color. The result is extremely sharp sprites that pack a lot information into a small area, and also mesh well with the sharpness of the UI.
One drawback we’ve discovered to relying on such a simple monochrome color ramp is that while on the perfect hardware the darker two colors are nicely distinct from one another, they appear much closer on lower-quality LCDs, causing sprites to lose some of their internal contrast. Correcting for this on one setup results in less than ideal viewing conditions on another. The current ramp is best displayed on high-contrast monitors with true blacks. Hm, as I write this I’ve begun imagining some kind of adjustable gamma option that changes the actual ramp itself, allowing the player to set relative brightness of each spritesheet component to whatever looks good on their particular monitor…
Machines
Machines were outside the scope of the original tileset specifications. As mentioned before, I’d be okay with mixing ASCII machines with a minimalist tileset, though Kacper decided to tackle the issue, anyway. The result is quite promising, and does a good job of pixelizing the machines such that they fit well alongside our other map sprites.
A comparison of non-interactive machine ASCII originals vs. their pixel version created using one-to-one glyph substitution.
The effect works well enough with non-interactive machines (the gray ones, seen above and as described earlier).
However, because interactive machines are often both smaller and use more outward-oriented designs than non-interactive machines (whose designs are larger and inward-oriented), that subcategory doesn’t look nearly as good. This is cause for some hesitation in making this change permanent as is. A redesign of the base ASCII glyph arrangement would resolve the issue, but also might result in a less effective ASCII version.
Either way, the spritesheet has already been expanded to allow for an alternate set of ASCII line glyphs specifically for machines (the original set was still needed for UI elements that use the map font). For anyone who would like to use tiles but prefers the basic ASCII machines (not yet sure if that type of hybrid player even exists!), the config file does contain that option.
Terrain
More work went into the terrain than I initially expected. At first I was thinking “okay, we’ll just replace the hashes with one of a handful of wall tiles and that’s it.” It’s not quite that simple, though keep in mind we’re still not doing linked and oriented walls--they don’t really add anything for Cogmind, in which terrain is incredibly simple and the focus is on tactical layout (plus oriented walls can unfairly give you too much information).
The first unplanned change is the removal of ASCII dot/period floors. They are replaced with a faint gray rectangle representing the floor section, and do a good job of reducing visual clutter when the general noise level has already been increased by pixel art.
I hadn’t considered the possibility, and even imagined it might be incompatible with the particle effect animations, but Kacper dropped it into the tileset so I figured I may as well try it out. I like it. Tests show that it is not only perfectly compatible the hundreds of existing particle effects, it even enhances some of them.
See the floor tiles highlighted by these UI animations, the red volley rangefinder and the green launcher AOE scan.
Strewn about on lower levels, and blown off robots and machines to slide across the floor, you’ll often see mechanical debris:
A roomful of mechanic debris in the aftermath of my reckless rocket rampage. Oh look, here comes another to join the scrapheap…
The tileset contains 16 debris tiles in all, one for each of the possible gray background ASCII debris symbols. Both the tiles and ASCII debris punctuation are organized by their pixel density so that areas of debris created by a noise function will look a little more natural.
Tileset debris, with corresponding ASCII for comparison. (A couple of the ASCII may seem out of density order, because that order is based on a multi-font average.)
The most prominent terrain feature, walls, required the most tweaking of any tile type despite their relative simplicity. Adjusting them also required making the tileset’s only deviation from the standard color ramp described earlier.
The issue stems from the tileset coloring system, which draws directly from the colors and levels assigned to the ASCII, all fully saturated colors with a specific brightness level (usually fairly bright).
Wall ASCII universally use the hash (‘#’) symbol, which naturally has a lower pixel count than any wall tile. Thus using the same color for ASCII and tile walls means the latter will require a lower brightness to avoid overpowering everything else on the map, especially since wall tiles are almost always the most numerous visible object. As explained in the original tileset specifications, this is easily achieved in the spritesheet by using a non-white color. So the original grayscale ramp (which uses pure white as its brightest color) needs to change a bit for that. (For the record, Kacper didn’t like the idea of deviating from the ramp, but was a good sport and understood that it had to be done for the greater good =p)
The brightest wall color was therefore lowered from gray 255 to 225, so from 100% brightness to 88.2% brightness. But that doesn’t go far enough to produce the best wall effect for the map as a whole (Kacper cringes). Honestly I really like the walls at their original sharpness, but that detail is at the same time distracting when it’s repeated across the map. We needed to reduce the contrast on those details to help other objects stand out more. So I progressively raised the brightness of all the darker colors to tighten up the color ramp and make it easier to focus on objects other than walls.
You can see the testing process below, taking the factory walls as an example:
Tweaking the grayscale ramp for walls.
If the change seems subtle to you, it’s more meaningful when trying to play on a full-sized map with other objects mixed in that you’d prefer to be focusing on. This effect is even more pronounced at larger tile sizes.
As for unique walls, currently there are only six types--wall variety is a good bit less than the number of map types, because some maps simply use recolors (e.g. for the same general area and theme but still different in some way). Not unlike other traditional roguelikes, Cogmind is not about terrain--it’s about interacting with the occupants and objects found among that terrain. There are (and will be many more) interesting environments, but they are created primarily from machines. Walls are merely barriers to influence tactical positioning, and tentative ones, at that, since you can always blast your way through them to forge new pathways :D. (Note: Always consider what may be on the other side!)
Compared to walls, doors were left completely unchanged from their original ramp, since we want those to stand out--they even use a bright pure orange to achieve that purpose. So we get to keep their juicy crisp details (Kacper sighs in relief). Same with stairs and branch access points.
Heading through a door to find an exit. You are going to be really happy to see one of these in game, because finding them is your primary objective, but not always that easy.
Robots
When I first saw Kacper’s robot concepts I thought to myself, this could be Cogmind! It wasn’t the same feeling I had with the other tileset concepts, which could at best be classified as “okay, this could possibly become Cogmind with some work.”
Some viewers might claim the robots are too intricate, with pixel-sized details too small to clearly make out, and this is certainly a valid point (as valid as any opinion about works of art--some of us can make out the details when we stop to inspect them for fun :D).
Most importantly, the tileset is designed such that you don’t have to focus on the details to distinguish robots from one another. Each robot highlights its important features to define an overall shape that is usually unique to that robot. This is not especially difficult with Cogmind’s robots in particular, because each robot must be unique in its loadout and behavior in order to exist in the first place. There are no “this robot is just like that one but with a different gun” situations.
See the cast of early-game combat robot classes that haven’t changed since the 7DRL prototype:
The prototype’s combat robots have all grown up and got sprited!
The many new additions have even more unique appearances. And of course the non-combat robots with their especially unique behaviors look completely unlike anything that you fight. Plus they’re all green. Regarding other colors, combat robots appear in yellow, orange, or red depending on the threat level of that particular variant; NPCs are pink so they really stand out; and there are also gray and brown robots, but those belong to a category you’ll have to discover in the game.
In any case, the robots above are fairly easy to distinguish, even more so when you see them in action because they are both labeled directly on the map and have their own unique weaponry or other behavioral differences--for example Swarmers always travel in big groups, Sentries always work alone, Watchers zip around sending out alerts without shooting anything at all, etc.
Notice I’m not showing the Behemoth here, because it’s now four times as large as any of these… nope, not going to mistake that for anything else!
What I like most about these and the many other sprites is that they accurately depict a cold mechanical world of robots, and at such a small size! The sprites even properly reflect a given bot’s size and loadout (mostly regarding propulsion and tools/weaponry, though sometimes even extending to additional components).
How do they do it?
First of all, the three-shade limit mentioned before is a very useful restriction here, as fewer shades enables sharper images, which means greater detail.
On top of that the robot sprites use a 3/4 oblique right-facing perspective, which is the best way to increase the variety of recognizable features that can be depicted. Forward-facing sprites leave a lot less room for variation, and work better with multi-hued tiles (which we don’t have in Cogmind).
Each visible side uses one primary shade plus a secondary shade for detail (with each side sharing a shade, for a total of 3):
The tri-shade Grunt as it appears in the spritesheet, x10.
Of course at the smaller tile sizes the detail only helps if you want to examine individual units up close, when during normal play all you care about is what is where. So at the same time we tried to give each robot a fairly distinct shape to aid at-a-glance recognition, as explained earlier.
Most interestingly, while you might expect that we’d leave some room in between robot tiles to keep them separate on the map, we didn’t! Robots are allowed to utilize the full width and height of their cell, so 12×12 in the base tileset, and the understanding is that the perspective shading helps you visually identify where one robot ends and another begins. The extra column and/or row of pixels to use for the robot itself gives more room in which to clearly define a unique shape, with a wider stretch of shaded edge where useful.
Robots’ perspective shading aids visual separation on the map. Here I’ve let myself get surrounded for screenshot purposes--don’t try this at home, kids. During combat you can safely ignore anything that’s green, and this particular scene simultaneously contains all four types of combat unit seen in the introductory levels of the game: To the north a pair of incoming grunts along with three surveillance bots happening by (quite rare, actually), and to the south a group of Swarmers flying around a Sentry.
Sure you can end up with dense, broad clusters of objects requiring a little extra time to thoroughly parse, but this is an issue even with ASCII. The point is it’s not incredibly difficult once you’re at least familiar with the individual objects. We’ve playtested it and are satisfied that it works just fine.
(I’ll also add here that if you really are staring down a massive group of enemies in Cogmind, you’re not going to care so much about its composition--you’ll instead do one of two things: run, or point your guided nuke in that general direction and kiss them goodbye… after which you will then probably run anyway because firing a guided nuke tends to piss everyone else off =p)
That’s it for the robots--there are quite a few more cool ones in there, but I’ll leave those for you to discover!
Items
Considering how tiny the items are, Kacper did a great job making them individually recognizable while ensuring that related subtypes share certain qualities. Because there is only one category of items that you won’t find almost immediately in the game, these I’m mostly free to show you now without spoiling anything big.
(Most of) Cogmind’s item types in their uncolored spritesheet form, both at 12×12 and 24×24.
- Matter and Data Cores are unique items that you’ll be seeing frequently.
- Propulsion: These are quite distinctive, and each does a good job of resembling its type, for the most part also taking the same form in which they’re used on the robot sprites.
- Utility: “Devices” is a pretty vague all-encompassing category, so it gets an equally vague sprite. Storage is quite specific by comparison, and appears appropriately box-ish. Processors and hackware are essentially two varieties of the same thing (small chip-like components), so they look similar but not quite the same because the player may or may not be interested in hackware at all. A large portion of protection utilities are armor, hence that riveted piece of metal.
- Power: The sprites here reflect power source progression itself in that these subtypes are simply increasingly powerful versions of the same general thing.
- Weapons: Cannons are larger, and energy vs. ballistic each have their own unifying characteristics. The launcher is a monster of a weapon in a size of its own, giving it that extra HELL YEAH feel when you find one (they are quite nice to have). Special weapons are usually tools and whatnot, so they look a bit more functional. Melee weapons (including the datajack), share a basic form but all remain distinctive.
Unlike robots, item sprites are actually colored differently from their ASCII counterparts. ASCII uses glyphs to represent a category and further distinguishes the subtypes within each category by color. This is more efficient for interpreting ASCII map data, enabling the player to quickly locate all items of a particular category (say, all the ‘=’ are types of propulsion) rather than differentiating everything equally at the subtype level; there are also not enough punctuation marks for 27 item subtypes, but plenty of extra if we do it this way. It’s the least confusing way to take advantage of the ASCII representation.
Because item sprites each have their own unique form, we are free to use color however we need to. Thus items are instead colored by their effectiveness rating. Each item is manually rated by how effective it is on a scale from 1~10, and colored appropriately on a sliding color ramp from cyan to purple to crimson. These colors have the advantage of being different from those used for any robots, so you can pretty easily tell the difference between an item and robot sprite even before examining their shapes.
All the treads in the game as they appear on the map, from the lowest-rated Light Treads to ???.
Using multiple colors for these may not be worth the added visual clutter, and to reduce confusion I’d consider changing all items in tiles mode to cyan or purple based on player feedback. (After all, this extra information is not available in ASCII mode, and it’s not a problem there.) I’m not particularly bothered by it, but it’s something I’d like others to weigh in on once they have their hands on the game.
(Color scheme exceptions: The common matter item is always purple, with a brightness based on how much matter is located there; data cores are always green.)
Besides their color and generally smaller size, item sprites are further differentiated from robots by their facing/shading. Notice that items are left-oriented, another good idea by Kacper.
Summary
Using the tileset certainly changes the feel of the game, which is somewhat hard for me to get over, but I do love it for what it is, think it handles itself well despite the limitations, and after playing with it for a while I must say it’s starting to grow on me.
Some (true) playtesting with 12×12 tiles. I just found me a ROCKET LAUNCHER. Splash damage be damned, you’re all going down.
Currently this tileset has only been developed at the base size, 12×12 cells, while other sizes will be extrapolated all the way up to 24×24, the 1440p dimension, without additional detail. Thus the relatively tiny size you see above actually applies only to those of you using a 1366×768 desktop (720p). Greater resolutions will be using larger versions of the tileset and have a slightly low-res appearance, working in the same way as previously shown scaled fonts.
A comparison of the two extremes, showing the same scene from Cogmind as it would appear in 720p vs. 1440p:
Cogmind tileset in 720p. (Screenshot taken in a 4:3 window, so the interface is not set to its true 720p aspect ratio--demonstration for tile size only.) Click for full size.
Cogmind tileset in 1440p. (Screenshot taken in a 4:3 window, so the interface is not set to its true 1440p aspect ratio--demonstration for tile size only.) Click for full size.
Regarding even smaller resolutions (e.g. 800×600), the game also supports those, but as this particular tileset can’t properly be scaled down they are currently ASCII only.
So you’ve finally reached the bottom of my 4,000-word Great Wall of Text intro to the tileset… What do you think?
RSS (posts)
Mastodon
Patreon
Discord
/r/Cogmind
Indie DB
39 Comments
I gotta admit, those tiles are pretty damn sexy, especially the items. While I’m still going to be playing with ascii for the most part, I’d be lying if I said the tiles weren’t tempting. Kudos to the artist!
Good to hear on both counts--that you’ll be using ASCII and that you also see the value in the tiles :). I think they’ll do a nice job of attracting eyes from outside our core community and help bring other types of players to roguelikes! Especially when combined with all the other accessibility features that make the interface more approachable.
I think I’ve just switched from ASCII to Sprite for the 12×12 size. Heck, I don’t even really worry about the ‘symbolic’ look; this does a fantastic job of bridging the middle ground -- and I was one of the symbolic-style pushers. The shading-as-detail look really lifted the whole vibe to a new level, and making the robots ‘bigger’ by cutting out the padding helps sell them as the stars of the show too. No complaints there!
If I were to nitpick a single sprite in the whole darn thing (I know, I know), the ‘piercing’ melee part stands out against its brethren as being ‘arm with a harpoon gun on it’. Which is probably not intentional. Given at least one of the weapons was ‘lance’, I guess I was expecting something more shaft-like. I’m also a little unsure about the ‘perspective’ treatment of the Cogmind himself, given it makes him half robot, half symbol. Hmm. Of course, if that’s my biggest complaint, you’ve both done exceedingly well. :)
Congratulations. It’s gorgeous!
Well, hm, converting people from ASCII to tiles was not my intention here, but yeah, they are lovely ;D. Very early on in development I was even against the idea of tiles at all, yet when I played with this full tileset once it was done I really started to enjoy it. Kacper certainly brought out the world of robots.
Sticking with the full-cell robots and letting the shading do the separating was my idea, but Kacper originally provided samples like that among his concepts, so I’m glad he thought to try that size to begin with. It’s really worth the extra size, and this feature would never have worked with a frontal orientation.
About the piercing weapon, I can see what you mean. I didn’t question that sprite at all during the process--while I recall it standing out a bit to me at the time, I did imagine that’s how it could be constructed. In its defense I’d say the goal is to keep all the melee weapons looking like one another, while a direct representation of a “piercing arm” instead of a “piercing weapon on an arm” would likely be easier to confuse with the slashing weapon.
At least we can say piercing weapons are by far the smallest category in the game--there are only five of them, and they’re quite rare, compared to several dozen other types of melee weapons alone.
For Cogmind, that’s mostly meant to be a symbolic treatment, since as you know we can’t have a specific representation for such an amorphous “robot,” but then the perspective is needed to keep it looking like it at least belongs in the same map interface. At least the perspective aspect is quite toned down, and in fact on closer inspection even breaks multiple rules of shading followed by the other objects, so I think it’s suitable enough. Before your comment I was recently even thinking it odd that it broke some rules, but after explaining this I now see why those characteristics make sense. Nice job, Kacper ;)
Haha, I can imagine -- but the tileset reads so easily it truly is a masterpiece. I’ve always happily enough played ASCII, but this feels very much a ‘make my life easier’ tileset -- you don’t need to have memorised much to know what the treads are, for instance, and that sort of saving can be considerable.
Hm. The slashing weapon is distinctive in that it hangs beneath the ‘arm’ silhouette; a piercing one could easily have sat ‘within’ the arm structure and been distinctive enough. Keep the spearpoint and you’re probably golden.
The cogmind does bother me a teeny bit is it meant to be front-angled or not? It’s doing a little bit of both. I love the overall shape, but the shading is a tiny bit troubling, and I’m not good enough an artist to articulate precisely my concerns.
That said, as noted the rest is phenomenal. I especially love the items being so distinctive.
True about the hanging vs. contained melee weapons, though I think the distinction may not be so apparent at the smallest sizes if the piercing weapon weren’t so visibly removed from the arm itself as it is. Yesterday I asked Kacper to check out your comments and share his opinions, but he’s been busy lately and hasn’t had a chance to get back to me. I’d further speculate that having a piercing weapon within the arm wouldn’t stand out as well as what we have now.
There is a bit of memorization involved with the ASCII, but I believe it’s much more manageable than any other traditional roguelike due to the auto-labeling system. As soon as you see something, its name pops up telling you what it is. With help like that (on top of it being a pretty simple system), you’ll learn them fast. (I know you know about the labeling, just linking for future readers.)
Nice article. I’m undecided if I’ll be playing the ASCII or tileset version, although I guess I’m leaning more for the ASCII one, at least for a first playthrough.
Since it seems that it’s possible to have an hybrid of ASCII and tile graphics (the non interactive machines you mentioned), I wonder if it would be possible to play the ASCII version, but with the debris using the tile set. I really liked the look of it and it makes easier to read the scene (see quicker if there’s an item to pick up or if it’s just debris, for example).
The good thing is you can always press a single key (F3) to swap between the modes instantly (with animation!), so even the same scenes can be inspected in either mode for fun, or to explore which mode you might prefer :)
That’s an interesting hybrid idea. Is the gray debris that distracting? More to the point, is this from experience playing the 7DRL? Or are you speculating based on the images? There’s a good chance that feeling would disappear once you’re used to playing. I never encountered any difficulty since the actual items really stand out being bright fully saturated colors, and haven’t heard other players mention this before.
While using the sprite debris wouldn’t be impossible in ASCII mode, it would look quite out of place. (It also makes more sense that the debris is just other non-usable “parts”, which are the same grayed out ASCII punctuation.) However, post-release if it really does bother some players who are going for the “pure tactical display” approach, an alternative would be to add an optional mode to simply show no ground debris at all--quite easy to implement, though the maps and engagements would lose some of their character.
Once we have the first release and accompanying forum for discussion, there will be a convenient place to discuss issues like this and I’ll have a better idea of what players need/want. In its heyday, the 7DRL feedback was mostly limited to a single forum thread, so I’m sure I missed other opinions former players didn’t have a place to voice, especially considering the rather huge number of downloads over the years. Maybe there are others who share your opinion!
Sprites are good, though at this point I like ASCII version more. Though I’m not a big fan of tiles in rogue-like RPG to be honest. Well, I play now DoomRL usually with tiles (damn, Derek Yu made a grate job here), but I always play NetHack and Brogue with ASCII. By the way -- is Cogmind will be free or commercial release? If second one -- are you going to send it to Steam Greenlight? I think you have a pretty good chance to take a public attention. Rogue-like genre is pretty popular now. Even fully text games can go to Steam -- SanctuaryRPG is a good example (99% positive reviews). And I also noticed some free (exactly free, but not f2p MOBA shit) games there (Heroine’s Quest: The Herald of Ragnarok).
While it’s nice that tiles will be the more attractive option for many (perhaps even a majority of?) players, I’m of course glad to see players still interested in ASCII. It does work quite well (being designed for it in the first place!) and will overall result in a better experience for “hardcore tactical roguelikers.”
Cogmind is commercial (the only way it can be developed, unfortunately), and the current plan is to eventually get it on Steam, yes. More of this will be explained in the next post, which will provide details about my plans for release.
Darn, I wrote “grate” when I meant “great”. What a shame! >_< Anyway, I'm pretty excited about Cogmind even now. It's very inspiring for me as for dilettante-ASCII artist.
Well, there is a ton of ASCII art to discover, so hopefully among other things that will keep you pressing forward to explore new ground! On a related note, in the next post I’ll be revealing a new feature that enables the collection of in-game ASCII art as well :D
Here’s the non-ASCII fan’s thoughts: ShamWow! Also, OMG! This blows away anything I expected from a tileset, even after the previews. It was Cogmind’s fantastic attention to design that made it attractive to me *despite* the ASCII format. Way to go Kacper.
My only other comment is the scaled cyan-purple color scheme for items isn’t all that great. Six of those just look like purple, or aren’t varied enough to suggest a quality level.
I’m glad you were interested in Cogmind all along “despite” the ASCII ;). So apparently now you’ll be using tiles :D. Interestingly, now that both are available I’ve been doing some switching back and forth while testing new game content, and I still find ASCII doing a better job in some regards, but I suppose everything was built from the ground up with ASCII in mind…
About the item color scheme, I agree with you. I just kept it as is from the 7DRL version, and would like players to try using it before making a change.
In use you might find it’s not much of an issue. In its defense, there isn’t a huge difference in actual capability between items of similar ratings. A weapon of rating 7 might do like… 5% more damage than a weapon of rating 6, which is of little significance given how the game plays. Multi-level differences are more meaningful, while in a lot of cases what you’ll really care about most are an item’s unique properties, which are often more reflected in its name rather than its rating (and therefore somewhat reducing the importance of color in the first place--this is why the ASCII version can easily get away without visually reflecting item rating at all). The main usefulness of the color scale is to help very low-level items stand out from the others, as even in the late game you can still find some basic items and they are still useful in some ways at that point.
One issue with the item coloring is that there aren’t many colors not already in use by various categories of robots, and reusing colors between the two is something I would almost certainly want to avoid. It’s most likely that we’ll end up with a simpler scheme, maybe a two-color one in which level 1-3 items are cyan and 4-9 are purple? This, or an entirely cyan approach, will probably work better than the existing one in the late game, where many enemies are red (very close to magenta/crimson…). Honestly neither myself or others have much experience in the late game, because it’s not very balanced yet and like the 7DRL you’ll probably get smashed to pieces somewhere around the half-way point ;). For now I’m mostly focused on improving the experience of the early game, then I’ll get to tweaking the latter parts a bit before release (though in the short term those areas will remain on the very hard side because they’re still incomplete).
We’ll definitely revisit the item coloring issue!
Do you have a special colour reserved for artifacts and other ‘superior’ stuff yet? If so, you could go blue/purple/pink to help sift the normal from the fancy, and leave the level to be peered at.
An aside: Are power items really the only category with three different designs that all do the same thing? Or is there a reason to lategame take a high level engine over reactor? I’m wondering whether there’s, eg, distinctions in total power output vs power:weight ratios, or the like.
White is the color for unidentified prototypes, but those exist at all levels (generally better than similarly rated items, and considered “best of class” for utilities). Plus all prototypes, identified or not, have a slightly oscillation/glow effect to them. So that plus the cyan > purple distinction will probably be enough.
There is only one category of very special items (which I haven’t mentioned anywhere because the category name itself is a spoiler), and it has a unique color in ASCII, but I didn’t give it one in tiles mode since it already has an extremely unique sprite. Pink is the color of NPCs, so that could work as a special item color, too, if needed, considering both are rare.
Regarding the aside: Power items are the only such category, yes. For the most part they’re just different names for the same things with increasing power output, so engines at level 1-3, cores at 4-6, and reactors at 7-9. It makes sense purely as an additional way to show progression. Thus there are no high-rated engines, and no low-rated reactors. There is however a little overlap in capability around the 3/4 and 6/7 transitionary levels.
That said, there are a few subcategories of power sources applicable to all of the categories in the same way, e.g. “light-weight” versions of a power source don’t come with much extra battery capacity of their own, but weigh a good bit less as a result. Other examples include “micro”, “compact,” and “heavy” variants. Overall power sources are certainly the smallest and least interesting category of items, since there are only so many variables with which to make them unique, and they exist just to power all the other components, anyway.
I could come up with some crazier power sources based on a few of the newer variables that have been added, but for now adding more utilities for their interesting effects is still much more worth the cost in development time.
The reason multiple sprites (or different colors in the ASCII version) makes sense for differentiating them somewhat is because later in the game there are still a lot of low-level
maintenance bots running around, and as expected they are powered by the same old weak power sources, which you wouldn’t want to bother picking up unless you are really desperate. Of course, we also have sprite color to go on in tiles mode now, but may as well make the distinction more obvious (as well as get that “bigger is better!” feel).
Regarding late game balancing, most (if not all) games under-test the late game, I assume because testers, especially volunteers helping with indie games, spend so much time on the slog getting there. To counteract this effect, it might be a good idea to provide a set of late-game-ready player models with different equipment concentrations to test *only* the late/end game.
I’m not too worried about an under-tested late game, especially in the near term, because with our first releases the latter half of the world will be linear as opposed to having its intended branching structure, so it will be impossible to properly test for balance anyway.
When everything is in place and it’s finally time to tweak the numbers (mostly spawning behavior), I have a lot of cool debugging tools at my disposal to properly balance content. Commands to display pretty colors, lines, boxes, blobs, etc. that show unit distribution, what individuals are thinking, doing or will be doing, how frequently they’re making decisions etc.
Just added a few more visualizations last night that allow me to examine the new cave environments via highlighting of areas based on their purpose: danger, risk-vs-reward, rewards, and fluff. I’ll be tweaking those numbers before the alpha release because you’ll immediately have access to the mines, which are a cave variant.
For a while I’ll be reluctant to give anyone debug-like access to the game, as I’d like to keep most of the game under wraps because I want it to be a kind of “epic game of discovery.” I want there to be plenty of secrets to discover, even for experienced and long-time players, so I’ll be protecting the data at least throughout alpha, if not longer.
As for non-balance-related testing, I’m confident there will be very few issues because of all the automated testing features. So we shouldn’t be having crashes left and right, or even serious bugs.
On a related note, last week I was worried that some rare combination of randomized map content in the late game would blow something up, so on top of the existing mechanics and AI tests I added another feature that repeatedly seeds a new world and runs through the entire game loading different maps with all their possible content in as many permutations as I want to leave it running for.
The final (eventual) step will be to program an actual Cogmind to beat the game on its own, then let it run forever to see if it can uncover any problems. That would be a fun side project whenever I start to recover some free time, and if successful could serve a double purpose I can’t reveal here and now ;)
The thought strikes -- if you’re doing basic web interface, for the beta versions you could well rig it to upload the entire logfile, thus simplifying bugfixing and the like.
Of course, this would require making the game run with a fixed-at-start random number generator so a logfile is deterministic, but it could work!
Actually, that’d be a pretty good way of doing high score verification, too. I’ll shut up now, you’ve got enough to work on… ;-)
Done, though you’ve seen that before. The crash reports are actually the entire game log that might show any anomalies/errors/warnings etc that appeared before the issue, as well as a stack trace that shows exactly what line of code crashed, which is almost always enough to figure out what went wrong. Determinism would help with really weird bugs, but is more of a nice luxury than absolutely necessary.
That said, what you’re referring to here is probably logging all player input to enable the recreation of the game state. While Cogmind does implement a robust seed system, the game logic has a few issues that prevent perfect replays. You can read more about Cogmind’s seeding in this comment thread, which also mentions my past experience with input recording.
Right now I’m using what is probably the next best method of high score verification aside from server-side replays. Not completely foolproof, but close.
I think this is looking great!
I wholeheartedly approve of switching to dark squares over the “dots for floors” look. Definitely a less cluttered look.
One concern I do have is that the current player sprite seems to be from a top-down perspective, but most every other robot is depicted from a side angle, and that discrepancy seems a little odd. (Or am I interpreting the player sprite wrong?)
On a somewhat related note, have you thought about the possibility of mirroring sprites (flipping across the vertical axis) for left and right movements? Basically you just make sprites face left if they have moved west, northwest, or southwest; and they face right if they’ve just moved northeast, east, or southeast. (You can either leave them unchanged or choose an arbitrary direction to always be north and south.) It’s a subtle thing, but I feel like it can be a nice effect if all your sprites are facing a direction to begin with.
On the other hand, maybe it would be a pain to implement in an engine that started doing ASCII only, and maybe it could be visually distracting. But it might be worth thinking about. :)
Happy to hear you like it; will you be using ASCII or tiles? ;)
I never would’ve thought to change the floors since I didn’t imagine it would be compatible with the way particle effects are rendered, but surprisingly they turned out really nice (I tested all several hundred just to make sure there were no unexpected side effects--none that I could see). With dots it’s of course a little easier to quickly figure precise ranges over short distances (without help from the other UI aids), but that’s a minor benefit compared to the visual noise it creates among the sprites in that mode.
Reiver voiced the same concern about the Cogmind sprite. I think the purpose of the slightly different appearance is to emphasize how different Cogmind is from everything else, and the sprite is more a symbol than anything because you can’t (or shouldn’t) represent an amorphous object like the Cogmind with any specific appearance. But now that there seems to be growing questions about this particular sprite, I should probably bring it up with Kacper. (I asked him earlier, but not in a direct e-mail, so I should do that and get an official response.) I can’t tell if your responses are purely the result of analyzing the tileset for its specific tiles, and therefore not something you might otherwise notice while playing, or if this is something we really need to change because it’s an outright bad idea. I did think that sprite was a bit odd myself while examining the tileset closely, but in game it seems fine, and I can see reasons to keep it like that.
It would be possible to mirror sprites to reflect left/right facings, and that would provide additional useful tactical data. However, it wouldn’t be worth the major sacrifice in map readability--the number of on-map shapes to recognize would suddenly double, slowing visual parsing. I think that approach works better in games with larger sprites and/or smaller map area. Cogmind’s map view can get really cluttered with robots and items, so any ways in which we can speed up individual sprite recognition are welcome. It’s a good idea in that it’s something I would definitely want to do if we had small maps or very large sprites (basically fewer on-screen objects), though given Cogmind’s unique situation it won’t quite help more than it hinders.
Thanks for the feedback!
Alright, fair enough, thanks for the responses.
I’m planning to use ASCII, but these last few posts have convinced me I’ll want to give the tileset a try too. Maybe I’ll end up using both and switching between them as whim dictates. :)
I highly recommend switching between them at various points in the game to compare and see what you think, especially since it’s so easy and fun to change modes, though definitely give each a chance since they are good for different approaches and either could take a little bit to get used to depending on the situation. I’m satisfied that both are quite playable, so it comes down to a matter of preference. (I say that, but I would always recommend the ASCII first to get the intended atmosphere.)
I like the style and color of the C-for-cogmind thing you’ve got there, it’s the shading that’s off. If it’s a robot schematic, fine, but give it the full perspective look. If it’s a symbolic look you’re going for (which I suspect it is), don’t do the shading the same way -- either use the shading as a form of detail/antialiasing, or to give it a halo or drop shadow or something to help it ‘pop’*. The almost-but-not-quite-either halfway perspective look is what’s throwing us.
(* yes, this word makes graphic designers weep. That’s why it’s so fun to use!)
I was thinking about this a little more today, and I think what’s causing the reaction to this sprite is only the extra mid-shade pixels at the center top and bottom. I don’t think these features that make it “different” are even noticeable at 12×12, so it must be the 24×24 upscale in that first screenshot that you guys are paying attention to? A solution could be as simple as shifting the prominent pixel on those edges.
I wonder if going an even more obvious symbolic route with the style is a good idea, or if it would seem even more out of place.
Either way, it’s now on my list to discuss with Kacper in our next correspondence.
(also @icelizarrd)
So Kacper got back to me on the Cogmind sprite, as well as the other piercing weapon sprite you brought up earlier.
For Cogmind, that sprite actually does follow all the same rules of composition as the other robot sprites. I didn’t realize this at first but it’s true. What makes it look so different is that, as a half-symbol/half-robot star of the game, it’s made to be brighter and therefore uses more of the foreground. I don’t see either alternative working very well, e.g. either make it more of a true robot (for which we can’t draw specific composition) or more of a symbol (as in give it truly different in style that pops, as you say). (Simply using the other robots’ foreground-is-corner style would make for a very weird ‘C’.)
In any case, I really like the shape and detail of the sprite and for now still agree with Kacper’s decisions here, so we’ll at least keep it for alpha and see if other players also bring this up as an issue.
As for the piercing weapon, the idea was to draw it as long as possible. Thus it works better slung under an arm so that it’s more recognizable as belonging to the melee weapon category--without the arm it loses a unifying characteristic of melee weapons, and if placed on the end of an arm won’t appear so long and thin or “piercing-like.” You mention “lance” as a specific example in your earlier comment, though spears are another type of piercing weapon in addition to a couple of odd ones, so we can’t rely too much on specific types to inform a definite shape for the sprite.
While I remain unthrilled with the aesthetic, I shall gracefully concede on the piercing weapons regardless -- that’s good logic, and I have nothing better to counter-propose with -- hm, beyond maybe making the arm thinner, so the pole itself becomes the emphasis on the eye. This is a very minor quibble though; the sprite works as-is.
As for the Cogmind, I must personally disagree with your initial assessment -- I notice it in your 12px gifs, and on thinking about it, it’s the pixels on the right hand edge that give me the feeling of it being 2.5D. The lack of a similar edge on the left hand side means it’s not flat, but rather suggesting that the C is a solid object (think of those big sign letters that are a foot thick), and that looks a little off-putting because I want to read the C as plan view, but the robot sprites insist that you’re looking at their fronts.
I see, thanks for clarifying. I thought it might’ve been the top/bottom sides that were throwing it off, since that’s what I noticed initially.
So you’re focusing on the right side and the fact that it’s not outright flat, but at the same time lacks the same depth as the other robots. Truly flattening it out would certainly work to show that it’s a symbol, but would also make it feel even more out of place among all the other actual robots :/
Or maybe that would be a good thing?
This could deserve more attention in the future. Maybe a topic on the forums when those are operational and we’re all checking out the public alpha…
My suspicion: Increasing the symbolic nature would help emphasise that it *isn’t* another robot -- that’s OK, because there’s plenty of other symbolic, top-down art on the map already (Machines & Terminals come to mind), but as you say that can safely enough wait till alpha.
I’m still playing with the tileset either way. ;)
I’m almost feeling conflicted. I’ve never had a problem with ASCII (honestly I tend to use whatever the game defaults to, it’s usually the ‘best’ look or the one the devs had in mind. I was pretty certain all along that I’d be playing Cogmind in ASCII because I -love- the immersive feel of it and how you’ve embraced and integrated your graphical style rather than it just being there. I still feel that way. But then…
I mean, DAMN that’s some fine pixel art. My compliments to your artist, seriously.
I’m assuming that even with the new machine tiles, the tiles mode leaves your lovely ASCII component art untouched?
Anyway, it’s strange that a post on a display mode I probably won’t play in has somehow made me so much more excited for the game. I think it’s because of how well it illustrates how much love you’re putting into this, how vivid an image you have of what Cogmind is and how it’s meant to play. I never really do the whole alpha/beta/early access thing, but I really am getting to the “just take my damned money!” stage now, so I can see me making an exception if that’s going to be an option.
I feel a disturbance in the force. The numbers of our ASCII-using brethren are dwindling at an alarming rate ;)
The new machines don’t affect the ASCII art at all, no :D. I would never…
The item art uses a separate font in the actual CP437 style, giving it a very traditional terminal look (honestly the most reliable way to do ASCII art if we want it to have any kind of traditional appeal), and other types of animated UI/art use either that font or lines from the regular map font. As of a couple weeks ago the alternate tiles machines were affecting a few parts of the UI, but I’ve since split them off into their own separate sprites so that’s no longer the case.
I still prefer the original ASCII machines myself, but then it’s very difficult to force a direct pixel translation onto machine art that was already balanced based on ASCII glyphs…
I am definitely passionate about the game and have a clear idea of everything I want it to be (with still more that has gone unsaid because it’s located in spoiler territory =p), otherwise I wouldn’t think it worth creating in the first place! I’m certainly not doing it for the money, which is a lot easier to make in other ways. But this is something I really want to do.
The main advantage I can see for you joining early access, even if you don’t want to play much until it’s complete, is that you’re a regular commenter around here so you can at least check it out and continue to follow development from an even closer perspective.
Provided the early access isn’t priced punitively high, I am so in. And I don’t do betas as a general rule. This just looks that promising.
:D. Not exactly punitive, no. There will be ample opportunity to comment and discuss the plan come next post :)
If one reason you don’t do early access would be for fear of an unfinished or unsatisfactory game, I can absolutely promise the final game will be very complete, and very awesome. I have an easier time promising these things than a real company, because I’m not doing it for the money =p (though as stated, having money does make it doable for a longer period, and will make future projects feasible!!!)
naw, I’m just broke, and philisophically against pre-orders. :)
what a poor choice of art style, by sticking to old school sprite and acsii art, you lock yourself in the past
it is hard to deduce what kind of entities things are, will this enemy shot at distance? close? is this a static object? this is beyong stupid
i suggest you to stray away from unreadable 60’s font and bad sprites and go modern
you’ll sell far more copies this way and you’ll be future proof
Cogmind’s goal was never to be a huge commercial success, nor was it even intended to be a long-term project! The goal is still not to be a huge commercial success (see: the fact that I continue releasing large content updates years after the game reached completion, for free instead of as DLC like profit-oriented developers would do).
I just wanted to execute a vision for a particular type of game, and it turns out that enough people enjoy this same sort of thing to really get into it and continue playing for years and years. Which is great because I also enjoy this type of game! I play my own game all the time and stream it with other players, and many of us play or stream other similar traditional roguelikes as well--lots of fun :)
Cogmind technically has numerous UI features that make it much more approachable than a lot of other traditional roguelikes, such as manual and automatic labeling of map objects (Cogmind was in fact the first traditional roguelike to do these), a persistent scan window, and more. Some people absolutely love the presentation style, tiles and all, and Cogmind has been taught in university courses on UI design, and been written about in books on game design. So it would seem there’s at least some appreciation out there…
At the same time it’s quite understandable that not everyone can appreciate and enjoy every type of game, a simple fact of life, but the good thing is I’m sure there are plenty of other games out there you can enjoy :D
It’s probably best to avoid assuming that a developer’s goal is to maximize profit, especially a traditional roguelike developer :P. If that were the case here I would’ve probably stopped working on it quite a while ago and not spent so much time on QoL, extra features, and hosting special events over the years, just for fun, all for free.
Honestly if the goal is money it would also make more sense to build the entire experience differently, but hey this started as a hobby project and only went commercial because there seemed to be enough interest and it meant that by working on it full time we could all have more of the type of game we enjoy!
And I’m glad that tons of people love it! Your passion really shows through in the blogs and updates- I think I’ve spent more time reading about Cogmind than playing :P Thanks for taking the time to share all the behind the scenes!
Yeah I’m glad about that, too--sure has made a lot of interesting new things possible over the years as we see it continue to expand! Blog’s been a bit slower lately, although I’ve been writing some updates on Patreon, plus of course announcements and ongoing development notices elsewhere… Less time for general-purpose articles, although I should do an ARG-focused one next since that was a pretty interesting experiece :)