Writing a Roguelike?

First some news: Provided I don’t fail either of the classes I’m in right now (highly, highly unlikely) I will be finishing my undergraduate degree within the next 2 weeks. Also, I should be getting an acceptance letter to go to graduate school shortly, based on what the professor who has hired me tells me. However, due to my brother being sick I’ve asked to delay officially starting graduate school until May, the start of the summer semester, so that I can be here if he needs me. This leaves me with a lot of spare time, as it isn’t quite long enough to get a job, and if my brother gets better I’ll see about moving up my start date. I’m going to try to fill my time with some colloquium, possibly auditing a class or two, and reviewing older classes before starting grad school, but I’m thinking I might want to start a project to fill my time.

On that note, I’ve been listening to the Roguelike Radio podcast as of late, and it is bringing an idea I’ve had a while back to mind. I’ve wanted to work on my programming skills for a while, and I’ve wanted to write an RPG system for a while. I am thinking that I might want to code a simple Roguelike to teach myself Object Oriented programming, or at least improve the programming I do know. My background in programming is a bit weak; I learned QBASIC in high school, took a class on C in first year, and a class on C++ last year. I’ve also taken a bunch of theoretical classes on algorithms and such, and used simple programming and scripting at a few of my jobs. However, I’ve never gotten into the more advanced features of any language, and only touched Object Oriented code once. I’d like to learn it, because it seems powerful, but I get turned off reading about it, as it is always held up as the “One true way of programming” and tells you to do things without any explanation, or draws all the reasons why it is better from working with a large team, whereas I would never be working with a large team. Anyway, I was writing up my emails to send to a friend, and thought I might as well post them here and see what people thought of them.

Theme: I’m thinking of a Doom-like theme. The player is on a mining colony and descends into an odd dungeon world made of the mishmashed bits of other worlds, filled with demons and monsters. Sort of like the DungeonWorld posts on my blog. This lets me add all sorts of things like in Nethack without worrying about continuity too much. Also I can play with different dungeon generation algorithms to represent different phases of the dungeon. As a result I’ll have to use a DoomRL or Crawl like targeting system, where you can shoot along non-8 axis angles, which is extra work, but I think it would be interesting. I’d start with some basic Doom monsters (Undead humans and the demons that throw fireballs), then I could add in things from all my D&D manuals as I go.

Environment: I’m going to use Unicode, so I can access a lot of characters for how the dungeon looks. ASCII is somewhat limiting, and I could draw a lot of cool things using Greek letters and whatnot. My temptation is to use pure-console code, ncurses, but that is a bit more challenging on Windows, due to the lack of a decent console. Also, I somewhat short-sightedly uninstalled VisualStudio when I was done with it. I should be able to redownload the free student version it as long as I still have my university email address. Otherwise I have to code it using Cygwin with gcc, which is a pain as it isn’t linux, but it isn’t windows either, which makes everything really strange. Or code it all in a VM or install linux on my laptop. On the other side, using something like  libtcod would be a lot easier, would make its own console, and would be easy to work with on linux, windows, etc. I think I lose something in purity though if you aren’t running it through the console of your choice.

Map: I think I’m going to go with the ‘whole map on screen’ style of Nethack, rather than a scrolling map. It is easier, a bit more strategic as you can see the whole dungeons layout, and I like Nethack. I’m going to start out with a rooms design similar to nethack, then add in more caves (Gnomish mines and such) once I’ve got that working. I’ll change the dungeon generation algorithm every so often to represent the player passing through different styles of region in the DungeonWorld. I would of course have persistent levels, as I can’t stand games without them, and I love having equipment caches, alters, shops and whatnot that you return to. These would all be features I add later, but I want to leave room for them.

