Official development blog

Tileset Concepts, an Open Poll

The response to last week’s advertisement for a pixel artist was overwhelming. I did expect a fair number of random artists from art forums just forwarding their portfolio, and certainly got that, but there were also a good number of applicants genuinely interested in the project itself.

In total the ad had nearly 1,000 unique views, attracting 34 applicants. Of those, 17 provided concepts for a Cogmind tileset, which I’m sharing with you today (anonymously!). Of those who didn’t provide concepts, 5 are qualified candidates to consider for hiring if we don’t find any initial concepts that are already on their way to being a good fit for the game.

But first, let’s look at the concepts. Naturally these grayscale samples will feel somewhat different once colored in game, but the results will still be monochrome, painted with a fully-saturated color of varying brightness to reflect the tile’s shading (if any).

The list--order is random, click to open the image and make sure to zoom it to 100% size for details:


Cogmind tileset concept submissions. (Click to open full size for details.)

I’m not making my own criteria or critiques public yet, hoping to instead hear what you all have to say. Some of you (those not using ASCII) will be the ones to actually use these, so I want your input. Have opinions? Favorites? Suggestions or preferences regarding style? Which of the above samples would you like to see expanded to become the game’s tileset and, more importantly, why? Leave a comment here or at any of the many other locations this post is mirrored.

Next Steps

If enough of you concur that some of these concepts are something you’d like to see in the game, the selection process will continue as I contact those artists to work out the details, as well as compare candidates based on other criteria, like experience and, um… cost ;)

Bonus Art

While we were only interested in concepts for tilesets, some applicants provided samples of other kinds of art, some of it pretty cool… This wasn’t required, but let’s not let those efforts go to waste :D.

These are all different takes on my ASCII art for Cogmind:


Chainsword and Quantum Rifle partially pixelized by Linus Chan.


Anti-matter Cannon illustrated by Gustavo Santos.


Mini-pixelized weapons and components by Gurkan Te (ShroomArts).

Posted in Art | Tagged , , , , , | 13 Responses

Wanted: Pixel Artist

Update 1/26: We’ve received a large number of applications, more than enough to find the artist we need.

Grid Sage Games is hiring! It’s not a full-time position, of course, but freelance pixel artists should take note and read on. Also pass the news on to anyone you know who might be interested.

I know that there are a lot of talented artists out there, but this project may not be for everyone, so making the specifications public should save us all some time.

This post also doubles as a look at what Cogmind is doing in terms of tile support, so let’s start there for some background.

Tiles Mode

Ever since Cogmind was rebooted in 2013, there have been plans to include a tileset. This is easy to forget since I almost never bring it up, but it’s only a matter of time--and the fact that we couldn’t be bothered with that particular feature when we already have ASCII and are busy implementing the mechanics and UI.

I say the game looks great in its “native ASCII,” but some players can’t stand ASCII no matter how attractive and accessible it is, and we want these players to enjoy the game as well. If Cogmind can reach a wider audience that’s good for everyone!

The prototype originally released in 2012 actually comes with a set of simple sprites:


Spritesheet from Cogmind’s 7DRL/prototype version (2012).

Those were put together one afternoon some weeks after the initial 7DRL release, and are only available for the default 12×12 font size. We’re going to need 1) a lot more and 2) better than what you see there :D

I finally turned my attention to this feature and updated tiles mode to catch up with the rest of the game. You can now switch between modes on the fly, and the change even comes with an animated transition (of course =p). For testing I imported the old 7DRL sprites:


Cogmind tiles-ASCII mode transition.

Being able to switch at the press of a button is not exactly a useful feature, but I can imagine playing a joke on someone by introducing them to Cogmind with tiles, then hitting F3 while their back is turned ;) (F3 is currently the key to switch modes).

So internally the game is prepared for tiles--now it’s just a matter of dropping them into the spritesheets, which are ready and waiting.


Notice that stylewise my sample sprites might not be what you first think of when imagining a roguelike with “pixel art tiles.” It is, however, the general style we need. Their almost icon-like appearance is more compatible with the game’s overall aesthetic, and in a way you could say it’s very similar to ASCII--minimalist, monochrome. Most importantly, we want them to be readable*, also like ASCII. They could even be more icon-like (other kinds of non-ASCII representative symbols?). (*I’m not implying mine are readable, by the way =p)

