Roguelike RPG in the OHR?

[camdog]

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

It'd be great if you drew some pets, though I don't have any specific ideas right now. Since I want this to community oriented, feel free to make up some of your own, both in look and function (and anyone else should contribute ideas as well...)

I'd like to spend some time doing a little more programming for this. As moogle said, it still lacks some traditional roguelike functionality. Like I mentioned before, I want to create this in such a way that emphasizes the OHR's strengths, rather than writing a mess of code to sidestep the basic engine. So, to reiterate my earlier question, is there anything that would be clunky to do in the OHR that we can all agree to leave out/change without obliterating the basic roguelike gameplay?

[msw188]

Now I have exactly zero experience with rogue-like games, but I have been having an awfully fun time messing with plotscripting items lately, and my gut feeling is that item ID'ing is possible, and in fact not very hard if we don't use the item-rewards in battle (if we are triggering battles from NPCs we could use the NPC argument and check a percentage after battle; also, stealing could be handled via tags in battle). This would use using the separate menu for unID'd items that I described before. It would pretty much be impossible to use these items in battle, however.

My feeling is that the weight system should be the thing to go. I don't know how much this contributes to a rogue-like, but I really can't see any way of accomplishing this in the OHR with anything less than a fully customized item system. One might argue that the unID'd item system is also a 'fully customized item system', but I think that the coding required will be much less of a hassle (maybe because I've been arranging an item acquisition system in my game, and even without weights it is a pain). On the other hand, itemID'ing would not need item acquisition to be able to ask the player to throw something away (the worst part), and only equipping might be somewhat difficult if we do not want the player to be able to ID items in this way.

All possible problems with itemID'ing go away if we use only 128 items, of course. No such simple solutions exist for weights that I can think of.

[Newbie Newtype]

It'd be great if you drew some pets, though I don't have any specific ideas right now. Since I want this to community oriented, feel free to make up some of your own, both in look and function (and anyone else should contribute ideas as well...)

Then I'll start with the Nethack Cat & Dog, and likely a small dragon-like creature.

Oh, and I'm also going to hand over different palettes, that can be randomized when you get said pet.

[camdog]

Now I have exactly zero experience with rogue-like games, but I have been having an awfully fun time messing with plotscripting items lately, and my gut feeling is that item ID'ing is possible, and in fact not very hard if we don't use the item-rewards in battle (if we are triggering battles from NPCs we could use the NPC argument and check a percentage after battle; also, stealing could be handled via tags in battle). This would use using the separate menu for unID'd items that I described before. It would pretty much be impossible to use these items in battle, however.

Interesting. I had almost the exact opposite initial thoughts. For one, I worry 128 items will not be enough for a full-fledged roguelike. For another, trying out unidentified items is a big part of the gameplay, so I consider the inability to use unidentified items to be a serious problem. (Of course, since this is a big part of the gameplay, it kind of invalidates the idea of sidestepping this problem anyway... I just wish there were a better solution.)

On the other hand, I imagine implementing a weight system would be very easy. I described my idea earlier in the thread. Do you see a problem with this approach?

Then I'll start with the Nethack Cat & Dog, and likely a small dragon-like creature.

Oh, and I'm also going to hand over different palettes, that can be randomized when you get said pet.

Thanks! The palette swapping is a neat idea.

[msw188]

If using unID'd item-use in battle is necessary (out of battle would be fairly easy, just a lookup table), then yes I agree itemID'ing is the worse of the two. My main issue with item weights is the interface. As I tried to explain before, what do you do when a new item is obtained, but the player is too weighed down to carry it? There must be some simple way for the player to know the weights of all of their items, including equipped ones, and be able to choose which one(s) to throw away to reduce weight properly. The main problem is the following:

The OHR does not support trashing less than a full group of items. Thus, if the player has ten potions, and realizes that he needs to throw away three of them, how do we give him the option of doing this?

There are other smaller problems, like how to handle item acquisition in general. If the item comes form an NPC, we could simply have text tell the player how overweighed he is, and let him do what he has to separately before activating the NPC again. But what about an item given through a battle, or a script? What about a shop? I think that this will all be quite difficult, more so than unID'd items would have been but for battles.

[Newbie Newtype]

I have a sneaking suspicion it might be easier to just try and convince James to increase the number of items we can create to 1024 or something, that way we can create different versions that are cursed and such.

Also, for the pet animations, is it okay for me to be lazy? I found the kitten hard to animate, so I didn't really make "hurt" or "weak" frames for it.

[msw188]

Here is an idea. What if you treat equipment separate from items somehow? As in, the OHR item menu is used for items only, and there are only up to 128 of these and we use the basic x=item, x+1=unID'd item. Then we use a custom menu for all equipment. This would mean that equipment can not be 'used' in battle, but any regular item can. It will also mean that we can customize the equipping system any way we like (thus incorporating cursed equipment comes as part of the game), and we can handle ID'ing of equipment separately as well. All equipment can just be constants defined in some long list, say in the form equipment:name, and their numerical assignment is just a number for a lookup table. In fact, we can start the numbers above 255 if we want one large lookup table for weights as well.

The only problem I can think of right now is what to do with weapons and how to fool custom into giving the hero the correct attack ID for their standard weapon attack. Maybe we eliminate the standard attack and replace it with something like 'Run away' (this will take up one item to be the hero's 'default weapon') and then we have 'attack' be a random-picking spell menu that we populate before every battle with the relevant attack based on the hero's customized equipment. It will mean that the first option on the menu will be 'Run away' though...

[Mogri]

Like I said, the only really satisfying way to do this is to create your own item system. Battles are the tricky bit, though. How do you deal with item id'ing mid-battle? This makes me think maybe roguelike battling is the way to go.

[Bob the Hamster]

I have a sneaking suspicion it might be easier to just try and convince James to increase the number of items we can create to 1024 or something, that way we can create different versions that are cursed and such..

<a href="http://gilgamesh.hamsterrepublic.com/wi ... imit">Plan for increasing item limit</a>

[msw188]

Plan for increasing item limit

Wow, so much of that is so incredible that I really don't know what to say. Sounds like a pretty long process though. And I'd like to add for both this and the plan for enemy formations, that when deciding how to store stuff, it'd be nice to have it in such a way that it can all be read and maybe altered using plotscripting...

[camdog]

James - I know it's bad form to ask when a feature will be done, but... Would you say it would be a better idea to focus on the other aspects of the game and wait for an inventory code upgrade, or just go ahead without the expectation that it will be done when we are ready for it?

[Mogri]

I'm pretty sure there are enough other things to work on here that you can neglect the inventory for a bit.

[camdog]

Ok, I know we haven't talked about this in a while, but rest assured I've been thinking about it. In fact, I've been mainly thinking about the item identification issue, which is the primary problem that keeps this project from moving forward. I say problem because I've yet to come up with a satisfactory way of doing it. All the ideas mentioned have serious flaws.

The two versions of every item is flawed, not only because it halves the number of available items in the game, but also because there (correct me if I'm wrong) is no way to randomize this. In other words, after one play through, the player will always know what the yellow potion does, which kind of ruins the point.

The idea of writing a custom item management system doesn't work either, since that eliminates the possibility of using unidentified items in battle which, again, kind of ruins the point. The only way around this is to write a custom battle system as well, but if we need to create a custom item management system and a custom battle system, we might as well just write this in C++, so I'm going to nix this idea.

Basically, I think I've concluded that item identification has to go, and the project should move on to other, more realistic pastures. I don't think this will ruin the game, just move the focus onto other things. I recently discovered a flash roguelike (http://www.kongregate.com/games/garin/monsters-den) that has no item identification but is still great, so I think we can make a fun game with out IDing.

Thoughts?

[msw188]

I just wanted to point out that you can give different unID'd items the same name to give the appearance of randomness. Don't know if that will make it too weird when you have several different unID'd, same-name items, though.

[camdog]

Actually, that's not a bad idea, and I can't believe I didn't think of it (I believe it's something the engine can handle, though it may be a touch weird for scripts we create for IDing.) That said, I'm still not convinced it's worth it to halve the amount of different items available.