Character: One of the reasons I want to write this is to play around with rules. As a result, I don’t know how many people will actually play it, but chances are I’ll never finish it anyway. So, I might as well focus on implementing interesting rules, rather then a pure focus on what makes sense to have.
I’m thinking of a system similar to the BRP roleplaying game, with percentage based stats. I’m also thinking I should have them rise with use, instead of with levels. I have a really elegant system for doing this, but it makes adding levels and hitpoints somewhat heterogeneous. Do I even want levels? If I don’t have them, how do I make your HP go up, since it isn’t used? So I’m thinking that skills will go up with use, and it needs more use as you raise them. Basically; every X successful uses (where X = your current skill) you get a roll against the skill. If you *fail* the skill roll, your skill goes up by 1. So it is easy to raise it from 10% to 11%, hard to raise it from 98% to 99%. It may take a bit of tweaking to find the right balance, but that is the basic idea. It is also quite easy to program.

As a result there won’t be any classes, which lowers replayability a bit, but makes it easier to get into the game, as you don’t have to make any decisions at the start of the game.

I might also have a doge skill, lockpicking, stuff like that. Dodge is probably a good idea, but balancing that would be a bit harder. Still, probably worth it.

Now hitpoints are the hard part. Obviously you want them to go up over time. I could have levels just equal an increase in HP, but that seems a bit bland. I could give each monster an XP value, and every time your XP total hits some number then you get more HP. Then I leave myself open to adding traits or such at certain level values later on, and I can tweak things if players rise in XP too quickly or slowly at certain parts of the game by altering my levelling algorithm; original D&D started with an exponential growth equation at low levels, then moved to something more sane at a certain point as I recall, to make it possible for players to keep getting levels. It also allowed low level players to catch up to the fun point of the game, since you could burn through the first few levels quickly. I’m not going to start with something like that, but I might add it over time once I get a feel for the game.

Imitative; I want to do a tick based initiative. I saw a demonstration of this once at a con, I think the game was Aces & Eights. They had a track by the side of the miniatures area, and each player had a token on it. Each action you did would move your token along the track a little. So lying down might take 2 ticks, but standing back up would take 4. So it was really flexible, and you had a choice between trying something big that would make it a while before you act again, or something small that would have less of an impact. There are some articles on RogueBasin about similar systems. It warns against using a turn counter, as you’ll eventually hit a memory error if you play long enough. The really simple way to overcome this is to use an offset from the current turn instead of an absolute value. Then you only have to worry about the total offset instead of a constantly increasing number.  The easy way would be a matrix where the current tick is always 0, and you add actions in an offset based on this. The problem you encounter is what happens if there is already a action at that point? So, for example, I make a move that means I next act at +5. There is already a zombie that moves at +5. Now, I have to use either +4 or +6, which is fine, depending on if I use first-in-first-out or last-in-first-out, but what if there is a monster there already? I’m thinking of a linked list of some sort, as I can dynamically add actions in, and don’t have to iterate over the array each time I want to find the next action, I just follow the link to the next one. Each cell in the array would have its offset, so when I add an action I just scan along until I find one with a larger offset, then add the new action in before it. Now, I would then have to decrement the offset on a regular basis, but that shouldn’t be too much of a problem, as I only have to do it on scheduled actions, not every cell in an array.

Then there is the ‘you stop digging’ problem. That is, what if I start digging that takes 10 ticks, and a monster appears? Do I force the player to die? Seems like a bad idea. The elegant way to change the rules would be have the effect of an action happen when you perform the action, then you just stick the player back into the initiative order a bit early. No worries about cancelling an effect. It is a bit unrealistic though; if the dirt is already moved or the spell cast, why do I have to wait to move again? Oh, that also doesn’t work; as it means that players get a free insert back into the initiative order, and have accomplished the task they were working on early.

It also adds a tactical element if some abilities take longer to work, as you risk an enemy moving, or you get a chance to hit them and interrupt their spell or ability. I think I could do that, and it sounds interesting. It means a lot more code though, as I’ll have to define the failure mode of each action. What is the failure mode for getting hit while drawing your gun for example? I guess I could have breakable and unbreakable actions. Do you have any suggestions?