I’m open to suggestions and the artist has relative freedom, or as free as you’re going to get within the scope of the technical limitations outlined below.


As in the sample spritesheet above, all the sprites are drawn in grayscale. This is because they’re recolored by the game as necessary, translating the amount of white into the alpha transparency of each pixel. So you “only” have 255 values to work with, don’t have to worry about multiple colors, and can use shading as little or as much as you want or need to.


A sample sprite (zoomed for detail), the hovering programmer bot from the prototype, in its original sprite form (left) and as the engine would color it using other base colors.

(By the way, if you’re new here and wonder why I’m going over what may seem like a basic feature of pixel art seen in some games, it’s because this is also a regular development post for the general readership.)


How many of these things do we need? The answer is somewhat flexible, since in quite a few cases we will end up reusing the same tiles for multiple objects. Below is a comprehensive list of the absolute minimum set of tiles/sprites needed:

  • 26x medium/large robots (take up maybe 75~100% of cell)
  • 5x small robots (take up maybe 50% of cell)
  • 4x quad-cell robots (each occupies 4 cells arranged in a square)
  • 2x 9-cell robots (each occupies 9 cells arranged in a square)
  • 26x item categories
  • 8x walls (different styles, no orientations)
  • 8x doors (closed)
  • 8x doors (open)
  • 16x debris, ranging from low to high density
  • 4x special terrain (solid earth, secret door, stairs)
  • 1x debris-like piece of metal
  • 2x destroyed terrain (wall, door)
  • 3x scan signal markers

Except where otherwise indicated (multi-cell robots), all tiles are the same square dimensions. My own example set uses 12×12 tiles, but we’ll need other sizes as well (explained further below).

I’ve already prepared the spritesheet where these tiles will go, complete with guides (many hidden here to avoid spoilers):


Cogmind’s new spritesheet layout (12×12 cells). (In total only about half of the cells are used.)

Reference coordinates have already been added to the game data, so it’s ready to drop and load.

Probably the biggest catch to all this: We need each tile to be available at every font size the game supports! I’ve written about Cogmind’s font sizes before. To recap, Cogmind can display fonts at 10×10, 12×12, 14×14, 16×16, 18×18, and 20×20.

Meeting this need may seem boring for some of you, or perhaps you’d enjoy the challenge of representing the same object at different levels of detail, from the more abstract lower end to the potential for much greater detail at 20×20. (We may need to make an exception to that consistency for 10×10, which is pretty tiny. It could even stay pure ASCII.) Aside: I should emphasize here that individual players will generally not see all, or even most, of the different sizes--this is not for some kind of zoom effect (though technically the player can switch sizes at the press of a button)--a single player will usually play at the size most suitable for their desktop resolution, and always stick with that.

The good thing is individual sprites aren’t too much work, being monochrome static images (no animation!!!) that are probably low on complexity (without color to help increase the density of details).

Beyond what’s described above there’s the possibility for additional sprites, though this will depend both on style and cost. We may want to increase the number of unique sprites for a certain category of robots, or, it’s certainly not a priority, but projectiles are another category of objects not yet accounted for (these are currently always ASCII, since they’re fast and simple anyway).

In summary, we need tiles for at least everything listed further above in up to SIX (6) different sizes (maybe five if we decide 10×10 doesn’t work).

To put the total workload in perspective, using the spritesheet template as a base I’ve compiled a single image depicting the minimum area of all necessary tiles:


Cogmind spritesheets--total area (click to view at full size).


You won’t have to worry too much about color other than knowing what colors might be used for a given tile in game, as that can affect overall brightness and visibility of any detail.

For this purpose you’ll get a copy of the game as soon as you have the job, and can use sandbox mode to test sprites as they’re dropped into the spritesheet. The sandbox contains every object in the game in one big open play area:


One section of Cogmind’s sandbox map (it’s ASCII, but there are contents I don’t want to spoil so I had fun obfuscating it into what appear to be UFO Defense motion detector blips =p).

One major consideration is how pixel art tiles interact with the surrounding ASCII elements. Tiles mode does nothing to change the UI, nor machines, which have to work visually with the rest of the map art. This may seem an odd design choice since the ASCII machines will likely end up with a lower level of detail than the rest of the tileset, but from another perspective this has the interesting effect of making the machines feel even larger than they already are (as multi-space objects):


The prototype sprites mingling with the new version’s ASCII machines.

