Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 ... 81 82 [83] 84 85 ... 104

Author Topic: Cogmind (sci-fi robot-themed roguelike) - BETA RELEASED  (Read 286704 times)

Kyzrati

  • Bay Watcher
    • View Profile
    • Grid Sage Games
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1230 on: April 29, 2017, 08:52:15 am »

Tons of progress this week, although I'm probably going to postpone the next release for an additional week while I pack in more stuff. A couple of gifs to check out:
(I posted a longer list of updates on r/roguelikedev, but all that stuff's going to be in the upcoming release preview anyway.)
Logged
Cogmind - Sci-fi Roguelike (devblog) | X@COM - The X-COM RL | REXPaint - ASCII art editor | Patreon

Kyzrati

  • Bay Watcher
    • View Profile
    • Grid Sage Games
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1231 on: May 01, 2017, 07:54:44 pm »

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

No, not plant seeds.

As most fans of the genre are aware, a fair portion of a given roguelike run is determined based on values returned by a pseudorandom number generator, commonly referred to as the RNG. Before it can do its job, an RNG must be "seeded," or given a value that starts the entire chain of values to be returned beyond that point.

Certainly when a roguelike starts up all it has to do is seed the RNG with the current time (the most common practice) and then not worry about it after that--the RNG helps create maps, chooses what populates that map, determines the outcome of actions, and so much more. But it turns out there are many other seed-related considerations and applications when developing games with procedural content.

Important to all this is the understanding that the seed used to initialize the RNG doesn't have to be random. If manually set to the same number each time, the resulting chain of numbers it spits out will also be the same!


Cogmind's Seed Structure
For reasons we'll get to, Cogmind doesn't just store one seed. There is of course The One Seed, actually called "worldSeed," which is the single seed from which all others are derived. So in a normal run the world seed is simply based on the current clock time (meaning yes, players who start their run at exactly the same millisecond will technically be getting the same world layout!). And by reusing a specific world seed value in a future run, the exact same world can be generated again and again. Or by simply starting a new run at a different time, the world generated will be completely different.

But if that's true, then why do we need more than one seed? The answer in two parts: 1) individual maps are not generated until the player reaches them; 2) different players may visit maps in a different order. Therefore at the very beginning of world generation, right after the world seed is determined, it then creates the world layout and within the data for each potential future map it stores the seed to be used to create that map if and when the player arrives there.


Every map has its own mapSeed, generated by the worldSeed (some extraneous comments and code trimmed for clarity).

When the player arrives at a new map, the map generator loads the seed for that map before starting the process. This ensures that everyone visiting that map via the same world seed will also get the same map, regardless of how they reached it.


Development and Debugging
As you can imagine, the ability to force the world to generate in a predictable, repeatable pattern by manually setting the seed is extremely useful for perfecting a map generator like the ones I've talked about before.

My first use of seeds in Cogmind would have to be during early pre-alpha development, where much of the focus was on map generation. Being able to seed the generator to recreate the same map again and again when working out problems with the underlying algorithms saved a ridiculous amount of time compared to just waiting for specific problems to pop up. So I could keep skipping through procedural maps until finding an issue, check whatever seed led to it, force the generator to use that seed, then step through the process to find out what went wrong (or could be improved). It's really easy to track down isolated issues by simply putting a breakpoint in the debugger for a specific coordinate in question, and examine what's up with it.


I spent a lot of my time looking at maps like this, waiting for a "bad seed" to investigate.

After releasing the alpha, bugs either reported by players or that I discover myself are sometimes related to the initial state of a map, and in cases like that it's ridiculously useful to be able to just load up whatever seed produced that map and take a closer look. Being able to reliably repeat a bug is the first, and biggest, step to actually resolving it! The alternatives are not too pretty--if unable to guess the cause from a simple report, having to wait for it to appear again to get more details is an annoying drawn out process, not to mention much more difficult to do remotely.


A run's seed is output to run.log while the game is running, as well as added to the final score sheet.


Preserving Consistency
It turns out there are all sorts of places where a seed can go wrong :P

Ideally a world and its maps and all the little details within those maps originating from a single seed should be the same for each player using it, so there are important game-specific considerations aimed at preventing "divergence."

A simple example would be scrap piles in the caves, which are kind of like treasure chests that drop loot. If I didn't care about proper seed support my normal approach would be to simply generate the loot on the fly when the player steps on the pile, but each player will have taken different actions before that point, meaning the RNG will give each of them different items! For consistency, all players using the same seed should have access to the same "random" loot. Of course the brute force method would be to pre-generate and store all the loot when the map is first created, but this is wasteful in terms of both time and memory. Instead each pile just stores its own unique "loot seed," and when necessary that seed is used to seed an RNG which generates the loot on the fly. That way it comes out the same for everyone on the same map. (It also means that attempting to save scum to get different loot won't work :P)


Determining loot from scrap at the point of interaction.

An example of a system that required a more involved solution to ensure consistent game worlds is the unique encounter handling. While some encounters in Cogmind are generic and might occur more than once, many are unique and should at most happen only once per run. (It would be weird to meet the same named NPC and specific encounter more than once in the same run :P) But because maps aren't generated until the player reaches them, there's no way to know which map might use a certain unique (or otherwise limited-count!) encounter. A given encounter may be allowed to appear on any number of maps, but what if player 1 visits map A first and gets that encounter, while player 2 instead visits map B first and gets that same encounter. Their maps will generate differently! And they'll have even more divergent experiences if they then visit their respective "other map."

