next »

[Kyzrati]

Been a while since the last update, because the next few major releases require quite a few new pieces of foundational work... not least of them is the cave areas, which are naturally generated and populated using methods very differently from the many existing room-and-corridor sections of the world.

I'll be doing a full blog post on how these areas are put together (should be the next one), but I thought I'd drop this sequence of images showing the dev feature I just added today:

That shows one of the new methods of integrating integrating prefab map sections with procgen caves (there are three methods in all). In this sample it finds the weighted center of one of the larger subcaves and plops down an outpost centered over that point.

[Kyzrati]

Generating and Populating Caves
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Before this point, the vast majority of Cogmind maps have fallen under the room-and-corridor style generation. The wide range of adjustable parameters, when combined with a variety of themed content (and prefabs!), give that one style plenty of potential to create a unique feel and gameplay for different areas of the world.

That said, roguelikes which combine multiple disparate map generators can do an even better job of presenting the player with new challenges. Check out this compilation featuring some of the map types found in Dungeon Crawl: Stone Soup:

DCSS map generation variety--click for full size, and see here for some descriptions.

Impressive!

With Cogmind, setting, lore, and atmosphere are important to consider alongside pure gameplay variety, so maps are designed to meet multiple goals in those respects, somewhat reducing the possibility for radical deviations. Aside from the 100% machine-built parts of the world, however, there is room for the more natural areas found in the planet's interior: caves.

Of course, caves bring with them a set of problems different from the original map generator and its associated algorithms. Fortunately the caves also have a very different meaning in terms of lore and gameplay, and lack the "living ecosystem" found in the core areas of the world, so there's no need to migrate many of those existing systems to fit a new architecture. (Besides, doing so would also lessen the impact of using a completely different map generator in the first place!) Instead, caves are all found in branches, a concept described in the Layout section of this article, and these branches have a different composition and purpose you can read about over there if not already familiar.

For this article I won't be going into descriptions of content (so it's mostly spoiler free); we'll instead be looking at some of the design and technical considerations accounted for with cave generation.


Generating Caves
Regarding the method used to generate caves, I've already given an introduction to the randomized cellular automata algorithm. There's plenty of background information that I won't repeat here, though at the time parameters were not yet set for inclusion in the world (those were demos created in the mapgen test program), so it's worth taking a peek at what the cave layouts really look like in game now.

Firstly, know that since release last year there has been one variation of the cave generator at work, in the form of mines:

A fully-revealed mine.

These are basically small square-shaped areas containing sparser caves interspersed by what appear to be dug out rooms linked by tunnels.

The real cave systems are significantly larger, and because individual caves have more room to expand, they're more likely to generate a few extra nooks and crannies.

A fully-revealed cave map, without content. Overlay insets show major loops and flow paths.

For reference, I drew overlays demonstrating the relatively linear overarching flow structure (despite being caves) here, and the primary loops here. There are definitely loops available for tactical purposes, but generally fewer than you'll find in other areas of the world--this could have a strong impact on strategy for some players. Overall the linearity-with-loops design should work together to keep the map from being too linear, while still doing away with boring backtracking. (And of course the player is free to create their own loops by destroying walls where convenient )

Again, if you want to read more about the principles of connectivity, looping, and guided generation as they apply to the algorithm, check out the introductory article. Here I just wanted to show an example of what a real cave layout looks like now that they're in the game. It's still possible the parameters will be further tweaked depending on how content generation goes, which is a work in progress. You'll also see below that the layout itself may in some cases be altered by content.


Populating Caves
While the system behind procedural cave layouts themselves was worked out back in 2014, the first stage of content generation wasn't added until last year.

This was in the form of "encounters," wherein caves (analogous to rooms in room-and-corridor maps) each have their own content pulled from a pool of available encounters that themselves generally fall into one of four categories: fluff, rewards, risk vs. reward, and danger. The encounter system was described in more detail towards the end of the map composition post.

As a reminder, here's what a potential encounter distribution scenario might look like in a mine:

A mine with distributed encounter types marked with their associated category color.

