Thursday, August 23, 2012

Looking back on Dungeon Crawl Stone Soup

Instead of just sharing my art this time, I decided to write a full out blog post about my work on Dungeon Crawl Stone Soup and my thoughts looking back on it two years later.

The moment I started writing about my work on the game all of my old nagging feelings and wishes about roguelike development came rushing back.  The genesis of this blog -- my recent realization of the folly of condemning work to obscurity -- definitely put some fire behind my words as well.

This essentially turned into a post-mortem of my time contributing to Dungeon Crawl Stone Soup's development back in 2010.  If you are unfamiliar with DCSS, it is one of the few enduring open source roguelikes out there.  Here's a link to the project's homepage:

Note: you can click any picture to see a larger version of it.

Dungeon Crawl Stone Soup was the first project where I worked primarily on character design and creation.  I decided to opt for something more akin to what games like Diablo do.  My goal was to keep the theme of several character types intact, but to create largely unique art for each variant.  In the picture you can clearly see how the designs in each row build off of each other.  Several of these were already established and only had to be overhauled, but the elephants and the creatures on the bottom two rows all had no precedent in the game.  Purely through iteration, 6 designs turned into 30.

LensCrafters should pay kickbacks to the developers of tile-based ascii roguelikes...
...and it doesn't have to be this way.  I played a lot of DCSS on a laptop leading up to me working as an artist on it.  I clearly enjoyed it enough to dump several weeks of development into it.  I also have enjoyed other roguelikes such as DoomRL.  Even if you're a fan of these types of games, let's take a step back.  Try playing the tile version of an ascii roguelike for an hour on a modern computer at a reasonable display resolution in 2012.  Now go apply ice packs to the burning craters that used to be home to your eyes.  Besides the inevitable squinting to make out anything, the uninterrupted uniformity of the visuals takes quickly its toll on your vision.  I'll admit I am partially to blame for this.  My dungeon tile set is primarily dark, brown, and grey.  Not exactly a great combination for eye health.  In my defense my main mistake was expecting the momentum of my art overhaul to radically change how the art was displayed for the better.  The older, super high contrast visuals were easier to make out, but I think they were an eye sore for different reasons.

Now that isn't to say I didn't have a very positive experience overall while working on DCSS, and there are some great dedicated people working on it.  However, I have to admit I was extremely frustrated with the restrictions placed on tile development.  There are many limitations you wouldn't expect.  This is because everything is 99.9% subjugated to the design and limits of the ascii version.  The following are three of the biggest issues I ran into:
  1. No sprite scaling.  This is why if you run the game at 1080 the sprites are still at their native size of 32x32 pixels.  It's possible to add scaling that retains hard edges in pixel art, but from what I saw there was zero drive to implement this.

  2. Animation frames hard-locked to turn count.  I briefly pushed for untying animation frames from turn progression.  That would allow any animation, such as torch fire, to play constantly instead of just being updated one frame per turn.  It would also stop animations from flickering 1000 frames per second whenever you moved across a room.  I was told that from a programming standpoint, it was going to be too much work to be worth it.  If it had been introduced into the tech, there are so many graphical elements that could have been created alongside it (monster idle animations for one).

    Here's a quick mock-up using the animation frames I created that are already in the game.  Look how much just animating the torches independently of turn count enhances a standard scene.  To tie this into my first point, you can also click the picture below to see how DCSS would look if all the tiles were scaled up 200%.

  3. Lighting effects (or any visual that spanned multiple tiles) were a big no no.  Tying lighting to specific tiles (ie. torches) could have added a nice visual flair without adding a glut of work.  The rationale that prevented the addition of a lighting system was that it would give tile players more tactical information than ascii players.  An example would be seeing torchlight casting out from an unexplored area and being able to visually judge the distance to an unseen wall.  Therefore, no art could extend beyond 32x32 pixels.

    Lighting could go a long way in making the game more visually interesting.  As it is, besides torches (my own addition to somewhat improve this), it is nearly impossible to avoid levels look very monotone and monotonous unless each tile could be hand-placed with tile art in mind.   Because the game has been out for years there is simply too much created level content to go back and redo it all by hand.  Not to mention when making prefabs, only wall *types* are chosen as they are created via text files.  The RNG picks the art variation per tile (remember, the tiles are just window dressing for ascii).

    My only regret related to this point is that I probably should have radically improved the brightness and contrast of the dungeon art once it was clear that a lighting system was never going to happen.  At that point I already had spent several weeks working on DCSS art in my free time.  All in all I had already made about 60 tiles.  Before I left the project I agreed to let all my art be open source with no restrictions so that anyone could modify or use it as they saw fit.  To this date, two years later, it has remained untouched.  I truly hope someone takes my dungeon art and either overhauls it or replaces it with something better.

    Here's another quick and dirty mockup I just made with very basic lighting effects to show how they can help add nice flourishes to the scene visually.