To address that, all unique or limited encounters are randomly assigned a valid map when the world layout is first generated, and they will be chosen from among the pool of encounters available for their map, which may or may not use them--it can't be sure because there may be other conditions required for that encounter to actually appear (conditions that cannot be confirmed until the map itself is created), but at least it's known that said encounters cannot appear on other maps and cause divergent runs from the same seed!

Seed-based map generation also requires explicitly separating out a number of components that factor into the initial state of a map, where those components are derived from player actions. Actions like bringing allies from one map to another, or plot-related content through which the player can affect future events, all need to be taken into consideration to prevent prior actions from affecting the base map, which should remain as consistent as possible aside from purely what the player influences. For this reason I'm careful to exclude anything player-specific from the map generation process until the very end.


Cogmind mapgen source transition from the underlying map to player-specific adjustments.

Other changes to the usual behavior are necessary when players manually seed their own run. This is to make sure that the handful of automated player-specific meta features are deactivated. These are features aimed at newer players, such as the tutorial map, which normally replaces the first map for a player's first three games. Another example is an encounter inserted only the first time a player enters a Waste map, wherein a Derelict says a little dialogue before running ahead and getting brutally crushed so the player immediately realizes that's not something they want to do :P


Bad things are about to happen.


Seed Formats
Seeds don't have to be numbers! Well, they are internally, but developers shouldn't place dev restrictions on players where unnecessary. It's time for more "ergonomic" seeds :)

Number-based seeds are boring, and not as easy to remember or share, so early on I made sure to allow any alphanumeric strings to count as valid seed input. Players can, for example, try out using their name as a seed, or some other interesting words or phrases. I've even had one player go through multiple runs, changing the seed to a new phrase each time, which when read together formed a longer message and appeared in the upload stats :P

Of course, internally these string-based seeds are no different from numbers. Each character is converted to its decimal value, all of which are multiplied against one another to create a final number the RNG can use as a seed.

So manual seeds have always allowed strings, but random seeds (i.e. the majority of seeds players are using by default) have still been represented by numbers. More recently I decided that I wanted to take this a step further and have even random seeds be expressed in words, but how would they be determined?

The solution was inspired by gfycat, which instead of generating a string of random characters for their URLs uses an AdjectiveAdjectiveAnimal format (see the end of their about page). My first thought was to go with lists of Cogmind-relevant words that I'd draw up myself, but that looked like it would be quite a lot of work--there had to be a quicker solution. And there is!

Cogmind already has a bunch of relevant adjectives and nouns in the game data itself, so why not just use those? Specifically, most items are named in a predictable Adjective + Noun format, and those words can be extracted for use in mixing and matching. Cogmind has nearly a thousand items, and the number of permutations if we pick three sub-words in a row gives plenty of variety. AdjectiveAdjectiveNoun it is :D

To create a seed, the entire list of existing item names is parsed according to various rules, creating a separate word pool for adjectives and nouns. Nouns are generally assumed to be the last word in an item name, and all the others are treated as adjectives. Other filters to keep some of the weirder items from creating seeds with odd formatting:
  • Word must contain at least three characters
  • First two characters must be different from one another
  • No words including punctuation or digits
  • Word cannot be entirely upper case
And finally no duplicate words are added to the pool (which would weight them higher). In the end we get random seeds like this:


Randomized "fake item names" as seeds--much better than something like "1477302648"! (see a longer list of samples here)

These fake item names are a heck of a lot more fun than numbers, and there's the added bonus of seeing words in there that you may not recognize, as a kind of teaser for other items that are actually out there somewhere. As mentioned before, the random seed used to create a run appears in the score sheet, and each is also listed alongside its run in the composite score history.


Scorehistory.txt, with fake item seeds.


Miscellaneous Applications
We're not done yet! Seeds have a surprising number of applications, so let's check out some more of them...


Community
Roguelikes are single-player games, but there are plenty of features with community-building potential. One of those is so-called "weekly seeds," where a single seed is played through by multiple people who can then share their experiences, or compete with one another for the best score, knowing that they are at least playing with the same fundamental circumstances.

Cogmind has had... semi-weekly seeds for the past couple years. Although not as popular as they were in the early days (when lots of the regular players were on the forums instead of chat :P), I'm sure they'll pick up again when the player base expands again this year. Some roguelikes such as Caves of Qud even have the weekly seeds built into the game itself (with separate leaderboards!), something I haven't done yet but probably should at some point.


Replays
One thing I've always wished I could to do is enable full replays of a run, which is most easily accomplished by combining a seed with the player's recorded input. But a couple of architecture road blocks have made that all but impossible :/. Cogmind's animation system is mixed in with the game logic, so features like adjusting the speed of animations (or canceling them altogether) are not possible. For replays to work there's also a need to use different RNGs for the game logic and any rendering-related functionality, which is something I didn't do. Essentially, this kind of feature should be built in from the beginning to make sure it works, rather than trying to tack it onto a sprawling 120,000-line code base :P

Obviously replays also add a lot of value with respect to learning and community-building. At least we always have streams and LPs, in any case.

