Official development blog

Full UI Upscaling, Part 1: History and Theory

A long time in coming, but here we go! This marks the beginning of what will be the most significant undertaking in Cogmind’s UI development history: making everything bigger. Not just the map, for which zooming was recently implemented as a toggleable option, but all the text as well.

This will be fun since I do love me some interface work, as evidenced by the massive number of optional QoL features I’ve introduced over the years, but despite pouring many hours into accessibility and streamlined gameplay before, this particular feature took the longest to get to.

Back in Cogmind’s early years I gave strong consideration to implementing it then--put together some mockups, discussed options with the community, and so on, but the time wasn’t right. Back then I couldn’t nail down what would be the most extreme (but still acceptable) options. We didn’t yet know what reasonable limits to put on such a feature, as in what’s the absolute furthest it could go without compromising other parts of the game design. It had to wait.

Being the way a player interacts with all of a game’s content, UI is naturally central to the experience, thus one of the most fundamental aspects a game’s design needs to address is matching up that design with its corresponding system requirements, including the display device!

To take an extreme example, there are obviously different considerations when developing for mobile vs desktop, and the results of the different decisions made to optimize a design for the target platform is also why ports between various platforms don’t always come out the same, whether technically or in terms of feel.

Not surprisingly, starting in the 2010s there began a trend towards developing games in order to ultimately target as many different platforms as possible (desktop and consoles being the most common crossovers), and it was very interesting to see player reactions to this trend, especially PC players lamenting how games were changing to ensure they could accommodate consoles as well. A necessary evil if you want to maximize profits, I guess :P

Finding middle ground so that more people can enjoy a form of entertainment is in some ways also a noble goal, although this naturally waters down the experience at the same time. The more strict your requirements, the more you can make assumptions about the target player’s experience, and in turn optimize a design for what you know to be true. Basically if done right, the end result will be better, for that particular group of players.

And that’s the backdrop for how Cogmind came to be born in its original form over a decade ago, wanting to have a large enough terminal grid to be able to simultaneously show a huge amount of info at once--Cogmind’s terminal dimensions are easily the largest of any roguelike, and also better support very large and active maps--Cogmind has the largest maps of any subterranean roguelike, and also by far the most active maps, with lots of entities milling about doing their own thing, some more or less important than others, but all worth of being aware of for various reasons.

The scope could not be so ambitious without what I decided at the time: This design will lean really heavily into having a large screen to play on. “Large” meaning physically large, resolution being irrelevant since we’re talking about a traditional terminal here, all that info simply appearing bigger when the screen is bigger, the display always being divided into at least a 160×60 grid. (By comparison, the classics use 80×25, and some later roguelikes use something in between, so Cogmind has nearly five times as much display area as the original roguelikes, or several times what is found in some other later roguelikes.)

Fast forward more than 10 years, and a much greater portion of people now play games on laptops, not to mention a greater variety of players have begun discovering and becoming interested in Cogmind, so the demand for alternative interface options is clearly growing ever larger.

Even if not the original target audience, I always wanted to accommodate more people when possible, and although my intention was to wait until somewhere around 1.0 to experiment with the possibilities, it’s also becoming clear that there’s no idea when Cogmind 1.0 will actually happen :P

Fortunately at this point we also have a very clear idea of Cogmind’s development needs, how players interact with the game, and pretty much all the UI considerations and limitations that we’d need to take into account to design the “most extreme” alternative interface layouts that could still work.

So it’s time to do that.

UI Requirements

Cogmind’s original UI concept had two basic requirements: a sufficiently large map view area, and a persistently visible list of all parts.

cogmind_essential_UI_areas_highlighted2

Interface components we can’t really do without, even if some were to take a slightly different form. Basic stats reflecting current resources and status are also pretty important!

Parts List

Unlike pretty much every other roguelike in which the player has a mostly persistent set of equipment, Cogmind’s parts list involves items that are subject to frequent tweaking and toggling, or at least warrant much closer turn-by-turn observation due to damage and/or status changes. The list also includes up to 26 different slots at once, whereas other roguelikes generally have half that, at most.

As such, being able to see and interact with this list in its entirety at all times is quite important, so it was given its own area on the interface. That will always be there.

cogmind_parts_list_various_late_game_RIF

Sample parts list.

Map View

Seeing the map, where most of the action happens, is also kinda important, too. But how much of it do we want to see at once? How large does this view need to be?

Cogmind was not designed to require widescreen support. In fact, the UI layout we have was originally built to fit snugly in 4:3 aspect ratio, only expanding horizontally to fill more space as available.

Therefore although it can be expanded to show more area, under that layout the minimum map view area allowed was set to 50×50 (in terminal dimensions this is actually 100×50, because map cells are square rather than rectangular, each occupying two terminal cells).

The number 50 is incredibly central to Cogmind’s design, because almost no weapons or active intel should have a range that can exceed the area a player can see by default. Cogmind being a game focused on ranged combat, repeatedly getting attacked from out of view would not be great, nor is having data on enemies roaming around you in multiple directions, known but out of view. These and other drawbacks of a small view area don’t make for an optimal play experience.

Assuming map view dimensions of 50×50, placing Cogmind at the center means the player can see out to a distance of approximately 25 or more in any direction. So ranges should for the most part be kept within that value.

Another reason to have a decently large map view in the first place is, again, the sheer size of maps to explore, and the potentially high level of local activity out there. A view area as large as 50×50 can still only see a mere 1/16th of the area comprising primary maps--more for some smaller maps, and even less for larger ones.

cogmind_sample_default_map_view_area_vs_full_map_size

Demonstrating a 50×50 area visible around Cogmind as seen while exploring a map (export provided by Mojo).

Like some roguelike classics, in TGGW it’s quite nice that you can see the entire map at once without any scrolling whatsoever, though it was clearly designed for such from the outset, with correspondingly short attack and sight ranges, and a smaller amount of concentrated content per floor, making each floor experience short and sweet.

TGGW_screenshot_04