So this is a feature which has been in use to populate other branches, and also even cave maps in the form of mines. But mines are relatively small and contain a fairly narrow selection of simple encounters, thus they didn't really need support for prefabs which allow for a wider range of unique (but still dynamic) content to be added fairly easily. Truthfully, there wasn't enough time to implement cave prefabs before launch in 2015, either, so that also played a role--mines use a bit of hardcoding instead.

Full-size caves, of which there are also many more than mines, will need better encounters. And certainly more encounters. These are areas that prefabs can really help since hardcoding content is a slow error-prone process, and scripting support for encounters has expanded greatly since first described, while adding multiple features for prefab content in other branches.

So the last thing really needed here is prefab support in caves. Well, caves have had prefab support, just not encounter prefab support--the more important and versatile kind.

There are actually two methods of adding prefabs to Cogmind maps. One is integrating them into the cave generator itself, which isn't even a part of the game engine (i.e. it can be run without Cogmind at all), and by nature this one will be somewhat limited in what it can do because it places prefabs before the caves are even generated. Thus these prefabs would be meant to serve a central role on the map, e.g. a huge and defining static area, or special entrances/exits. Relying too heavily on this type of prefab will result in maps becoming too repetitive and familiar over time, as it's not a very flexible system (at least not without a ton of extra work for each new map). It's more efficient to add a majority of cave prefabs through method #2, the encounter system.

The problem: How do you integrate static prefabs with a cave map that's already been generated?

Prefabs themselves have a defined shape, one that we obviously can't change to fit the surroundings, so the only option is to terraform the caves as necessary to accept a prefab. This must be done without having a negative impact on cave connectivity, and also in a way that looks good, and doesn't cause some other manner of chaos .

I've currently added two methods for prefab-cave integration. And hopefully two will be enough (hardcoded encounters pick up the slack in terms of highly unique content, or those that are more free-form and able to fit into any cave without disturbing its natural structure).


