Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411521 Posts in 69377 Topics- by 58431 Members - Latest Member: Bohdan_Zoshchenko

April 28, 2024, 05:38:50 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsCogmind (sci-fi robot-themed roguelike) - BETA RELEASED
Pages: 1 ... 36 37 [38] 39 40 ... 71
Print
Author Topic: Cogmind (sci-fi robot-themed roguelike) - BETA RELEASED  (Read 236946 times)
JobLeonard
Level 10
*****



View Profile
« Reply #740 on: May 28, 2016, 11:35:09 PM »

Now make a Vlambeer-esque trailer Wink
Logged
Kyzrati
Level 10
*****



View Profile WWW
« Reply #741 on: May 29, 2016, 12:50:23 AM »

Heh, exciting, but that would be rather deceptive given the material!
Logged

JobLeonard
Level 10
*****



View Profile
« Reply #742 on: May 30, 2016, 02:17:06 AM »

Well... how about just a Vlambeer-esque montage of combat then?
Logged
Kyzrati
Level 10
*****



View Profile WWW
« Reply #743 on: June 03, 2016, 04:59:59 PM »

You can now auto-sort your parts list:


Next I'd like to see about animating it :D

Edit: Animation style #1--simple and direct (more to come):
« Last Edit: June 03, 2016, 07:52:34 PM by Kyzrati » Logged

JobLeonard
Level 10
*****



View Profile
« Reply #744 on: June 04, 2016, 04:26:04 AM »

What's the sort algorithm you use? Tongue

I just wrote a even-slower-than-bubble-sort variant for you (note how the swaps often stall):



Code:
class ShowSorter {
  int[] values, targetPos, targetDelta, swap;

  ShowSorter(int n) {
    values = new int[n];
    targetPos = new int[n];
    targetDelta = new int[n];
    swap = new int[n];
    for (int i = 0; i < values.length; i++) {
      values[i] = i;
    }
    this.shuffle();
    java.util.Arrays.fill(targetPos, 0);
    java.util.Arrays.fill(targetDelta, 0);
    java.util.Arrays.fill(swap, 0);
  }

  void shuffle() {
    for (int i = values.length-1; i >= 1; i--) {
      int j = (int)random(i);
      int t = values[i];
      values[i] = values[j];
      values[j] = t;
    }
  }

  void findTargets() {
    for (int i = 0; i < values.length; i++) {
      int v = values[i];
      int pos = 0;
      for (int j = 0; j < values.length; j++) {
        //Note: this only works if all keys are different!
        if (values[j] < v) {
          pos++;
        }
      }
      targetPos[i] = pos;
    }
  }

  void findDeltas() {
    for (int i = 0; i < targetDelta.length; i++) {
      int delta = targetPos[i] - i;
      if (delta < 0) {
        delta = -1;
      } else if (delta > 0) {
        delta = 1;
      } else {
        delta = 0;
      }
      targetDelta[i] = delta;
    }
    // for all stable positions, see if the neighbours want to displace it
    for (int i = 1; i < targetDelta.length-1; i++) {     
      if (targetDelta[i] == 0) {
        if (targetDelta[i-1] == 1) {
          targetDelta[i] = -1;
        } else if (targetDelta[i+1] == -1) {
          targetDelta[i] = 1;
        }
      }
    }
  }

  void swapValues() {
    for (int i = 0; i < values.length-1; i++) {
      if (targetDelta[i] == 1 && targetDelta[i+1] == -1) {
        int t = values[i];
        values[i] = values[i+1];
        values[i+1] = t;
        t = targetPos[i];
        targetPos[i] = targetPos[i+1];
        targetPos[i+1] = t;
      }
    }
    findDeltas();
  }

  void draw() {
    for (int i = 0; i < values.length; i++) {
      text(values[i], 50, 20+15*i);
    }
  }
}
Logged
Kyzrati
Level 10
*****



View Profile WWW
« Reply #745 on: June 04, 2016, 04:40:49 AM »

Well, speed is unimportant here since there are only ever about 5-10 things to sort per category Tongue

Algorithmically I do nothing complex. In fact, I'm not sure there's even a name for the kind of sort I used, since it creates multiple lists from a single initial list, and rebuilds the final list from a combination of the other lists. It makes the code a lot easier to understand (and write!) given the unique situational needs.