Sample screenshot from The Ground Gives Way, with a mostly-explored map floor showing its layout.

Cogmind needs space for the scope it aims to fill, and a UI to match that, or at least facilitate exploring it instead of having to scroll a million times to form a mental picture, or constantly checking different directions to be aware of potentially impactful developments out there.

Basically from a gameplay standpoint roguelikes are best built with an optimal interface designed with optimal play in mind.

But now let’s switch gears and see what we can do in terms of making everything larger by breaking that design while attempting to mitigate the downsides :D

Alternative UI Layouts, an Evolution

Back in late November over on Patreon (and made available to everyone a little later) I put together a diagram and basic explanation for a hypothetical route Cogmind’s interface could take on the way to something that would expand the potential number of players for which it’s suitable.

Here I’ll be diving into that diagram again to give a more organized summary with some extra details.

Cogmind UI Layout Phases

General overview of potential semi-modal and modal UI layouts for Cogmind. See below for explanation.

Phase 1

The first phase is Cogmind’s current UI layout since mid-2013 when I started the commercial version (the 7DRL version was slightly different, always using 4:3). I’m using 76×50 for the map dimensions since that is the default map view width for 1080p users, which comprise the majority of players. As you can see, both the base sight range and good sensor/attack ranges are safely within the map view (these images are all drawn to scale!).

Phase 2

Before I started considering an immediate move to an across-the-board increase in cell size, I experimented with just zooming the map. Early experiments were promising enough to convince me to just do it--plow through the implementation and see what it feels like in practice (I wrote a series on that).

Cogmind map zooming (WIP)

Quick map zoom recording taken while implementing the related animation work.

One argument for prioritizing map zoom over figuring out how to enlarge the rest of the UI (if even possible) could be that such an approach might just be satisfactory for some players who say they’d prefer “a larger interface.”

Most play time is spent looking at the map, after all, and although this would not impact text in the rest of the interface, humans are better at recognizing familiar letters at smaller sizes than, say, game-specific monochrome sprites on a map. While Cogmind’s tiles were designed to be fairly recognizable via general shape, that’s still not comparable to our existing familiarity with letters (on that note, this is also why Cogmind ASCII mode can be more easily enjoyed on smaller screens than tiles).

That said, for everyone else who still can’t handle the smaller text, a zoomable map would only serve to further highlight the disparity between tile size and text size. Not only that, but as you can see from the Phase 2 diagram above, playing with the map zoomed pushes even base attack/sight/intel ranges somewhat out of view, much less enhanced the ranges. We’re going to need some powerful QoL features to make that playable in a serious capacity! (Update 240211: Some time after finishing this article I put together another piece detailing all that, with numerous demos.)

In that light, I decided it wouldn’t be a great idea to release just a Phase 2 UI with map zooming. I think for a lot of people it would feel more like a band-aid than a complete solution, and the latter is what I’d rather provide, especially as this will define a portion of peoples’ first impressions of a “new and improved” UI.

Phase 3

Phases 1 and 2 combined are basically the same old Cogmind interface, just with the ability to zoom the map (and supporting QoL features in that case). Phase 3 is a significant departure from the norm and requires a lot more work to realize.

The differences start at the lowest level, converting what has always been a 60-row terminal console to one that only requires 45 rows. This allows for an up to 33% increase in font size from what everyone is using now. For example if you have a 1080p resolution, 60 rows translates to a font size of 18 (=1080/60), where 45 rows would instead translate to a font size of 24 (=1080/45). So anyone currently using a size 18 font would see their maximum increased to 24, a 33% boost.

cogmind_resolutions_and_font_sizes_2024

A summary of the most common resolutions and the corresponding font size increase enabled by a 45-row layout (among a few even lesser-used resolutions than these top four, the increase might instead be closer to 20%). It’s interesting to compare this chart data to a similar one I made back in 2014 in an article about fonts, when the most popular resolution 1080p stood at a much lower 33%, and 768p was ranked a much closer 25%. 1440p/2160p were barely footnotes by comparison and there was a somewhat wider spread of resolutions in use.

The increase in font size results in a 44% reduction in total space to display info, and a 54% decrease in visible map area, which is a lot, but the latter is at least less severe than that caused by Phase 2 map zooming, which drops visible map area by 75%! The main difference is that Phase 2 zooming can be toggled in real time, whereas this info loss to accommodate a 45-row architecture by default is not capable of seeing full ranges as originally designed.

That said, as long as the QoL features built around map zooming work out well enough, they can also be of help in the Phase 3 UI, which technically already handles most ranges fairly well, and keeps the base sight range fully within its boundaries.

cogmind_interface_phases_potential_layout_evolution_phase_3

Overall I believe if given a choice between using a Phase 1/2 interface or Phase 3, the latter is probably a preferable default (except for among a good portion of current/frequent players who are quite used to having easy and efficient access to all the info provided by the regular interface).

And once players are using this Phase 3 layout, map zooming will likely become less useful overall (docked before it’s even been introduced xD). For one it would shrink the map view even more ridiculously, while turning size 24 tiles in our 1080p example above into 48px tiles, which is kinda huge :P

cogmind_semimodal_ui_layout_1080p_map_zoom_sample

Combining map zooming with a 45-row interface is… yeah. (sample assuming 1080p resolution, open for actual size, which is even larger than it appears here)

That’s probably overkill for most needs, though I can see zooming occasionally coming in handy for some people who still prefer the regular UI layout. In any case we’ll have stats on preferences in the future, and it’ll be very interesting to see how usage of various modes, and map zooming, plays out. (I can say that so far among the patrons who have access to test builds with zooming/Phase 2 enabled, almost no one is making serious use of the feature, but that’s not saying a whole lot because they were frequent players used to the playing without zooming to begin with.)

One welcome side effect of the font size increase is that 1080p players, who as noted form the majority, will be using size 24, which is a 2x upscale of the base tile size, in other words the original size for which the tile designs were optimized! Both myself and Kacper (the tileset artist who created most of them) are very happy about this :) (2160p players will also have access to such a multiple as one of their options)

