next »

[Kyzrati]

Yeah types. Well, both new classes and variants thereof. I add new ones almost every release. And often times these are the impetus for a portion of the new parts, because I want them to be distinct

[JobLeonard]

Oooh, for the NPCs! I thought for a second you'd drop the blank-slate Cogmind, which would kind of go against everything I know about the game.

[Kyzrati]

Year 3 of the Cogmind
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Unbelievable... I've been working on Cogmind for three and a half years now. Yet another year has gone by, and this time the end is very much in sight!

To start off, as I did for 2014 and 2015 here's a collage of development images from the past year:

Images from the past year of Cogmind development as appeared on this blog and Twitter (full mega size here).

GIFs outnumbered PNGs about three-to-one, but an animated collage wouldn't be able to include enough images to do the year justice . I don't have anywhere specific I collect only GIFs, though I did use a number of them on the page I put together this year dedicated to summarizing some of the innovations Cogmind is bringing to the genre.


Development Time
As usual I've been keeping close tabs on where every hour is spent, altogether 6,383 hours so far:

Cogmind Monthly Development Hours, 2013.7-2016.11 (click for crisper full-size version). (The color coding is for different aspects of development tackled each month, the subject of a future in-depth article to come when Cogmind is complete.)

That's 1,982 hours this year compared to 2,321 last year, when I was doing a lot of promotional prep for the launch (trailer, website, etc.), and didn't take any vacations like I did this year. (The year before, 2014, totaled 1,528 hours.) Comparing purely work on the game itself, this year added 1,151 hours compared to 1,273 in 2015 (and 1,078 the year before that), so in that respect progress has remained relatively steady. There's lots more interesting data in there, but I'll get into that another time.

At the end of 2015, my only worry was that I'd be forced to do a full launch earlier by cutting or postponing newly-planned features, but through a careful balance of progress and minimal marketing, revenue has remained steady, and Cogmind keeps growing extra features :D


Releases!
2016 saw seven major releases.

Cogmind release summary, as seen on the FAQ. For links to changelogs, full release notes, and preview images, see the Release History I maintain on the forums.

As you can see, progress consisted of maps upon maps upon maps... Cogmind began 2016 with 14 map types, and is ending it with 26, each of which also added unique mechanics, components, and in some cases major plot events. The world got so big that it was finally time to add a world map.

Sample Cogmind world map in action.

And with that Cogmind's story is almost complete, which is my primary criterion for judging Cogmind to be 1.0. So we're close!

As far as sharing progress, note that the nature of this dev blog has changed--while I used to share smaller specific development updates here, this year you'll notice I've instead shifted to publishing mostly longer articles of (hopefully) greater value about some relevant gamedev topic, with occasional aggregate Cogmind updates where they align with that goal.

Regarding individual features and content, I technically share even more updates than I used to, but that progress is posted to the announcements board, subreddit, and Twitter (also some other forum threads).

I like this division of focus, and will continue the pattern into 2017, with planned articles on topics like pricing, game difficulty, code testing, roguelikedev tips, and more.


Milestones
So what other big milestones did 2016 see...

Well, the biggest would have to be that Cogmind passed both the 2,000- and 3,000-player thresholds this year! (The latter just this month.) This was the first full calendar year that Cogmind was available for purchase. Yep, in addition to the 2015 initial launch, the public alpha (Early Access, if you must!) has continued for 19 months now. Sales have been acceptable, enough to avoid forcing me to cut features! Actually, enough to convince me that I have leeway to add more, and as a result 2016 brought tons of new mechanics and QoL features that wouldn't have otherwise been possible. So thanks from myself and on behalf of future players :D. On that note, back in May I did a recap of the first 12 months of Alpha Access, wherein I shared revenue breakdowns, among other reflections.

Cogmind's community has grown in absolute terms, though as we're still in alpha most new supporters play for a bit then stop to wait for 1.0. I decided against holding another tournament like the Alpha Challenge 2015, at least this year, because while it was great fun, it also took too much time away from development last year :/. The leaderboards, however, have been very active, and there has been lots of helpful related discussion (both development-wise and player-to-player) on the forums.

A recent snapshot of the top of the Cogmind leaderboards. The leaderboard system has advanced somewhat as well, now separately listing further areas reached by player, and providing access to the score sheets for each run.

Forum discussion has slowed somewhat in the second half of the year, though, as many long-time players have switched to hanging out on the chat server (Discord) for the past 4-5 months.

On the project side, out of curiosity I compared Cogmind's lines of code to a year ago--this year it passed the 100k LoC mark:

Cogmind lines of code, from 2015 to 2016.

In the past year there's been a net +16,396 lines of code, or a 17.2% increase. Not a lot! That's because as described earlier much of the progress this year was in content--new maps and their corresponding robots, components, events, etc. All of that stuff is implemented via external scripts, map prefabs, and other data files rather than code. Essentially this shows the core game was already solid in 2015, all it needed was more content to realize The Vision.

But hey, we passed 100k


Recognition
Each year Cogmind attracts more attention, and this year in addition to the smaller sites that published related news/articles, Cogmind appeared among the Top games on Rock, Paper, Shotgun, on Destructoid's Top 33 list, and Nerd Much's Top 50 list.

