Economy in Roguelikes - Part I: Thoughts

In games that even roughly follow the RPG template, as the game progresses the player or party increases in power on two axes (axis plural apparently, I love English). One axis is character strength or experience, the other being character equipment and items. As someone who's creating a game, specifically a roguelike, making these areas of the game interesting is critical to my success. I'm going to cover some of my recent thoughts on the second area, equipment and items, in a short series of articles.

Anyone who's played a recent RPGish game has seen the drill. You start off equipped no better that a set of dirty rags and a dull knife and end the game in shiny enchanted plate armor and a +5 sword of awesomeness. This provides both a "carrot" to the player (look at how awesome your equipment is), and a "stick" (get behind on the equipment curve and suffer). In almost every game, the way one goes about this is pretty standard.

• Enemies drop trash items and/or cash that one collects
• Enemies (sometimes bosses) randomly drop items worth keeping
• Unused items can be sold to shops for cash.
  
• Cash can be used to either buy new equipment, gamble for new equipment, or improve existing equipment

There are some consequence to this system, one major one that has come to my attention is what I've seen called the "vacuum cleaner" behavior: Since in roguelike you have one life, people play optimally. Since every item dropped can be converted to cash, which can be converted into power, one should collect every item and return it to town to sell. This is generally boring, so games have come up with "band-aids" to patch over the issue.

• "Town Portal" scrolls, to make return to the market less painful.
• Pack mules or Bag of Holding - Increase amount one can carry, making return trips to sell items less frequent.
• The items enemies drop are low weight and stackable (Final Fantasy XII), also reducing frequency of return trips.
  
• Pets who can return to town and sell items (Seen in Torchlight)
• Transmute spells, which will convert items to cash.
  
• Shops and merchants who are co-located near/in the dungeon at hand.
• Have a time system, either food or a deadline, which punishes players for returning to town more than the item is worth.
  
• Remove the selling system in its entirety (Crawl)

The other half of the issue is returning home to buy better equipment. This almost always follows the Sorting Algorithm of Weapon Effectiveness (read this link). The ways I've seen new equipment introduced into game include:

• As you travel farther from the starting area, or visit new towns, better equipment appears for purchase. 
• As you progress in the plot, items shops everywhere restock with better items
• Many items exist for purchase from the start of the game, but you can't use the good ones due to lack of skill, strength, or level
• Many items exist for purchase from the start of the game, but are priced out of range of all but the most dedicated grinding players

Analysis of these thoughts and my plans for Magecrawl's economy will have to wait for another post. Let me know if I missed something, or your thoughts in the comments.

Why your next roguelike should be in a managed language

So I strongly believe that for new projects, the language of choice is important. It determines what platforms you can target. It can determine your license. It determines the type of code you write. It determines who would be interested in working with you. It determines how quickly your code can run, and how quickly you can write code and find bugs. It is one of the more important decisions you can make, since changing it requires a huge amount of work.

Now I'm going to divide languages into two groups, with a grouping I feel is pretty safe to make:

• On one hand you have unmanaged languages. Those are ones that are generally considered "lower level". 
• They almost always have pointers. 
• They compile down to assembly (or are written in it). 
• They are generally extremely fast when run, with little overhead when carefully programmed in. 
• They are also very unsafe. You can scribble over memory almost anywhere. You can corrupt your stack and crash on returning from a function. You can many times walk off the end of arrays and lists and crash. I generally program in these at work, and some bugs can take days to sort out. 
• Good examples include: C, C++, and assembly
  
• On the other hand you have managed languages. The are the ones that are generally considered "high level"
• They never have pointers, unless dealing with unmanaged code
• They generally compile to a virtual machine or are interpreted
• They are slower they the equivalent unmanaged code. How much depends on the language and what your doing
• They are generally "safe". You get exceptions for doing incorrect things like walking off arrays and such. If you don't catch that exception, your program will still die, but you'll get a nice stack trace.
• There are many example, the most common include Java, Python, Ruby, C#

When making your decision, you have to make tradeoffs in determining what language to use:

• What languages you know - People generally lean towards languages they know for their "fun" projects. Others enjoy the chance to learn something new
• Speed vs. Portability vs. Speed of Development 
• All things being equal, C is the fastest and most portable. However, it's also the easiest to shoot yourself in the foot with. It also doesn't have a standard Graphics and Input Output library. 
• Other languages come with portable graphics libraries, but may be too slow. Also note, that most roguelikes are turn based, so speed is in general less of a concern
• Syntax and language - Sometimes the language itself is not suited for what you want to do with it or is hard to read and write.
  
• Library - Sometime there is a library you really want to use for your roguelike, but it can only be used in a given language
• Note, with many languages, it is possible and sometimes easy to call other languages. C# gives P/Invokes (see libtcod-net), and Java the JNI for example.
  
• Ideological - Some people choose languages to write in based upon a philosophy or outlook.
• Some people reject Java due to it being "too slow", with too slow based upon Java from the 90's on machines twice as slow as today
• Some people reject C# due to distrust in Microsoft and fear of lawsuits, even though there is a open source implementation of it and the lawsuits could only matter if your using the interop libraries.