Regarding that replay technique, it can even be used to implement saving. Instead of actually saving the entire state of the game, save all of the player's input from the beginning. Then when it's time to load, seed the RNG using the same value, followed by all the same input to get the same final result! I've heard that Brogue saves work this way, although "replays" are such a complicated thing that I've also heard Brogue's saves are prone to breaking in some cases, which prevents loading that saved game :/. Still, a very cool system overall!


Saving Large Worlds
Another type of seed-based saving is useful for large open-world games, in which storing the entirety of the game state isn't feasible (too much space!), nor is keeping every visited location in memory. Instead the world is divided into chunks, each with its own seed (essentially how Cogmind's map-specific seeds work), and a chunk is only generated when the player nears it. Storing that area on traveling elsewhere, or saving the game, is simply a matter of storing its seed along with whatever changes occurred between its generation and the time it's stored. So even games with destructible terrain and other player- or NPC-induced changes can take advantage of this kind of "delta map" system to keep system requirements within reason, despite having nearly infinite space to explore. (Literal space exploration games can use this same method. One such example was Infiniverse, but sadly its site and some relevant technical articles are no longer available...)


Seed Catalog
One of the more unique seed applications I've seen is the Brogue "seed catalog," which comes with the game and contains a list of every item found on each of the first five floors for the first thousand seeds.


Excerpt from Brogue's seed catalog.

Basically it's a meta-approach for adjusting the difficulty, or perhaps to look for a seed more suitable for a desired play style (since early-game items in that roguelike can have a significant impact on long-term strategy).

Have you heard of any other uses for seeds? I'm sure there have to be more out there...
Logged
Cogmind - Sci-fi Roguelike (devblog) | X@COM - The X-COM RL | REXPaint - ASCII art editor | Patreon

sambojin

  • Bay Watcher
  • Three seconds to catsplosion and counting.......
    • View Profile
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1232 on: May 01, 2017, 08:55:47 pm »

Step counter and input counter seeds, that are linked to lookup tables in JRPGs? Especially heavily used in Final Fantasy speedruns, etc.

Not so much a time-based "randomization" from an initial milliseconds-after-midnight number, but it can appear random until you know about it, from which point on it is then an entirely deterministic system.

A seed of sorts, but in a slightly different category than the ones you've talked about, because it's really just a player controlled number that refers to a fairly small lookup table for determining encounters, monster types encountered, etc.
« Last Edit: May 01, 2017, 09:00:46 pm by sambojin »
Logged
It's a game. Have fun.

Kyzrati

  • Bay Watcher
    • View Profile
    • Grid Sage Games
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1233 on: May 03, 2017, 12:41:18 am »

Ah yeah that's kinda related. Not quite of the repeatable variety, but it could be combined with a manual seed to produce the same encounters, which would make for a JRPG experience sharable down to the combat sequence.
Logged
Cogmind - Sci-fi Roguelike (devblog) | X@COM - The X-COM RL | REXPaint - ASCII art editor | Patreon

sambojin

  • Bay Watcher
  • Three seconds to catsplosion and counting.......
    • View Profile
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1234 on: May 03, 2017, 12:38:49 pm »

Yeah. In speedruns, that's essentially what they're doing. Routing the best seed possible to complete the game in the best time.

It's pretty reproducible in stuff like FF and even Pokemon, even though there's usually some RNG elements at play somewhere to screw up the whole thing. Encounters in FF are deterministic for instance, but attack damage isn't (although it's within a ballpark of certainty).

So not reproducible in the Cogmind sense, but still a seed of sorts.
Logged
It's a game. Have fun.

Kyzrati

  • Bay Watcher
    • View Profile
    • Grid Sage Games
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1235 on: May 03, 2017, 09:55:06 pm »

By request, just added an optional "numbers mode" for the part data visualization, for more specific part-wide comparisons.
Spoiler (click to show/hide)
Not sure if it should be the default yet, if only because more numbers = more overwhelmed new players :P

Maybe make it on by default, but it only works in Tactical HUD mode, which only non-beginners will have active.
Logged
Cogmind - Sci-fi Roguelike (devblog) | X@COM - The X-COM RL | REXPaint - ASCII art editor | Patreon

Kyzrati

  • Bay Watcher
    • View Profile
    • Grid Sage Games
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1236 on: May 04, 2017, 07:40:33 pm »

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

Normally I wouldn't have another post up so soon, but the topic of versioning has become somewhat time-critical. I've been thinking over it quite a few times in recent months, but haven't been able to make a final decision on where to go from here.

Why now? Well, know that in one sense--one of the more important senses, actually--next week Cogmind will be "done." All the confirmed maps are in, all the major NPCs exist and are doing their thing, all the endings are in place... The story will be complete.

Spoiler: 2.5 MB GIF (click to show/hide)

Development will continue, but this is a pretty significant milestone.

That said, there are still certain items left on the TODO list that keep me from calling it a true 1.0. And honestly I'm not ready to handle all the meta work that should come with a 1.0, anyway, mainly on the marketing side which at the very least requires putting together a new trailer and getting in touch with press/LPers. (I still like the two-year-old alpha trailer and am tempted to just update it using new visuals, but even that takes a while.)

So what to do about version numbers in the meantime?


Searching for version numbers in the matrix.

We could at least wait until the Steam EA release (as a different kind of milestone) before switching to a new system. However, rather than basing it on an external factor like that it'd be nice to keep the system a little more relevant to the current state of development, and we're definitely switching some gears here (more on that later).