In closing
I truly respect the hard work of the guys behind DCSS.  I feel we did great work together and while I've written at length about the things I wished for, there were definitely several small effects added to go along with my tiles thanks to the very talented Enne Walker.  My criticisms are intended to try and make people reconsider their ideas of what is possible in this genre visually.  Sure, graphics aren't everything...but there is already a substantial and ongoing effort behind creating and maintaining a working tile version that -- so why not take it further?  The tile version should be free to grow and discover its own unique potential, balance with the ascii version be damned.  I seriously doubt a venn diagram relating ascii and tile players would have much, if any, overlap.  Even for that group of players, I'd like to think they'd appreciate having a slightly different experience when switching between the two builds.

So why not push the limits farther?  Why not aspire to create better atmosphere and reach more people?  Maybe I'm expecting too much from these existing projects.  They are obviously bound to many existing expectations from the hardcore group that beats and re-beats the same game for years.  I definitely think it is more likely that the real future of the indie side of this genre will be forged by new games like Dungeons of Dredmor and Binding of Isaac that branch off the roguelike concept and make something new.  Imagine if a guy as talented as Derek Yu ( had free reign to make DoomRL ( from the ground up instead of just working within its confines.

With all that said, I can't help but think that there are a ton of pixel artists out there who fill their blogs with awesome game art that will never get used for anything.  Any one of them could answer the call if there was a boundary-pushing environment to work and innovate in.


  1. Your artwork for Stone Soup was incredible--epiphanic in the roguelike genre--and it surprises me that it didn't overcome the dev team's inertia.

    Nice retrospective.

  2. This was a pretty interesting read. I think it points out the issues that always seem to arrive when a group brings in an artist they primarily wanted art from. I thought some of your ideas made sense, but I can also see where the bumps of ascii and tiles remaining equal come in.

    On another note, did you start out with pixel art? If not how hard is it to transfer more traditional skills over? I'm addicted to roguelikes and always thought about contributing, but always opt to just continue improving what I already do.

    1. Well, I feel as an artist you shouldn't consider yourself bound to any one technique. The main things you develop over time is your eye and style. These carry over into anything you do. I'd suggest looking at a variety of pixel art you admire with a critical eye and study and experiment with the techniques the artist used until you find what works best for you.

      An open source project like DCSS is a great place to get started with pixel art. First, the canvas you'll be working on is very small -- 32x32 pixels @ 72dpi. You'll learn way more than you'd expect if you start toiling away within that tiny frame. Second, if you complete a piece of art and it is accepted into the project, your art will become part of the game. Third, there are no deadlines or demands beyond what you place on yourself. Artists come and go freely and each contributor generally only submits a handful of art over time and leaves.

      To clarify, no one initially brought me onto the project. It was really as simple as I liked playing DCSS and felt I could help improve it. One day I went into their irc channel, told them I wanted to make art for the game, and they filled me in on where their dev tracker was. From there I just opened up the existing tile sheets for the game (unencrypted bmps in the game's directory) and just picked monsters I wanted to recreate the art for. You could do this right now. Find a monster on the tile sheet you think is in serious need of improvement or replacement and have at it! There are a ton to choose from. To test your art, you can just overlay it over a screencap of the dungeon.

      Only after I felt that I had paid my dues via improving existing art and felt comfortable in the format did I move on to filling new art requests and making my own designs. Hopefully these insights into the process combined with the blog helps remove the unknowns and makes it easier to decide if the reality of the process appeals to you.

    2. Hi John! I really enjoyed reading this article, though I have to admit I enjoyed reading this bit in your comment thread the most -- you described the same experience I had as a Crawl tile contributor. I started out making improvements, moved onto making new variations for tiles, and have gone on to make unique new designs of my own. I'm not sure the exact numbers, but I've submitted enough tiles to be counted in the hundreds at this point. Virtually all of your tiles are still in the game, though Grinder has lost his wings!

      I think an important thing to note is that the development team is a lot like the tiles team in that it fluidly changes as people join and leave -- though it's magnitudes more stable than tilemaking. Recently there have been many new tile contributors, and things are changing more rapidly. I don't think the developers ever expected to have two or three people to submit multiple tiles for the same thing in the space of a week, but that is the community that we're looking at now!

      More kinds of tiles have become acceptable in the game, as well. There are multiple monster graphics that span more than one tile. While I doubt some of the things you suggest (light sourcing in particular) will ever show up, anything could happen in the future.

  3. Derek *did* have free reign working on DoomRL. He just didn't have much time for it :/.

    That said, we still plan on improving a lot within the engine, especially that we don't constrain ourselves to any of the mentioned problems you described.

    1. Kornel, I probably should have guessed that Derek had your full support. I read your blog many times back when I was working on DCSS and considered you to be one of the most progressive of the ascii roguelike programmers, especially when I read your thoughts on the potential pros and cons of making Doom2RL purely tile-based. Prior to that, adding sounds to the ascii version was truly a great touch.

    2. Thank you! Which reminds me I should really ressurect the blog :/. I was under impression that no one read it.

  4. BTW, we're currently looking for people to help out with GFX for the other roguelikes, so if anyone here is interested... :>

    1. If someone reads your post and feels that they have the right skills and dedication to help him, they should jump all over this. The best thing a driven pixel artist could ask for is a solid programmer who can also do solid gameplay design and ship completed builds. Hell, I'd probably try and take you up on this if I wasn't already commited to a project. I really hope you find someone devoted to helping you expand the boundaries of tile projects. You definitely deserve it.

  5. I think the official NetHack tiles have a reasonably good style for high pixel density displays. They're high-contrast and reasonably simple. The floor tiles have practically no detail and are easy to distinguish from the rest of the set, which makes it easy to quickly read the figure and ground in the map. Some of the object and creature tiles still have elements a single pixel wide, which are pretty unreadable at standard resolution.

    I'd like to see more people approach roguelike tiles as a visual information design problem as well as a tile art problem. Start with what's the most important information the graphics should convey (which tiles can you walk through is pretty important, for example), and think of the most effective way to do that.

    The point about idle animations is also good. Another really important thing is which on-screen entities are animate. Doing idle animations for the monsters would be an excellent way to show this quickly, but absolutely nobody does this. I guess because it's both even more work for the graphics side which tends to be sidelined to begin with, and is inimical to the basic "the world stops while the player thinks" program model, but probably also because few roguelike devs even think that this feature could be really good for the game.

    1. Risto, thanks for your reply.

      I think the art in Hack Slash Loot is very much along the lines of what you are describing. High contrast, reasonably simple, easy to see at any resolution, and focused purely on providing information to the player. That game also does idle animations, attack effects, and sound. I don't think it is a landmark game by any means, but it fits visually into that style.

      While that kind of art has it's place, I think there is just as much room in roguelikes for art more akin to art like what's in Zelda on SNES or even approaching Diablo levels of detail. And that is certainly possible if programming is done to support it.

    2. HSL is a good example too, yes. Hadn't realized it does that bobbing idle animation, which is neat and takes no extra graphics work. The reason I'm particularly interested in this kind of style is that with a bit of thought, you can make it work even if you only have programmer art to work with. Even roguelike projects with no separate graphics talent involved can benefit.

      Graphics like SNES Zelda (or Shiren the Wanderer, if you want a more direct roguelike vibe) would be a great thing to see in a new roguelike, but that takes a lot more skill, work and coordination to pull off. You need to establish the art style with someone who can coordinate the total design, and need pixel artists who can consistently draw and animate sprites in that style whenever new elements are added into the game. This can be quite hard with the traditional roguelike development method, where you are working with unpaid help and keep expanding the game with things that need new tiles through the years.

  6. A very interesting read! I've been considering organising an episode of Roguelike Radio about tile development/design, and your post makes me want it even more. Is this something you'd be interested in participating in?

    1. Darren, thank you! I just did a quick search and saw you are the one behind

      That is an awesome coincidence, because I found and listened to your podcast with Derek Yu last week and thought it was fantastic.

      I'd love to participate in an ep. Let me know if you have any questions or details for me anytime via johnatt AT gmail.

    2. Darren, please email me when you get a chance so I have a way to pm you.

  7. Thanks for the retrospective. Your massive art contribution was (and is) really appreciated. :)

    Your complaints are all spot on. I hope you never got the impression that I disagreed with any of that. By the time you showed up, I had long since resigned myself to the limitations of needing to match the ascii version.

    A game that leaks information (like lighting, pseudo-3d walls, or any multi-tile effect) of out-of-sight tiles is always going to be a much better game visually. There's really no question. Sadly, I just don't think that game can be Crawl. Like you say, such a game probably needs to be designed as a graphical game from the ground up so that it can be freed from those limitations.

    The sprite scaling and animation are definitely just something that I didn't have the time to do. There's no reason that somebody couldn't just go and implement those features.

  8. I remember saying something similar on the last DCSS poll: something to the effect of, the game is awesome but absolutely hideous. I mostly talked about a lack of thematic unity. In many ways the ASCII version is prettier than the tiles version. I called DCSS the tentacled monstrosity of roguelikes. I think I suggested they just hire a graphic designer and monetize the damn game already.

    In terms of coding, it's true that it takes an incredible amount of work to add something very small, but that's where development should be headed. DCSS seems focused on endless expansion of the game logic, which is well suited to the distributed, community coding, rather than engine rewrites, which requires a great deal of expertise -- but I honestly think that's the most entertaining part. (I think someone said that the greatest joy of coding came from writing a few thousand lines of code that does apparently nothing.) I kind of bristled at the excuses that programmers gave, which are pretty much just that. This is kind of personal, this is why I don't stay in communities that long I guess.

    This can be rather frustrating, it reminds me of Vim's implementation of almost everything out there except smooth scrolling with text wrapping like every other goddamn text editor out there. Sure, engine rewrites, but that's where all the fun is.

  9. This comment has been removed by the author.