So the next job in this process is to figure out how to squeeze Cogmind’s normal 60-row interface into only 45. Say goodbye to 15 rows from… somewhere :P

This will require a fair number of window and content adjustments, but it’s doable, with the biggest change being a semi-modal inventory. I’ll cover that part of the design in my next article, along with mockups and a more detailed look at just what we need to change.

One potential drawback of our map view returning to its original “pre-widescreen” width of 50 is that it goes against the flow of Cogmind’s on-map QoL design work. Because pretty much everyone has a horizontal rectangular map view wider than the area originally required by design, over the years we’ve benefited from some new interface elements that appear directly over the sides and/or corners of the map--alert messages, full combat log, special mode UIs, audio log, achievement popups… These will now be closer to Cogmind and potentially crowd the view under some circumstances, so we’ll have to see how they fare and whether some kinds of new adjustments are required.

Anyway, after being pleasantly surprised by the map zooming feature of Phase 2, I look forward to seeing how Phase 3 turns out :D

cogmind_450p_mockup_zoomed

Funny enough, with a new 45-row minimum terminal height Cogmind could be played using the size 10 font in a window as small as 450p! (mockup shown here with zoomed map, open for “full size”… okay the crisp version) The original minimum was 600p.

Phase 4

Phase 3 is definitely being worked on now, with plans to release it in early 2024. There is no timeline for Phase 4, and whether or not it could even happen depends on the outcome of Phase 3, but purely in theoretical terms it seems like a natural progression from Phase 3 that isn’t completely out of the question.

cogmind_interface_phases_potential_layout_evolution_phase_4

In the interest of reclaiming more of our map view, I like the concept of making the top-side windows modal as well, and see it as a reasonable possibility, if requiring yet more compromises to convenience and gameplay efficiency.

At the same time, doing this would have some nice advantages over Phase 3, like almost fully restoring our original 50×50 map view, and also alleviating some of aforementioned corner/side pressure caused by other on-map UI elements.

This is the first in a multi-part series about building Cogmind’s fully upscaled semi-modal interface layout:

Posted in Dev Series: Full UI Upscaling | Tagged , , , , | Leave a comment

Year 10 of the Cogmind

Well then, we’re well into Cogmind’s 10th year now xD

It’s kinda hard to nail down a clear “ten-year” mark, since we could measure Cogmind’s age from its birth as a 7DRL nearly 12 years ago, or when I started working on it full time in mid-2013, or its first commercial release in May 2015, but anyway yeah this is my 10th annual review, a thing I started doing every year since I decided to build this world of robots in full.

In previous years I’ve opened the review with a collage of dev images of varying themes and content, but approaching the end of this year we have one major theme that stands out, and that I’ll be writing more about below, so let’s hear it for the interface mockups!

cogmind_semimodal_UI_layout_mockups

Mockups put together in REXPaint some weeks ago during a dev stream in preparation for Cogmind’s new UI layout (open for full size).

Development Time

As of the latest tally I’ve reached a total of 16,785 hours of work in these 10 years. Numbers go up.

One of the things I’ve been focusing on a bit more in recent years is a revival of the greater game:non-game work ratio that Cogmind enjoyed in its early years when I was less interested in promoting it and more interesting in just building cool stuff.

Sure even now I still spend lots of time engaged directly with the active player community (which has other benefits for development like feedback!), though definitely less so outside that, as evidenced in part by the lower blog activity until very recently :P

This trend held in 2023, in fact marking the first time I’ve spent more than twice as much time on building Cogmind rather than doing other supporting work since the pre-alpha days!

cogmind_graph_annual_work_game_community_ratio_2014-2023

The ratio of direct work on Cogmind vs optional supporting work, mostly community-facing stuff. (2013 excluded because that year I did very little outward-facing work aside from quick blog posts and little progress updates on various forums, so 2013 would significantly skew the graph as an outlier.)

The dip below 1.0 for more than a year was the Steam release, a hectic time demanding that lots of effort be redirected to promotional needs and fielding customer support and such.

As for 2023 though, the extra focus on Cogmind itself can also be reflected in another graph with a similar path…

cogmind_graph_annual_item_count_increase_2016-2023

Net number of new items added to Cogmind each year. (<2016 excluded as outliers and mostly pre-alpha content being created to seed the first version)

I’ve included 2024 in that graph because the work on all those items was already completed on this year’s dev time, but have yet to be released, and as you can see it’s quite a cache. The final 2024 number by the end of next year will also be higher, almost certainly breaking the record.

Now obviously items are not everything--building the game involves other elements, plus raw item numbers can’t tell a full picture since some are very easy to add while others are quite involved, but Cogmind is an extremely item-centric game, plus they’re easy to quantify :P. This new batch of items in particular is composed of quite a few belonging to the mechanics-heavy very interesting category, so in that regard this spike is quite meaningful. Shown another way:

cogmind_graph_annual_item_count_2015-2023

Net total item count in Cogmind, 2015-2023 and beyond. The first three years there are Alpha, followed by Beta.

I’d share another of those cool item art collages, but I’ve already done that several times this year--scroll down SITREP #51 Another Big Bang to see one.

So overall I think this has been a pretty good use of time, and admit I’ve also also been increasingly motivated (and freed up) by Patreon support to keep focus on development itself, so that’s been quite a boon!

On the flip side, 2023 has also brought significant headwinds that somewhat reduced the total time I could devote to development in the first place (another reason to prioritize game work!). Basically lots of health issues, ugh, among them a repeat of what seriously incapacitated me back in 2017 (albeit from a different source--got randomly attacked by a bird wtf xD). That’s also why I had to cut most of my streaming this year, only doing 7 streams in the last 8 months (25 total streams in 2023 vs 40 last year), but anyway forcing me away from streaming also freed up time for development, so there’s a positive in there somewhere :)

Regardless, development has been accelerating rapidly into the latter months of 2023 and I’m excited to share what’s coming down the pipe, but first there’s more recapping to do…

Releases