Greek
I wouldn't say continuing along with "Alpha #" releases is off the table, making next week's release Alpha 15 as expected. Plenty of games do Alpha 1-2-3 their way to 1.0, and I admit I'm fond of the Alpha system, if only because I've been using it for a good while. But there are a few reasons for which, if possible, I'd like to find a satisfactory alternative.

Another vote for switching away from the alpha designation is that for most people it implies a game is in a very unfinished state, probably even buggy or unenjoyable, neither of which would describe Cogmind even years ago. While it's true I've wanted people on the outside to believe that for the past couple years of alpha so that I could reduce the number of buyers and instead focus on development (not unlike my approach to pricing), I'm now more willing to allow the terminology, and first impressions, to start inching into new territory :)

For a short while I was thinking of using "Beta," as it naturally follows Alpha, but that's technically more of a "this software is feature-complete though still subject to pre-1.0 tweaks and fixes" sort of state. If we wanted to judge Cogmind's development in those software terms, it's clearly still in alpha and will be for a while, since I plan to do lots more with it! Even major new features...

Hey, maybe we could do something off the wall and go with "Gamma" releases? Haha, okay that might cause some confusion.


R for Release
Some games and libraries simply increment an integer with each release: R1, R2, R3... Pretty straightforward. I like it. I've also used it before, for X@COM. Minor patches can just add a decimal or letter, e.g. R5.1 or R5a.

If I went this way, another thought is to skip straight to the actual release number, so "R15," just to keep the sequence going rather than starting over, though an "R1" is a pretty meaningful statement for that one release in its own way. A true new beginning rather than more of the same.


Maybe one day!

"RC#" is another option, though not too often used with games (?). Designating a Release Candidate is more akin to beta, or the final versions of beta software, not to refer to something that will continue receiving large feature updates for the foreseeable future. But then you have games like Starsector, which has been using an RC numbering system alongside their decimal-numbered releases for many years now :P


