Probably one of the latest hot marketing terms to see rampant use in the indie scene is “roguelike,” regardless of whether it really suits the game in question.
No, I don’t plan to tackle that can of worms (the topic gets more than enough attention over on /r/roguelikes), but I would like to begin a series of posts aimed at clarifying “what makes Cogmind a roguelike,” and, more importantly, what perhaps unexpected features it adds to the mix.
We’ll start with the basics, those features which most players familiar with the genre have come to expect.
Procedural Generation
This is the element that has apparently become synonymous with “roguelike,” which is completely wrong--granted it’s an absolutely required core feature of roguelikes, but the genre is defined by so much more than PCG (procedural content generation).
For each new game Cogmind generates the world layout, individual maps, and procedurally* distributes what content you might encounter. *Note that “procedural” is not “random”--the process is driven by data and algorithms with a purpose.
However, overuse or misuse of PCG risks leading to a bland experience, thus most roguelikes don’t go so far as full procedural generation of enemies, items, etc. Neither does Cogmind. Players and the world itself can both benefit from a certain amount of static content to latch onto. In Cogmind we could easily generate robots from an assortment of parts (considering we have so many), but there’s a lot of value in keeping robots (and parts) hand-crafted as they are. Static content has two advantages, enabling 1) us to build the game’s lore around specific dependable content and 2) players to form a strategy around known factors in an otherwise ever-changing world.
In this area Cogmind is therefore pretty much what you expect from a roguelike: maps are generated, most everything else is defined beforehand and referenced by the generator when putting those maps together. The approach is sufficient to provide infinite replayability without putting too great a burden on the player to relearn everything with each new play.
Cogmind’s map generator building factory map layouts for a 200×200 space from a combination of algorithms and a few hand-made prefab pieces.
Permadeath
Another roguelike staple, permadeath goes hand-in-hand with procedural generation. In case you didn’t know, permadeath means no loading saved games aside from continuing your most recent game, and loss is permanent (unless you’re cheating!=p). It would be quite boring if a game forced you to restart from the beginning on failure without offering a new experience each time, hence the advantage of procedural maps here.
You’ll be seeing a lot of this until you get the hang of it. (One of the performance indicators is obscured as it’s a minor spoiler. Also, the factors that contribute to your final score will likely be changing.)
Cogmind is actually more forgiving than many traditional roguelikes. In most roguelikes if you stand motionless and unresponsive next to an enemy, you’ll probably be dead in mere turns.
Not so with Cogmind. While I wouldn’t recommend letting enemies wail on you, the mechanics are such that sudden death is impossible. Even quick death is unlikely unless you’re intentionally avoiding the most basic defensive measures (or you’re exploring optional dangerous areas in the late-game).
You are pretty resilient and most likely to die from poor planning/decision-making, or attrition (this works because there is no normal way to heal/repair damage beyond reaching new areas!). The pre-alpha is currently not balanced enough to promise you won’t run into some very deadly situations, but the final goal is a fair game in which you can win a majority of runs once you’ve accumulated enough meta experience.
Despite the long-term attrition approach to success or failure, rarely are you forced into a “walking dead” scenario wherein you’re pretty much guaranteed to lose the game but just haven’t died yet.
For the experienced player, comebacks are commonplace. You can be reduced to a barely functioning mobile pile of scrap, only to several hundred turns later once again be an armored four-legged menace bristling with cannons (or maybe you decided to keep a low profile and stole some flight units and sensor gear instead).
And even for the new player, there’s always the opportunity to simply absorb the damage from attacks while fleeing (or even outrun pursuers) until you happen across an exit, which might be just around the next corner.
In short, there is always hope! On reaching a new area you’ll (usually) be safe from attack for a bit, giving you a chance to build up if necessary.
Turn-Based
This is a somewhat controversial factor of roguelikeness, more so in modern times where there’s a high degree of genre mixing going on in the indie segment. Roguelike gameplay traditionally takes place in both discrete time and space (the two are fairly complementary). Certainly all the classic roguelikes fall under this category.
Roguelikes are a test of problem solving skills rather than reflexes, thus we should have as much time as necessary to consider options and make decide on a course of action. Sure we’re all guilty of the “pressed the key too many times and died” experience, but we did have the opportunity to stop and think if we hadn’t gotten so complacent at the wrong time!
This puts pausable real-time games like FTL into a gray area I won’t address here, but I do think non-pausable real-time games, while they can certainly embrace the roguelike spirit, really belong to a different category (“roguelites”) because they test decision-making from a different angle by putting an emphasis on physical coordination.
Anyway, Cogmind is turn-based and grid-based, the latter part so ingrained in the UI that even the map tileset doesn’t use connected wall segments.
Regarding the turn-based mechanics, for those who haven’t played the prototype I should briefly introduce how it works. Cogmind uses a “time-energy” system as seen in a number of other roguelikes: Each game turn gives every actor (robot) 100 units of time, and performing an action reduces the available time by the cost (duration) of that action. Whichever robot has the greatest available “time” is the next to act. So performing actions with a greater time requirement will allow other robots to perform more actions before you can act again (unless they, too, perform time-consuming actions).
All of this happens under the hood, though you’ll get a feel for it as you play, plus some of the numbers are shown to you where important to help make comparisons and weigh decisions.
Most actions take about 100 time units, i.e. can be carried out once per turn. There are primarily two other actions that can vary greatly in how much time they require: movement and shooting.
Current speed in “time to move one space” as shown in the HUD. Also the amount of time required to fire the currently active volley of weapons.
One significant difference between Cogmind’s design and the average “time-energy” system (or other similar system) is that in other games the time differences between actions are intentionally fairly subtle, or at least don’t exceed a certain reasonable threshold. By comparison it’s possible in Cogmind to have extremely exaggerated time costs, so be careful of that! This would be a result of your own design, something you have to aim to balance while maintaining peak efficiency for the functionality you want.
In a worst case scenario assuming you’re a massive hulk of parts hopping along on one leg, you could move a single space and suddenly everyone within sight gets 2-3 shots at you, and again for every further step you take (in this case, if your goal is to escape, you may be forced to drop your stuff and run; or pull out that grenade launcher you’ve been hoarding and make a stand!).
The opposite is also true: you could fly so fast that enemies don’t even see you as you zip down the corridor and off into another room.
As you can see your speed value is incredibly important to how things play out.
Firing weapons can have a similarly exaggerated effect on relative time since you’re allowed to fire as many weapons as you want, but the total firing time could span multiple turns during which other robots can continue to act.
This makes large attacks front-loaded (since you are in effect spending a block of future time that you don’t have--time energy can be negative), but dangerous if used improperly. The benefit to larger volleys is that each additional weapon requires less additional time to fire, until it’s almost insignificant (because the more firing, the more that are able to do so simultaneously).
There is a lot of tactical decision-making involved in how many of what type of weapon to fire at what kind of target, but that will be for you to explore.
Combat
Ah, bumping into something until you kill it, the time-honored simplest method of conflict resolution in roguelikes.
It’s true that roguelikes don’t have to be combat-oriented, but aside from fun 7DRL experiments we see that the most popular roguelikes are all about causing death and destruction.
For all its guns, cannons, and missile launchers, Cogmind is actually kind of an anti-combat game. Unlike in other roguelikes, combat is not a way to improve yourself. Sure you can “re-appropriate” parts scrapped from a robot, but there are also plenty found elsewhere for the taking (and what you find elsewhere is better, no less).
This has the advantage of making the stealth approach a much more meaningful strategy, which the game has plenty of mechanics to support. You aren’t required to fight anything at all. That said, it’s likely that even the stealthiest Cogmind, and most players aiming to win (as opposed to just causing mayhem, which is lots of fun, too), will end up fighting the occasional battle in the interest of avoiding greater confrontations that are even more difficult to evade or control. (For example, if you encounter a lone patrol squad that might spot you and warn others, you have the choice to lure them to a suitable battleground and take them out, or take a detour and risk it.)
Most roguelikes are heavy on combat, and while the genre is now trending towards more interesting forms of interaction than bump-them-til-they-die, melee attacks remain a staple action. They take a back seat in Cogmind.
In fact, Cogmind’s original prototype had no melee weapons at all--they have since been added as a new option you probably won’t solely rely on, but that do come in handy in certain situations.
Handy indeed…
The vast majority of combat in Cogmind takes place at range, which changes the experience significantly. This is not you one-sidedly mowing down waves of short-range attackers approaching from a distance; encounters are all-out firefights in which almost every enemy you meet can pound you from range.
Not only that, but you can fire as many weapons as you can attach and power at once, none of those left hand, right hand limits :)
About to let loose (poor strategy--one grenade or rocket at a time would be enough for these guys). I made this into a gif so you could see the scene in both ASCII and tiles.
Inventory Management
Interaction is a key gameplay element in roguelikes. While items (and usually by extension an inventory) are by no means required for a roguelike, they do offer a useful medium for expanding the number of possible interactions.
I’ve already covered Cogmind’s unique inventory system and its impact on gameplay in great detail in a separate post.
ASCII & Tiles
While I don’t believe ASCII is an essential feature of roguelikes, it does embody the ideal roguelike interface: a simple easily readable representation designed to facilitate decision-making. For my take on the inherent benefits of ASCII as opposed to tiles, see this earlier post. No sense in rehashing that discussion here.
Most popular roguelikes these days offer both modes, and so does Cogmind. The use of ASCII is pretty well represented and documented throughout the blog and game website; the tileset and an analysis of its composition can be seen/read here.
What most roguelikes don’t have is ASCII art. Drawing it all was a huge amount of work (one reason most RLs avoid it…), but in Cogmind every item has associated art that adds a lot of character (or “characters” depending on how you look at it =p).
Compilation of ASCII art samples (click for full size, or check out the introduction to all these item categories in the Cogmind ASCII Art Gallery).
Cogmind’s ASCII particle effects are also a big draw seen elsewhere only in moderation, not least of all because they can cause a bit of a pacing issue with what are normally quick to play games. The negatives are mitigated by tying animation speed to the importance of the attack--weak weapons animate extremely quickly while big powerful weapons and explosions can afford a little extra time for their animation (like maybe 300-1500 milliseconds compared to 100-200ms).
If I’m going to put the effort into making something blow up, may as well as give it some juicy particle goodness. (Composite image showing explosion reversal and switch to tiles mode for fun.)
Accessibility
Roguelikes are traditionally not very accessible. [/understatement]
However, modern roguelikes are trending towards broader accessibility, what with standard 2D visuals (no ASCII, even?!), proper mouse support, and other features mainstream audiences expect from a modern game. This is great for attracting new players to the genre, something we need in order to create bigger better roguelikes, while also aiding discoverability of those that already exist.
What I’ve done with Cogmind is apply most of these same modern UX design principles to a traditional ASCII interface, which surprisingly very few developers bother to do. And why not? We get to keep our minimalist ASCII and at the same time make the game accessible to players who won’t, for example, memorize 100 keyboard commands.
Simply put, Cogmind’s design adheres to a handful of guidelines that go a long way towards accommodating different types of players.
First and foremost, every action and command must be accessible via both mouse and keyboard. Sometimes there are even multiple keyboard commands for the same action (four different sets of movement commands are supported).
Furthermore, alphanumeric keyboard commands are embedded directly into the UI wherever they make sense and can look good, facilitating learning of hotkeys.
Embedded keyboard commands appear all over the place, and fit nicely with the style of the interface.
Here I must regretfully announce one of Cogmind’s only major failings in this area: there are no keyboard rebinds! It’s theoretically possible, but given the state of the program architecture would be a rather large project in itself. Everything is arranged on the keyboard as logically as possible, though this doesn’t help players with non-US keyboards. We’ll see what kind of issues we encounter once the game is released, but there’s always mouse input, or a mouse-keyboard hybrid, as alternatives. Update: Manual keybind support has been added since this post, albeit not directly within the game itself--using an external config file is required.
And we’ll see if we can get any of the really fringe players on board with drag-and-drop inventory manipulation! :)
Cogmind doesn’t yet have any explicit support for color blind players, though some solutions could be implemented based on needs as described in an earlier post. Update: Cogmind has since added a colorblind mode accessible directly from the Options menu!
One design feature that will hopefully mitigate the need for alternative color blind solutions, while at the same time improving the general player experience, is multi-channel feedback.
Wherever possible, Cogmind presents the same information through multiple means, usually a combination of colored words, symbols, sound effects, and animation.
For example, when you are low on core integrity (health) a warning sound plays, a red “ALERT” text box appears next to integrity on the HUD, and all the interface window frames oscillate between their normal green color and red. It’s unlikely you’ll miss the news.
Plenty of indicators and alarms warn you when things aren’t going so well.
An example of multiple ways to obtain the same information: The name of an enemy robot is automatically shown when you first see it, and can also be found by hovering the cursor over it (to show its name, whether it’s spotted you and other info in the HUD scan info area), pressing ‘1’ to label all robots, holding ctrl-shift and hovering the cursor to label that one robot, right-clicking on the robot to open its full data page, or pressing ‘x’ (look mode) then ‘tab’ to automatically shift the cursor to the enemy and label it (from where you can press ‘d’ for data to open its info if you want to know more than the scan window shows).
Calling up a label for a nearby robot, basic data for which is also shown in the HUD scan window: red name for hostile, green rectangle for its current core integrity, red exclamation mark meaning it’s spotted you, and the base chance to hit it. (Same scene shown in both ASCII and tiles.)
Text-heavy games like roguelikes place a lot of importance on fonts, and with good reason because there’s a lot of reading to do. I’ve mentioned before that Cogmind’s design attempts to shift as much information as possible from the message log to the map itself, but you’ll still be reading plenty of words, phrases, and short sentences.
The earliest roguelikes, true terminal RLs, had no choice but to stick to a single font, but with more and more of today’s roguelikes making use of emulated terminals, we have more options and should use them to lighten the burden on the player. (For an in-depth discussion and lots of images from other roguelikes, see this post.) Wide/square fonts are difficult for reading text, while narrow/rectangular fonts create distorted maps. So why not use a mix of both? Naturally plenty of modern roguelikes that have moved away from the traditional grid-based environment already do this, but we can technically apply it to the grid as well.
For the 7DRL/prototype Cogmind chose to emphasize a square cell size for maps, which unfortunately meant that text like the list of parts was not very pleasant to read--this has been vastly improved by enabling mixed font dimensions in the current version.
Improved readability of the respective interface areas is Cogmind’s biggest single visual change from the 7DRL prototype, and something that sets it apart from almost every other ASCII roguelike. With multiple fonts we can get the best of both worlds. (More about Cogmind’s font design here, and many more fonts have been added over the years since this post.)
Audio feedback is an element of accessibility, but also contributes to the game’s environment, so it gets its own section:
Audio
One could say this feature is somewhat controversial with regard to roguelikes, because it is known that many traditional roguelike players will play a game silently or to alternative music/audio, even when the game provides its own. Certainly players we may be able to attract from adjacent genres are used to and interested in relying on a game’s own audio, and I think there is much room in traditional roguelikes for the suitable application of sound effects.
Audio feedback is to me one of Cogmind’s biggest leaps forward as far as roguelike evolution is concerned. Not many traditional roguelikes take advantage of the potential benefits of a robust sound system, and none do it to the same extent Cogmind does. I’ve already written an entire series of posts on the usage and development of sound effects in roguelikes and Cogmind.
While I wouldn’t say audio is absolutely necessary to play, it is without a doubt a huge part of both the experience and the accessibility of the interface. The interface is relatively dense and there can be a lot going on, making it sometimes difficult to notice everything of importance. Thus for every visual effect there is an accompanying sound (yes, that’s quite a lot of sounds), making it more likely you’ll be aware of important events and changes.
In its final state Cogmind will include even ambient sound effects to further develop the atmosphere, as described before (update: and since added!). The goal there, as with map-wide ambient music/sound, will be to implement them in a manner that doesn’t interfere with the existing sound system’s accessibility-enabling qualities.
More than a Dungeon
The average roguelike dungeon-diving experience can be described as a single player exploring corridors and rooms in which lurk individual or groups of unrelated monsters or humanoids. You aren’t expected to question why that dragon didn’t eat those orcs last time it got hungry.
Roguelikes with themed dungeon areas get around this oddity by at least limiting the local population to a variety of similar or related creatures, though rarely do we see any kind of larger ecosystem (the recently revived Incursion is a notable exception). This form does have its merits, successfully condensing as much interesting and unique material into as small a space as possible and thereby increasing the number of unexpected emergent situations to focus on the tactical decision-making aspect so central to roguelikes.
In this area Cogmind makes a rather large departure from most roguelikes with one of its more exciting aspects that I’ve been holding off discussing in any detail: A dynamic world with an overarching AI.
One reason for delaying its introduction was that it’s a final stage of pre-alpha development that has only taken shape in recent months, and of course even in introducing this feature I can only say so much without spoiling the game by revealing how it works.
In short, all robots have some purpose other than just attack the player (and many robots don’t/can’t attack at all), while many areas of the game are overseen by a larger AI that controls the population, a population which is at the same time capable of communicating within its own ranks.
This is actually a huge topic to be discussed in two separate upcoming posts, one about the world layout and traversing it, and another about the inhabitants of that world. Stay tuned for those. Linked.
Conclusion
The “list of features” approach is not always a valid way to identify “roguelikes,” a label that some players afford to games simply based on the gestalt experience offered by the totality of their moving parts. It is nonetheless a useful way to discuss this timeless argument. I mean topic.
Few will claim that Cogmind is not a roguelike, but at the same time there are many elements that set it apart from traditional roguelikes in both form and substance. I hope that it will appeal to both long-time players and those new to the genre. A truly modern roguelike. Rock, Paper, Shotgun really picked up on that when they named Cogmind one of the best upcoming PC games of 2015, writing “Cogmind is an impressive merging of old and new school game design.” :D
RSS (posts)
Mastodon
Patreon
Discord
/r/Cogmind
Indie DB
18 Comments
This is something I think about often… no, not that you don’t yet grasp how little you understand how definitive ASCII is to roguelikes and how graphics cheapens the experience.. ;-) but rather that there’s a level of quality which roguelikes can aspire to, but to this point no-one has really bothered or had the time and energy to get to. It’s a full time job after all. And easier to clone what has been done, than to look past it.
As I got more and more familiar with the internals of Incursion, what became unappealing is how inflexible it is. It encodes the original take -- descending levels with increasing difficulty, where random shit is crammed randomly together with little rhyme or reason. Because of this, I’ve gone back to my own game engine and will be developing my own game based on that. And your efforts, of course.
“not that you don’t yet grasp how little you understand how definitive ASCII is to roguelikes and how graphics cheapens the experience.. ;-)”
Ha! I was the one who everyone thought was crazy at multiple times throughout 2014 when I claimed all Cogmind needs is ASCII, and does a perfectly fine job with it. Despite lots of support for ASCII as an optional mode, not a single person came to my defense (nor when I said Cogmind’s graphics should *default* to ASCII, not tiles). Where were you then? ;)
While I do believe ASCII is the preferable form of representation for roguelikes, I think you can still capture the essence of the genre with tiles, even if it “cheapens the experience” in one way or another (depending on how it’s implemented).
I would imagine that for Incursion you could abstract the world into a greater more flexible system of which the existing game is only a subset, though it would certainly be a lot of work. This is what I did with X@COM (so far), abstracting the mechanics and content from the original and implementing them as pieces of an overarching system with greater potential that modders and myself could then take advantage of.
Of course, I would also imagine that building your own system from the ground up is preferable to attempting to hammer something reasonable out of a crazy code base like that one. After all, even Julian himself abandoned the existing public version of the game in favor of a multi-year rewrite that we’ll never see.
Despite being a pretty long time roguelike player (started on rogue, infact, despite my young age) I’ve never been into the argument the way a lot of folks have. I do see the reason for it -- even I cringe when I see how many games are using that label as a selling point when they have little or in some cases absolutely no similarity to the classic roguelikes. If nothing else, clarity and consistency are important. As I said elsewhere recently, I think it might be about time the term either gets replaced entirely, or goes back to only applying to very traditional, classic clones of rogue, while the rest get their own, proper genre name.
As I said before, I tend to use whatever interface style a game defaults to unless it is for some reason horrible. (For example, I tried to play Cataclysm DDA with its default tiles and they were just really distracting and I ended up going back to ASCII) I don’t have any particular attachment to ASCII (too young for nostalgia, for a start) but I appreciate its clarity and how quickly you can identify everything once you learn the symbols. The thing is, tiles -- GOOD tiles -- are every bit as good for that. Any graphical interface for any style of game SHOULD focus on being clear, recognizable, and just generally useful for the player. Honestly with maybe a few exceptions, if you’re putting together your game’s art and you aren’t focusing on how playable it’s going to be you’re doing something pretty wrong. I definitely don’t think sticking to ASCII just because it works as a clean, symbolic interface is necessarily a good reason. I’d honestly like to see more… uh, “roguelikes” experiment with different types of symbolic visuals, but I think that might be the artist in me.
Augh I’m getting carried away here. The point I was going to make -- but it got too meandering so I erased it -- is that your tiles are a great example of how you can have something that’s both quick and easy to recognize, but also easier for people who aren’t used to ASCII to form a mental connection to. Having said that, to my mind ASCII just fits Cogmind like a glove. You’re a robot, that being how you see the world just feels right to me. Definitely how I’ll be playing.
Sound though, while there’s no reason why you HAVE to have sound in every game, there’s also absolutely no compelling argument for leaving it out. (Aside from the effort of producing it all, of course) When used right it becomes an integral tool for the player, a literal extra ‘sense’ that connects them to the game-world. When I play Doom I know exactly which monsters I’m up against even if I haven’t seen them yet -- and I don’t have to turn to see them because of that. When I play, say, Descent, I know a foe has missile-lock on me without having to look, because I hear the tone. Kind of clumsy examples, but it’s so true. Sound is definitely something I’d like to see a lot more roguelikes and similar games taking advantage of, and the audio clips you threw our way awhile back really got me excited. Sound’s also great for immersion of course. Ever try Infra Arcana? The sound in that one manages to be equal parts immersive and useful. It was the first roguelike I tried that had sound and the difference blew me away. (Come to think of it, that one also has really well done tiles…)
All told, I think evolution is a good thing. If you take it in its purest sense, “roguelike” indicates pretty much a clone of the original, and there really is only so far you can take that before you’ve done it all. Let’s be honest here, the kinds of folks who primarily play roguelikes are not the kinds of folks who need a shiny new graphics engine every two years -- if we want the same gameplay, we’ll go play the same game. I guess I DID end up weighing in on the argument here, huh? Well, I’ll go the whole hog then -- I think the term “roguelike”, and the argument surrounding it, are both becoming more restrictive than they are useful, and it’s probably time to move beyond them, if not now, then soon.
Anyway what I actually commented to say before that ridiculous tangent was that I’m super stoked to read more about the world and especially the AI, even if there’s not much you can tell us. Exploration, world-building, emergent gameplay, I have such a huge soft-spot for these things. I love it when a game gives us a convincing world, a set of rules, and then leaves us to ask those all-important questions like “what happens if I push here?” One of my favourite hobbies is finding new ways to break the first Deus Ex, for example. Even your 7drl prototype, with its little details like the engineers repairing stuff and the dreaded programmers getting dispatched from some unknown place to deal with your intrusion, felt like this odd, slightly alien world where things had a purpose, even if I didn’t know it. And I wanted to know it. To me, that’s a pretty big deal.
Alright I’ve talked way too long here. I get pretty passionate about things I like, especially when I haven’t slept. Keep on keeping on, I’m looking forward to hearing more.
Whoa, dude, complementing my megapost with a megacomment? ;)
True about tiles capable of being similarly readable as ASCII (in games designed for them). My own dilemma with Cogmind has always been that the game was designed specifically for ASCII, and therefore the tiles (as good as they are) will always seem a bit forced. Though if you compare the numbers, there are flat out more people who will play a game with tiles, even if they aren’t as good as the ASCII (to someone familiar with both styles), so we need them…
But I’m glad you’ll be one of those to use ASCII. I think a lot of people used to ASCII (myself included) will be sticking with it, but Kacper’s given us a nice alternative that we can use to attract mainstream players.
I did play a good bit of Infra Arcana, but that was the early versions years ago. I have seen the tiles before, and they’re quite nice, though I didn’t recall that sound was eventually added. Most roguelikes don’t go nearly far enough with audio, but it is a rather large investment of time and/or money. Immersion and usefulness are both equally important functions of sound in Cogmind. You’re going to love it :D. Just today I was putting together the trailer, in which you can finally both see and hear the game at the same time.
I think the community is gradually moving to be inclusive of experimental or alternative games that share only some qualities with traditional roguelikes. It just takes time. My opinion (which I’ve expressed in related discussions before), is that we just continue to call a lot of these hybrids “roguelikes,” and call the classic ones and those that stick to the tradition “traditional roguelikes.”
There’s probably too much variation in the genre, and no one authoritative enough, to convince everyone to use alternative terminology. The newly coined term “procedural death labyrinth” seems to have caught on pretty well, though, describing those games that use procedural maps and are out to kill you. Some of the more responsible devs have taken to using that instead of “roguelike” to describe their game, but the majority are only vaguely aware of what roguelike really means and continue to use it, anyway. Whatever.
To the topic at hand, it’s true that I can’t be handing out details about the AI or the world structure, but there is still much interesting “surface-level material” to discuss. Enough that I drafted three long posts last week, all ready to lead us towards launch!
The 7DRL/prototype did do a neat job of making the world feel alive--it was just an idea I had at the time and it was really quick and simple to implement, so one goal for the full game was to just do lots more of that =p. It all ties in with the story and you’ll be happy to know you can explore the various purposes of all these actors and what they’re doing. Plus there’s plenty more going on.
I think the symbol focus of ASCII (and reaching beyond it!) remains unexplored even in “new roguelikes”. There’s some difference between symbols and icons, though both are closer than ‘artistic depictions’, and I wish that was explored more. I’ll certainly be playing ASCII mode, too, at least some of the time!
I enjoyed the ADOM fights over the new art; I’ll play both but dang it -- it should be symbol art like ASCII! (But in general it doesn’t have to be on a square grid. I enjoy the hex roguelikes, and I think there’s lots more room to explore there.)
But keep up the good work, I love the animations and color changes, and I’m new to the 7DRL version and trying to figure it out. Your ASCII art is amazing.
Thank you and welcome :)
I’m sure the ADOM fights were interesting (don’t have time to follow it closely myself, and I was never into ADOM); I don’t much like the new art, but I guess that style appeals to the broadest audience possible, which is the most likely route to more players and therefore revenue :/
We were originally going to have a separate symbolic/icon-like tileset that mimics the utility of ASCII, but that artist was falling behind so in the interests of keeping the project on schedule I dropped it.
The 7DRL is a little rougher to start with since there’s no tutorial or context help, making it seem daunting at first. This is of course remedied for the full version. But push through the basics and have fun!
An increasing number of 7DRLs are toying with the idea of hexes, a format which I’ve considered using many times in the past because, as you say, it has generally been underused. I’m sure I’d already have done it if not for the fact that all my underlying library and engine architecture are geared towards standard grids. I like to push the genre to evolve, but that’s one area I’ve yet to tackle…
Yes, I’m glad team ADOM is doing the art to open the game up to a wider audience, and I think it will be more accessible and leverage the Steam release much further. But they chose a style that usually makes me run away from a game. :) Maybe that’s a good thing, they don’t want art for people who love ASCII, but for those who hate it. Ultima V style tile art wouldn’t have widened their base. But it’s a nice high quality.
I’m glad people are exploring hexes (and they are “easy” since it’s a staggered row of squares!) but it still feels like a gimmick, and you’ve got so much richness already you don’t need gimmicks. But maybe it will be fun to explore in future projects! But it is amazing how our tools both lift us up and hold us back for what we do.
I’ve been toying (purely in my imagination) with the idea of a non-tile based action-rpg with ASCII look and feel, sort of Kroz crossed with Gauntlet. I remember the way DarkStone handled tile-based free movement, with each tile divided into subsquares, and the subsquares “clear” or “blocked”, giving them the ease of tiles but more map flexibility than just full tiles on/off. Of course today even lightweight computers can handle arbitrary region comparisons, so that may be a restrictive dead end; but it’d be easier to build a map with. :) Ah, but that’s one of my projects; I’m here to enjoy yours!
And thanks for sharing REXPaint, too, I’m looking forward to playing with it sometime soon. :D
“Maybe that’s a good thing, they don’t want art for people who love ASCII, but for those who hate it. “
Precisely the point I’ve made before. From one angle it is unfortunate that we have to sacrifice some “purity” in order to gain more players, but the additional support does at least stand a greater chance of providing financial sustainability, without which we can’t put as much effort into the roguelikes we love!
I think hexes work better for pure strategy games, or puzzle games, but not so much traditional roguelikes. Like you say, the fact that I don’t have any readily available tools and libraries which I’m familiar with in order to quickly produce something satisfactory with hexes makes it a lot less likely that I’d do it. I’m more into game design than the technical aspects of the project--which are also fun, but spending all your time on the latter means you never finish the former! So for now I just stick to territory where I have a good foundation.
The map structure you describe is perfectly plausible. I use that same method for projectile pathing in both Cogmind and X@COM, actually. For unit positions I do prefer to just keep it simple and center them in their cell, but they technically have a volume/shape which is smaller than the space they occupy. Technically a lot of 2D games use a similar model for collision detection, but I’ve never heard of it being used in an ASCII game before. Every space in Cogmind is actually a 9×9 grid of subcells, so when you’re looking at an average sized 100×100 map, in the engine there is a 900×900 grid superimposed on top of it.
Have fun with REXPaint! It’s made my roguelike development so much easier, and I hope that others can get the same benefits out of it.
And no problem sharing your own projects; after all, many of our regular readers around here are developers, too :). If what you end up building contains enough roguelike features, I recommend /r/roguelikedev as a good place to share it and talk with other devs.
9×9 subcells -- that’s really cool, I’ve not heard that technique used for any tile game or rogulike before. Fantastic! I hope as you go along or after you’ll keep writing up your techniques. I love the various Ascii art and animation posts.
“Retro” is funny; everyone has nostalgia about something different. I love Atari & C64, ASCII & Roguelikes, Might & Magic & Ultima IV+V, Sierra Quest and early VGA graphics, Arcade games and Vector games. Others love jRpgs and NES and 16bit consoles and cartoons and all things Zelda, not my style at all. More power to them! They seem to be winning, outside of Roguelikes… “I for one welcome Link as my new Galactic Overlord.” :P
Ah, I keep forgetting to check out X@COM some evening, I love it every time I read about it.
And I love reading through Squidi’s ideas and old articles on procedural generation, and anyone else I can find on google. Always a fun topic, feel free to hold forth when you get the urge!
http://www.squidi.net/three/
I’ve got an active game project I keep writing code on; then redesigning, then writing more code… Totally breaking the “just get something out there” goal -- finally focused on that goal since Christmas amidst distractions. (Not quite 7DRL; 7(Month)RL would be an improvement for me!) When I get something, I’ll mention it -- try and stop me! hahaha! (sorry. better now.) I’m trying to remove “cost of movement” as a gameplay mechanic without becoming just a menu and still have a fun RPG -- too many turn into walking simulators, esp on replay. I’ve enjoyed Desktop Dungeons and FastCrawl for their inspiration along those lines and rogulikes are generally good at that coffeebreak session, at least at a casual level.
And Sean O’Connor’s Slay, though it’s not an RPG. I call it “Tactical Solitaire”, which I wish were a whole field of its own. :D
I will continue to maintain the devblog, for sure. After Cogmind there are more games, too :). (Though, and I’ve never said this before, I’m also thinking of a sequel to Cogmind if the first one is successful enough.)
I’m actually familiar with Squdi’s site (I’m sure a fair number of developers are!); a good number of inspiring ideas in there.
Designing games always results in trade offs, so it’s just a matter of what’s more important to the experience you’re trying to create. You can lessen movement requirements, which tends to force you down the route of creating a denser world. Execution is everything when it comes to an idea (even if the idea’s been done before), so it’s nice to get that vertical slice in there to see what it feels like before you invest too much effort.
X@COM is a lot of fun, though in its current state is mostly aimed at players already familiar with the original UFO Defense, since it’s not very helpful when it comes to teaching you the mechanics and how to play. It will be fun to bring that project to completion, as it will be deeper than even Cogmind, but a completely different type of game.
>…and all the interface window frames oscillate between their normal green color and red
That sounds really distracting and irritating. I appreciate being notified of something like low health, and part of the interface changing to red would certainly do that, but please don’t introduce oscillating colors to any part of the interface.
No problem, I’ll just add an option to turn it off. In general I’m waiting until release to take requests for UI changes, once players are actually using the system and can speak from experience, but in this case in the interest of making it possible to create a completely static interface I’ll go ahead and add this to the options menu now… done!
To the reverse of what you’re saying, during the prototype phase many players were actually asking for more obvious reminders when some aspect of your status was at dangerous levels, because there’s so much going on it can be easy to overlook (with core integrity especially, it’s not something you pay attention to as closely as you would HP in other roguelikes, because it doesn’t drain anywhere near as quickly--much more important is the state of your parts). I felt the same way when playing, so there are multiple reminders. Maybe I went overboard by adding glow, though ;). That was more done as a way to improve the immersion aspect, but from a pure mechanical/accessibility standpoint, the fact that an alarm sounds and a text label pops up in the top right are probably sufficient for most players.
You say people with non-US keyboards could have problems. Have you already played a keyboard-heavy game with qwerty controls on an azerty keyboard? It’s awful. Since most people in the world use few different keyboards, you should adapt the game to the most prominent of them. Complete rebinding is not necessary, you can just add an option which, if the keyboard is not qwerty, replaces the keys pressed by their qwerty equivalent.
That’s the solution I was planning on using, at least I think it was because the situation is rather confusing and there doesn’t seem to be an ideal way to handle it besides allowing complete rebinds (which is even more difficult).
Are you referring to treating an AZERTY keyboard as if it had QWERTY keys based solely on their position? As an AZERTY user is that an approach you are familiar with? Seems like it would be annoying to not have the keys labeled for what they are (or have I misunderstood and you’re referring to another approach?).
Either way, aside from the fact that it will take a while to implement*, the only reason it hasn’t been done yet is that you don’t need the keyboard to play Cogmind--it’s optional. But something will have to be done about it eventually! It’s one of the only support requests that I haven’t attended to but wish I could immediately.
*(It will involve quite a lot of research and testing before even the actual implementation, since it’s not something I’m familiar with xD)
I’m not experienced as a programmer, so I will probably tell bullshit. Please, forgive me in advance ;)
I think you should create 2 functions, one to manage key inputs, the other to manage key displaying. Each function would depend on a parameter: the keyboard layout. Then, when you want to display a key/when the player presses a key, the correspondent function modify it. Take an action requiring to press q on a qwerty keyboard. The game dsplays q. With the azerty setting, the function will alter it to display a. And if the player presses a, il will be modified to be a q.
In the worst situation, as an azerty user, i can assure you people playing the game more than a few hours will have not issue with “q” beying displayed if they can press “a”, since it only needs to remember the displayed key is false. But having to press q instead of a (or the other way) on an azerty keyboard is really tedious. So if you only manage to alter key inputs, it would be great.
I hope it is understandable, since English is not my primary language :)
Well, my intent was to better understand the situation from the player’s point of view, not the programming of it :P. I already have my input abstracted from the game logic itself. In fact, I wrote about it in some detail here :)
Perfectly understandable about the automatic position-based conversions. That’s what I was wondering--whether that would be an okay solution, and was what I was planning to try first. Still seems like it would be somewhat confusing since keys aren’t labeled for what they are though. Isn’t that annoying considering that pure keyboard players use the entire alphabet to interact with items, and those letters will all be at different positions? (Or like I asked before, is this something that is commonly done in games that don’t have rebinding? I need to know more from players who encounter these things! I don’t use an English OS, but I do use a US keyboard layout :P)
Try playing an azerty game ;) (if qwerty keyboards work like azerty, alt-shift can change the setting, but I doubt it is so simple)
From a player POV: there are 3 types of games (and Cogmind in of the most complicated) :
1)Games which do not display the keys: for these games, playing with the wrong layout he’s not a problem, we just have to learn a different set of keys that qwerty users (except if movement if done with wasd, or if some important keys are hard to press).
2)Games with QTE: really problematic. If the games displays a and you only have a fraction of second to press it, your brain may not make the conversion quickly enough…
3)Games like Cogmind, which display the keys alongside the commands. Itr is quite hard, since you generally choose which key to assign to which command either based on its situation (e.g. wasd, qe), either based on the first letter of the command (m for map, l for log…), which makes it easier to remember (even if that can be harder for non-english people: I know log, map, inventory, etc. but some words can be harder to think to). If it is based on its situation, you have to assign the key situated in the same place ; you can afford not to adapt the key displayed, because players will quickly remember where it is. However, if it is linked to the first letter of the command (I assume it is, like most roguelikes), you must keep the same letter, and adapt the game to take into account the different layout: so yu don’t have to modify the key displayed, only the key the player has to press.
I hope it is good enough, I can’t be more precise, and my feeling is maybe not representative of the whole gaming community, so you may want to ask to a larger player pool (forum, reddit).
Good luck for the development!
Okay, thanks for the info! I will continue to do more research in the future (I’ve collected some other opinions and notes on this issue before--more to do).
(With regard to how to switch keyboard modes in the OS, I have mine set to change input methods using Shift-Alt-# combinations (several of them), but that’s for IMEs/language input rather than keyboard layout.)