Increasing machine detail would be a very difficult task, both given the engine constraints and because it would vastly increase the number of required tiles. The only compromise plan I’ve been able to come up with is to mimic the current ASCII setup whereby machines are constructed of reusable smaller pieces, only they’re pieces with greater detail. Without a lot more tiles, though, it would be difficult to add much meaningful machine-specific detail.

I don’t doubt that larger machines could look good. Check out this quick piece from last year by Ben Porter (@eigenbom), of Moonman fame:


Machine: ASCII vs. pixel art concept.

(By the way, Ben is Kickstarting his already three-years-in-the-making pixel art procedural platformer--check it out!)


Anyone interested in filling this position should mail me at Please include “[ART]” in the subject line.

I’d prefer candidates with a professional/freelance background specifically in pixel art, though if you can show me a cool concept I can overlook most other requirements.

The two must-have items for consideration are:

  1. A portfolio, something with more than a couple random pieces of art.
  2. Billing rates for the type of work detailed above. Obviously you can give a general range here--we’ll get into specifics if you’re chosen. (Offers of “free work” will not be considered.)

I’ll give preference to anyone who also provides a few sample tiles/sprites to demo their concept (in both small (12×12) and larger (18×18~20×20) sizes). Tiles in this style are small and quick to produce, so it should be easy to provide a few examples if you’re really interested in the job. This is not required, but if I’m shown concepts I already really like at a rate I can accept then I’m naturally less likely to do much more proactive searching. (Note: I may want to show some concepts publicly--anonymously--before making a decision, so please inform me if this is not okay with you!)

Because a majority of artists won’t be familiar with this project yet, here’s a list of a few common object types (some given different more descriptive or general names than they have in game; and to avoid spoilers I’m not listing anything that’s new since the public prototype):

  • Robots: recyclers, engineers, haulers, fliers, soldiers, sentries, hunters, programmers, behemoths
  • Item Categories: engines, treads, legs, guns, cannons, melee weapons, devices, processors

I’m hoping to find someone who both has a good concept and is very interested in Cogmind. I suggest you check out Cogmind’s website for inspiration and to learn about the game. You can even go play the old prototype, linked at the bottom of the FAQ.

It doesn’t really matter where you are, though I’d prefer U.S. artists just because I have an easier method of payment there. As for rates, this is a niche game (at least I’ll continue to believe this until the market proves me wrong =p), so I hope to keep costs down, but I will provide fair pay for quality work. Either way, know that this is not a rev share deal.

Schedule-wise, this is a very flexible job since we don’t have any strict deadlines that absolutely require tiles. The game is only now nearing an alpha launch (aiming for April) and we don’t even need them all ready by then--more like just a small set. There is still plenty of work to do on the game, far more than it will take to finish the tiles. As long as it is economically feasible, though, there is quite likely to be additional intermittent work in the future as more special content is added.

Send any questions via e-mail or leave them as comments here (and anyone else feel free to chime in about anything!). (Remember: E-mails should include “[ART]” in the subject line.)


Cogmind is 100% going to be a game. This is not some vaporware project you’ll contribute to without any meaningful recognition. The first release is coming soon, even (hopefully with a partial tileset, but we have plenty of players already interested in ASCII alone).

Cogmind may be niche but it’s no small-time project, either, having been recognized as one of the best upcoming games of 2015 by Rock, Paper, Shotgun and making it into Indie DB’s Top 100 of 2014. So there are other benefits to immortalizing your name on this cool page:


Cogmind’s in-game credit’s page (WIP).

As you can see, the position’s waiting to be filled :D


During the application process I’ll reply to all e-mails (eventually--not immediately), but once the position has been filled this post will be updated to reflect that. So until you see that notice here, this position is still OPEN!

Update 1/26: We’ve received a large number of applications, more than enough to find the artist we need.

Posted in Art | Tagged , , , , , | Leave a comment

Robot Hacking

Many earlier posts have already covered hacking as it applies to various interactive machines, a feature that was implemented a year ago. Only now have we finally reached the tangentially related robot hacking mechanic.

Robot hacking was planned from the beginning, but it took this long to reach this point because it ideally should be handled after AI development (now mostly completed), which had to come after most robot designs were finished, which had to come after X, Y, Z, etc. So as it turns out robot hacking is one of the last major mechanics to be implemented.