What I really wanted to do with this was turn it into a cool animation, which as you can see here is now done Cool


We'll just call it the Awesome-Looking Cogmind Sort Roll Eyes
Logged

JobLeonard
Level 10
*****



View Profile
« Reply #746 on: June 04, 2016, 05:34:58 AM »

That animation is siiiiiick.

Quote
lgorithmically I do nothing complex. In fact, I'm not sure there's even a name for the kind of sort I used, since it creates multiple lists from a single initial list, and rebuilds the final list from a combination of the other lists. It makes the code a lot easier to understand (and write!) given the unique situational needs.
So a merge sort variant? Or radix sort?



Logged
Kyzrati
Level 10
*****



View Profile WWW
« Reply #747 on: June 04, 2016, 06:19:31 PM »

I really have no idea. I consider myself 80% designer, 20% programmer, and the latter part of me knows so very little Shrug

Its most basic component is simply creating a new list from scratch by taking each element from another list and doing a less-than comparison until it finds its spot. Whatever that's called Tongue
Logged

JobLeonard
Level 10
*****



View Profile
« Reply #748 on: June 05, 2016, 02:32:11 AM »

Really? I could have sworn you had a compsci background  Shocked

Anyway, that would be an insertion sort, with the extra overhead of copying the entire list each time:





Check out all the other sorts here: https://www.youtube.com/user/AlgoRythmics/videos
Logged
Kyzrati
Level 10
*****



View Profile WWW
« Reply #749 on: June 05, 2016, 04:07:59 AM »

Really? I could have sworn you had a compsci background  Shocked
Hahaha, I can barely do basic math. My expertise is in languages (the human kind). Many people just assume I have a compsci background based on my work, but no Smiley. Actually, in college I started first semester with an eye towards joining the CS program because computers always interested me, but I gave up on the first math prereq after only a week and decided to just stick with language studies. Still, I spent far more time that year on my hobby gamedev projects than all of my regular classes combined! (Honestly I still didn't get very far because I had no teacher and wasn't very good at figuring stuff out for myself.)

Learning programming patterns is pointless in my case because I never remember them, even after having used them Tongue
Logged

JobLeonard
Level 10
*****



View Profile
« Reply #750 on: June 05, 2016, 01:00:20 PM »

Sounds like you would love programming in Lisp-like languages Tongue
Logged
Kyzrati
Level 10
*****



View Profile WWW
« Reply #751 on: June 05, 2016, 04:17:46 PM »

The first language I coded a complete game in was Scheme Wink
Logged

JobLeonard
Level 10
*****



View Profile
« Reply #752 on: June 06, 2016, 02:12:31 AM »

Ever tried Racket? I keep hearing great things about it.
Logged
Kyzrati
Level 10
*****



View Profile WWW
« Reply #753 on: June 06, 2016, 02:24:36 AM »

Nope, knowing only C++ has been good enough for me. I'd love to have time to play with other languages, but there's always just so much to do!
Logged

Kyzrati
Level 10
*****



View Profile WWW
« Reply #754 on: June 07, 2016, 04:35:18 PM »

Alpha 9 is ready!

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

In short, this is huge lore release #2, features some epic battles, and you can more easily build allies :D

The full Alpha 9 (0.10.160608) changelog:

* NEW: Branch map "Warlord"
* NEW: 9 special-purpose robot classes (8 with new art)
* NEW: 2 new NPCs (unique robot classes)
* NEW: 2 major plot events
* NEW: A central matter distribution network (allocated per map) supplies matter to Fabricators (no Matter Storage Units required)
* NEW: All Fabricators have a Network(Report) function to hack
* NEW: Disabling matter-related machines (those that spill matter on destruction) reduces local matter stores
* NEW: 3 more Trojan hacks (secret)
* NEW: 8 new non-interactive machines (2 explosive)
* NEW: Fabricators are also used by 0b10 robots for several purposes
* NEW: Fabricators and Repair Stations display on-map timer while processing
* NEW: Score sheet lists everything fabricated, and where
* NEW: Eighth damage type (secret), with new unstable weapon mechanic
* NEW: 10 new items
* NEW: More lore to uncover in dozens of terminal records
* NEW: Hundreds of lines of minor NPC dialogue covering lore, plot, and in-theme tips
* NEW: All unauthorized hacks (Trojans/brute force) can be learned/discovered in game
* NEW: +10% to hit immobile targets (includes disabled robots, as well as stationary non-robot targets)
* NEW: -20% to hit per "dynamic obstruction" (e.g. robot) between self and target
* NEW: Extension transfer network will respond to a persistent threat (e.g. those of you repeatedly intercepting Haulers)
* NEW: Investigation dispatches now reported to the log, as are reinforcements dispatched to aid busy engineers that come under attack
* NEW: Score sheet records exits discovered in each area (those with unknown destination appear in brackets; those approached marked with *)
* NEW: Explosions cause UI instability effect, varying by power and distance (optional, controlled by existing screenshake setting)
* NEW: Autosort parts list by subtype with a single command ( : )
* NEW: Deactivate part-sorting for weapons with new cogmind.cfg entry: partSortIgnoresWeapons
* NEW: Removal/replacement of processors and hackware (destroy-on-remove) parts requires confirmation
* NEW: Self-destruct by keyboard (Alt-F10) requires confirmation
* NEW: Resource (energy/matter) insufficiency messages for any action indicate the required amount
* NEW: Active Order/Intel modes have on-map reminder at top while using keyboard-based interface
* NEW: Inventory contents factor into score sheet "peak state" at a reduced value (10%); are also listed
* NEW: All supporter names registered since Alpha 8 added to in-game list (see Credits menu)
* NEW: All item-attribution names registered since Alpha 8 added to the item collection gallery
* MOD: Schematics enable construction at any Fabricator, regardless of tier (schematic info window displays time cost for each tier)
* MOD: All fabrication matter/time costs adjusted (Fabricator tier now a factor in the latter)
* MOD: Base chance of successful schematic loading at a Fabricator raised from 70% to 90%
* MOD: Removed Repair Station restrictions on part rating
* MOD: All repair time costs adjusted (repair station tier now a factor)
* MOD: Removed Scanalyzer restrictions on part rating
* MOD: High-tier Scanalyzers less likely to break parts or require repeat scans
* MOD: Reduced chance of investigation squads composed of Hunters, especially in late game
* MOD: Broadcast Trojan only needs to be installed once to take effect on all matching machines across floor
* MOD: Zhirov artifact analysis terminals moved into the rooms for their respective artifacts
* MOD: Manual and terminal record text updated to reflect new systems
* MOD: Robots less likely to immediately finish off disarmed hostiles instead of attacking more dangerous targets
* MOD: Reduced Mni. Drone Bay drone count to 3, changed art
* MOD: Removed matter cost (1) from Impact Mace/Kinetic Spear/Plasma Lance attacks
* MOD: Effect of mass support utilities reduced
* MOD: Stats for all flight and hover propulsion adjusted (see release notes)
* MOD: Doubled effect of Hub Network destruction
* MOD: All Behemoth/Marauder variants immune to critical hits, and the effects of Core Analyzers
* MOD: Neutral robots local to Caves now in various states of disrepair
* MOD: Neutral 0b10 robots more reponsive to being under fire, consider any damage an attack, even if not the intended target
* MOD: All Recycling Unit hacks are easier
* MOD: Renamed "Index(Repair Units)" hack command to "Index(Repair Stations)" for consistency
* MOD: Nearby Compactor attacks cause console window vibrations rather than screenshake
* MOD: ECM effect values in parts list info mode match those used in item description
* MOD: Swapped weapons and utilities inventory type-sorting order for consistency with parts list categories
* MOD: Motion Trail Duration option defaults to 2000ms rather than 0 (off)
* MOD: Better differentiated 'A'/'R' and 'H'/'K' pairs in all 17 variants of Smallcaps typeface
* MOD: Non-flying robots trying to get at player through a door less likely to be able to squeeze/jump past
* MOD: Seeds are no longer case sensitive
* MOD: Reformatted "weaknesses identified" text following analysis appended to robot info
* MOD: Score sheet Inventory list merged with Parts list, includes slot count
* MOD: Score sheet Parts/Inventory lists sorted
* FIX: Crash on accessing a rare category of Zion dialogue (fixed in earlier stealth update, credited here: [Sherlockkat])
* FIX: Continuous UI border effects like glow for critical core could prevent inventory drag-drop interaction [seafrank]
* FIX: Typos in "Epsilon Eridani System" and "Dirty Bomb Trap" terminal records [biomatter]
* FIX: One cave cache not fully embedded into walls [biomatter]
* FIX: Hunter analysis text referred to older variant loadouts [biomatter]
* FIX: EM disruption effect against robot cores (temporary deactivation) lasting far longer than intended
* FIX: Robot analysis hit/evasion bonuses didn't match stated 5% value (were significantly higher)
* FIX: Maneuvering Thruster and Reaction Control System effects not factored into melee defense calculations (regression)
* FIX: Prototype ID hack results not properly limited to standard Complex 0b10 prototypes
* FIX: Self-destructing part sfx could be heard anywhere on the map, regardless of player location
* FIX: Explosions completely out of view could not be heard, even if still within audible range
* FIX: Theoretical crash when displaying multiple simultaneously active Stasis Beam effects (not possible under normal play yet)
* FIX: Theoretical crash when accessing previous manual hacking buffer entry under a specific situation
* FIX: Manually changing .cfg-listed font to a non-existent typeface would reset it to another outdated now-invalid typeface
* FIX: "Power Chain Reactions" weren't tallied for score sheet, despite being listed
Logged