More recently RPS did a sudden quick article on Cogmind following one of this year's larger releases. That title was quite a shock, and something I totally wasn't ready for. Very busy those few days xD. In any case, it did spur another big chunk of sales which will help propel development to 1.0! Very grateful for that coverage.

Then just this month Cogmind was once again voted into the Top 100 indies of the year on IndieDB.

It's good there's just enough attention going around to keep bringing in new players, because I'm still not doing any active marketing outreach. I get legit review key requests, but they go on a list for later and I'd rather focus on development and the existing community for now. That said, I have been doing a lot in the wider roguelike community, including making my way over to the US to take part in the awesome Roguelike Celebration! I felt like a nervous wreck, but gave a talk people seemed to enjoy anyway .

I don't really look forward to it, but by necessity 2017 is going to be a very different kind of year because I'll have to mostly shift away from creating content and on to business and marketing -_-. That's where hobby development really shows its superiority over doing this to make a meager living!


2017
This is it. 2017 will be a crucial year for Cogmind, because it's the year we reach 1.0, and the year we'll finally see what cogmind can do once it reaches a wider audience--will it flop, or will it be able to pay for more roguelike goodness in the future?

I never imagined back in 2013 when starting out (and most certainly not when putting out the initial free version in 2012!) that I'd still be working on Cogmind now, but I'm glad I am because it's the result of good things! There haven't been any serious development hiccups, and progress has continued at the expected pace, I just repeatedly pushed back the long-term schedule to fit in more stuff. It's true that many of these things could have simply waited until after a "1.0" launch, which is what I'm sure most sane (or financially desperate) developers would do, but even Alpha 1 was a pretty solid game, and there's been ongoing player support ever since it was released, so I never really saw a need to rush it.

That said, development is naturally coming to a 1.0 milestone. I mean, look where I've set the current progress meter:

Cogmind development progress as of November 22nd, 2016.

Almost everything's at 95%, which is basically me-speak for "you could call it done but I could always do more, and I am."

There's still the ambient audio to work on, a portion intentionally left for last so it could more efficiently be handled all at once, and there are already so many sound effects that they essentially create an "ambiance without any ambient sound," so it wasn't required for alpha to have additional background effects anyway (though there are a few placeholders out there). I'll be getting on that soon.

For fun I put together a time-lapse gif showing how the public progress meter (always shared via the FAQ) has evolved to reach this point:

Cogmind development progress graphs, from August 2014 to November 2016 (early on in pre-alpha there were still enough incomplete subsystems to warrant displaying them individually, but eventually for much of alpha it boiled down to just maps and story).

Looking to the future, well, I've also continued to share the major bits over in the FAQ:

Cogmind dev roadmap snapshot, November 2016.

A bunch of the pending stuff will be scratched off with the next release--just two more releases and the last remaining bits of Cogmind's world will be complete, to be followed by whatever features I feel shouldn't really wait until post-1.0 development. I.e., they need to be in there before Cogmind gets more attention from the less die-hard fans. I haven't finalized exactly what those pieces are yet, as there are quite a lot of optional features and content still left on the chopping block. I'll take stock of those later, and after implementing them it's time to do a 1.0 release. And then, you know, keep releasing more after that

In short, Cogmind 1.0 is coming in 2017. Getting nervous, but also can't wait!

And once again, Happy New Year :D

Playing with a fake weapon that fires 30 missiles. Because hell yeah 30 missiles.

[Fat Pug Studio]

I've been following the development of Cogmind for a while now, and i must say i'm very impressed. Everything from idea, to graphics and performance is top notch. I wish you the best of luck with the game, you did a magnificient job, i will be the first to buy it 

[JobLeonard]

I don't know if we have a "best devlog of 2016" thread yet, but this definitely deserves to be in there.

[Kyzrati]

Thanks Fat Pug Studio! I'm giving it my all... perfectionism has its drawbacks, but there are some benefits, too

I don't know if we have a "best devlog of 2016" thread yet, but this definitely deserves to be in there.

Well, this year I've certainly reduced the overall number of full-length articles, but I believe the quality has continued to increase (which is kind of a problem because I have trouble not trying to outdo myself, haha xD).

[Kyzrati]

Dev shots! Decided to make an AI path visualizer for fun, just to watch the AIs calculating paths to their destinations as I cycle through the turn counter.


And another in which you can see the map itself as well:


And some still shot variants from Cogmind's position:








So... while I actually just did all this for fun, it turns out the pathfinder, which I wrote as a beginner over a decade ago and still use today, actually isn't all that optimal . I never knew that, so now have a clear target for optimization if I need a performance boost at some point. Visualizations are useful!

[Kyzrati]

Have an ASCII New Year! :D

[LuisAnton]

 