“Major” in a development sense, though content-wise not necessarily so depending on how you play--keep in mind that if this part of the gameplay doesn’t appeal to you, you can pretty much ignore it. Hacking other robots is intended as an optional method of dealing with threats, augmenting stealthy hacker builds by giving them an alternative to trading volleys in regular direct combat. Something-moved-blow-it-up tank-type robots are less likely to be carrying around the utilities that make hacking a viable strategy. On the other hand, hackers already using their utilities to manipulate machines can also rely on those same parts to help dispatch enemies.


Initiating a hack is fairly straightforward, though more involved than just walking up to a robot and pressing a button.

First of all, you need to access the target’s system, which is achieved via a new type of item called a “datajack.” Datajacks are implemented as special weapons (require a weapon slot) which attempt to punch through the target’s armor and connect to its local system.


An example of a melee datajack.

Technically this doesn’t have to be done point blank, because datajacks also come in remote varieties that can be fired at a target from range.


Info for one type of remote datajack.

Remote datajacks do have some drawbacks, though, being further from the target and therefore less likely to both hit and successfully penetrate. Using them also requires matter, which is a semi-finite resource.

Even if initial attempts to hack a target fail, successfully connecting with multiple datajacks will confer a bonus to subsequent hacks on that same target. This means if you have the resources and are really determined to hack something, you could also simultaneously fire a volley of datajacks that stick the target full, and then hack it ;)


Once connected, while all you see as a player is the final chance to succeed at each type of hack, there are several factors contributing to that percentage.

First and most important is the difficulty of hacking a given class of robot. Enemies are classified as either easy, medium, or hard to hack--hacking a Recycler bot is quite easy, while not just anyone can hack a Programmer. In addition, more powerful hacks have yet a lower base chance of success.

As with machine hacking, the more you hack a certain system (in this case, differentiated by robot class) the more familiar you become with how it works, conferring an increasingly large bonus to future hacks. But the biggest contribution to hacking success comes from attack-oriented hacking utilities. Sticking a target with multiple datajacks increases your chances further.

UI and Effects

The main robot hacking interface borrows the same style as machine hacking, color-coding options based on their chance of success.


A sample terminal hacking menu (top) vs. the common robot hacking menu (bottom).

In the lower image you can see the current list of possible options when hacking a robot. It’s not nearly as extensive as machine hacking, which includes dozens of different targets, but this is a good starting point (I may add more while tweaking gameplay in the future):

  • PARSE: Scans the robot’s system for useful internal details, including its current level of system corruption and a breakdown of hacking calculations and success rates. Experienced players probably won’t use this feature much, but it is a good way to learn more about the game’s mechanics.
  • LINK: Embeds a program that broadcasts data to Cogmind and all allies via the datajack, helping predict what the robot will do next. This confers bonuses to both hit% and damage.
  • REBOOT: Completely disables the robot for a certain duration (around 15~25 turns), long enough to either destroy it if there’s nothing else to worry about, or run away to avoid the negative effects of combat. Rebooting a robot erases its short-term memory, so if you’re out of sight when it starts up again it won’t know where you went, or even that you were ever there.
  • OVERLOAD: Outright destroys the robot by overloading its core. Naturally this is more difficult than a simple reboot.
  • ASSIMILATE: The most difficult type of hack, which reprograms the robot to serve you. You’ll be able to issue it general commands, as covered in an earlier post about ally orders.
  • MANUAL: Opens a separate console for text entry. More on that below.

Secondary Effects

Even if you fail a hack, for the more difficult ones there is still a chance of “partial success” in the form of secondary effects. These effects are not meant to be reliable, mostly existing for fluff purposes, or as a little reward for at least trying to hack something =p.

A failed REBOOT could still cost the target some turns as it quickly restarts some systems, or possibly somewhat corrupt its core. Failed OVERLOADs may reboot, damage, or corrupt the robot. Failed ASSIMILATIONs may overload and destroy the robot, or corrupt it. (In case you’ve forgotten what “corruption” refers to here, it’s essentially an alternative way to kill a robot without necessarily doing much physical damage--it will be destroyed if system corruption reaches 100%. The drawback being you never quite know for sure how corrupted a particular robot is unless you PARSE it.)

Manual Hacking