A year ago as the end of 2022 approached I decided to pour a couple weeks into building a cool special event, producing Polymind.

cogmind_beta11.2_polymind_logo

“This holiday season you are NOT the Cogmind”

Aside: My annual reviews each year cover a Dec~Nov period, and usually come out in the first days of December--this year’s is late since I was too deep in the coding mines at the time. So Polymind is technically part of Year 10.

It’s a pretty cool mode (still available) that turned out well, I wrote a post-mortem about it, and the effort behind Polymind is already serving as the basis of at least one new official mechanic, after it was proven feasible from a technical standpoint :D

This year’s primary release was Beta 12, featuring revamped Garrisons, a major new faction mechanic, and the generative Scrap Engine build crafter.

cogmind_beta12_encrypted_comms_logo

All your base are belong to us.

The release turned out nicely, but is… definitely not what I originally planned to happen. What was released as Beta 12 was actually supposed to be part of a larger release, but itself grew so large in scope that it took a while to complete and had to be split off and released alone. Funny enough that was a mere precursor to what is continuing to happen to the other content it was to be a part of (now Beta 13, but soon to be more than that xD). More on that later.

Community

The player community continues as strong as ever, with new blood (oil?) joining all the time and friendly veterans teaching the ropes, guiding folks to their first win and beyond. Great to see and be a part of.

The latest prereleases have been experimenting with a unique form of optional Discord integration, which has been good for additional discussion and extra reference material. I wrote about that implementation earlier this year.

Cog-minder and its wiki and tools continue to grow. The original wiki I set up many years ago has been taken out of action by the host’s poor server maintenance--it still exists but recently became inaccessible to most browsers. It had already been partially gutted (the imported stat data) by an impossible MediaWiki upgrade path, so I was going to replace it with something else eventually. In the meantime it’s now a temporary landing page that redirects visitors to Cog-minder.

I’ve added functionality to support another of aoemica’s awesome projects, a combat log analyzer that produces pretty graphs and summaries based on the full export data from Cogmind’s newly-detailed combat log.

aoemica_cogminder_combat_log_analyzer_WIP_231222

aoemica’s combat analyzer! Before the next full release I’ll make further adjustments to Cogmind to further improve the potential accuracy and usefulness of this tool.

Normally I use the annual review to put out a call for some Cogmind votes over on IndieDB in their annual Top 100 list, but being too busy this year and not really wanting to bother with it anyway, just dropped a couple links on the Discord back then--apparently that was enough because Cogmind made the list for the 9th year in a row xD

Far more important is Patreon support, which really keeps things humming along. I greatly appreciate it! It’s especially helpful in this relative lull in outside interest until I get the new UI in order.

veradux_cogtree_2023

A 2023 “cogtree” by veradux, adorned with Runia’s excellent 3D-printed models :D

2024

This is where things get interesting, because 2024 is going to dwarf 2023, easily becoming Cogmind’s biggest year yet. We’re getting map zooming (already built), a new UI layout with larger font sizes for everyone (in the early stages of implementation), and of course the UFD expansion (a sizeable chunk of which is already built as well), plus most likely additional very significant things but I don’t want to speak too soon lest the birds come after me.

nervously glances out the window

Late this year I paused the expansion to prioritize major new UI features, including map zooming after figuring out how to make it compatible with the engine and game in general, as described earlier in this series. Its time has come.

Just this week I streamed the first playtest of that feature, and was pleasantly surprised. With help from new QoL features it was quite playable, even while zoomed in most of the time.

I tried it out with both pure mouse and pure keyboard input. Note that it was streamed as regular play rather than focusing on demonstrating all the relevant features in a short time, so the video is not a good source for a quick summary, but if you want to see it in action that’s one current option, and I did eventually have natural opportunities to test all the features and talk about them.

For better reference I’ll be finishing off that article series with a writeup on the QoL I built to support map zooming (there’s a lot :D).

cogmind_map_zoom_comparison_demo (scene from my test stream)

A snapshot from the stream I modified for use as a cover image to demonstrate the difference from zooming (open for full size).

Following that I’ll be documenting the process of an even bigger new interface project. Yep, even bigger than zooming.

Last month I wrote a little preview about this here, if you’re interested in the details and related numbers, but the gist can be garnered from the scale diagram I compiled:

cogmind_interface_phases_potential_layout_evolution

General overview of potential Semi-modal and Modal UI layouts for Cogmind.

This is what the mockups were created for, allowing Cogmind to be played in a 45-row terminal instead of the current 60, meaning a font size increase of up to 33% depending on resolution. (Although I streamed the mockup work, it wasn’t archived on YouTube since it was a pure laid back impromptu dev stream and we were listening to music.)

There were very significant design and architectural challenges to making this a reality, but having already surmounted them and built the foundations to make it possible, it’s now safe to say this can be a thing, and what I’ll be working on next. Phases 1 and 2 are complete (2 has yet to be released outside patron test builds), and 3 is under construction.

In the coming weeks the blog will start seeing articles about these Phase 3 developments.

That brings us to the 2024 release schedule… As usual I can’t give dates, but what I’d like to do here is give a general idea of what each future release contains, especially since it varies from what was originally projected.

As mentioned there was just going to be Beta 12 and that was Scraptown and friends. Well, “friends” got way too big so I thought I’d split it up into 12 and 13. Then while working on 13, “friends” got even bigger, one map becoming three maps and expanding to include a huge range of mechanics, a major faction, more large-scale events, and a new ending. With the new emphasis on inserting UI enhancements into the process, more splits are in order :P

Below is what I’m thinking for a tentative summary of the coming Beta releases, including what they might be called:

  • Beta 13 “Larger Text/Map Zoom”: Subcaves, map zooming, semi-modal UI
  • Beta 14 “United Federation of Derelicts”: Scraptown/UFD
  • Beta 15 “0bPrime”: New late-game map and ending (mysterious)
  • Beta 16 “Unchained”: Unchained! (you die here, so maybe we don’t need more betas? ;)
  • Beta 17 “Hexidium”: New map for only the bravest minds