I saw this gif yesterday while browsing twitter, no idea it was related to Cogmind! Then, just by chance (it's been ages since my last time here) I lurked TIGSource a bit and found your devlog in the third? page... and this gift. WOA.

I wish you the best for Cogmind this 2017!

[Kyzrati]

Hehe, yes this gif sure made it far and wide on New Year's, one of my most popular tweets ever

I could've put something me-specific in there to use it more as advertising, but felt that would cheapen it. Still, even seeing it in settings not attached to my name, apparently some who are really familiar with my work spotted that it was mine right away, since I'm the only one who does ASCII like this

Glad I spent the time on this little gif scene. I think it's going to be a great year!

[Kyzrati]

Was debugging and had walls turned off, which is a pretty cool aesthetic, actually :D


And some fun details about that New Year's gif from earlier:
-It's running inside Cogmind
-The "city" is just a huge machine (top-down!)
-Firing zero-damage missiles

I spent a good chunk of time on it, during which naturally there were a few bugs and issues to work out...

Here is the fireworks area of the map, but I forgot to remove all the debris from the ground ("sky")...


Shooting practice fireworks manually to test them. This pattern was, um, supposed to be a circle


Then this @ decided to shoot himself with a rocket.


Here's one of the @'s dropping his fireworks tubes at the door of the building, where it then goes off after he makes it to the street...

[Kyzrati]

Still chugging away on the next release, which should be ready the week after next... Lots to do before then.

Just finished a huge chunk of new content, with dozens of new items and secret stuff coming with the "new narrative." Some of the art:


There's an option to keep areas outside the FOV colored (albeit darker) rather than use the green overlay:


And less a chance of misclicking/mistyping on the game menu now that the buttons require confirmation:

[Kyzrati]

Continuing work on QoL requests for the next release, we now have item labels colored by integrity:


For now it's optional and off by default, though, because item autolabels done in color can be confused with robot autolabels (= slower reaction time), which is why I didn't do them by integrity in the first place. It's also off because I'm adding another feature to the standard labels, darker labels for items that are at less than 75% integrity:

[Kyzrati]

Map Prefabs, in Depth
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

An increasingly common approach to roguelike map development today is to have content partially determined by so-called "prefabs," with layouts which are hand-made rather than fully procedurally generated. Doing so gives a designer more control over the experience, or portions of it at least, without completely supplanting the advantages of roguelike unpredictability.

Prefabs are a great way to add more meaning to a map, which when otherwise generated purely procedurally and visited again and again by a determined YASD survivor is often going to end up feeling like "more of the same" without a little manual help to shake things up. Yes, even procedural maps get boring once players start to see through their patterns! Not to mention the general lack of anything that really stands out...


Background Reading
I've written and demonstrated a good bit about map generation before, including the basics of how I create prefabs for Cogmind, starting with essentially drawing them in REXPaint. This method is light years ahead of the old "draw ASCII in text files" method I was using with X@COM (now that I have REXPaint, I'm definitely going to have to go back and convert that system, that's for sure!).

Sample X@COM map prefab excerpt, typed! In text! The horror! (At least it used a little bit of syntax highlighting to help pick out important features...)

And once prefabs are created, one of the major challenges is how to actually get them into a procedural map. After all, they need to seem like they belong! Previously I demonstrated some methods for handling that part of the process in cave-style maps, namely geometric centering (sample) and wall embedding (sample). Read the full post regarding that style over at Generating and Populating Caves.

But most maps in Cogmind are not caves, instead falling under the room-and-corridor style. Naturally these other maps will require different methods for embedding prefabs, and below I'll be sharing these methods in addition to a more detailed look at what Cogmind's prefab definition files have evolved into over the years.


"Seeding" with Prefabs
One way to place prefabs is before map creation even begins, in fact shaping the initial generation itself. This approach is for prefabs that will help define the core feeling or difficulty of the map as a whole, thus it's more suited to larger prefabs, or key points such as entrances and exits. It's easier to control the absolute distance between these important locations by placing them first. So high-priority prefabs come first... that makes sense .

As entrances and exits are essential features while also having a large impact on how a given map plays out, thus my maps are designed to place most of them first. Not all of them are handled as prefabs and are therefore beyond the scope of this article, but some special exits that require more flair, fluff, events, or other types of content use this "initial prefab" system. The first such example is found very early in the game in the form of the entrances from Materials floors into the Mines (admittedly one of the less interesting applications, but I don't want to leak spoilers for later content).

Step 1 in the map generator is to go down a list of potential prefabs and configurations and put them on the map!

Complete feature list for Materials-type maps.

Sample step 1 (feature variant 3) as seen in the map generator for Materials.

In this case, as per the feature list the generator chose to go with variant #3, which calls for two BLOCKED barriers to prevent pathways from linking areas on either side of them, in addition to two top-side MAT_00_S_1_MIN prefabs, one to the west and one to the east. Looking at the relevant feature data (those last two lines), these prefab areas block all entity spawning within their area, and have ever so slightly variable coordinate offsets (some prefabs elsewhere make much greater use of this ability to shift around).

The MAT_00_MIN file stores the data that allows the engine to decipher what objects are referenced within the prefab:

Data references shared by all Mine entrances.

And "MAT_00_S_1_MIN" refers to the file storing the layout itself:

Mines entrance MAT_00_S_1_MIN prefab layout, as seen in REXPaint. (This is a multilayered image, so here you can't see the complete machine hidden under the 'A's.)

The southern edge calls for a tunneler (width=3, the yellow number) to start digging its way south to link up with the rest of the map (when its generation proper begins), while both the left and right sides are tunnellable earth in case later pathways are dug out from elsewhere on the map that would like to link up here. Those are simply other possibilities, though--the only guaranteed access will be from the southern side.

Final map after all steps concluded, incorporating Mine entrances placed first.

Other common candidates for initial prefabs are huge semi-static areas, sometimes as large as 25x25 or even 100x100, which play an important role on that map either for plot or mechanics purposes.

A portion of map generated with two large prefabs (highlighted) that were placed first.

The next method is a bit more complicated...


Embedding Prefabs
Most of the prefabs in Cogmind are not applied until after the initial phases of map generation are complete. Therefore all the rooms and corridors are already there and I had to determine the most flexible approaches for adding this type of content to a map without screwing up either the prefabs or map itself.

Before going any further, though, we have to decide which prefabs to add in the first place, a decision naturally affected by the theme, depth, and other various factors associated with the map in question. That process is handled via the "encounter system" I initially described in this blog post (half-way down), but I never got into the technical side of how those encounters are selected, or how those with prefabs are actually merged with the map, which is relevant here. (*Clarification: An "encounter" refers hand-made content which may be loot, enemies, friends, or basically anything, sometimes combined with procedural elements, and sometimes but not always associated with one or more prefabs.)

In general, while there are a few types of encounters that appear across multiple maps, like rooms full of debris, each type of map has its own pool of potential unique encounters. And then there are multiple base criteria that may or may not be applicable in determining whether a given encounter is chosen:

• Depth limits: An encounter may only be allowed within a certain depth range. (I've actually never used this limitation because maps containing encounters generally only appear at one or two different depths anyway.)
• Count limits: An encounter may be allowed to appear any number of times, or up to a maximum number of times in a single map, or up to a maximum number number of times in the entire world (only once in the case of true unique encounters such as with a named or otherwise NPC with very specific behavior).
• Mutual exclusivity limits: Some encounters may not be allowed to appear in the same map as others. These will be marked as belonging to a certain group, and exclude all others once one is chosen.
• Access limits: Encounters can require that they only be placed in a room connected to a certain number of doors/corridors. It is common to restrict this to 1 for better prefab layout control (i.e. knowing which direction from which the player will enter makes it easier to design certain prefabs).

Encounters are also not given equal weight--some are common while others are quite rare. I use words/strings to assign encounter weights in the data, because they are easier than numbers to read and compare, and can be more quickly tweaked across the board if necessary (by changing their underlying values).

Encounter weight value ranges (source).

 

Encounter weight values (data excerpt), where each column is a different map, and each row is a different encounter.

So you've got some prefabs chosen and a map that looks like this:

Completed room-and-corridor map generation, sample 1.

Or this:

Completed room-and-corridor map generation, sample 2.

Or something else with rooms and corridors. How do we match encounters with rooms and actually embed prefabs in there?

Unlike "seeding prefabs" described earlier, these "room-based prefabs" actually come in a few different varieties, but all share the characteristic that they are placed in what are initially rooms, as defined by the map generator. Of course the map generator must know where it placed all the rooms and their doors in the first place, info which has all kinds of useful applications even beyond just prefabs. Can't very well place prefabs without some likely target areas to check!

The most common prefab variety is the "enclosed room" category. A random available room is selected, then compared against the size of each possible prefab for the current encounter. (A single encounter may have multiple alternative prefabs of different dimensions, and as long as one or more will fit the current room then oversized options are simply ignored.) In order for a rectangular prefab to fit the target room it may also be rotated, which doubles as a way to provide additional variety in the results. And yet another way to expand the possibility space here is to randomly flip the prefab horizontally. (Flipping vertically is the same thing as rotating 180 degrees, so kinda pointless )

Steps to place an enclosed room prefab.

• Find a room that's large enough to hold the desired encounter/prefab.
• Find a target rectangle which borders the doorway. (The horizontal axis is randomized to anywhere that will allow the door to be along the prefab's bottom edge. Prefabs are always drawn to face "south" by default, to establish a common baseline from which to shift, rotate, and flip them. And those with a single-door restriction are always rotated so that their bottom edge faces the door, whichever side of the room its on. This makes designing the experience much easier since you always know which direction from which the player will enter this type of prefab.)
• Prefab dimensions will generally not precisely match those of the room in which they're placed, therefore the surplus room area is usually filled in with earth and the walls are rebuilt along the new inner edge (though the room resizing is optional--it can be left as extra open space).
• Place the prefab and its objects, done! (rotated example shown on the right)

There are some further customization options as well. Doors can be expanded to multi-cell doors, like for special rooms that want to be noticeable as such from the outside (as a suggestive indicator to the player). Or the door(s) can be removed to simply leave an open entryway.

Variations on the above room prefab via post-placement modifications.

The third form shown below takes the modifications a step further by removing the door and entire front wall to completely open the room to the corridor outside, creating a sort of "cubby" with the prefab contents.

Front wall removed for cubby variant.

Storage depots found in Cogmind's earliest floors use the "cubby room" design. The reason there is it makes them easy to spot and differentiate from afar, which helps since the point is to enable players to expand their inventory if necessary for their strategy.

Storage depot prefab as seen embedded in a Cogmind map.

Another "accessible room" variety is essentially like an enclosed room, but the prefab is designed to allow for maximum flexibility and access rather than expecting the room to be shrunk down to its size and new walls created. These prefabs usually don't have internal walls and instead just become decoration/contents for an existing room without changing its structure. While it may end up in a room larger than itself and therefore have extra open space, including these types of prefabs is necessary to fill parts of the map containing rooms with multiple entry points where rooms with obstructions and walls wouldn't do because they could illogically block off some of those paths. For the same reason, accessible room prefabs must leave all of their edges open for movement (though may contain objects that do not block movement).

Steps to place an accessible room prefab.

• Find a room that's large enough to hold the desired encounter/prefab (any number of access points is valid).
• Position the target rectangle anywhere in the room (random).
• Place the prefab and its objects, done!

The primary drawback of using the encounter system to place encounters in randomly selected rooms is that there is no control over relative positioning of different encounters. While it's possible to add further restrictions or tweaks to guide placement on a macro scale, it seems to work out okay as is. The existing system does, however, also sometimes result in suboptimal placement of encounters, i.e. a smarter system could fit more into a given area, or better rearrange those that it did place to maximize available play space. But these effects are only apparent on the design side--the player won't notice any of this.

An alternative would be to use a room-first approach, choosing a room and then finding an encounter that fits, but in my case I wanted to prioritize encounters themselves, which are the more important factor when it comes to game balance.

Post-mapgen prefabs placed in a map, highlighted by category for debugging.

So overall my prefab solution is a combination of external text files and binary image files, processed by about 3,000 lines of code.

(...article exceeds post length limit--continued in next post...)

[Kyzrati]

(...continued from previous post...)

Inside a Prefab
So far we've seen how prefabs fit into the bigger picture, but another equally important aspect is what goes into a prefab itself. Each prefab must have an associated definition file (sometimes shared by multiple prefabs if they have similar contents), which is a simple text file that describes the objects found in the prefab.

My first ever prefab article (linked earlier), written two and half years ago (!), appeared before even any prefabs had been used in Cogmind. As you can guess, things have evolved since then, getting a lot more versatile and powerful as new features were added to meet new needs throughout alpha development. Here I'll give a general rundown of those features, to give a better idea of how they work.

At the most basic level, a definition file is simply a list explaining what object each ASCII character in the prefab represents. After placing the initial prefab terrain--walls/doors/etc, the generator consults the corresponding definition file and creates those objects at the specified positions. Reference characters are written to the prefab image's fourth layer as part of the design process (they can be any color, but I always use green for consistency).

Sample prefab layout image (draw in REXPaint and stored as a compressed .xp file). Green letters and numbers all exist on the highest layer (layer 4) and refer to objects. This particular prefab represents one quarter of a garrison interior, which are built entirely from a large selection of prefabs.

In a definition file, each line corresponds to a reference, of which there are five types:

Prefab definition object types.

For consistency and to aid readability of prefabs when creating/editing them, I always use upper case letters for props and traps (the latter actually being a subset of the former), lower case letters for entities (robots/mobs), numbers for items, and punctuation for debris (of which only one reference is actually necessary, because the actual appearance is determined by the engine).

Note that a "tag" is the internal name for an object, which may not always match the name the player sees, to enable objects that appear the same but are actually different for whatever reason.

The above basic info, a character plus the object's [TYPE] and [TAG], are the only required data for a given object, but most objects will be followed by additional data keywords that describe the object in more detail (overriding otherwise default behaviors). The set of applicable keywords is generally different for each type of object, though any reference can specify the [SHIFT] keyword, which instructs the prefab to randomly shift that object within a certain area, (+/-x, +/-y), so that it doesn't always appear in the same place.

Sample prefab keywords used to expand on different object definitions. Custom syntax highlighting helps parse the file when editing.

Items and entities specifically have more options for their [TAG] value. Quite often it's desirable to select one from among multiple potential types, a feature supported by additional syntax and keywords.

Randomizing entities in prefabs.

The first example demonstrates how it's possible to designate any number of entities from which to randomly select, in that case a G-34 and G-47.

The second example, on the other hand, simply specifies an entity class, and the game will select an entity appropriate for the depth at which the prefab is placed. This is useful for prefabs used across multiple depths, and has the added benefit that any changes to object names (and other values!) do not force reconsideration of existing prefabs. For the same reason, hard-scripting specific object names is avoided where possible.

The third example simply demonstrates random selection between different classes works, too.

Designating a class instead of a specific name may also call for additional keywords (optional), where [CATEGORY] suggests which category to select an entity variant from, where a single class may belong to more than one entity category, [STRONG] tells whether to select an entity that is one level stronger than the current depth, and [FALLBACK] tells the engine to fall back on the weakest variant when technically no variant of the desired class exists at or below the current depth.

Randomizing items in prefabs.

Items (and traps, actually) often do the same thing, and can range from extremely specific (Ex 1) to extremely vague (Ex 4). Ex 2 demonstrates just a sampling of the available categories to select from, as away of narrowing down the selection pool--important for balance and controlling the experience! And Ex 3 is a pretty situational one, randomly selecting an item that would normally be equipped by the entity in parenthesis, to allow for thematic loot (the scene of a specific battle, for example).

Where no specific tag is given, the [PROTOTYPE] keyword suggests that the item should be chosen from among prototypes (a better type of item) than common items, [NEVERFAULTY] designates that a chosen prototype should never be a faulty version, and [RATING]+X can be used to have the map generator attempt to choose an "out of depth" item instead (where X is the number of levels higher than the current one to choose from).

The theme of non-static prefab data is an important one, as it's a relatively cheap way to make even handcrafted content stay fresh despite repeated exposure. To take this theme even further, individual keywords can be modified by various prefixes with different effects:

Prefab keyword randomization modifiers. These can be applied to any data keyword for any object.

For larger scale randomization we also have two available columns at the beginning of each line (excluded from all of the above samples):

Prefab generic randomization capabilities and syntax.

Despite the appeal of randomization, it is often desired that multiple entities or items placed near each other in a prefab should be of the same type, even when randomly selected. Thus by default whenever the object for a reference character was chosen randomly, any cardinally adjacent matching characters will automatically use the same object type (extending as far as necessary in a chain). Where there is a need to allow adjacent objects (even those with matching characters) to be different from one another, the [UNIQUE] keyword can be used to explicitly force that.


Some Statistics
As of today Cogmind contains...

• 148 base types of encounters, 115 of which use prefabs
• 372 prefabs in all (much higher than the number of encounters because some have multiple prefabs, and as explained before not all prefabs are associated specifically with encounters)
• The largest prefab is 100x90
• The smallest is 3x2 (mostly a mechanical thing)
• The average is 7x7
• The single encounter with the greatest variety of unique prefabs has 12 to choose from

In total, 25% of encounters are categorized as "fluff," 15% as "risk vs. reward," 14% as "danger," and 46% as "rewards."

[Kyzrati]

Spent much of the day working on targeting system improvements, essentially for keyboard-only players.

Like automatically re-targeting the same space again


and auto-recalling previously used waypoints for subsequent guided weapon firing


There's a longer list of relevant changes (and some demos) here. Now in the final stretch for the next release--another huge one 

[Kyzrati]

Our first major release of 2017!

And a major release it is, with a changelog to rival even Alpha 12 and, even better, early-game content updates so that everyone can experience lots of new stuff rather than just those players exploring the late game. Alpha 13 brings with it a "new narrative," yet more UI features, mechanics... basically a ton of improvements to simply make Cogmind even more engaging.

And new friends. Lots and lots of new and interesting friends...

For a visual sampling of some of what comes with Alpha 13, you can browse this couple dozen feature images I put together.

For the full release notes with extra detail and an introduction to what this release is all about, see here.

The full Alpha 13 (0.10.170117) changelog:

* NEW: Branch map "Zion" expanded
* NEW: 1 major plot event with potentially far-reaching effects
* NEW: 1 major new NPC (unique robot class)
* NEW: 1 new common robot w/unique behavior, "Thief"
* NEW: 5 new special robots (3 unique classes, 10 variants in all)
* NEW: 32 new items (total = 800)
* NEW: Trap items have a unique sprite
* NEW: New special item type in caves: Scrap (moving onto it automatically searches)
* NEW: Wide-ranging set of ally-sourced hacking abilities to discover, available as part of a new system
* NEW: More reasons to visit Mines (what those are I'll leave you to discover)
* NEW: Several new cave encounters
* NEW: 87 more score sheet entries (total = 579)
* NEW: 3 new low/mid-tier Fabricators and Recycling Units
* NEW: Ninth damage type (secret)
* NEW: Triangulation mechanics/utility
* NEW: True cloaking mechanic (via new Cloaking Devices)
* NEW: Recycling Unit Retrieve(Components) hack output explicitly states number of components retrieved, since may not equal full contents
* NEW: Repair Stations, Recycling Units, and Scanalyzers color listed items by current integrity
* NEW: Repair Station repairable item list marks those which are broken to avoid requiring opening info window to confirm
* NEW: Explosion falloff stat context help explicitly mentions visual representation in the form of AOE color's brightness relative to the origin
* NEW: Encounter-based optional world map shortcuts
* NEW: "Alert Popups" option that displays flashing on-map warnings and alerts for low integrity/energy/matter
* NEW: "Part Auto-sorting" option that enables automatic sorting parts after changes (occurs once moving again)
* NEW: "Show Non-FOV Color" option to show areas outside with darker colors rather than the green overlay (toggle at any time with Ctrl-`)
* NEW: "Click Walls to Target" option that allows that feature to be toggled (now off by default)
* NEW: "Color Item Labels" option to use integrity-based color scheme for item labels, both manual and automatic
* NEW: Standard item labeling method uses slightly darker shade to indicate items at less than 75% integrity
* NEW: Option to allow right-clicks on walls to enter targeting mode (cogmind.cfg only: see rmbWallsToTarget)
* NEW: Manual explicitly states that fliers must switch to another form of propulsion in order to bump-rewire disabled targets
* NEW: Any encounter action in which an NPC drops an item is accompanied by the proper material-based drop sfx
* NEW: Manual and context help clarify specific stat effects of propulsion overloading
* NEW: Confirmation required for suicide/quit game menu options (including a required 1-second delay)
* NEW: Armor auto-replacement breaks ties using each armor's respective rating
* NEW: Added "Multiple Projectiles" section to manual (under Weapons) to explain how they work
* NEW: Sealing a garrison after installing a trap on the entrance itself gives explicit log message referring to the trap's destruction
* NEW: In-game manual's keyboard navigation supports Numpad as well
* NEW: Attached processor to be dropped/removed/swapped flashes until confirmed (or window expires)
* NEW: Numpad 0 equivalent to 'd' key for opening object info; in keyboard mode also identifies item at current location without examine mode
* NEW: Explicit context tutorial message about the drawback of attempting to aim through an obstacle at a target behind it
* NEW: Overhauled autotargeting and target selection system (see new manual section "Targeting Priority" under Advanced UI)
* NEW: Targeting and examine modes both support -/= and Numpad -/+ for cycling through objects
* NEW: Firing at an empty space or other non-robot target is remembered for subsequent shots, automatically targeted again if still visible
* NEW: Repeatedly firing a guided weapon will remember and automatically reload all of previous attack's waypoints, if still visible
* NEW: Shift modifier w/Numpad cursor movement in examine/targeting modes jumps four spaces (customize via cfg: cursorJumpDistance)
* NEW: In targeting mode, Backspace or Numpad Enter centers cursor on self (keyboard mode)
* NEW: Added explicit Notes section to manual
* NEW: All supporter names registered since Alpha 12 added to in-game list (see Credits menu)
* NEW: All item-attribution names registered since Alpha 12 added to the item collection gallery
* MOD: All former optional target cycling methods unified, is now always distance-based (near to far)
* MOD: Target cycling includes only armed hostiles if any, otherwise all non-allied targets
* MOD: Item cycling order in examine mode switched from row-based to distance-based, near to far; also accessible by Ctrl-Numpad -/+
* MOD: Entering targeting mode via 'f' with only a melee weapon active will limit target cycling to adjacent targets
* MOD: Diametric Drive now a prototype
* MOD: Upped melee sneak attack base hit chance to 120%
* MOD: Derelict Log ASCII art recolored, rather than matching Data Core
* MOD: Non-hostile Derelicts use much brighter shade of gray
* MOD: Trap Extractors somewhat more commonly found among regular stockpiles
* MOD: Gui. Remote Datajack now a prototype, improved to rating 9
* MOD: Trap items changed from light gray to red (in ASCII mode)
* MOD: Reduced number of sound channels for environment destruction, to lower volume of large-scale collateral damage to machines
* MOD: AI (enemies and allies) spot targets one space further away than previously, more in line with their actual sight range
* MOD: Z-Series renamed to Q-Series
* MOD: Minseweeper variants renamed: Extractor -> Sweeper, Miner -> Extractor
* MOD: Particle Charger integrity increased (+10, all variants)
* MOD: Original set of Cloaking Devices renamed to Phase Shifters
* MOD: Utility Shielding no longer protects Armor parts
* MOD: Allies are tier-prioritized when passing to new map, better ones appearing closer (any lost in transition will naturally be weaker)
* MOD: Drones show their class name in info page instead of "Special"
* MOD: Controllable allied drones appear in blue instead of fuchsia
* MOD: Assimilated prototype robots always appear blue
* MOD: Scanalyzer-listed non-scanalyzable items appear blue instead of yellow
* MOD: Mines infestation less common, and sometimes accompanied by a new encounter
* MOD: Imp. Signal Interpreter displays non-combat classes in a different color
* MOD: LRCs are now their own class
* MOD: Inventory sorting accompanied by sound effect (became silent in Alpha 11 due to removal of interface message w/typing sfx)
* MOD: Removed "Auto-sort Inventory" from options menu (still available in cogmind.cfg as autoSortInventory)
* MOD: Removed "Distance-based Volume" from options menu (still available in cogmind.cfg as soundIgnoresDistance)
* MOD: Removed "Center Cursor on Move" from options menu (still available in cogmind.cfg as centerCursorOnMove)
* MOD: Removed "Animated Volley Range" from options menu (still available in cogmind.cfg as animateVolleyRange)
* MOD: Removed "Target Preference" from options menu (now obsolete)
* MOD: Major NPCs no longer susceptible to core disruption
* MOD: Allies/AIs no longer attack dormant bots (until awoken)
* MOD: Item rating value context help clarifies its importance in simplifying the comparison process
* MOD: Added mechanics details including machine-caused LOS reduction to the manual's "Spotting" section (under Combat)
* MOD: All EM cannon energy costs increased approximately 40%
* MOD: Recycling Unit tunneling more likely to discover areas closer to current depth than further away
* MOD: Log message reporting a world location learned via derelict log etc. is different if location was previously known
* MOD: World map will not show additional discovered but unvisited Factory areas at the same depth (may have been learned by tunneling through chutes)
* MOD: Score sheet "Alien Tech Recovered" renamed to "Alien Tech Used" (behavior unchanged)
* MOD: Confusion due to corruption no longer tries to move into walls, take exits, or otherwise attempt an involved action (rewiring, machine interaction)
* MOD: Recall() hacks no longer appear on Command terminals, nor do they have an effect there
* MOD: Svarog and Perun core integrity +33%
* MOD: Zionites have a new sprite
* MOD: Gaining new intel no longer automatically opens intel window (can reactivate feature via cogmind.cfg: autoOpenNewIntel)
* MOD: Melee attacks never miss walls/doors/machines
* MOD: Mechanics, Protectors, and disarmed combat bots no longer considered a "threat" for movement purposes (requires "Stop on Threats Only" option on)
* MOD: Part rejection side effect of corruption no longer occurs outside combat situations
* MOD: Thermal Generator effect description changed to avoid implying it prevents thermal damage
* MOD: No Garrison Access below -8
* MOD: Assaults and Intercepts no longer dispatch simultaneous with Exterminations
* MOD: Increased effect on alert level from disabling machines and having allies in tow during combat
* MOD: +1 rating to all hackware at the Improved tier and above
* MOD: Adv. Remote Datajack rating +1
* MOD: Hackware stat progression rate reduced significantly
* MOD: Two additional higher robot hacking difficulty tiers
* MOD: Previously hackable prototype robot systems now much more difficult
* MOD: ARCs/Z-Series/Behemoths and many more now fully hackable (difficult but not impossible)
* MOD: Reduced by ~20% the chance of hostile Programmers successfully assimilating allies with average/high hacking defenses (e.g. Grunts/Hunters)
* MOD: Build command at all Fabricators easier
* MOD: Preloaded item schematics at Fabricators now better than usual, even out of depth
* MOD: More Fabricators will tend to have preloaded schematics
* MOD: Slightly reduced mass support for all flight propulsion at and above rating 4
* MOD: World map no longer accessible during examine/targeting modes
* FIX: Getting a Repair Station refit or being repaired by a Mechanic ignored extra slots of multislot items, attaching more parts than necessary [Vectis]
* FIX: Advanced key command listing for evasion info still showed '/' despite having been switched to '\' [zxc]
* FIX: A particular late-game encounter involved a robot that could still take a hostile action even if assimilated before acting [zxc]
* FIX: Under rare circumstances a valid path between cave entrance and exits may be blocked off by a wall [Sherlockkat]
* FIX: Vi-key running via 'r' modifier wasn't working in all cases [Dracunos]
* FIX: Part mass visualization should show relative values for unidentified non-propulsion parts [Dracunos]
* FIX: Removal of BUILD order in Alpha 12 shifted tallies for other ally orders in score sheet [Widmo]
* FIX: Backup parts which became "Unknown" due to data loss remained unknown even after attachment during Mechanic repairs or Repair Station refit [Widmo]
* FIX: Mechanics headed to resupply at a Repair Station which is then disabled may still resupply if interactive section not completely destroyed [Widmo]
* FIX: Recyclers headed to insert at a Recycling Unit which is then disabled may still use it if interactive section not completely destroyed [Widmo]
* FIX: Recycling Unit's Refit function only available manually rather than via button (until reconnect) if repaired an attached part [Widmo]
* FIX: While flying was possible to swap with a non-flying ally on the other side of a hostile (will now clear them, too) [Widmo]
* FIX: Unable to cycle through World Map in keyboard mode if current or previous locations in Waste or Garrison [Widmo]
* FIX: Inconsistent new map autosave behavior depending on Show Map Intro option setting (now always saves as soon as possible) [Widmo]
* FIX: Manual terminal hacks seeking analyses for robots that have no schematics would always indicate unavailable at current depth [Widmo]
* FIX: Extracting resources from a container by waiting on top of it did not update the scan window if displaying that container [Widmo]
* FIX: While flying, was possible to hack a machine directly on the other side of a blocking hostile [Widmo]
* FIX: Typo in W-25 Informer and B-99 Colossus analysis texts [Widmo]
* FIX: Reclamation Units could reclaim themselves on destruction [Amphouse]
* FIX: Derelict Surgeon variants overheated simply from upkeep costs due to an imbalanced loadout [Happylisk]
* FIX: Allied MAIN.C classes/variants transferred to a new map would be renamed [elite277]
* FIX: Clicking on the evolution UI where the Confirm button will appear, even before assigning slots, advances to next map without new slots [piedol]
* FIX: Allies were causing almost no additional increase to the alert level in combat
* FIX: Traveling through Recycling didn't increment evolution count by the proper amount in score sheet
* FIX: Confusion due to corruption was warning when a move would ram a robot or step on a known hostile target, making negative consequences avoidable
* FIX: Weapon toggling hotkey (') behavior didn't work properly when autoReadyLauncher option activated in cogmind.cfg
* FIX: In rare cases a horizontal line may appear after a log message and get stuck there until the message was redrawn due to scrolling
* FIX: NPCs that speak on sight were not supposed to flash the green '!' to indicate dialogue, since a bump is not required to trigger
* FIX: "Traps Extracted" score sheet entry was including non-player tallies as well
* FIX: Chute traps never spawned on Factory depths visited on a previous run in the same session
* FIX: One or more prop-sourced ambient sounds could disappear early when overlapping with others during movement
* FIX: Rebooting, dormant, or otherwise inactive programmers were still capable of protecting nearby allies from hacking attempts
* FIX: Crash in message log system if attacking a wall with a base accuracy of exactly 110%
* FIX: One character (147) in ASCII art contained a few extra pixels when using 14x14 font

[JobLeonard]

* NEW: 1 new common robot w/unique behavior, "Thief"

Will it be more infuriating than the Scavenger?

[Kyzrati]

* NEW: 1 new common robot w/unique behavior, "Thief"

Will it be more infuriating than the Scavenger?

You know what, it's funny you ask because yes, it might very well be! That said, currently they're pretty rare. I'll use them a little more later on when there's time to again expand on cave encounters (these are a type of derelict). Curious how people react to meeting one, though

[JobLeonard]

it might very well be!

Are you trying to kill off customers via strokes caused due to high blood pressure?