Anyway, I like this idea as I can make some monsters faster just by making their actions faster, without having to worry about movement rates and such. Nethacks system always confused me a little. Then I can add modifiers into actions speeds, such as a stimulate making all actions 1 tick faster, or being encumbered making movement actions 1 tick slower.

Monsters: Ok, making monster stats in my system is easy. Just assign them a skill for each attack they have, a speed for each action they have, and some HP. The hard part is AI; I have no idea how to do AI. There are some articles on roguebasin that might help, but man, most of them are written for more advanced people. I might do a simple ‘if you can see player, and have an attack in range use it. Otherwise move towards player.’ This would be pretty easy to exploit with traps and such; I might go into some of the weighted random bits? It could also be too lethal given how many monsters have ranged attacks when you open a door and everything in the room shoots you. I could add a surprise factor that slows monsters when they first see you…

Saving: I’m going to save my games in text documents, and just save the players stats, what item is on each square and its traits. The hard part will be figuring out the best way to write it, and then parse it back, and the balance between having to change it on a regular basis and adding a zillion exceptions. So, I was thinking each square would just have a delineated list of items: (1,1)|shotgun, 1; bullets, 10; shells, 43| or something like that. That would make it easier to edit, and avoid breaking the save file every time I add a new item, like Nethack does. It would also make it really easy to edit a save file when I want to test a new time, as it is easier to read text instead of numeric codes. Then you get the problem of charged items; Do I add a charge value to every item in the save file, or write an exception? This type of thing doesn’t seem too worrisome though, as it would only effect my input and output bits, so rewriting it as I add things isn’t too worrisome, as long as I don’t care about save compatibility too much. I could even write scripts to upconvert save games to the new files if I wanted.

Items: I’ve still got a lot to decide here. The upside of the science fiction setting is that my game won’t instantly feel like Nethack without all the weird bits. The downside is that thinking up items is harder. Weapons are easy; they just give you an accuracy boost, or fire slightly faster than normal. Or worse, I could make degraded versions that you can find at lower levels then you normally would.  I could also make one with slightly larger magazines than normal. Armour is also easy; it reduce the damage you take per blow. That is common in tabletop RPGs, but I always found it cumbersome. However, once you have the computer doing the math, why not?

I’ve got mixed feelings on having some sort of foodclock. On one hand, it is a lot of extra work, and would just be a copy of most other games, right? On the other hand, if I don’t have it, what keeps you from grinding level 1 forever? On the upside, it means no more games were you die just because the RNG won’t drop any rations.

Moving on; a lot of what gives Roguelikes their depth is weird items and how they can be used. If I’m going for a more modern theme then it feels wrong to throw a lot of amulets and wants and such in. I’m thinking I could play off the descent into hell aspect a bit to justify some of those, but still, any suggestions here would be appreciated.

Programming: The hard part is I don’t know Object Orientation very well; we only used it in a couple projects in the last class I was in, with a terrible prof. I started this in part to learn object orientation, but it is tempting to go with what I know in large part. I wonder how much of a sin it would be to use mostly functional programming, and save object orientation for the monsters or something like that? Part of the temptation is there is a really nice guide on how to do a lot of basic things in C++ called The Beginner’s Guide to Roguelike Development in C/C++ that details how to get started that I could extend. However, it is written entirely from a functional programmer perspective, which I’m quite comfortable with. I’m wondering how hard (or sinful) it would be to start with the basics such as movement in functional code, then put things such as items and monsters into objects? I’d need to find a good book on OO as well, my textbook was horrible. Again, recommendations here would be appreciated. I was tempted to try learning another language, like Python or Lua, on the principle that I use scripting more then I use a high level coding language, but learning C++ is a pretty useful skill I think, and would let me get started a lot faster. There is also a temptation to use pure C, so I don’t have to worry about object oriented code or anything, but that would kind of defeat the point, and I really don’t have to worry about portability or performance that much.