Take this list with a pinch of salt, because as you can see plans do change when I decide to add yet more Stuff, but anyway delays only mean simply that--more content and features, so the timing is not super important in that regard. However I do want to try releasing a little more frequently than in past years with these ever more massive updates, so somewhat smaller cuts would be nice where feasible.

Notice I don’t have Phase 4’s modal UI in there anywhere yet, either--it’s too early to say much about that one since it depends on how Phase 3 fares.

I very much look forward to bringing you some awesome releases in 2024!

cogmind_photo_recycler_eating_source_code

Unless a Recycler eats the code.

Posted in Annual Review | Tagged , , , | 2 Responses

Adventures in Map Zooming, Part 4: Polishing

The core functionality of our map zooming feature is operating smoothly--common windows are popping up where they’re supposed to go, map interaction itself appears normal… however there are plenty of less vital systems that still need to consider the effect of zooming.

And after those there’s the public-facing side of this feature, like how do you access it, and do we need to animate it?

Odds and Ends

Gotta check every little thing, like the tiles-ASCII toggling animation, does that work?

cogmind_map_zoomed_tiles_ASCII_swap_bug

Nope.

How about the map export function?

cogmind_map_zoomed_map_export_bug

Nope.

Anyway yeah just a case of going in and seeking out what prior assumptions they made about the interface that no longer held true when zooming is possible.

For the tileset animation I think it was as simple as having needed to set it to match whatever tile size the map is currently using, rather than always using the standard size. Funny result though :)

The map export issue was similar, resulting in only the top-left corner of each oct tile being rendered, but to a huge mostly empty image. Resolving that was a little more complicated than simply switching to a dynamic tile size because you don’t want the output to actually use larger tiles (doing so takes forever and results in a massive image file that doesn’t even add any extra data since it’s purely a pixelwise upscale). Instead what happens now, assuming the player is zoomed in, is an automatic zoom out, prepare the image, then zoom back in, all behind the scenes. (Map export images are created by repeatedly moving the map view, rendering the view area, and copying that view to an image surface, eventually stitching together all the views into a final image.)

Many of Cogmind’s optional special modes also have their own UI elements, usually an interactive window in the bottom-left corner of the map, and although I don’t generally update those, failing to have them take into account a zoomed map would almost be equivalent to leaving them behind. That would be bad, especially the fan-favorite Player 2, and the essential-for-some RPGLIKE.

This ended up requiring that some of them be moved to the new window-container-map-view-thing I described last time, or in other cases slight architectural changes.

cogmind_map_zooming_special_mode_UI_compatibility

Sample special mode consoles remaining functional regardless of zoom state.

Okay we’re just about finished up with the zoom function here, let’s not forget about the last but not least important test of all… stress testing!

cogmind_map_zoom_stress_test

Repeatedly zooming in and out doesn’t seem to break anything, except maybe a few eyes if you keep this up.

Access!

From the beginning and throughout this entire process so far, I had simply dropped the zoom toggling code into the input section for responding to the map intel key, ‘z’. Now it’s time to consider how the player will access this feature…

Actually, as far as keyboard input goes ‘z’ seems appropriate, yeah? Obviously.

Then where does intel go? Under past circumstances I’d be tempted to leave map intel to F8, its matching window key which also works, and despite the awkwardness of F8 being a function key, I don’t believe toggling intel has been a common need in the first place.

That said, while working on map zooming I’ve also been somewhat thinking about interface developments down the line, and realized we’ll later on need to free up yet another key anyway, so where can we get two keys? The answer is inventory sorting.

Cogmind’s inventory can be sorted by type, mass, and integrity, each with their own key (t/m/i). We don’t really need the latter two. It’s not that they absolutely never come in handy, but after the Beta 11 storage rework the largest build inventories are no longer as extreme as they used to be, so there are fewer items to parse through, and you can also relatively easily see the mass/integrity info fairly easily in different data visualization modes--colored bars and numbers for integrity (which are also automatically subsorted for matching parts), and the ‘q’ info mode shows mass as its first number.

Two whole keys! And lucky for us they match our needs perfectly: ‘z’ for zoom, ‘m’ for map intel, and ‘i’ for… well you’ll found out what that’s for later ;)

cogmind_inventory_type_sort_final

The inventory’s {t/m/i} buttons have been replaced by a single large {sort (t)} button.

So anyone wanting to toggle the zoom state of the map can tap ‘z’ and boom, but what about mouse users? Can’t forget mouse users.

I had some different creative ideas* for this one, but settled on just making it a typical button. The <ZOOM> button appears directly over the center of the map, in the bottom left corner of the central multiconsole. It uses the same style as the <MAP> and <ESC/?> buttons, and is similarly capable of glowing.

cogmind_zoom_button_demo_tutorial

There is also a new tutorial message shortly after starting the game that points out the zooming feature, after which the button will glow until it’s used for the first time.

The button disappears completely while keyboard mode is active (like the CYCLE buttons in the parts list), since it’s not needed in that case.

*Before getting creative I originally wanted to use the mouse wheel for zooming, but it’s a mere toggle rather than a smooth zoom, so that’d be a bit of a waste for the wheel, and making such a change would remove the simple method mouse users can use to pass turn(s).

Fluff

Towards the end of the map zooming work I couldn’t help but take advantage of the opportunity for a new animation to test out a lot of possible concepts. Like dozens and dozens of them.

I shared a bunch of samples from that process on Patreon, like this one I thought was pretty neat:

cogmind_map_zoom_animation_ascii_merge_unused

In this animation test, zooming the map in ASCII mode merges multiple copies of each character into a larger version to fill the final cell size.

The problem with such animations is that they can be too distracting when the purpose of adjusting your zoom is clearly to get a better look at something or some things, be it closer up or further away. So you need to be able to quickly focus, a need which most animations are likely to detract from.

And while sure it’s fun to get a cool new animation, if it gets in the way it would more easily “get old.”* Yeah we could make it optional, but if it’s detrimental and most people would presumably want it off, then why add it in the first place?

*on that note, I do plan to eventually swap out the world map animation for something snappier! the world outgrew that thing a long time ago…

In light of that analysis, and having not found anything extremely compelling while exploring animation styles, from early on I was already leaning towards having no animation at all--short and sweet, right? Instantaneous results, either big like you want it or small like you want it.

But maybe there’s some other type of animation that could add a little style and maybe even be somewhat helpful for quickly digesting the new view area…

I got to thinking that one of the main elements that’s universally important and the first aspect you might visually analyze is the general layout of the map. This is usually defined by walls and doors, so what if we just highlighted all of those after a zoom?

cogmind_map_zoom_animation_highlight

Wall highlighting shortly after a zoom state change. Zooming out lets the highlight last longer since it’s more relevant in that case, having added new content to your viewport.

I also considered highlighting other objects like machines and hostiles and/or something more, but figure it’s easy to go overboard and get back into distraction territory, so decided to stop there for now.

And that’s it, the map is now zoomable, and zoomable in style, and can be played that way. But it’s not yet ideal! Playing with a zoomed map introduces yet more challenges that we’re going to need some new QoL to help resolve next time…

This is the fourth in a five-part adventure through the process of putting all this together:

Posted in Dev Series: Map Zooming | Tagged , , , , | Leave a comment

Adventures in Map Zooming, Part 3: Implementation

Time to get serious! Last time I told you about my engine upgrade and the new “quads,” now it’s to put them to use.

If you recall, for my initial Cogmind map zoom demo upon adding Quad support to REX, all I did was change one thing in the game: the map font size.

The game doesn’t care about the engine side of things so it simply worked, or at least didn’t crash and we could easily see how it’d appear, despite of course numerous input and secondary display issues in some other windows. By just tweaking a few more variables it would be easy to solve all those problems in order to purely have a consistently larger map view. Things get a lot more complex if we want to support both the regular map font and quads, not to mention the ability to swap them dynamically while the game is running.

But with the engine fundamentals solid and behind us, we’re ready to tackle those challenges.

Normally with UI feature implementation I’ll start by writing out a comprehensive list of everything that needs to be done, and any other elements I can think of which might be affected and therefore need testing and confirmation. While I drew up at least part of such a list like a good dev, this is one of those rarer cases where attempting to write a complete list ahead of time is probably not all that feasible or helpful, as it’s basically… the entire interface :P

With a change like this I would need to test pretty much everything, so instead of trying to be complete about it, I just noted areas of the code to be adjusted as I thought about them while working on fixing high-priority features, trying my best to finish off entire groups of related interface elements to speed up the process.

I started in the most important place, restoring the basic functionality required to speed up the rest of the implementation, like fixing map panning and cursor-map interactions. And realtime zoom toggling in order to easily compare and confirm that everything functions properly in both states.

And it was shortly after getting those bits operational that I discovered I wasn’t quite done with the engine xD

When examining the details of what still needed to be done in the map area itself, I realized that while zoomed in we’d probably also want to increase the font size of many types of text that appear over the map, especially object labels which are already integrated pretty tightly into the map coordinate and orientation systems.

cogmind_map_zoom_wip_map labels_small

Yeah these labels are not great like this, using the regular text size (ignore the fact that they’re not even pointing at the right objects here :P).

To maintain the proportionality of map-related text when zoomed in, we’d need… zoomed text. Oh no.

Back to REX

Last time I introduced the engine’s base cell size that fits individual text characters, wide glyphs for square map tiles, and the new “quad,” or four map tiles in order to enable a zoomed effect. To zoom text we’d need yet another type of glyph size, one that like the doubling of map tiles for quads (2×1 to 4×2) instead doubles text/base cell size (1×1 to 2×2!).

For me one of the first annoyances was what to call this new type, and I decided they’re probably best named after the number of base cells they occupy, meaning I had to go in and retroactively rename all the quad stuff to oct. Now our zoomed text glyphs can assume the name “quad.”

rex_terminal_grid_demo_quad_and_oct

A new member joins the REX glyph type family!

Because I had built a generalized system to simplify handling of both wide glyphs and octs (previously quads), inserting this new type was actually fairly easy (whew!).

rex_testing_console_quads_and_octs

REX again displaying operation of the newly renamed octs, and the new quads (the main new area of interest being the large olive-colored box).

Well, the initial implementation was fast, but on returning to Cogmind to apply it to map labels I found an issue…

cogmind_map_zoom_wip_label_text_shearing_bug

The text quads worked nicely in most places, but sometimes this happened. Perhaps we’ll just say this Recalibrator is corrupted and leave it at that? :P

It took a while to figure this one out, since I couldn’t quite tell if it was a Cogmind problem or a REX problem. This was particularly tricky to track down because it looked like an engine bug but also had a property that suggested it couldn’t be an engine bug, yet its other behavior pointed to it to being impossible to be a bug caused by the game itself… Anyway, a really weird confluence of situations managed to hide the real reason for a good hour. It had to do with a specific type of partial transparency of the new quads/octs, and of course it was caused by just one line of code in the engine.

Zoom Text Applications

Yay now we can have some large text on the map, too!

cogmind_map_zoom_wip_map labels_large

Revisiting the scene from earlier, this time with larger labels.

Beyond labels, I also enabled the on-map mode indicators to make use of quad text. To facilitate this (and by necessity for architectural reasons), I also refactored that part of the UI--they used to be drawn directly to the map at the end of its rendering process, but now they are a real window.

cogmind_map_zoom_item_large_text_label_category_mode_indicator

Cycling through item label categories, with the mode indicator visible at the top of the map view.

On-map popup alerts like low matter/core/etc. also got the zoomed text treatment, for one because they otherwise looks fairly small compared to everything else and would be even more likely to go unnoticed.

“ALERT” announcements are also larger now, almost too large when they include longer strings, but again having them remain at normal text size doesn’t seem ideal for getting noticed among the larger map cells. I might tweak those later when the UI undergoes more changes down the line, but for now they’re large.