Kyzrati
Level 10
*****



View Profile WWW
« Reply #755 on: June 13, 2016, 05:21:49 PM »

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

Today I'd like to share the process behind the development of a singular UI feature, in particular the part (equipment)-sorting implementation, which is a good example of taking a simple premise and working it one step at a time, examining the results of each new element added throughout the process until as a whole it satisfied (and even exceeded) expectations.


The Issue
Inventory turnover is quite frequent in Cogmind (more on that here), and the result is almost inevitably a cluttered list of equipment in the HUD, especially later in the game when you can equip a couple dozen different parts, and especially with utilities, the most versatile category of parts capable of a wide range of functionality.


A cluttered list of parts.

While playing I've found myself sometimes having to take time out to reorganize that list, grouping multiple parts with complementary effects like heat sinks, hackware, or other processors to better understand my build at a given time. And I know that some other players do this as well, as having a list of equipment that's easier to parse facilitates rapid decision-making and avoids otherwise unnecessary mistakes.

So what we needed was a way to quickly and automatically group identical parts, or parts with similar functionality.


Initial Work
With interfaces there's of course the important question of how to present this feature to the player, but in this case I didn't start there, having only a vague idea of how best to do that. Instead, it made more sense to start with something more fundamental--without regard for appearances, the first step was to simply make sure the sorting algorithm itself worked, and just display the final result.

In game development, piling on too many features at once, even just multiple facets of a single feature, unnecessarily increases the complexity of the task. Everything should be broken down into the smallest understandable pieces so that any bumps along the way can be smoothed without too much confusion as to where the problem might lie.

Where the sorting is concerned, nothing special is going on, it simply reorganizes items by moving all empty slots to the end of their own category, while the items are listed in ascending order determined by comparing each item's internal database ID number.


Stage 1: Sort and instantly move parts to their new location.

As expected, that didn't quite work so well the first few times I tried it--bugs here and there, crashing immediately the first time I tried to use it (this is common Tongue), and on subsequent attempts doing odd things like stacking a bunch of items on top of each other, or erasing them completely -_-

All issues were resolved quickly, though, because the code was unburdened by whatever else I'd end up doing later to improve it for the final iteration.


Animation
It's no secret that I like to animate everything I can, so it's never a question of if, but how. Animations not only have a lot of potential cool factor, but when done right can also provide good visual feedback for an action or command.

For the sorting I decided to start out with something really simple, which would likely not be good enough for a permanent solution but required the same code along the path towards where I felt like I wanted to head, anyway. Basically the idea is rather than "teleporting," items should somehow actually move, so I started with just having them slide directly from their current slot to their destination.


Stage 2: Slide vertically to post-sort position.