Centered Prefabs
The most easily implemented cave prefab is very intrusive, simply dropped onto the geometric center of its parent cave. (Remember that here I'm referring to "cave" as a single cave-room, just one of many caves that make up a single cave system map.) Here's an example of a prefab outpost plopped right into a rather large cave:

Geometric centering of an outpost in parent cave.

Notice that the outpost's territory completely overwrites both the closed and open areas that were under it, and includes an open buffer zone around it as well. Intrusive, but it gets the job done here.

I chose to center a prefab over the geometric center of its cave (meaning a position that gravitates towards that largest open areas of that cave) in case the parent cave has a big open fat area to one end and a long protrusion headed off in the opposite direction, in which case its geometric center could be some distance from its simple coordinate center. In such a situation, using the latter would be more likely to break one of the few rules governing this type of prefab placement: Prefabs are allowed to overlap any earth and the parent cave itself, but not other caves.

One of the current limitations on centered prefab design is that they must be rectangular, though I might remove that restriction later if it becomes annoying at some point. Organic/rounded centered prefabs have their thematic uses, especially in caves, though technically this can be faked under the current system by rounding corners in the prefab and simply leaving a little more open space at the corners where it integrates with the map.

Here I should remind readers that prefabs are not static (unless I want them to be )--most come in variable layouts, and also have randomized content, so there's plenty of variety even for a single encounter type. This leads to unexpected roguelike fun for new players ("hey I remember this place from last time, there's a helpful friendly robot inside--OMG WHAT'S SHOOTING ME") while also being designed to provide strategic challenges for experience players ("there is definitely useful loot here and I can take the usual guards, but is it worth the small chance of possibly being ambushed by a larger force?").

As mentioned a few times before with regard to world structure, branches are meant to be the less predictable areas of the world, compared to the main complex where there are plenty of procedural-driven systems at work, but they're relatively consistent and predictable for the experienced player. This offers two different types of major areas you can bounce back and forth between as necessary (or desired). In terms of design, prefabs are the key to "custom" content available in branches, so it's important to get them right


Embedded Prefabs
This one was more complicated.

There needed to be a way to add prefab areas that are not nearly as intrusive, for the more common cave-like situation where you have interesting encounters off the main path in some side area, or at least not right smack in the middle of a cave. This meant there needed to be a way to excavate areas for prefabs off the edges of existing caves. And that meant there needed to be space to do that excavating, and a way to efficiently locate that space...

As you can see in the full-size cave image further above, caves are fairly tightly packed in. So my first thought, in order to vastly increase the amount of earth (diggable area) between caves, was to do cave generation in two phases: a first phase uses a cellular automata-like process to define cave-shaped blobs which are marked off limits to digging during the regular mapgen process, then do the normal process, which would automatically avoid the natural "pockets of earth" formed from phase one. These pockets would then be available for latter digging out by encounters for their prefabs. As promising as it sounds, the more useful this approach (i.e. more pockets), the more it would have a broad impact on the caves as a whole, lengthening corridors and increasing the amount of space between individual caves, regardless of whether there were any prefabs inserted. This solution felt a bit too extreme.

There's a much easier alternative that doesn't compromise the integrity of the existing cave designs: Simply expand the diggable area around all the outer edges of the map so at least those are generally valid directions. Now there's plenty of area to dig! Then comes the next step: Where exactly do we start digging? This is really easy to do by eye--we can immediately see ideal places to dig out little areas, but in the code caves are just numbered areas with a list of their internal coordinates. So at this point it was a matter of figuring out the smallest set of rules that could search for applicable locations and satisfy all conditions and potential layouts when trying to excavate areas for prefabs.

I spent two hours figuring out a workable set of rules.

The final rules are very brute force, but they work so let's go with them :D

Steps to embed a prefab in a cave wall.

• Select a random prefab for a given encounter, and rotate it to face a random cardinal direction.
• Pick a random open cell in the cave, intended to be one front corner of the prefab's location. Then based on the length of the front face of the prefab, locate where its opposite corner will be. If the second corner is not inside the cave, keep trying with different points.
• Measure the distance along the imaginary sides of the prefab until it hits a wall.
• Every prefab has a manually set "maxProtrusion" value, a restriction on the amount its depth is allowed to protrude into its parent cave. If the distance measured on either side exceeds the maxProtrusion value, push the corners back towards the wall until both distances are within that value. (If there is no distance at which the protrusion value can be obeyed on both sides, which might happen with a combination of small protrusion threshold and highly uneven/diagonal cave edges, go back to #2.)
• Check the validity of the prefab's target area: The "outer rectangle" cannot contain any stairs (since it would overwrite them) and the "inner rectangle" can only be earth--not even open cells from the same cave are allowed, since it would allow unexpected/unpredictable alternative entrances to the prefab area.
• Also ensure there is at least a 1-cell-thick wall of earth around the sides and back of the inner rectangle (i.e. not immediately touching some other open cave or prefab area), for the same reason indicated in #5.
• Place the prefab on the map! Then convert to wall any earth cells around the outer edge that are adjacent to open prefab space.
• Add objects as per the prefab's definition, like... a terminal that allows you to access a door and collect a cache of nice launchers someone so considerately left here :D

If no valid area was found in the current cave within a certain threshold of tries, try with other random prefabs for that encounter, and if that still doesn't work, start over with another cave. (Encounters are chosen first, so the goal is to find a valid place for that encounter.)

Unlike centered prefabs, embedded prefabs can be non-rectangular since their sides and back edge are guaranteed to be against earth, meaning they can have a built-in cave-like appearance as in the example above.

The above diagrams were drawn in REXPaint. Here's a shot of a real prefab generated in game:

Sample embedded prefab in game.

Time to make some more prefabs!

[Kyzrati]

Made another modification to the cave generation logic, now that many of the basic encounters are ready to be placed. They were originally randomly distributed, and would therefore have too great a chance to bunch up and cause huge spikes (or lulls) in difficulty. So there I've switched to a weighted distribution method that has encounters preferring larger caves, as well as caves with connections to fewer other caves that already have encounters. Individual encounter types can also prefer larger or smaller caves to further affect the weighting process.

[Kyzrati]

And suddenly I decide to drop the Alpha 7 release tomorrow... I've put up a collection of images showing what's to come. Among them, just yesterday I threw in a few simpler QoL features, the usual last-minute stuff before a release :D

Examples:

Hacked stockpile intel is now labeled along with other items.


Attempting to move while severely overweight will give you a warning before the first such move in while.


And one of the less useful machines has been revamped, yay! Regain the loot lost to Scavengers by hacking or shooting recycling units.

[JobLeonard]

And one of the less useful machines has been revamped, yay! Regain the loot lost to Scavengers by hacking or shooting recycling units.

I wonder if this will make them any less hated

[Kyzrati]

I hope not.

[Kyzrati]

Alpha 7!

For the full release notes containing plenty more detail about the content and mechanics of this release, see here.

The full Alpha 7 (0.10.160323) changelog:

* NEW: Branch maps "Lower Caves"
* NEW: Branch maps "Upper Caves"
* NEW: Branch maps "Proximity Caves"
* NEW: Branch map "[redacted]"
* NEW: World Map! (Backspace/F9/new "MAP" button) (examine your route, and possibly learn layout in advance)
* NEW: Score sheet contains list of complete route taken through the world, by depth and map
* NEW: New category of interactive machines: Derelict terminals
* NEW: More lore to uncover in dozens of terminal records
* NEW: Learn many forms of intel about areas before visiting them, including depth, zone layouts, trap/machine/guard locations and more
* NEW: New special item type akin to Data Cores: Derelict Logs (effect unrelated, though they are similarly auto-collected)
* NEW: New Trojan hack (secret)
* NEW: Some Trojans and brute force hacks can now be learned via in-game/in-theme methods, as can the access code to Recycling
* NEW: 1 new prototype robot
* NEW: 4 new Derelicts
* NEW: Several new types of drone bays, with corresponding unique drones
* NEW: A dozen new rare parts
* NEW: First alien artifact!
* NEW: A couple dozen more encounter types
* NEW: One more story-related major NPC encounter (new NPC robot class)
* NEW: Target robot system corruption increases chance of hacking success (+X/3%)
* NEW: Minor NPC dialogue now animates over the map itself, color-coded by relation w/speaker
* NEW: Scene descriptions no longer confined to the log, shown as cyan messages over the map
* NEW: Mouse users can pan map by holding Shift and simply moving cursor
* NEW: Stockpile intel from terminal hacks also provides item-specific map labels on request
* NEW: Attempting to move while severely overweight will give a warning before the first such move in a while
* NEW: Four new size 12 font options (720p): "Tall", "Smallcaps", "Fuzzy", "Tallcaps" (8 total options at that size now)
* NEW: Smallcaps typeface manually scaled to 8 additional sizes in three variants (Cogmind includes over 100 font bitmaps now)
* NEW: Second variant of the 14/Terminus font, crisper with some glow to it
* NEW: Initial tutorial messages include a notice about changing the text font
* NEW: 24 more score sheet entries (total = 434)
* NEW: Added Ctrl-PrtScn as duplicate command for PrtScn, for players with PrtScn already assigned to an external program
* NEW: More Recycling Unit features, including component storage and hack or shoot to retrieve stored components
* NEW: Mining Claw may on rare occasions rip parts from target and put them directly into your inventory (or drop if space insufficient)
* NEW: All hover propulsion gives a +5% to dodge when not overweight or in stasis (e.g., hover now has half the flight bonus)
* NEW: All supporter names registered since Alpha 6 added to in-game list (see Credits menu)
* NEW: All item-attribution names registered since Alpha 6 added to the item collection gallery
* MOD: Hunter armament buffed--they're scary again
* MOD: Nerfed high-level Targeting Computers, Melee Analysis Suites, Target Analyzers (too easy to stack now); buffed entry-level variants
* MOD: Nerfed high-level Sensor Array and Terrain Scanner ranges; buffed entry-level variants; all energy costs slightly lowered
* MOD: Coverage of all Storage Units halved
* MOD: Drone Bay integrity and coverage tweaked, now doubles as makeshift armor
* MOD: Exp. Signal Interpreters now more capable than Advanced variant
* MOD: Adv. Signal Interpreters can no longer detect H-88 Terminators (requires Exp. level)
* MOD: Momentum damage modifier cap for melee attacks doubled from 20%/40% to 40%/80% (non-piercing/piercing)
* MOD: Dormant, unpowered, disabled, and broken robots outside view can now only be discerned by Exp. Signal Interpreters
* MOD: Default font changed from "Cogmind" to "Smallcaps" w/glow variants (former renamed to "Cog")
* MOD: Shift-LMB to center map on cursor position works, but is now an undocumented command
* MOD: Inventory displays item sprites rather than ASCII when in sprite mode
* MOD: Intel overlays for stockpiles display item sprites rather than ASCII when in sprite mode
* MOD: Effects of Maneuvering Thrusters and Reaction Control Systems do not apply when overweight
* MOD: Behemoth core exposure reduced by 5%
* MOD: 50% increase to effect on alert level from destroying or jamming a garrison access point
* MOD: Improved visibility of projectile count on info page for multi-projectile weapons (was easy to overlook)
* MOD: Ramming non-combat robots counts as an aggressive action and they'll now flee and send out distress calls as with regular attacks
* MOD: Machine serials that used unique letters derived from the current map name now always use the first letter of that name (cosmetic)
* MOD: Garrison Access terminal seal animation improved (also fixed issue where it might not finish playing on slow machines)
* MOD: Size 10 font "All Caps" renamed to "Smallcaps"
* MOD: Some glyphs in all Terminus fonts modified
* MOD: Terminus (non-bold) fonts given a faint glow at sizes 18, 20
* MOD: Added slight anti-aliasing to 12/Terminus font to further improve readability (especially on smaller screens)
* MOD: Help screen commands for keyboard control of allies more clearly indicates how to enter required mode
* MOD: Drone Bay ASCII art tweaked
* FIX: Crash on Tab-cycling targets after causing time to pass by swapping parts before original target destroyed by another actor without having exited look/fire mode [Sylverone]
* FIX: Score sheet missing Garrison Status hack tally, throwing off the dozen hacks listed after where it should be [zxc]
* FIX: Score sheet recorded turns spent in Hub_04(d) to Armory [Sherlockkat]
* FIX: Score total for prototype IDs didn't account for those learned via hacking or Component Analysis Suites [Enno]
* FIX: Jamming a Garrison Access point via brute force hacking now applies same Programmer dispatch reduction as sealing/destroying it
* FIX: Crash on replacement of attached Processors or Hackware direct from ground while inventory full
* FIX: Basic/Imp. Signal Interpreter indicators remained on map even in view if moving multiple spaces per turn
* FIX: Overlapping simultaneous explosions could not affect the same robot more than once (Gamma Bomb Arrays etc. will be more effective now)
* FIX: Hunters could no longer track targets through walls (Alpha 6 regression)
* FIX: EMDS missing projectile name in penetration message text
* FIX: Toggling sprite/ASCII modes from the option menu (instead of via hotkey) didn't update previously seen areas until seen again
* FIX: Fullscreen successful win animation might not play out on slow machines
* FIX: Botnet trojan success text used incorrect plurality when value is 1
* FIX: Typo in new offensive hackware effect description
* FIX: 20/Terminus text font missing integrity block glyph
* FIX: Size 8 mini font wasn't grayed out in the option menu's font list while tileset active
* FIX: One line-junction glyph in the size 8 mini CP437 font misaligned

[JobLeonard]

 

[Kyzrati]

Move along, nothing to see here, less exciting than I wanted it to be... but I'll finally get to do some streaming again :D

[Kyzrati]

Slight annoyance for players: On entering large maps, the first turn can take a couple seconds while all the AIs figure out where they're going to go (too many pathfinding calculations at once because there can be a ton of inhabitants).

Solution: Delay AI turns by time based on their distance from the player's starting position, as seen here :D

[Kyzrati]

Time for some dev statistics!

314 days ago I released the first version of Cogmind Alpha.

This weekend it passed 2,000 supporters. (Big thanks to everyone here who has helped with that!)

As of yesterday development reached 4,976 hours, the largest two components of which were coding (41.5%) and community (31.0%).

The game source itself, excluding all external data, scripts, engine and libraries, stands at 78,580 lines of code (C++).

[Kyzrati]

Cogmind is being rebuilt as an intense ASCII RTS. These two sides really don't like each other (zoomed out).

[JobLeonard]

Aand now someone will mod that in, I'm sure (I hope)

[Kyzrati]

Heh, as neat as it is I don't see this as working as a mod. I guess in theory anything is possible, though . I will admit it was quite easy to do this on my side, at least just to record this, but to make it a full game one may as well rebuild it from the bottom up.

...hey wait, that's what I'm doing here why don't you believe me?!

[Kyzrati]

Pretty big improvement to the visuals by simply deleting three lines of code

Destroying obstructions recalculates FOV every frame rather than at the end of the animation.


Earlier--like 2013 earlier--there was a slowdown concern when the mechanics were based on many FOVs, but that isn't really a worry any longer (since only you and your drones calculate FOV now), so now it's possible to finally see explosions in their full glory as they expand into previously unseen territory, rather than being confined to areas already visible

For comparison, this is what the same scene looked like originally (with the animation blocking on):

[JobLeonard]

Did you discover it by accident or was it on your "if I ever optimise this bottle-neck away, that's going to change" list?

[Kyzrati]

Well, technically there is no optimization going on. I had intentionally put the delay in there (which is why this change comes about simply by "deleting three lines") and never intended to remove it, but one could say this is partially a result of the recent April Fools joke, during which I removed this and several other blocks to get everything animating fully fluidly.

Not long after I was thinking why not let at least FOV update more fluidly in the regular game, and then realized the whole reason I put that block there in the first place was when the original FOV mechanics had the potential to be slow if updated too frequently.

So sort of an accident, at least never something I had on my TODO list

[Kyzrati]

FOV Aesthetics
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

At its most basic, displaying field of vision in a roguelike is simply a matter of whether you see a cell or don't. These cells are in view--draw them; those cells aren't--don't draw them

But there can be more to it than that!

There are plenty of ways to get better-looking FOV, though before recently I hadn't spent any time exploring them in the context of Cogmind. By contrast, this was something I did early on with X@COM, because FOV plays an even more central role in that game, being directional and having control of multiple units each with their own viewpoint. With Cogmind it was never a high priority or even something I seriously considered since the FOV system's original iteration couldn't handle additional processing, and the central algorithm had already been highly optimized as part of the pre-Cogmind engine's code base.

However, last week while playing around I realized there's now a lot more breathing room in the system, enough to make some experiments worthwhile.

These experiments have paid off in the form of new FOV features described below :D

To clarify, this article is concerned with the aesthetic side of FOV, rather than how to determine what is visible from a given position. For the technical side you can see an earlier post from 2013, and also check out this FAQ for how myself and others calculate it.


Within FOV
Some roguelikes allow for dynamic FOV-affecting elements within the player's own FOV. This includes features like light sources, or fading/darkening objects that are further from the player.

Dynamic lighting is great for realistic environments. I use it in X@COM, where it's quite an important part of both the realism and mechanics, so there are lamps, light posts, flares etc. that can light up areas of the FOVs around them when ambient light is otherwise low.

A night scene from XCOMRL, showing light emitted from soldiers (triangles) and lights ('L'--the source of light for the gray ones along the road is actually three floors up).

Cogmind intentionally doesn't do any of this, but I'm including this feature in the discussion for completion's sake, and to explain why . Unless a roguelike is specifically designed around this (say, a pure stealth roguelike where lighting is a core mechanic, or a world in which light plays an important role in creating the atmosphere), it can easily become an unwanted barrier, obscuring tactical information in a way that brings out biological differences between players (e.g. eyesight), something best avoided where possible in game design.

The FOV area is where a player needs to be especially aware of what objects can be seen, and just as importantly, where those objects might not be seen. The latter can be difficult to discern within an FOV of variable (non-uniform) brightness. Clarity of tactical information is of utmost importance to a roguelike given the emphasis on gameplay over visual appeal. This is also why Cogmind's map view is generally quite static, and contains a lot of black (few to no background colors except when something important is happening/displaying, like combat or object labels and other UI feedback).

So I'm glad this isn't a necessary part of Cogmind's world (that way it doesn't interfere with other goals of the design), though I'll likely want to put more work into the FOV design when continuing the X@COM project (yeah, "it'll happen one day").


Outside FOV
How to display what's outside the player's FOV is pretty important, too, though of course for different reasons. Players need to be able to scan previously explored areas for reference, and those areas need to be sufficiently distinguishable from currently visible areas (especially the floors so that it's possible to easily locate the FOV edge in open areas). At the same time objects outside FOV ideally must be distinguishable from each other as well!

From the outset, Cogmind has technically included four different "extra-FOV display modes" that it inherited from X@COM. These alternative modes make sense in a game like X@COM, but are pointless in Cogmind, as ambient light levels are static and uniform, and there's no dynamic lighting, so Cogmind has only ever used one of them (of course it's the most processing intensive one :/). But while we're here, might as well look at what they are:

Comparing XCOMRL's four methods of displaying non-FOV space (click for full size). Bonus image: FOV coverage mode showing exactly where each unit can see.

For Cogmind, to fit the theme an additional green overlay was layered over method #4 (unlit grayscale):

FOV vs. non-FOV areas in a Factory map.

Note that because the original colors of terrain and objects outside the FOV are different, and that helps distinguish them under normal circumstances (while in view), the grayscale method is best because it reflects those differences. The simpler alternative, using some static darker color for everything outside FOV, is harder to parse because objects lose that relative brightness and then shape takes over as the only way to tell objects apart. Not very helpful:

The previous scene shown instead with a uniform green--no good. I am, however, considering an additional FOV toggle for non-FOV areas, which you can see in these darkened and full color experiments.

Conclusion: Grayscale conversion is awesome.

I use the luminance method to convert, taking the original RGB components of a cell's foreground color and setting each value to a new value created by combining 30% of the original color's red component, 59% of its green, and 11% of its blue (e.g. r=g=b=0.3*r + 0.59*g + 0.11*b).


FOV Transitions
So most of the above is background/supplementary to the meat of what I've really been working on lately. While I haven't made any changes to the appearance of FOV, inside or out, when the player is just sitting around thinking about what to do next, a lot of time is also spent moving, and that now involves some interesting new display options.

FOV options!

Delayed Updates
Since 2012 (!), when any obstructing terrain was destroyed, FOV would not be updated until the current action completed. This could delay an update until a 1-second explosion fully plays out, for example.

Delayed FOV updating in action.

There are multiple drawbacks to this method: We can't always instantly see all the results of an action (feedback delay), and explosions appear overly constrained in some situations despite having technically already blown through obstructions.

The main advantage is speed: FOV is only calculated once no matter how many doors, walls, or machines an explosion blows through. The locations of every FOV-affecting change to the environment are stored in a list while the effects of an action are being carried out, and at the end of that action the engine checks if the player can currently see any of those locations. If they can then it updates FOV.

This "delayed update" option is still available, because as the least processing-intensive method it might be useful on an extremely slow old CPU. Otherwise there's no reason to not go with method #2: real-time updating.


Instant Updates
Last week I realized that Cogmind doesn't really calculate much in the way of FOVs, not like its parent game X@COM (dozens of units each calculating FOVs in a 3D environment, on top of omnidirectional FOV-based light sources). Cogmind has hundreds of AIs in a single map, but they use a non-FOV visual detection method, so all we have to calculate is the player FOV and possibly those of their active drones.

The "instant update" option also checks the same list of environmental changes, but rather than waiting until the action is complete, it's allowed to recalculate FOV every single frame as long as there has been some change.

Instant FOV updating in action.

This is the common and natural way to handle it in a terminal roguelike, but large-scale turn-based games with other CPU-intensive routines to carry out might delay this kind of update until the end of an action (or they'll delay it for design reasons). Cogmind's original FOV system, together with the game's heavy use of animations in some cases, was that kind of barrier to instant updates when it was first developed, which is why instant updates weren't a thing to begin with.


Fade In
Even with instant updates, when Cogmind moves or obstructions are removed, newly revealed FOV areas just *pop* into existence like you see in most roguelikes.

Why not have the new area fade in? Some players will appreciate the extra flair, and it does perhaps introduce a slight benefit in that for a split second you can differentiate between what's new and what isn't.

Doing this isn't too hard: When calculating a new FOV, if a location is visible but wasn't visible on the previous calculation, store its coordinates in a list; then, when rendering the map, fade in the cells at those coordinates.

At first the fade-in code wasn't working, so as part of my tests I ran this debugging mode that showed FOV changes in red. It looks kinda cool so I'll just show that here :D

FOV record debugging visualization.

After confirming that FOV changes were being properly recorded, it was just a matter of tweaking the fade formula to actually render those changes dynamically.

Specifically, when each location is stored by the FOV algorithm it must also store the time when that particular change took place, and while rendering the engine uses the time elapsed since that point to calculate the amount of fade, which in this case is not actually a simple linear fade in from black to the target color. Instead it uses a 400-millisecond linear interpolation along a sine curve from the RGB color (0,48,0) to the target color. (0,48,0) was chosen to approximate the dark green colors used to display known areas outside FOV, to give a smoother transition from outside to inside FOV. Each cell's record is removed after its 400 millisecond timer has expired.

Fade-in FOV updating in action (tiles mode).

Fade-in FOV updating in action (ASCII mode).

400 milliseconds isn't very long, but it must be responsive so that fast-moving players can clearly see what's ahead. Besides, the best secondary animation effects are subtle--in my own work I most often use fade timers in the 200-400ms range.

Performance-wise this is another step slower than the instant update, but it's not like we're updating a ton of units here, so it shouldn't be an issue.

The biggest issue I did run into, and one I initially thought might keep me from enabling this feature, was how to reconcile the differences between revealing unknown areas compared to previously known areas. Unknown areas are black, and previously known areas are, as per the grayscale-with-overlay method, displayed in various shades of green. So in revealing new FOV areas, the ideal linear interpolation would shift from black or the relevant green shade to the new color, but it's impossible to achieve a perfectly smooth transition without knowing the actual color from each source cell. Unfortunately there would be a lot more code (and processing) involved in figuring that out, so the easiest route here was to pick a single source color that was dark enough to work for black-to-light transitions, and also compatible with the various shades of possible green from known areas.

Before coming to that conclusion, in the search for a perfect transition I experimented with another alternative: using a static uniform color for everything outside FOV. As described earlier, however, failing to account for relative brightness of individual objects is a a pretty poor way to handle non-FOV display, being difficult to parse.

So, back to the chosen color, (0,48,0). Using a static color to transition from a variable source causes a bit of flicker at the FOV edges depending on what color the walls are, most noticeable while racing down a narrow corridor where the majority of your FOV is walls.

And with that we have the final results of our new FOV updating features: See explosions in all their glory!

Instant FOV updating with fade-in on explosive removal of terrain.

I think I might prefer the Instant method for its traditional feel and instant feedback, though technically the coloration only applies to the map itself, and not animations nor the most important feedback mechanisms like labels and indicators--those still appear all the same regardless of the fade-in effect. Either way, for now I'm setting the game's default to Fade In, because it's "better." What do you think?

[JobLeonard]

Everything about this is sexy, but the red fade-in is especially cool. It SCREAMS Terminator:





Maybe the game can keep track of if you're going for a combat build and adjust the colour accordingly?

[Kyzrati]

Heh, and the red was just popping instead of fading--that was just a static color for debugging that I thought looked neat. There's a lot of potential for cool effects here, though most would be a bit too distracting and un-roguelike (the fade is guilty of the latter!). A special red mode would be fun, one reason I'd like to one day do a more action-oriented spin-off in which I could intentionally go overboard on those effects

I did just add an optional feature on the "useful side," the ability to temporarily brighten non-FOV areas while looking around: