Roguelike RPG in the OHR?

[camdog]

So, I've noticed that a few folks in the community are interested in roguelike games. I've dinked around a bit with Nethack and Angband, both of which I enjoyed (though I've gotten nowhere near beating either of them), and I thought it might be a cool experiment to see if I could do something similar with the OHR.

I've put together some basic scripts for creating random dungeons, creating random treasures, and fighting different enemy formations based on what dungeon level the player is on. The scripts are a little rough around the edges, but they all work as intended. At this point, the game isn't too tough or extensive, but it will give you an idea of what is possible with the engine.

Since most current roguelikes are community projects, I thought at this point it might be fun to expose the engine to the public. The scripts are written in such a way that anyone with a little hamsterspeak knowledge should be able to elaborate on them. And of course anyone could contribute new graphics or ideas for enemies, items, quests, etc.

I don't know the best way to handle a collaborative OHR projects. The tactic of emailing from one author to the next that's been used on previous collaboration projects obviously won't work here. Perhaps we could set up a subversion repository of the unlumped game and have authors check in the relevant unlumped files for inclusion? I've never used subversion, and I don't know how much leeway we have messing with unlumped files, but it's the only idea I have so far. Let me know if you have any better ideas.

So, the basic question is, would anyone be interested in working on this? What's uploaded right now has no documentation for working with the script framework, but the basics should be pretty obvious if you look at it. If a bunch of people are into this, I'll probably write up some documentation as well.

Get the game here.

If you don't know what I mean when I say "roguelike", go here.

[Newbie Newtype]

This sounds really awesome, and I would definitely be interested in helping out, being a Roguelike fan myself.

EDIT: I notice the OHRogue uses the current battle system. Are we going to stick with this, or try for a more Rogue-like combat system on-map? I'm sure a Rogue-like combat system wouldn't be too bad since you only have one character to manage so HP/MP/etc display wouldn't be too hindering.

Maybe for a turn based movement system Rogue-like games use, maybe we can have suspend npcs turned on, and when an action is done, or an arrow key is pressed, everything is moved one space using the wait for npcs/hero commands.

[camdog]

My original idea was to use the default battle system, since this would give the game a slightly different flavor instead of just being another rogue clone, and it would utilize the strengths of the OHR instead of trying to work around it. I figure the resource management strategy of a rougelike along with a deep OHR-style battle system (something along the lines of darkmoor dungeon, perhaps) would make for a pretty neat game. This way would also make it easy for people to contribute monster ideas.

Of course, nothing is decided yet. If everybody would prefer a more traditional roguelike interface, I imagine that's the direction this project will end up going.

[Newbie Newtype]

Oh, okay. We might want to have some sort of party-based system instead of just one character if we're going to have FF style battles.

With that, we may also switch to NPC triggered battles, because monsters can then be randomly placed just like in Rogue-like games.

[Mogri]

This is of course fantastic. I have one suggestion that will help out the game enormously: put each dungeon on a separate map so that you can store them all.

Actually, the original Rogue didn't store level info either, but it also didn't allow you to go upstairs until you found the amulet, so it didn't have the abuse problems present in your engine.

There are a few aspects that any roguelike worth its salt should have, some of which are harder to implement than others:

Item ID'ing. This could be kind of tough depending on how many items you're planning to have. If you don't need more than 128, you can just put the un-ID'd items in the slot before their ID'd counterparts and check whether to give the player the un-ID'd item or the ID'd one.
Encumbrance. This is much trickier because it involves assigning a weight to each item unless you want an apple to weigh as much as a suit of armor.
Hunger. This is easy to do.

[camdog]

Oh, okay. We might want to have some sort of party-based system instead of just one character if we're going to have FF style battles.

Yeah, I was thinking it might be neat to be able to find pets, as in nethack. Strategy could be built in to pet selection by making all the pets start at level 1, but more powerful pets are found at lower levels (so you had to balance between experienced pets and pets with more potential power).

With that, we may also switch to NPC triggered battles, because monsters can then be randomly placed just like in Rogue-like games.

This would be easy to do in the current engine. We could set certain enemy npcs to follow the player and add an action element to the game as well.

Actually, the original Rogue didn't store level info either, but it also didn't allow you to go upstairs until you found the amulet, so it didn't have the abuse problems present in your engine.

Angband always generates a random level, and it lets you go up and down at will. It fixes abuse problem by only generating interesting items on a new level if you spent a bunch of time on the prior level. Of course, OHRogue doesn't have this, since none of the currently available items are particularly interesting, but a mechanism similar to that could be built in.

Another option might be to simply not generate treasures or staircases near each other.

Encumbrance. This is much trickier because it involves assigning a weight to each item unless you want an apple to weigh as much as a suit of armor.

This would be a pain in the slime, but we could probably simulate this by a script that's really just a lookup table, such as (in pseudocode)

Code: Select all

weight := 0;

foreach (items as item) {
  switch(item) {
    case (sword): weight += 20;
    //etc.
  }
}

return weight;

It wouldn't be so bad if we get a bunch of people working on this, and people just add to the switch statement whenever they create a new item.

Hunger. This is easy to do

Yup.

Item ID'ing. This could be kind of tough depending on how many items you're planning to have. If you don't need more than 128, you can just put the un-ID'd items in the slot before their ID'd counterparts and check whether to give the player the un-ID'd item or the ID'd one.

I think this is going to be the biggest problem. 128 items seems pretty slim for a roguelike. My only thought so far is that maybe only some kinds of items need identification? (Just potions and magical items, for example? We don't necessarily have to worry about rotten food and the like).

[Mogri]

Yes. If you want to do it minimally, only potions, scrolls, spellbooks, wands, and such would be un-ID'd.

The other option is to make a custom menu system. That way, you could just use tags to determine whether to display an item or its unidentified equivalent. This would also allow you to distinguish between the items by giving them randomized appearances as in NetHack and Rogue.

[msw188]

What about a separate menu for unidentified items, and then the actual item menu is only used for identified items? This will mean that only identified items will be available in battle (without some extended trickery). Will also make item acquisition from battles quite difficult unless bug 525's feature requests are fulfilled.

[Newbie Newtype]

What happens when you gain more than one of the same unidentified item?

[msw188]

Well, that depends. If you want you can change the relevant menu choice to say UnIDitemA_x#, where # is the number of occurences of item 'A' you have. This is practically just as much work as setting up and maintaining the menu to begin with.

I personally think that the weight system will be the truly difficult thing to implement. The player is going to need a fairly simple and intuitive way to see the weight of everything they have (including UnID'd items, and equipped ones!), and much worse, an interface that allows them to decide what to get rid of if they want a new 'item'. This interface should allow them to scrap equipment, or only a few of their grouped potions, or a combination of several things. This might be an argument for disallowing grouping of items altogether (see Bug 522), which also would change how we'd like to approach KM's last question.

[sorlok_reaves]

I don't know the best way to handle a collaborative OHR project.

You can un-lump the game, and put each lump under SVN (or CVS) version control. The OHR can run unlumped games, so that helps.

SVN isn't good for binary files, so a developer would have to lock the map in question when editing it. But your game will most likely be script-heavy, and SVN/CVS will merge the files together, if possible (it's usually good at this.)

[camdog]

After thinking on this a bit, I've realized there's another possibly insurmountable problem with item identification. Regardless of description, items will reveal their stat bonuses on the equip screen. Even if we do two pairs of items, the unidentified item will still reveal its stat bonuses. The only way to avoid this would be to disallow equipping unidentified items, or replace an unidentified item with no bonuses with the identified item, essentially making equip an identify spell. In my mind, both of these solutions destroy the gameplay of identifying items. If anyone has a solution to this, I'd love to hear it.

Having said that, I think this begs the question, is it totally necessary? I know it's a staple of roguelikes, but couldn't we make a good game by focusing on other things that the OHR is good for? I guess the real question is, would it be worthwhile to work on a roguelike game that doesn't have all the standard roguelike elements, and would you be willing to contribute? This goes for any gameplay element that may be hard/impossible to implement in the OHR.

(That said, if anyone can offer a good solution to these problems, I'd be happy to work on implementing them.)

[msw188]

How is this problem handled in regular rogues? What happens in those games when you try to equip an unID'd item? Doesn't it tell you your new stats?

If you want stats to change without visibility to the player, you could write a script that adjusts stats before every battle depending on what is equipped. A fairly horrible script without a 'read item data' command, but not as bad as implementing a weighting system I'd say.

[Mogri]

After thinking on this a bit, I've realized there's another possibly insurmountable problem with item identification. Regardless of description, items will reveal their stat bonuses on the equip screen. Even if we do two pairs of items, the unidentified item will still reveal its stat bonuses. The only way to avoid this would be to disallow equipping unidentified items, or replace an unidentified item with no bonuses with the identified item, essentially making equip an identify spell. In my mind, both of these solutions destroy the gameplay of identifying items. If anyone has a solution to this, I'd love to hear it.

Having said that, I think this begs the question, is it totally necessary? I know it's a staple of roguelikes, but couldn't we make a good game by focusing on other things that the OHR is good for? I guess the real question is, would it be worthwhile to work on a roguelike game that doesn't have all the standard roguelike elements, and would you be willing to contribute? This goes for any gameplay element that may be hard/impossible to implement in the OHR.

(That said, if anyone can offer a good solution to these problems, I'd be happy to work on implementing them.)

This isn't totally insurmountable. Sure, you can see the stat bonuses, but A) equipment can have other effects and B) you can make the stat bonuses ambiguous. In many roguelikes, equipping something identifies it anyway.

However, you may want to sidestep this problem entirely by making your own equip menu. Why? Otherwise you can't really deal with "cursed" equipment properly: you'd have to wait until the player left the Equip menu to say, "Hold on, you can't actually equip this."

[Newbie Newtype]

If you want, maybe I can spend some time drawing pets for you, if I can find out what kind of pets you want.