To accomplish this, I repositioned entire subconsoles themselves as part of the animation, which is an approach I've actually never used anywhere else in the interface, though is something I've been looking forward to doing for a long time. (For a detailed look at what I mean by "subconsoles," see this piece I wrote on Cogmind's UI implementation.)

The result is better than nothing, but with all the items shifting over one another it's really hard to tell what is and isn't moving, so the animation doesn't add anything of value to the process.

A better way to make it more obvious what is moving is to shift them along more than one axis, i.e. offset them a little to one side.


Stage 3: Slide along an arc to the destination.

At the above stage I also wanted to try and convey some information in the amount of offset, specifically that items moving further from their previous position would travel along a wider arc, like so:


Arc sorting path visualization example (not actual sort targets).

But the effect was a little too messy for my tastes, especially since the coarse grid resolution of a strict terminal interface doesn't leave any room for gradual pixel offsets (a rule I'll not break in Cogmind for any reason). Items are either barely offset, or offset quite a bit.

Note: I originally thought I'd have some of them, perhaps the empty slots, offset to the right while everything else moved along the left side,  but assumed that would reintroduce too much chaos.

Seeing as the distance-based variable offset was causing a problem, I just removed the variability, setting them all to use a static animation offset whether they were moving to an adjacent slot or to a position ten slots away. At this point I also changed the movement path from an arc to a straight up rectangle to make it easier for the eye to follow given the grid.


Rect sorting path visualization example (not actual sort targets).


Stage 4: Slide along a rectangle to the destination.

With the desired movement path more or less determined, I saw that when many items were moving at once, while you could sorta tell which they were, it would be far more helpful if the movements were easier to follow, and the first way to tackle that is to simply not do them all at once!

Thus each item is "staggered," beginning its movement animation at a random time within an acceptable range from when the command is entered (in this case 0~700ms). Each item takes 300ms to reach its destination, regardless of the distance, so the entire animation will take no longer than 1 second, regardless of the number of items involved.