The final hacking option opens a separate console in which you can type anything you want. It was originally introduced as a flexible way to enable specific plot-related elements (e.g. find X and hack it by typing Y for a unique result), though naturally it could and will be used as a part of interesting but less important encounters, and it’s certainly an excellent opportunity for secrets ;D. In fact, as I see it most manual hacking will be of the secret variety--usage will be pretty infrequent and special. (While the mechanics have been added, there are currently no implemented effects, as those will come later during world design, so for now I can only speak to what I intend to do with the system.)


Really, anything.

Manual hacks don’t have an associated percentage because they always succeed (assuming the text you enter is applicable), though you do have to make the connection first.

Now that we have this nice little console class available, I could use it for entering debugging commands, or even cheat codes! (or not)


In case you’re running low.


You’re not the only one hacking. Programmer class robots now live up to their name, sometimes attempting to shut down your friends, or reprogram their former allies. This makes them even more formidable than they already were, but I like the idea of enemies that are truly feared. Remember this is a roguelike at heart, not some mainstream RPG where you can generally expect to be able to confront and kill anything without any serious consequences.

Programmers also serve in a defensive capacity. If a visible ally within their protective range is the victim of a hacking attack, they will attempt to stop it.

The cool thing is, if you can manage to get some Programmers on your side, they’re capable of carrying out both offensive and defensive hacks for you. They’ll sometimes choose to reprogram robots to join you, or at least attempt to temporarily shut down hostile robots, while also shielding your other allies from enemy hacks.

Cogmind can also protect allies from hacks by attaching the same defensive hackware utilities used for machine hacking.


NOTE: Apparently Windows hates PNG wallpapers, so when the previous post was first published, the PNGs I provided looked great when viewed alone or in the browser, but were vastly reduced in quality when used as an actual wallpaper (kinda defeats the purpose). All wallpapers have now been converted to JPG to properly retain all that awesome (switching from a lossless to lossy format to improve quality is SO counterintuitive, but this is Windows…) Get the new ones here.

Posted in Mechanics | Tagged , , , , | 4 Responses

ASCII Wallpapers

Shortly after designing and implementing the animated ASCII title screen, I figured we finally have enough material to put together a few Cogmind wallpapers. These are now available for many common resolutions over on the Cogmind website’s media page.

Here’s a test of the first one while on a recent workcation in Japan.

So far we have five different designs, the simplest being nothing more than the ASCII title logo itself. Probably the most interesting are those that combine the title with a set of ASCII weapon art. The weapons were chosen from among those I’ve been showing intermittently over the past six months (though I still haven’t gotten around to doing any art showcases here on the blog--so many other things to write about…).


A variety of ASCII guns and cannons. Get the size you need from the media page.

The weapons shown here are only a small portion of those you’ll find throughout the game.


Another version of ASCII weapon wallpaper. Get the size you need from the media page.

I should eventually add a few that show more in-game content, but good ones would require a lot more work, and not enough of said content exists yet. For now there are two partially-implemented factory maps for those who desire a full screen of sci-fi green ASCII.


One of the factory wallpapers featuring a section of procedurally generated factory. Get the size you need from the media page.

Feel free to drop any ideas for other wallpaper designs followers may be interested in.

In other news, Cogmind was just honored with a spot among Rock, Paper, Shotgun’s Best PC Games of 2015 (roguelikes category). Unexpected at this stage, but very welcome!

Posted in Art | Tagged , , | Leave a comment

The Importance of Roguelike Food Clocks

Traditionally a majority of roguelikes include some sort of food system. Hunger management does seem like a natural part of role-play adventuring, but it also serves a much more important function: Pushing the player along is an integral part of [most] good roguelike design.

All but sandbox games present the player with a specific goal to aim for, though achieving that goal should be about more than a brute force grind to become unstoppable. Of course we could simply use various means to directly cap player power, like stat ceilings or limiting the amount of items available, though I’d argue against these methods because they essentially take options away from the player. From a player’s point of view, the constraint which affords the most flexibility is how much time they have to achieve the goal--within this constraint the player can do whatever they want.

Types of Food Clock

Using an arbitrary turn count (the roguelike equivalent of a real-time timer) is one option, though a rarely used one. Why not give the player some amount of control over the mechanic?

The most common food clock is, unsurprisingly, actual food and hunger. It’s easily understood, and the timer becomes closely integrated with elements of the game mechanics themselves (searching, combat, looting, identification), making it feel more natural.


You won’t see this in Cogmind.

But food doesn’t work for all games. Some take place in an incompatible setting, or prefer to avoid the burden (on either designer or player) of integrating it with the game’s other mechanics.