I also decided to convert the program shutdown animation to the zoomed text, and unlike its other uses described above, this is the only instance in which it is used regardless of map zoom state.

cogmind_close_animation_new_strip_size_2

Cogmind’s program shutdown animation with larger central bar.

The MegaTODO

The UI is way more than just a handful of temporary popups though! Back to that growing list of challenges… well, technically most are not especially challenging, it was just a case of putting in all the necessary hours to scour the source for anything affected by the advent of new glyph types.

There were lots and lots (and lots) of alignment issues due to years of relative coordinate assumptions behind the fact that map spaces were always twice as wide as text, and both text and map spaces had the same height. Now map cells could be four times as wide as text, and twice as tall!

Most popup windows relative to something on the map needed to have their dynamic coordinates take into account additional calculations.

cogmind_cursor_hover_detection_debug_visualization

The old REX debugging visualization for examining UI z-depth and cursor hover focus came in quite handy for solving some of the more mysterious issues.

cogmind_debugging_console_index_structure_output

I also finally built an exporter for Cogmind’s window index structure to help track down some issues related to cursor input. In fact it also helped me find and resolve an unreported and difficult-to-notice bug in Cogmind’s UI that’s been in there since the very first version!

A chunk of the adaptation work actually required larger architectural rewrites, like the project of splitting the map interface into a trio of classes.

The first new class was purely to hold interface data that must be preserved during zoom events. Whenever a zoom occurs, the entire map interface is actually destroyed and recreated from scratch (far simpler than trying to convert everything over), but doing so would also lose some important info needed to facilitate various QoL features such as targeting history and resource alarm records. So data of that nature was moved to an external class to preserve it regardless of any zooming.

The second class is more interesting, a kind of container for other windows, those that are positioned over the map itself.

A number of windows such as on-map dialogue lines, combat logs, and achievement popups may need to be placed on any UI row within the map area, and these being organized under that window itself was never an issue before. But what happens when the map is zoomed such that a single “oct” occupies two rows? The map window’s grid coordinate system now no longer has any values corresponding to every odd row of the main interface, meaning its child windows cannot be placed on those rows.

So all of those map-related windows in which vertical alignment is important down the sub-row level needed a new parent window, kind of a fake alternate map window that always has a finer coordinate system regardless of the viewable map’s zoom state.

None of these informational windows are interactive, either, so this “finer map” window doesn’t need to capture mouse input and only has to occupy a 1×1 spot in the top-left corner of the map. It is a good example of an “unhidden yet transparent and therefore invisible” control window, allowing it to update normally and its children can both appear visible and use their parent as a coordinate reference (placing subwindows outside of a parent is fine).

The reason it must have an unhidden state is because that’s a prerequisite for actually updating itself and updating children, but is at the same time transparent because the window doesn’t actually want to display anything of its own.

cogmind_debugging_window_zlayer_data

Another useful debugging feature, the ability to show all windows that exist under a given cursor location and their z-depth. With the cursor in the top-left corner of the map there, it shows that there are two map classes overlapping at that location, the single-cell window container CMapFine, and the regular CMap class. The other values can show things like coordinates, indices, current colors, tile values, and any active animations at that point.

So yeah, long story short, this process wasn’t just about changing font settings and recalculating coordinates.

At this point all the heaviest lifting was done, but there was still an awful lot of residual work before map zooming could be called feature complete. I’ll share more on that next time.

This is the third in a five-part adventure through the process of putting all this together:

Posted in Dev Series: Map Zooming | Tagged , , , , | Leave a comment

Adventures in Map Zooming, Part 2: Engine-level Architecture

Taking a different tack from last time, I decided that it would be worth getting really dirty with low-level engine work for the next attempt at map zooming. One of the main reasons we’d need to go this route if there’s ever to be hope of reasonable performance in software mode: Dirty rects. If we play by the engine rules we get to keep that functionality in its existing simple package, which generally means massive savings on CPU cycles.

REX

It had been a while since I’d done any serious tinkering in “Rogue Engine X” (REX), Cogmind’s underlying game engine. The acronym you might recognize from REXPaint, the engine’s ASCII painting software I built with it for my own use and later released (dang that’s been out for over 10 years now, too, with many of its own users).

I do very occasionally add a little REX functionality here and there to cater to Cogmind needs (or REXPaint for that matter), but it’s been mature for like 12 years so there’s never been any huge developments in that time.

My plans this time were for a pretty big one: Add a third type of glyph size.

To summarize, in traditional terminal style the display is just a uniform grid of monospace glyphs, each with a foreground and background color. Less traditional, and needed to produce Cogmind’s map with square spaces as opposed to rectangular ones more appropriate for text elements, two adjacent text cells can be occupied by a single “wide” glyph.

rex_terminal_grid_demo_narrow_vs_wide

The concept is simple, though does require that text characters take up about half the width that tiles do, which can be a little restrictive at certain sizes.

So the terminal has a base cell size, though doubling the width of that base size gives another wider type of glyph that can be used as well. (I also shared a larger diagram and some related ideas under the section “mixed fonts” in my Fonts in Roguelikes article.)

cogmind_terminal_grid_demo_narrow_vs_wide

Notice how the tiles in this Cogmind screenshot each occupy two cells, delineated by the partial grid overlay.

In practice it gets a little more complicated than one might imagine from the above description, because glyphs are not drawn directly and immediately to the visible console as shown, but instead first drawn to their own subconsole, and numerous subconsoles can overlap one another at different positions. This is great for organizing an interface, though when it comes time to merge everything to create the final view, partial overlapping means you can have pieces of larger glyphs showing through, etc.

The idea is to now add something even bigger than wide glyphs, but a key point is that whatever the new dimensions are they must still be a multiple of the base cell size. We have the regular base cell size used for text characters, a wide glyph size used for map tiles/characters, and what can we extrapolate comes next for a zoomed map if we want it to retain a square aspect ratio? Enter: the quad.

rex_terminal_grid_demo_quad