Decimals
Speaking of decimal systems, they're definitely the most ubiquitous. But I don't really like the idea of purely sticking with a bunch of numbers. (Just this week I posted about how and why I've circumvented numbers where seeds are concerned :P)

Numbers aren't as easy to remember, and more importantly any sub-1.0 version numbers might be assumed to reflect the amount of development remaining until completion (e.g. 0.5 is half finished), even if they're not intended that way. Given that there's a huge number of possible future features, and I can't say exactly which will make it in, it's tough for me to nail down where a given release stands in terms of numbers.

Trivia: Technically Cogmind does have decimal version numbers, but they're all simply 0.10 (a common "this is an early build lots more to do!" number) followed by the date, e.g. 0.10.170509. These are just for my reference, because I find it really useful to have the date in the "version" itself.

One way devs work around the boring number version issue is to give releases unique names. I did this for X@COM, for example "Sheer Terror" when adding terror missions, "Sound Like a Hero" when I added sfx, "Chryssalids in my Backyward" for... the chryssalid update :o. They're a fun and easy way to remember, more interesting to read, and useful for setting the theme of a release.

Spoiler: 1.4 MB GIF (click to show/hide)

I've thought of naming Cogmind releases for a long time, even retroactively naming older ones for consistency, but never went ahead with the plan.

Actually, I have sort of named each Cogmind release, if only in one place: IndieDB. For release announcement posts there I always name the release rather than reporting it as a number like elsewhere, just to give the post title a less boring look since it appears listed with other games, and also to give a hint of what the release includes. The next release is already dubbed "The End," Alpha 14 was "Hack 'n Slash" (melee multi-wielding), Alpha 13 was "Rise of Zion" (new plot thread), Alpha 12 was "The Place No One Lives to Tell About" (boss map), etc. While we're at it, do you have any opinions on named releases?

In any case, version names are really just supplementary to another system, as ideally a game's versioning should reflect some kind of sequence.


Dev Cycle
As far as other considerations go, the decision here depends somewhat on the future release schedule.

In the past it was easy to maintain a 4/5-week release cycle, with a couple weeks of adding a big chunk of content centered around a new map or branch, followed by a week of bigger feature(s) and then some little ones. While I really like that approach, which makes each release pretty substantial (and discussion-worthy!), future updates won't usually have new maps to be focused around, which themselves lead to lots of other related required content, features, and mechanics.

I'm also looking forward to the pace being a little more flexible and responsive, such as releasing smaller batches of new features every two weeks or so. This change in pace would be another reason to depart from the original alpha designation, if only because sticking to the ongoing "Alpha #" system can distort and dilute the effort and value of the previous releases, each of which took a lot of work to complete.


Grid Sage Games release history as of 170504.

I very much enjoy the practice of releasing with meatier changelogs, but then players also appreciate more rapid development, so there's a good chance I'll be heading in that direction for a while, at least for much of 2017 (once past the "actually releasing on Steam" hurdle).


Are you done yet?
No, this is cathartic and I might be coming close to a decision :P

Having written all of this out, I'm leaning a lot more strongly towards an R# system, maybe calling it R1, kinda like a fake 1.0.

And beyond that? I guess then we can, okay, eventually declare a release the 1.0, and then I imagine there will be updates even beyond that (I probably won't be able to stop myself even if I wanted to), so then we could go with numbers since there is no longer some kind of commonly-assumed target after 1.0, which just breeds updates like 1.01, and so on. Alongside it we'll probably just continue with the R-numbering as well.

Anyway, regardless of what versioning we go with for now, I'll keep up the same date-appended pure number version (still 0.10!).

So what do you think--have I overthought this enough yet? :P

I... still can't decide. Because after sleeping on this post I woke up thinking about it from another angle and started to question the whole R-thing, in that unlike a < 1.0 decimal version number, or clearly having an "alpha" right in the version name, using something like "R" doesn't even hint that the game still has a fair bit of development coming, or that it's technically "early access." That information has to be expressed externally to the versioning, which is somewhat annoying. Maybe just let innertia do its thing, call it Alpha 15 and stop thinking about this? Or is it time for something new? Hm.

Maybe Beta? It's different from Alpha but clearly "not done," and we can ignore what it really means in terms of software development (most games ignore it...). Hm.


Update later same day: For scheduling reasons I had to make a quick decision since it's Friday and for some reason I really thought it was still Thursday :P. So... Beta it is.
« Last Edit: May 05, 2017, 09:32:56 am by Kyzrati »
Logged
Cogmind - Sci-fi Roguelike (devblog) | X@COM - The X-COM RL | REXPaint - ASCII art editor | Patreon

Kyzrati

  • Bay Watcher
    • View Profile
    • Grid Sage Games
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1237 on: May 05, 2017, 09:36:56 am »

Just posted a 39-image Cogmind Beta preview (warning, 8 MB page :P)

Milestone release coming May 9th!
Logged
Cogmind - Sci-fi Roguelike (devblog) | X@COM - The X-COM RL | REXPaint - ASCII art editor | Patreon

endlessblaze

  • Bay Watcher
  • likes dragons for their fiery breath
    • View Profile
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1238 on: May 05, 2017, 09:59:55 pm »

Huh it's been a while since I played.
I should do that agian.

Shame my computer stopped working. I'll have to get that fixed
Logged
Kids make great meat shields.
I nominate endlessblaze as our chief military executive!

Kyzrati

  • Bay Watcher
    • View Profile
    • Grid Sage Games
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1239 on: May 06, 2017, 10:59:00 pm »

Notice: In two days Cogmind goes Beta, and most tier rewards will be removed--e.g. no more Prime Tier with supporters list perk. Last chance to get that for anyone thinking about it :D
http://www.gridsagegames.com/cogmind/buy.html
Logged
Cogmind - Sci-fi Roguelike (devblog) | X@COM - The X-COM RL | REXPaint - ASCII art editor | Patreon

sambojin

  • Bay Watcher
  • Three seconds to catsplosion and counting.......
    • View Profile
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1240 on: May 07, 2017, 01:59:40 am »

Damn me having money in my steam account, rather than in my paypal account, otherwise I'd grab an improved and hand out a few keys to other forumites. I'll have to wait til Friday and hand out a couple of proper beta keys.
Logged
It's a game. Have fun.

Kyzrati

  • Bay Watcher
    • View Profile
    • Grid Sage Games
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1241 on: May 07, 2017, 04:27:48 am »

I'm going to leave the improved tier up, but remove its other benefits, so there'll still be a package deal available for less, just no longer any in-game credit. All of that stuff was for alpha--technically that perk should've been removed a few weeks ago since I dropped its price a bit, but I've been waiting for this milestone to complete the transition...
Logged
Cogmind - Sci-fi Roguelike (devblog) | X@COM - The X-COM RL | REXPaint - ASCII art editor | Patreon

Kyzrati

  • Bay Watcher
    • View Profile
    • Grid Sage Games
Re: Cogmind (sci-fi robot-themed roguelike) - ALPHA RELEASED
« Reply #1242 on: May 08, 2017, 08:15:57 pm »

Cogmind Beta 1: "The End"

A major milestone, a big ending, and a new beginning, all in one! After four years in development, Cogmind's story is truly complete, and today we begin a new phase: Beta.
To kick it off we have the largest release ever, which not only finishes off the plot lines with a new map and seven different animated endings, but also adds major NPCs, lotsa QoL, and more lore, mechanics, challenge modes... Check out the huge collection of feature images in the Beta Preview from last week to see some of what's included.

Also note that Cogmind Beta is priced differently, having recently been set to its final base price. And for anyone who wants to help spread the robot love, gifting is now easier.

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

The full Cogmind Beta 1 (0.10.170509) changelog:

* NEW: Branch map "[redacted]"
* NEW: 7 different animated endings, with content dependent on plot-related actions
* NEW: 1 major new NPC (unique robot class)
* NEW: 4 new minor NPCs (unique builds)
* NEW: 3 more prototype robot variants
* NEW: 2 more robot analysis records
* NEW: 21 new items (8 completely new item mechanics) (total = 846)
* NEW: 2 more Trojan() hacks (secret)
* NEW: 1 more Force() hack (secret)
* NEW: 37 more score sheet entries (total = 626)
* NEW: 48 more sound effects (total = 847)
* NEW: Added content to "Archives" map
* NEW: Score sheet filename appends win type indicator, and +'s for boss kills
* NEW: scorehistory.txt Location column differentiates between win types
* NEW: "Devolution" experimental challenge mode (for now set in cogmind.cfg: challengeDevolution)
* NEW: "Inhibited Evolution" experimental challenge mode (for now set in cogmind.cfg: challengeInhibitedEvolution)
* NEW: "Gauntlet" experimental challenge mode (for now set in cogmind.cfg: challengeGauntlet)
* NEW: "Super Gauntlet" experimental challenge mode (for now set in cogmind.cfg: challengeSuperGauntlet)
* NEW: "Pure Core" experimental challenge mode (for now set in cogmind.cfg: challengePureCore)
* NEW: "No Salvage" experimental challenge mode (for now set in cogmind.cfg: challengeNoSalvage)
* NEW: Any active challenge modes are listed in log on starting a new run
* NEW: All treads have at least a 5% chance per slot to instantly crush ram targets of medium size and below
* NEW: Ramming with treads active never leads to self-damage or destabilization
* NEW: All legs have a 20% chance per slot to kick a ram target out of the way, avoiding any self-damage but damaging target
* NEW: Sound effect origins heard but not seen temporarily marked on map, color coded by type (can toggle in cogmind.cfg: disableVisibleSfx)
* NEW: More specific result text for final game over screen and score sheet on a win
* NEW: Score sheet meta data now records all wins and their type (listed by Game subsection's new "win type" entry)
* NEW: Game over screen includes buttons for mouse users to restart/quit without keyboard
* NEW: Added explicit note to manual about challengeScavenger leaving static stockpiles untouched
* NEW: Will not reload previous target position if entering targeting mode after having fired at a machine, but that machine is now gone
* NEW: "Map" manual subsection under Advanced UI, collecting in one place all reference info on temporary map-related indicators
* NEW: Keyboard mode can inspect walls/doors as other objects, for both armor and resistances
* NEW: Random world seeds composed of word combinations rather than random numbers (creates fake item name via adjective + adjective + noun)
* NEW: Item info for Self-destruct Interrupters and similar disposable non-part items now includes a battery indicator (also in scan window)
* NEW: Non-part items with internal power sources (e.g. Self-destruct Interrupters) flash blue on the map while active
* NEW: Core reset results in a particular additional negative effect, as well as another bonus
* NEW: Explosion/projectile EM damage spectrum listing now shows associated chance of triggering chain reaction
* NEW: Destroying Network Hubs gives bonus points
* NEW: Dedicated RNG for hacking success checks
* NEW: Earn increasing bonus points for destroying hostile combat robots from alert level 3+
* NEW: Follower ally kills earn bonus points
* NEW: Transmission Jammer activation animation highlights robots that will be jammed (also changed appearance)
* NEW: Data Miner more helpful
* NEW: Some Waste areas have additional effects
* NEW: One more way to gain access to Deep Caves
* NEW: Highlighting of all cave-in prone areas now freely available in tactical HUD mode (no Structural Scanner required)
* NEW: Hold Ctrl-Alt to greatly brighten color of visible cave-in prone spaces
* NEW: Power-consuming utilities can be toggled all at once using " (or new CYCLE button, like propulsion/weapons)
* NEW: If no parts to toggle on entering a cycle command (;/'/"), will display a reminder message
* NEW: Overloaded attached power/propulsion/weapons in part list info mode ('q') display their modified stat values, and highlight them
* NEW: Multiprojectile weapons in scan window and part list info mode ('q') have a * between their damage value and type
* NEW: Parts/inventory color-code weapon damage type abbreviations
* NEW: Increased number of tie-breaking rules on "Furthest Area Reached" leaderboards (depth > boss kills > regions visited > date)
* NEW: Unlocking a garrison after installing a trap on the entrance itself gives explicit log message referring to the trap's destruction
* NEW: Commands, targets and results of all successful hacks mirrored to message log
* NEW: Static color for machine trace lockout and Force() hack success reflects Cogmind affiliation/state
* NEW: Robot analyses count as lore, added to collection system (including '!' indicators for uncollected Analysis() targets)
* NEW: Lore collection UI includes better keyboard-based page scrolling support
* NEW: Robot info temperature readout context help contains explicit note about meltdown threshold ("DANGER")
* NEW: Dedicated map shift mode toggled by ` (keyboard mode only, and supports all sets of movement keys)
* NEW: Offensive hackware decreases chance of successful hack repelling by hostile Programmers
* NEW: Part data visualization shows values next to graph in most modes (only available in Tactical HUD mode; can deactivate via cfg: precisePartGraphs)
* NEW: Full list of Tactical HUD features added to manual
* NEW: Simple animated effect for part destruction by impact damage causing system corruption
* NEW: All supporter names registered since Alpha 14 added to in-game list (see Credits menu)
* MOD: Win types are differentiated; none are simply "reached Surface" (the collective term on leaderboards is now "Ascended")
* MOD: Opening an item swap menu via keyboard autocloses open item info windows (matches mouse behavior)
* MOD: Recall(Extermination) hack no longer appears at Materials terminals (useless at that depth)
* MOD: Random traps will no longer be placed within 15 spaces of where Cogmind enters a main 0b10 map (does not apply to branches)
* MOD: Misfires due to corruption less likely to hit allies
* MOD: Adjusted AI movement behavior to theoretically reduce possibility of enemy combat bots "jumping" into rooms
* MOD: Transmission Jammer description updated to more clearly list all of its effects
* MOD: Machine structural analysis (resistances) now provided automatically on viewing info (no Structural Scanner required)
* MOD: Several non-fabricatable utilities and weapons that were not prototypes now categorized as prototypes (though never faulty)
* MOD: Taking any action other than ramming resets the ram permission check, to avoid ramming a previous unintentional ram target that suddenly moved
* MOD: GRD reduced from 4 waypoints to 1
* MOD: C Programmers no longer carry GRDs (guaranteed elsewhere)
* MOD: Shortcuts to special cave areas through Lower/Upper caves can only appear in the first cave map, not the second
* MOD: Data Miner ASCII changed from '0' to 'm'
* MOD: Name changes for "Operators" (the NPC kind)
* MOD: Placeholder location name "Tunnel" given a real name
* MOD: On-map dialogue/scene descriptions limited to ten most recent lines (all still recorded to log as normal)
* MOD: O7 resistances improved
* MOD: Core/part shielding prevents effects of critical hits against protected targets, rather than completely ignoring them
* MOD: Stasis Generator slot count reduced to 1
* MOD: Unstable Evolution challenge only shows instability message on evolution/depth changes rather than during all map transitions
* MOD: Each successful Overload/Assimilate hack increases global system defenses against all future robot hacks by 1/2% (respectively)
* MOD: Options menu Player/Seed entry boxes no longer accept commas
* MOD: Tunneling between rooms slightly more lenient: no cave-ins for wall-earth-wall scenarios
* MOD: Destroyed wall spaces can cave in just like destroyed earth
* MOD: Sensor behavior in "that secret map" no longer has any meta component, and can be learned via specific means
* MOD: Two specific random dialogues in Zion now considered lore despite their low value, to keep them from baiting players seeking new lore (green '?')
* MOD: Multi-cell robots can no longer be hit more than once by penetrating weapons
* MOD: Part autosorting prioritizes EM weapons within their own category (e.g. EM guns before TH/KI guns)
* MOD: Waiting now costs 100 time units, rather than simply canceling any time remaining in current turn
* MOD: Direct Schematic() terminal hacks for items likely to be out of depth (as with preloaded Fabricators)
* MOD: ESC key access to game menu enabled by default in keyboard mode (can disable by setting disableEscMenuAccessKeyboard in cogmind.cfg)
* MOD: Schematic(), Analysis(), and Load() hack readouts referring to robots list their "Tier" rather than "Rating"
* MOD: Intercept squad dispatch timing factors adjusted
* MOD: Ambush Traps can no longer contain Saboteurs, and are capped at 3 attackers instead of 4
* MOD: Hacking command buffer no longer stores manual unique codes or Zion hacks
* MOD: Broadened definition of "ally" for purpose of some score sheet entries, e.g. Ally Attacks/Total Damage/Kills/Largest Group/etc.
* MOD: Transmission Jammer effect requires visual on target
* MOD: Transmission Jammer works on active Engineers and distress signals from other non-combat robots
* MOD: Messages for jammed distress signals only shown if that signal would have alerted a nearby armed hostile
* MOD: Non-combat robot distress signal message more explicit about results
* MOD: Increased difficulty of rescuing "SW"
* MOD: The most dangerous mid-game maps are inaccessible in the easiest difficulty mode
* MOD: The most dangerous late-game maps are inaccessible in both of the easier difficulty modes
* MOD: Spotting hostiles and dialogue robots while motion trails toggled off now flashes !/? markers rather than using background color marking
* MOD: Flashing '?' indicators for NPCs with uncollected lore dialogue, or benefits, now flash indefinitely until interacted with
* MOD: Part list info mode and on-map part labels differentiate between prototypes and alien items, marking the latter with a second asterisk (**)
* MOD: Internal Heat Shields removed in favor of superior new part with additional mechanics
* MOD: Programmer variant names reworked
* MOD: Programmer defensive hack success rate no longer a static 25%, with high-tier Programmers much more likely to block hacking attempts
* MOD: Upped hacking attack time cost for Programmers, from 100 to 150
* MOD: Programmers have reduced chance to reboot higher-tier robots
* MOD: Higher-tier Programmers more capable of successful hacks
* MOD: Evolution UI rearranged to put confirmation button in a more natural location
* MOD: Causing a positive salvage modifier on a robot can never result in more matter than the upper limit of its salvage potential
* MOD: Busy engineers don't always call for reinforcements when they come under attack at lower depths
* MOD: Removed Auto-ascend from options menu
* MOD: Stepping on an exit/stair position always enters it, but requires confirmation (can disable confirmation via cogmind.cfg: ignoreAscendConfirmation)
* MOD: Ramming a target off an exit automatically takes that exit
* MOD: Part data visualization defaults to Integrity for new players, rather than Coverage
* FIX: Component Analysis Suites were using their old processor tile in sprite mode, and removal would still destroy them [Amphouse]
* FIX: System Backup Modules and other corruption-purging utilities reported their effect to the log even if nothing to purge [Amphouse]
* FIX: Bonus points for Wall Chamber destruction were applied per cell rather than only once [Sherlockkat]
* FIX: Imprinter death not registered properly if enemies with Zion [Sherlockkat]
* FIX: Dispatch and high-security messages continued even after Command garrisons activated [Sherlockkat]
* FIX: Deep Caves entrance was always accessible without key or other special means [Shobalk, Sherlockkat]
* FIX: Certain uncommon types of allies may not follow if outside your FOV [Sherlockkat]
* FIX: A particular Reinforced Shell layout in Armory contained two invisible pieces [Sherlockkat, zxc]
* FIX: Hunter info Scan Cloaking data entry not showing its value [zxc]
* FIX: Under special circumstances some regenerating items might be restored to greater than maximum integrity [zxc]
* FIX: Controlled Mechanics were no longer capable of repairing allies when in AID mode [zxc]
* FIX: Zio. Metafield Generator missing its effect description [Shobalk]
* FIX: Dropping a Storage Unit resulting in inventory overflow would stack it on top of the first item force dropped at current position [Widmo]
* FIX: ISC terminal entry query incorrectly highlighted a reference to "Command" [Widmo]
* FIX: Firing at a target followed by a second target against which entire volley fails to cycle remembered first target for input recall [Widmo]
* FIX: Two status entries and three utility effects with decimal values always appeared negative under some versions of Wine on Linux [MJWkr, gammafunk]
* FIX: New autotargeting system would recall previous misfire targets if still in view [gammafunk]
* FIX: In rare cases Zionites might be completely blocked in by machinery [gammafunk]
* FIX: Friendly O8 hack in Zion stopped working in previous release due to data typo [MTF]
* FIX: Crash during special event in Recycling (broken by Alpha 14) [MTF]
* FIX: Under rare circumstances a valid path between cave entrance and special exits may be blocked off by a wall [MTF]
* FIX: Crash on destroying a specific piece of a certain Manufacturing Module while active [MTF]
* FIX: Was still possible for important NPC allies to stop following into a new map (despite adjustments in previous release) [MTF]
* FIX: Typo in Stasis Generator query [MTF]
* FIX: Data Miner hackware would self-destruct, despite not being an 0b10 bot [GJ]
* FIX: Backup parts auto-identified via refit showed correct name/info if inspected, but still listed as Unknown in parts list until reattached [GJ]
* FIX: Destroying a Network Hub, Energy Cycler, or Phase Generator would not cause the intended effects if unstable at the time of destruction [GJ]
* FIX: UI crash on using a Core Expander while a "G Unit" active [GJ]
* FIX: Removing an incomplete Asb. Biocell Array can drop Cogmind to negative energy [GJ]
* FIX: M Guard AI exhibited odd behavior in combat [GJ]
* FIX: Patrolling ARCs triggered by fire from outside their sight range would not notify deployed robots of the attacker [GJ]
* FIX: Signal Interpreter effect description missing a period [DDarkray]
* FIX: Derelict logs that reveal later map zones would not label exits which happen to be within those zones [DDarkRay]
* FIX: Manual contained obsolete reference to inventory window ASCII display contents [Bacon]
* FIX: Allied AI followers might accidentally step on known hostile traps [Finestep]
* FIX: Under rare circumstances it was possible to load into a new map with an empty parts list [buthix9]
* FIX: Even-length destination names displayed in left-oriented access labels at right edge of map were offset from their target by 1 cell
* FIX: UI crash if ally transferring to new map moved within 500ms of the transfer to a coordinate that doesn't also exist in target map
* FIX: Taking a Self-destruct Interrupter to a map other than where it was found would deactivate its battery timer, allowing unlimited use
* FIX: Reconnecting to O Command terminal under the right conditions would repeatedly award bonus points
* FIX: Destroying two or more Network Hubs reported to the log a bonus lower than actual value
* FIX: "dangerous territory" base commander dialogue kept repeating every time you stepped next to him
* FIX: M. Deconstructor works against machines again (was messed up by special condition added last release)
* FIX: Some generic AIs with scripted attack responses on coming into view would say their dialogue but not actually attack if too far away
* FIX: RMB on undiscovered phase wall would not enter firing mode as expected, meaning it could be used to detect them
* FIX: Dirty Bomb Trap description specified explosive damage but is actually EM
Logged
Cogmind - Sci-fi Roguelike (devblog) | X@COM - The X-COM RL | REXPaint - ASCII art editor | Patreon

Akhier the Dragon hearted

  • Bay Watcher
  • I'm a Dragon, Roar
    • View Profile
    • My YouTube Channel
Re: Cogmind (sci-fi robot-themed roguelike) - BETA RELEASED
« Reply #1243 on: May 08, 2017, 08:27:14 pm »

Congratulations on making it to Beta!
Logged
Quote
Join us. The crazy is at a perfect temperature today.
So it seems I accidentally put my canteen in my wheelbarrow and didn't notice... and then I got really thirsty... so right before going to sleep I go to take a swig from my canteen and... end up snorting a line of low-grade meth.

sambojin

  • Bay Watcher
  • Three seconds to catsplosion and counting.......
    • View Profile
Re: Cogmind (sci-fi robot-themed roguelike) - BETA RELEASED
« Reply #1244 on: May 09, 2017, 02:07:08 am »

Look. I'm not saying you're the greatest ascii particle effects master ever Kyzrati (I just don't know anyone who's better at it, so you probably are), I'm just saying that I'm going to rip that spoilered .gif and remove a few end frames as my standard happy birthday message on facebook from now until the end times. Unless you make another.

Thanks. And Happy Beta Day!
Logged
It's a game. Have fun.
Pages: 1 ... 81 82 [83] 84 85 ... 104