One common alternative is to have some dire threat chasing you. This is more literally something behind the player “pushing” them to advance. FTL uses this mechanic.

Any food clock puts a (sometimes soft) time limit on the player’s game and therefore limits what the player is capable of. The endlessly leveling mummy trick (mummies don’t need to eat) in old versions of DCSS is one example of what happens when a food clock mechanic breaks down in a generic roguelike--the developers had to introduce a new spawning timer mechanic to deal with that and similar scumming behavior.

Regardless of the method used, they all benefit the experience by pushing the player forward. In a broader sense, being pushed along forces decisions, counteracting the player tendency to postpone decisions as long as possible, or at least until sufficient knowledge or ability is obtained to ensure a certain outcome. This tendency is at odds with the core roguelike experience--solving randomized problems. It’s an inherently less interesting way to play a game since it removes most of the challenge. (One exception would be those players who are “just along for the ride” when they play a game; definitely a minority of roguelike players, though perhaps more common with AAA games that focus on style rather than substance.)

More specifically, food clocks cut down on grinding, which is good design. (Unless you’re trying to make an addictive MMORPG or similar that milks poor gamers for their money/time.) Those who grind will likely have less fun in the process, and anyone who doesn’t grind will consider the game poorly balanced or outright unfair. In other words, a food clock is saving players from themselves. Herein lies a golden rule of game design: If the optimal way to play a game is to do something boring, players will still do it even if it makes their experience less enjoyable. Thus a well-designed game should strive to avoid rewarding this kind of behavior.

Cogmind’s goal to provide a grind-free experience goes hand in hand with pushing the player along. A food clock is essential here.

Cogmind’s Food Clock

So what about food for robots? Well, we could artificially require some resource as a substitute, but I’d rather not go that route. I don’t particularly want another resource management sub-game that ties into everything else, nor is there a need for one.

Cogmind instead wraps the food clock more directly into the existing game mechanics, specifically stealth and combat (and by extension play style).

The more you affect the environment, the greater the enemy response to your presence. Remaining stealthy is one way to postpone a stronger response, and I believe that as a more difficult challenge, successful use of stealth is a very valid way to operate outside the normal food clock. But once you mess up and the fighting begins, the cumulative effect of your presence can eventually snowball into a big mess. This increases the pressure to leave the area. Theoretically you could continue to fight, but against an unlimited army you can only lose to attrition. Did I mention you can’t repair your core? (Note: The “presence” effect is less pronounced through the first few depths to make them a little easier; in the 7DRL the first three Materials floors didn’t have any pressure to move on at all.) As Cogmind grows more powerful, though, you evolve to cover your core with more parts and attrition via integrity damage becomes less of a threat. It’s at this point in the game, about one-third through, that electromagnetic damage appears. EM damage is the game’s original (and most convincing) food clock mechanic.

Regardless of where they impact, hits taken from EM attacks can result in system corruption, which in turn causes all sorts of nasty things to happen. Current list of random effects due to system corruption:

  • Random log messages (harmless, just annoying)
  • Data loss: Forget the layout of one or more previously explored areas of the map
  • Data loss: Forget what certain parts do--they become unidentified
  • Misinterpreted scan data: Low/medium-level robot sensors display incorrect information
  • Misdirections: Unintentionally move in the wrong direction
  • (more to come)

As system corruption accumulates from subsequent attacks, the random effects progressively worsen and grow more frequent. Corruption can even kill Cogmind if it reaches 100%, though the side effects are likely to be deadly long before then.


In case you haven’t yet noticed the side effects, while corrupted your map will also occasionally glitch as a reminder.

Corruption resets to zero on reaching each new depth (because that’s when you evolve), so suffering the effects of corruption can be a very powerful motivator to forge ahead. Cleaning system corruption any other way is not easy.

Aside from corruption, in the mid- to late-game main maps (as opposed to side-routes) your location will occasionally be pinpointed and a strike team sent to deal with you. While Cogmind is more than capable of dealing with one of these teams, engaging them is tempting you to begin the whole snowball process of you interacting with more and more of the map’s inhabitants, attracting attention and increasing your “presence.” There are other strategies for handling these teams, but those are for you to discover ;)

Reinforcing this whole food clock system is the fact that you can only move forward in the world--there is no way to revisit previously explored levels. But that’s a topic for another post.

Posted in Design | Tagged , , | 6 Responses