I wouldn't be honest in saying I don't have a preference. C# is in my opinion the nicest language to work with. It runs everywhere with mono, it is type safe and fast enough for what I'm working on, and the syntax is close enough to c++ that I picked it up easily. The bindings to libtcod make things nice as well.

However, Java is a good language as well, with many successful roguelikes written in it. Python is another language I enjoy to write in, and has multiple good toolkits to write roguelike in (libtcod, pygame, wcurses).

What I'm not saying here is that unmanaged languages are bad. C is the mothertongue of roguelikes. C++ is very popular as well. I use both at work daily. I'm just saying is that for turn based, and low graphic real time games, the benefits may not out weight the costs.

Review: Triangle Wizard

Since this is Thanksgiving weekend, I didn't have to program. At the recommendation of someone in a comment thread, I decided to check out Triangle Wizard. Here's my mini-review:

Name: Triangle Wizard
Type: Roguelike, real time, modified
Website: http://www.trianglewizard.webs.com/

I had never heard of this game before yesterday. It's a freeware real-time roguelike, which only runs under Windows. It came with an installer and installed/ran with no issues.

The title screen reminded me of Diablo, it was well polished. One this it could use would be mouse support, it took me 15 seconds to figure out what was going on. I selected tutorial since I knew nothing so far.

The tutorial is one of those "learn as you do" training rooms. I had some trouble figuring out which icon was your mouse cursor and which was the player. Once I passed that, I figured out that it was a hybrid mouse and keyboard game. The keyboard moves the character and selects spells. The mouse handles targeting and casting. I love this control scheme. It makes "run-and-gun" strafing easy and smooth. If magecrawl was going to be real-time, I would seriously steal it. Another feature that I love is the "persistent casting". You can set it, and any enchantments you have cast will recast when they expire. The tutorial had a few bugs, which I sent to the maintainer, but it effectively taught me the basics.

The character selection screen was a bit confusing. The "right arrow" seemed to randomize selected items. It took me a few minutes to figure out how to set my name. Once I figured it out, I selected a human pyromancer.


Within ten seconds of starting, I was swarmed by half a dozen brigands. After fending them off, I got a chance to explore. There seemed to be a huge number of spells you could buy early, maybe too many. It was a bit overwhelming. Beyond that, I explored awhile until I ran into a "summoned phoenix". It was immune to my fire spells, and killed me.

I'm obviously not very good at the game, since I've played a few times and keep getting killed on the opening level. However, it has peaked my interest, and I'll try it some more. If you have a Windows machine, it worth a try.

Design Goals of Magecrawl

Introduction

While magecrawl is still in major development and there are major areas of decisions that haven't been made, I have a few overarching design goals and principles that I'd like to stick to.

Roguelike

While to qualify what is exactly a roguelike is a difficult question, magecrawl should fit squarely into the category. I'm aiming for things such as productively generated content, permadeath (see below on instakills), and very much the "ascii feel".

Libtcod (via libtocd-net) provides a great way to give a game an ascii feel while still be reasonable to program and look good. Productively generating conent is what keeps the game worth playing again after winning. I hope to add some sort of optional content for those who "assention" is not enough.

No obscure knowledge needed

Games such as Nethack all but require a large base of obscure knowledge to win. While some knowledge between games should transfer over, that's the primary way one can get better at games, sometimes the amount needed to win goes overboard. Reading a gold detection scroll while confused, polymorphing into a cocktrice to use their eggs as weapons, and the entire identification game in Nethack are prime examples.

Instakills are not fun

In games with permadeath, walking down the stairs and dying is not fun. The skill in playing a game should be primary in getting out of sticky situations, not playing the game a few hundred times to memorize all the things not to do. Read "Fake Difficulty" for more on this.

The tricky part with this goal is not making the game easy, or trivial. I want some areas to be fiendishly difficult, and I don't mind killing the player when they do stupid things. Running should sometimes be the best option, as running into Sigmund in Crawl can be.

Arcane theme

As the name suggests, magecrawl has something to do with magic. Every character will have some sort of magical ability. This does not mean all you can play is squishy robe wearing glass cannons. Based upon the (skills/class?) you choose, wading into melee, calling down fire from heaven, or sending others to do your dirty work should all be options.

One nice things about sticking to the theme is that it allows for better fluff and some ideas that wouldn't be possible otherwise. In a future essay, I'll talk about my plans for economy which have magic as its linchpin.

Conclusion

While I hope that I'll come up with many other great ideas and features in the months (and years?) ahead, these are the foundational ideas I'll try to build upon.

Map Generator, and the need to do other things

So the last 2-3 weeks, I've been working on map generators for magecrawl. Here's a few examples:

This is my "Stitch" map generator. It generates a graph of entrances, halls, and rooms, then reads "chunks" from a file and stitches them togeather to make a map. Right now, it looks pretty boring since there is only one room type and 4 hallway types. While there are some issues, I'm pretty proud with it.

 

This is the 'cave' map generator. It implements this algorithm for generating caves with some tweaks. It seems to give more consistent maps than my stitch generator.

The only issue I'm having is that staring at map generators during all my free time gets a bit boring. Last week I implemented a few 'nice' features that were suggested from those who played with the magecrawl tech demo gruop. This week I worked on cleaning up the code, using my point struct instead of int x, int y where reasonable and LINQing up the code where it makes sense.