next »

[Kyzrati]

Apparently Windows hates PNG wallpapers, so the files I provided earlier are vastly reduced in quality when used. 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: http://www.gridsagegames.com/cogmind/media.html

[Kyzrati]

I can't imagine this will be super useful since most players will pick a mode and stick to it, but you can swap between ASCII and tiles on the fly, and of course it's animated :D



(This is a quick tileset I made one day a couple years ago for the prototype.)

[Kyzrati]

ROBOT HACKING

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

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.

Access
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

Calculations
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 . 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.

Programmers
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.

[JobLeonard]

 

[Kyzrati]

So I changed the website title to match the in-game ASCII version (animated), and added this cool mini version to the OP:


Also just now received some nice fan art from eigenbom

[JobLeonard]

Nice

Hey Eigenbom, how many people got some fanart from you today? I saw you sent somthing to Eigen (who is making Pioneers) too :D

[Kyzrati]

eigenbom's busy getting ready for his imminent KS, or right now more likely already asleep , so I'll answer for him: Aside from the two you've seen, the third was Kerfluffle--all sent out via Twitter earlier today.

[JobLeonard]

Nice!

[eigenbom]

Heh they are just silly little drawings.

[Kyzrati]

So this is the kind of thing that often happens the very first time I try to animate some new UI element. One (or two... or more ) variables wrong in there somewhere!

Anomaly indeed!

[JobLeonard]

ANOMALY DETECTED

You could say that :D

[UmutD]

Very cool glitch actually :D If I were you, I might try to keep this version as a split second effect, to show before the actual "anomaly detected" animation

Btw, I really liked the alternative tileset! Although I like ascii, for practical reasons(readability of walls and such), I might prefer that one while playing, if that will be available as an option.

[Kyzrati]

:D It looks quite different from what I was attempting, but mistakes like this do suggest some interesting ideas that inform further animation work. Plus I'd like to hide some glitch-like effects in the game proper, as secrets...

Most animations have something wrong with them the first time I run them because it's just me imagining what it should look like and writing the scripts to do it, but this one was especially crazy and so fun to share

[Kyzrati]

Someone mentioned that they were hoping Cogmind wouldn't be too hard on their eyes, so I imagined doing a foreground-background inversion "just to see"... Would need a little more work than the couple lines of post-processing used here, but it is interesting:

[JobLeonard]

It's hard to deny that it's more readable, but man is it ugly in comparison...

[Kyzrati]

More readable in the sense that it's easier on the eyes, but it's much more difficult to distinguish objects, at least the way the fonts were designed--they don't look good dark-on-light, and you can no longer rely as much on shape to tell the difference between glyphs, as everything becomes a block.

In some respects it looks cool, at least. I'm going to add it to the game as an easter egg... so now you know it's in there "somewhere"

[Kyzrati]

WANTED: PIXEL ARTIST

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

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 12x12 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.

Specifications
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.

Technical
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.)

Workload
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 12x12 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 (12x12 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 10x10, 12x12, 14x14, 16x16, 18x18, and 20x20.

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 20x20. (We may need to make an exception to that consistency for 10x10, which is pretty tiny. It could even stay pure ASCII.)

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 10x10 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).

Considerations
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!)

Requirements
Anyone interested in filling this position should mail me at [email protected]. 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:
[list=1]
   

• A portfolio, something with more than a couple random pieces of art.
• 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 (12x12) and larger (18x18~20x20) 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.)

Credit
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

Notification
During the application process I'll reply to all e-mails, 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.

[happymonster]

Good luck with finding an artist!

At these small sizes I wonder if a style of more solid shapes (rather than the outlined style in the prototype sprites) would work better. I'm not sure there is enough space for some objects otherwise..

[JobLeonard]

Shared the message in the various internet social networks that I frequent, good luck!

[Kyzrati]

Good luck with finding an artist!

At these small sizes I wonder if a style of more solid shapes (rather than the outlined style in the prototype sprites) would work better. I'm not sure there is enough space for some objects otherwise..

The smallest sizes will be tough, for sure. We'll see what concepts artists come up with. I'd like to share some publicly and get opinions before making a decision. Still early in the searching process (applications are streaming in...).

I'd do the job myself through trial and error if I was only working in the very small sizes. Unfortunately I need 16x16~20x20 sprites (with two even being 60x60), and that's something I certainly can't do!

Shared the message in the various internet social networks that I frequent, good luck!

Thanks! The ad is getting a huge amount of exposure between all the different places it's appeared. I'll only be hiring *one* person out of all this, but the publicity is good for the game in general, too