In addition to the staggering, it was also time for some cosmetic enhancements to moving items in order to further improve readability. Two such effects were added:
  • Any item that will/is/was moving will have its reference letter repeatedly replaced with a random one for the entire duration of the sort. The letter is going to change anyway (because it's moving to another position in the alphabetical list), so rather than just have it suddenly change, why not spruce it up with a little something? This also works well in combination with the staggering, since any given sorted item is only moving about one-third of the time during the sort, but even while it's not moving you'll be able to identify which those are.
  • On arriving at its final position, an item will flash white and fade back to its original colors, a process that takes 400ms. The flash reinforces which items just moved, and just plain looks cool. To me this plus the staggering really makes the whole effect :D

Stage 5 (final): Staggered sliding with randomized letters, and white flash on arrival.

Oh yeah, and there's a little beep each time an item reaches its destination :D

From inception to its final form, this process took approximately four hours.


Notes
Other considerations encountered during implementation:
  • Item order doesn't normally hold any meaning, except with weapons, which when active will fire in the order listed. For strategic reasons some players may prefer that certain weapons to fire first, so in that case it was necessary to add an option to ignore them for sorting purposes. Sorting was primarily meant for utilities, anyway, and to a lesser extent propulsion. I do a lot of weapon toggling myself, but don't really care about their firing order, so I'll be happy to sort them with this new feature Smiley
  • Further improvements could maybe include the option for fully automated sorting which operates immediately when a part is attached, so the player never even has to use a command to do it manually. Less impressive than seeing a bunch of items being sorted together, though Tongue
  • The current system doesn't yet take into account integrity differences between items with identical ID numbers (this is obvious with the Exp. Heat Sinks in the final sample, as they reverse positions twice), so there is still room for better consistency and other sorting improvements.
Logged

Kyzrati
Level 10
*****



View Profile WWW
« Reply #756 on: June 22, 2016, 04:57:49 AM »

On vacation right now, so I get to do Cogmind-related things that aren't entirely considered work Tongue

Logged

JobLeonard
Level 10
*****



View Profile
« Reply #757 on: June 22, 2016, 05:29:39 AM »

Nice promo-meme Tongue
Logged
Kyzrati
Level 10
*****



View Profile WWW
« Reply #758 on: June 23, 2016, 06:39:33 AM »

I saw it done for DF before and couldn't resist making one of my own Smiley
Logged

Kyzrati
Level 10
*****



View Profile WWW
« Reply #759 on: June 29, 2016, 07:14:36 PM »

Inventory Management, Revisited
[Cross-posted from the devblog here--follow link for better formatting and light-on-dark style.]

Few roguelikes are without some kind of inventory system, as it's a familiar and flexible way to provide access to the tools a player uses to overcome challenges. Regardless of however many items an inventory might contain--2, 26, 52, or something else--how it interacts with the rest of the mechanics, as well as how the player interacts with the system itself, both play important roles in shaping the player's experience.

With Cogmind in particular, there is a huge amount of inventory management involved in regular play. By comparison, with many roguelikes you settle into a set of equipment that only changes when you find some better individual item, rather than when that equipment has simply been damaged too many times, or an enemy suddenly gets a lucky critical hit that destroys one. In Cogmind all attached items essentially act as physical shields that protect you to varying degrees, and they can all be destroyed. According to the combined stats of reported runs from the previous version (Alpha 8 ), 43.5% of all items players equipped were destroyed before being removed or replaced. That's a surprisingly high number for a roguelike, but is of course something the player expects and can prepare for. (Note that for the purposes of this topic, "inventory" also includes "equipment in use," thus bringing the number and types of slots into play. These concepts are essentially inseparable with regard to the management aspect.)

Back in 2014 during pre-alpha development I wrote an article on Inventory Management (hence this title's "Revisited"), that one explaining the purpose of inventory and the ideas behind dynamic inventory size and decision forcing. Since then however, there have been a few changes, and certainly an expansion on the interface side of things, altogether enough to warrant another more in-depth look.


UI
From a UI perspective, with Cogmind an important goal of the inventory system was to make interacting with it as simple as possible. As one would expect with a system marked by high turnover, there's a lot of item removal, equipping, and swapping to be done, and the UI had to be designed to facilitate that.

With such a variable inventory state and the relevant actions being quite frequent, priority #1 is to keep the number of required commands down. The first step towards achieving that goal is to ensure both the inventory and equipment are visible on the main GUI, thus they occupy a non-insignificant 29% of the screen space at all times.


The base 4:3 layout for the main interface, with dedicated inventory/equipment areas highlighted. Even the 16:9 layout is 24% inventory.

Without the need to open a separate menu for inventory actions, the number of commands is already cut in half--a minimal OPEN > SELECT > EQUIP > CLOSE becomes SELECT > EQUIP! But there are many ways to do even better than that.

On the mouse side, Cogmind supports drag-and-drop inventory management, allowing mouse-using players to just drag items where they want them to go. This is the most intuitive method of item manipulation for beginners, helping keep the barrier to entry low.


Drag-drop inventory management example.

The dragging doesn't even have to be to a specific location--items will automatically be equipped to the first applicable slot, or if there is no room then dragging to a specific target allows it to be swapped. Drag to the inventory to unequip, drag to the map to drop... Also for mouse users, ctrl-clicking an object on the map bypasses the inventory completely and equips it.

But playing with the mouse isn't necessary, and pure keyboard players have access to a number of extremely convenient features as well. In addition to single-command equipping (Ctrl-#), single-command unequipping (Alt+Letter), and single-command dropping (Alt-#), items can be equipped directly from the ground with the 'a' key, in which case if there isn't any free space they will intelligently replace a current item that is outright inferior, and if the replaced item is better than something in the inventory, it will be stored and the worst item will be dropped instead. (The same system applies to equipping items from the inventory, and picking up items from the ground ('g')--all of them use the same automated system.)


Cogmind smart inventory explanation.


Keyboard-driven example, just moving around pressing 'a' to automatically replace parts.

Here it's worth mentioning a helpful aspect of Cogmind's design contributing to inventory management's simplicity: only one item may be present on the ground at a given location. So when you go to pick something up there is no need to specify what it is you want! Very handy. (This same feature aids rapid assessment of what items are nearby, compared to some other tactical grid-based games in which you may be faced with stacks of items, requiring a more indirect way of seeing what they are and therefore adding an extra layer of abstraction between player and items.)


Strategy
So how many items are we working with here? Cogmind only has four types of equipment slots--power, propulsion, utility, weapons--and starts with seven slots divided evenly among them (only one for power). That slot count, which equates to the number of items that can be in simultaneous use, gradually increases to 26 (that number oh-so-common in roguelikes for obvious reasons Tongue). Using a common humanoid system as a comparison, that's like having a character with several heads and bodies, a couple amulets, all 10 ring fingers, and numerous arms and legs. Cogmind's pure inventory, on the other hand, is rather small compared to most roguelikes, with a base size of only four, though that size is flexible depending on the player's strategy. It can increase to 20~30 or even more if the player is willing and capable of devoting enough of their slots to storage space. The average peak inventory size of all reported runs in Alpha 8 was 8.78 items, though an average of only 5.03 items were carried at any given time (wasteful!). (The first post about inventory management talks more about flexible inventory sizes.)

The trade off is that extra storage is heavy and slows you down, so the tankier the build, the more likely it can maintain a larger inventory capacity (and will also probably need one due to increased combat attrition as a slower mover).

For balance purposes, back in Alpha 6 I did remove the largest inventory expansion module, Hcp. Storage Units (+8), otherwise we'd likely be seeing a higher average capacity. Now the heaviest single-slot inventory boosting item gives an extra six slots. Some players like to stack two or even three of those to get an inventory size of 16 or 22. The largest recorded inventory capacity in Alpha 8 contained 28 slots.

Still, a large inventory is not always necessary, and a game can be won simply on the back of the versatility afforded by a couple dozen pieces of active equipment. That and with the removal of Hcp. ("high-capacity") storage, it's a little easier to reach the point where the slot cost of maintaining a given inventory size reduces a build's overall effectiveness (because storage doesn't do anything but hold spare parts :D).

About slots: Most items only occupy a single slot, to facilitate swapping and avoid unnecessary complexity (in terms of design, implementation, and most importantly on the player's end), but some less common special-purpose items might occupy multiple slots at once (usually just two, though there are a few items even larger than that). I added that feature (which didn't exist in the first prototype) as a way to enable another type of "cost" that could be traded for some benefit.


More UI!
An important consideration when you have so much in the way of items/equipment to manage is ways to organize and compare them. To that end, there is a feature that sorts attached items by subtype so that same and similar items can be grouped together, quite useful when you have a couple dozen pieces of equipment divided into only four slot types.


Equipment sorting in action.

The inventory can also be forward- and reverse-sorted by mass, type, and integrity (all three accessible by both keyboard and mouse).


Inventory sorting in action.

In terms of additional information, the space out to the right of items is used to show stat visualizations, of which there are currently six:


Cycling through item data visualizations: Coverage, Details, Integrity, Energy, Heat, Mass. A seventh will be added soon, and we've recently been discussing the possibility of adding yet more alternative graphs to suit other player preferences.

Frequent swapping of items (of which there are quite a few) is also made easier by side-by-side comparisons that highlight any differences.


Item stat comparisons.


Stat comparison in action.

All these features combine to support the inventory management aspect of the game, and players of course really like it when whatever they want or need to do is easy.

The primary remaining imperfect aspect of the inventory management system is dealing with very large inventories, because the inventory displays no more than 12 items at a time, of which you can only interact with 10 (since the two at each end are themselves scroll buttons).

At one point on the forums we were talking about a special "inventory management" mode that could involve a temporary window displaying the full inventory contents and make it easier to do multiple inventory actions in a row. Maybe something like this:


Mockup: An open full-size inventory window.

But since then, with somewhat smaller inventory sizes (no Hcp.) and a large number of convenience features (above), I'm pretty sure this is no longer an issue worth introducing another major interface feature for. Also, as of Alpha 6 processors and hackware can no longer be repeatedly swapped out, which was the primary cause behind a frustrating amount of inventory shuffling for optimal play, so it looks like the issue has solved itself through other evolutions in the game.

Still, every time it seems like some part of the interface is done, another way to improve it pops up for some reason or another, so I'm sure we'll be seeing yet more in terms of inventory management features :D
Logged

Pages: 1 ... 36 37 [38] 39 40 ... 71
Print
Jump to:  

Theme orange-lt created by panic