Big chonker tile has arrived.

Doubling the map tile size turns 1 wide tile into 4 (2×2), so while a wide cell occupies two base cells, a “quad” glyph would occupy 8 base cells, 4 in the first row and 4 in a second row. This behavior is similar to the wide glyph, just wider, while also expanding in a second dimension as well, so introducing it to the engine logic is, uh, fun :P

I had to rewrite most of the wide glyph support in order to add quads, but having wide support already there to reference was helpful, and merging everything under the same umbrella kept the overall complexity from expanding much.

To design and test quads I loaded up my old REX testing environment, which contains a random assortment of little test consoles and behavior samples to ensure everything is working properly. One of the important things to test beyond basic functionality (which itself took a little while to get down) is quad overlap with other consoles of different types, and screen edge overlaps.

rex_testing_console_quads

Been many years since I used this thing! It was put together as the engine features were coming together back in 2011 (my first post about it).

Some of the environment is animated/dynamic, though with quads it’s more about rendering and alignment issues, and confirming that underlying data values are correct.

I got pretty excited seeing the quads appearing normally each time a new test was devised and (finally) passed.

It’s official: REX has quad support!

Fonts

REX/Cogmind/REXPaint/etc use bitmap fonts, so if we’re adding a new glyph size that means we also need to accommodate that size in the font files.

While I allow quad fonts to be loaded from file, and that’s what I worked with for the initial implementation, it seemed unnecessary for our needs as far as providing this zooming feature in Cogmind, since our main goal is to simply allow the upscaling of map tiles. Therefore another part of this engine rework was to allow quad bitmaps to be generated as needed. Basically quads don’t have to exist until a given font set is actually set to be used, at which time the bitmap will be generated in memory by upscaling a specified source bitmap which has already been loaded.

Cogmind

Then there’s Cogmind over here not having any idea what’s about to hit it. Hm, what will the impact be? My first quick test was to simply switch the map font to a quad and just… see what happens!

Well for the most part it Just Works. Wow. No crashes, just big tiles.

There’s some obvious kinks like the fact that I didn’t even change the map view dimensions, causing the map view to also quadruple in pixel size and extend off behind the HUD and off screen, therefore “centering” Cogmind in the bottom right corner. That’s to be expected, along with other issues like console alignment and any other source code references assuming the map view is using wide-type glyphs.

But the important thing is that IT WORKS.

cogmind_zoom_map_first_sample

Cogmind’s very first use of the new “quad” glyph support added to REX.

That ain’t no mockup. Also because it’s playing by the engine rules there is zero performance hit from this feature. Zero.

You can see the UI jank--to record that I had to turn off autocentering and use the mouse for directional input, plus the misalignments and weird stuff in various locations (check out the items in the inventory xD). BUT IT WORKS.

There is clearly still a lot to do. Manually test swapping the font is literally all I’ve done so far on the Cogmind side of things--the size can’t yet be toggled dynamically, but before starting this whole adventure I did prove it could work in theory by testing whether the game would explode if I tried to destroy the entire main map interface and recreate it on the fly.

The disparity between the surrounding UI text size and map tile size when zoomed is kind of annoying--it’s not quite the same aesthetic, but if it means some people who otherwise might not be able to play could now do so, I guess that’s a good thing! Also again I find myself wondering what portion of potential players will find this sufficient since it doesn’t address text, but maybe in combination with the Terminus font it will work for most people. We’ll just have to find out.

While doing the latest map zoom experiments I also came up with an initial list of complementary feature ideas, those that could help blunt the negative impacts of having a much shorter view range than usual.

  • Cogmind may not necessarily be centered when zoomed, instead having the view gradually shift so that you can see further and further in your general direction of travel, out to your actual sight range. Cogmind’s unmodified sight range (16) while truly centered in a zoomed view would extend at most about 4 spaces out of view in the worst case scenario--a north/south direction, so Cogmind would generally be within that distance of the center unless sight range is further boosted. (East-West direction is less of an issue since the view is a horizontal rectangle for most people’s screens.) I can see this dynamic view positioning being fairly complicated to implement well, but a good formula and related behaviors there could save the player a lot of time that would otherwise be spent scrolling around.
  • The above feature is likely more appropriate for keyboard users, not mouse users who wouldn’t generally be happy with a map sometimes shifting to a different position under their cursor during successive movements. For that type of input it would be nice to have a way to quickly set your own relative centering position, depending on the direction from Cogmind you wish to see more of while moving or performing other actions.
  • Labels for important things, especially hostiles, that enter FOV but are not currently in view can be shown at the edge of the view in their direction. Or perhaps not the whole label, but more like the floating indicators that appear to denote an offscreen drone or Cogmind location. Cogmind already stops and labels new hostiles, so this would just be an extension of that feature to accommodate zoomed folks who want to have a little more info about the cause. Heck, maybe in temporarily pausing the action it could even shift the view over a bit to directly see the cause?
  • For new players, zooming the map could perhaps assume they would like everything to be larger or more readable, in which case maybe it’d be a good idea to also automatically switch the font to Terminus at the same time? Just a thought though, not a fan of this approach, and I think it won’t be nearly as relevant given the nature of future planned UI updates…
  • This one’s just fluff, but I can see feedback SFX and an optional very fast animation for the transition between zoom and standard view, for people who want to use both and do it in style :)

Lots of optional features out there, it appears, though exactly how many of them are actually useful, and more importantly can actually be implemented in a way that brings out that usefulness, remains to be seen.

Anyway, those are just some general notes for now, and I haven’t done any real playing with this feature active, but later once it’s actually built and not hacked together I’ll definitely be trying out some runs to see what about this setup irks me and if there’s anything I can do about it.

Although a zoomed map this isn’t the kind of feature I want to use, I imagine it could be useful to others, and look forward to seeing where development takes it. I’ve always loved working on UI to begin with :)

This is the second in a five-part adventure through the process of putting all this together:

Posted in Dev Series: Map Zooming | Tagged , , , , | Leave a comment