Advertisements
Published in: on December 2, 2012 at 3:07 pm  Comments (17)  
Tags: , , , , , ,

The URI to TrackBack this entry is: https://canageek.wordpress.com/2012/12/02/writing-a-roguelike/trackback/

RSS feed for comments on this post.

17 CommentsLeave a comment

  1. This sounds like quite a big project to teach oneself OOP!

    That being said, big projects teach you big things. From my experience, and from smarter persons’ as well, OOP is best used for things like gui’s and programs simulating things. Taking that into account, make the character, monster and “objects” like that into objects in your program and see where it takes you. There’s nothing stopping you from writing functional code by starting like that.

    When it comes to languages, C++ might be popular but it’s one big mess of a language. Something like Ruby or Python would be a much smoother way to ease into OOP. Personally I prefer Ruby if I had to choose between those two.

    If you really want to learn to think in a new way that would make you a better programmer, take a look at CLOS. It will make you think differently, and be a better programmer afterward.

    • Well, I was listening to Roguelike radio, and thought I might actually keep at this project if it was interesting enough.

      The upside of C++ is that I’ve already worked in C and C++. Additionally a lot of scientific software, such as GEANT4 is written in it. The other languages used in science a lot (FORTRAN, Matlab and R) wouldn’t exactly be the best choices for a game. FORTRAN would be possible, but well, I don’t even know if it supports object-orientation, or if it has any compatibility with libraries that would support writing a roguelike.

      Yeah, I glanced at that CLOS document, and it was way beyond my head. I’m looking more for an introductory level text.

      • Come back to CLOS later, it will blow your mind. Promise.

        Yea, go with what you know. It will probably make it easier to keep at it.

        Personally I love Fortran, and modern versions like Fortran 95 even have OOP features.

        Thanks for the hint about the Roguelike radio!

        • Would FORTRAN work with ncurses or one of the other good roguelike libraries? What do you like about it?

          • For your project it’s probably not a good fit. It has the OOP bits but no.

            I like it because it is still so very clear at showing what goes on. Move data from memory to the CPU, do some math and move data back to memory. It’s like seeing the wheels turn.

            It shows how computers work, i.e. move numbers about. Maybe not the best tool for your job. :)

            • I’ve taken a class on assembly and how CPUs work, so I think I understand that bit at least!

    • I tend to agree with Canageek that the OOP philosophy is overhyped and treated more as a religion than a design methodology – especially in academic circles. While it is a great way to manage the ever-growing tangled complexity that roguelikes can easily degenerate into, I’ve found that rigid adherence often does more damage than good.

      Andreas has a good point about starting just starting with something and seeing where things go. Most large-scale roguelikes started incredibly simple and grew organically: the advantage there is your skill and ability has the the time and opportunity to grow alongside your title.

      I’d encourage you to start small with whatever you feel comfortable with but don’t invest yourself heavily in its success. Expect a rewrite or two (or ten). Each step along the way makes you more than just an experienced coder – it makes you a stronger designer and developer and you’ll find the latter two will serve you well in whatever career you wish to pursue.

      • Hey Craig: I’ve got to admit, I never got started on my project. As I listened to more Roguelike Radio, I realized no one would ever play my game, as it wouldn’t actually be a whole tone of fun.

        I don’t have any problem with OOP, but I wish I could find a teacher that actually explained it to me. The programming profs I’ve had that taught it didn’t explain any of the logic behind it, but then, they didn’t explain the logic behind much of anything.

        • Nothing kills enthusiasm quite like taking a course on it. I literally fled from chem because of a single prof and I am just now discovering how amazing it can be, a full decade later.

          I think you’ve got a lot to offer: you’re methodical, you’re smart, you’ve got a mind for the mechanisms behind rules and the effect they have on a game. You think like a designer. I believe you have a great concept and you certainly have the skillset. If you don’t have the time or have other priorities that’s one thing but please don’t let the roguelike glitterati discourage you.

          • Thanks for your comments. I just realized that while I can make rules, I have no idea how to actually make a game FUN, and do something different then the hundreds of other roguelikes out there. I realized everything in my idea seemed to be already done by DoomRL or one of the other ones better, and most of my ideas seemed to be the parts of games other people didn’t like (Stockpiling, backtracking, etc)

            • If you are having fun learning don’t worry so much about how others will receive it. Concentrate on making the game you want to play, and you actually play test it to be sure you like it as much as you think you would. The best games/music/other art I have come across have always been labors of love where someone is true to themselves rather than common wisdom of how to do things.

              On the other hand if you don’t have the drive and no longer think it would be fun, then move on to something that you can find fun and rewarding.

            • I agree wholeheartedly with UbAh’s approach. ADOM, Dwarf Fortress and DoomRL all started that way.

              It seems from your original posting that you do a lot of tabletop gaming. Just to get you thinking in a different direction, I believe there are subtle differences between the two gaming media: experiences around the table are often more vivid and emotional and as such require intricate and careful design of more “human” factors such as theme, story and interaction. Furthermore you have one shot to get it right and no chance to stop and try that idea again – but this time with an added twist.

              Fun in game development is often more emergent and iterative and will often surprise you as well. If you have some time, check out Chris Crawford’s articles on interactivity in game design. There may be some interesting ideas for you there.

  2. BTW, nowadays Fortran is not spelled in all caps. That is the old way. Newer dialects have free form source, long names for variables and only caps where it’s needed.

  3. How goes your adventures in procedural generated fun?

    • To be honest, I’ve never gotten around to it. The other person I was planning on doing it alongside never got started, so I let it slip away. I’ve been quite lazy in the last month and a half.

  4. Your ideias seem to be very embrionic still.
    My general apreciation is that you should follow the advices on *Extra Credits* Episode about *How to become an Indie Game developer* (see on youtube).
    Keep it simple, on your first attepmt. Then make it simpler on the second attepmt.

    I had classes about OOP, but I actually learn it throught Deitel and Deitel “C++ How to program”. It took me about 3 months.
    I’d also recoment “Practical C++” by Qualine and “Thinking in C++” by Bruce Eckel.
    However, if your true goal is to make a game you should try to do a very simple one right now with what you already know (functional/procedural programming). Following along “Beginner’s Guide to Roguelikes in C/C++” is a great idea. Craig seems to have real experience in programming, but he still tries to explain his choices in enough detail, that someone new to programming can understand why he’s doing it the way he does.

    I had the personal experience of trying to program a RPG game in my spare time for a year, and failling!
    After that failed experiment I almost gave up on making my own games, but as a last goodbye tried to write a tetris clone.
    I took me about 40 man hours to finish it. And that achivement, of actualy finishing a fully functioning game, reestablished my confidence and made me continue to dream about making games.
    The reason why I was able to write it in such a short time, was because I knew my graphics/sound API (allegro) very well (one year using it!), I was really strict about what I was trying to accomplish:
    1. finish a playable game
    2. use the least amount of programmer time
    This meant no time drawing graphics or doing sound, just stole what I needed from the web. Complete disregard for code performance (passed std::vector by copy to functions). Deleting code if it started to be difficult to compreend (programming sessions were very scattered and if I could not remeber what a function or class was for, I’d simply delete it).

    Hope this helps.
    Ganbatte!

    • Hey. I pretty much abandoned this idea shortly after I wrote it down, but it is great to hear your feedback. I’ll keep those books in mind if my job ever turns back to something with more programming in it.

      The problem I had with the “Beginner’s Guide to Roguelikes in C/C++” is that it was basically straight C, all functional programming. So if I want to do it that way, I’d follow his guide, but it would kind of defeat the point of learning OO coding.

      I’ll keep some of your tips in mind, thanks.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: