Roguelike RPG in the OHR?

[msw188]

Well, do as you wish, but my guess is that you won't need more than 128 items to begin working on the game, and by the time the game needs more than that, hopefully the item limit will be lifted. But this is all looked out from the point of view of someone who works on his game for maybe a few months, and then lets it sit for a few months, and then works on it again (there's a reason my first game took six years to complete). And I've also put my game on hold for weeks and even months at a time waiting for a bugfix or new feature. So maybe my view on it is somewhat different than yours.

PS: One thing that might be helpful scripting-wise is to define your own constants in the style of the hsi constants for the unID'd items. So, even though custom will only export the final instance of item:unknown, you could define your own item:unIDmedicine in your script file.

[Mogri]

The one disadvantage to the proposed method is that autosorting your items will give you an indication as to which is which. Granted, this is the kind of thing you'd need a lot of experimentation to do, but once you've figured out, for example, that the potion of sickness is the last one in the order, you'll avoid drinking the last potion on your list.

It's still your best way to go if you want to have usable unid'd potions.

[camdog]

It will still stack them too, won't it? You're inventory might end up looking like:

2 Potions
3 Potions
1 Potion

And, of course, IDing one potion will have the same effect as IDing the whole stack.

[msw188]

To Camdog:
Yes, I believe that this seems right. After all, if you have a bunch of the same unID'd potion, and you identify one, you now know what they all do, right? Or shouldn't it be this way?

To Mogri:
I don't understand what you mean. Autosorting does not put items in order by ID number, it just puts usable items ahead of unusable ones, I'm 90% sure.

[msw188]

How has this been going? Any progress? Any definite plans on what stays and what goes? I haven't yet heard of a satisfactory interface for the player acquiring items that exceed his weight limit, and I'm not sure how satisfied Camdog was with halving the available items to incorporate item IDing.

[camdog]

Well, real life has admittedly been getting in the way of my OHR projects lately, but rest assured this is still in the back of my head. Since you bring it up however, I might as well go ahead and make some executive decisions based on what we've discussed, and hopefully when we have the ground rules hammered out people can begin to contribute. So, here goes...

IDing items: Ok, this is going to be controversial, but I think we should ditch this entirely. I have yet to hear a satisfactory solution to this problem that doesn't involve rewriting the item handling stuff entirely. Multiple versions of each item halves our available items, and the stacking problem (which I mentioned a few posts above) makes it seem hackish. Likewise, taking un-IDed items out of the usable inventory until they've been IDed through plotscripting wizardry eliminates the possibility of using them before identification, which takes out a lot of the fun. I think this issue has been the major hang up for the project, and I don't want to just stay caught here. Further, I think the game will be fun without it if we concentrate on the other aspects of the gameplay, even if it is throwing out a traditional part of roguelike gaming. In fact, I've been playing a game called Monster's Den lately, which is a neat dungeon crawl that has no item identification, and it doesn't seem to suffer to much by not having it.

Item Weight: I think we can solve this problem by creating a lookup table for item weights, and a function that tallies weight. If we call the tally function every time a player acquires an item(s), if he exceeds the weight limit we can display a message that says he's carrying too much, send him to the item screen to drop items, and loop it until the weight drops back under the limit. It would probably look something like this (in pseudo code):

Code: Select all

function getWeight(itemId) {
  switch (itemId) {
    case (1): return 2;
    case (2): return 8;
    //etc
  }
}

function tallyWeight() {
  var totalWeight := 0;

  foreach(itemInInventory as item) {
    totalWeight += getWeight(item);
  }

  return totalWeight;
}

function callOnAcquireItem() {
  while (tallyWeight() > MAX_WEIGHT) {
    show text box(TOO_MUCH_WEIGHT_MESSAGE);
    show menu(item screen);
  }
}

Monster Encounters - I think we should keep this as random encounters in the default engine, because it's easier that way and allows us to use all that nice pre-built battle stuff the OHR has. This will also give the game a different tactical flavor than most other roguelikes.

Map/Item Generation - I think Moogle's idea to keep randomly generated levels (as opposed to creating a new one at each level change) works well. This will keep people from item farming around a stairwell, and make it easy for contributors to create special levels (by allowing them to draw a special level on the appropriate map in custom, and then adding that map number to a special map lookup table, so the script knows not to put a random map over top of the pre-made one).

So, my current goal isto create some documentation for contributors to do things like add new quests/items/monsters. This will probably be me moving all the lookup tables to a separate plotscript file and including a readme that will describe where to put information in addition to the stuff you add to custom. (ie, when you create a new enemy in custom, include the levels it appears on and the frequency in X lookup table...) I also need to add a specific mechanism for creating quests (and if anyone has an idea of what that might look like, please mention it). Another thing that can be worked on is the development of the town above the dungeon, and possibly even more extra-dungeon areas.

Does this sound acceptable to everyone?

[Bob the Hamster]

I have interest in eventually adding some form of roguelike item-identification as a built-in feature of the OHR's item system.

If such a feature existed, how would want it to work? Your ideas can help me plan it.

[msw188]

I'm sorry to keep being the negativity source for the item weights, but I still don't understand how that will work right. If we are just sending the player to the standard item-drop screen, how will he know what weights his items are? How will he discard currently equipped equipment, instead of items? Most importantly, how will he only discard 1 of his 2 Super-Duper-Elixir-ma-jig's?

Perhaps we need a separate 'Item Discard' menu to handle these problems, which is only accessed any time the weight tally is called and the max weight is exceeded. This way we can keep the standard item setup, and then the only difficult part is maintaining this menu on the fly.

[camdog]

James:
I suppose for built in IDing, you'd need to have an unidentified name as well as an identified name (such as, unidentified - "potion", identified - "bottle of salt water"), and then not group the unidentified items. That may cause a problem with a limits on the item screen, but perhaps that could simply be expanded? Each item could have a flag for "needs IDing" that defaults to off. Perhaps then you could have text boxes with an option to id an item, right next to the "use textbox x immediately after" and other options, since items and spells can already link to text boxes, and that would allow story events to trigger IDing as well.

It might be neat for items with the same un-IDed name to prepend an adjective selected randomly from a user-defined pool, the way most roguelikes do with potions (ie, a murky potion IDs to something different in every game).

msw:
Ugh, yeah. You're totally right. That's what I get for making up answers off the top of my head. I suppose we could include weight values in item titles, as it "Copper Sword (11.4 kg)", although we don't have many characters in item names to begin with, so we'd probably have to do severe abbreviation for that to work. I also totally forgot that the OHR only lets you drop whole stacks of items, not one at a time.

Still, I think plotscripting our way around this is more doable than the item ID problem. However, and I don't mean to be lazy here but, would it be so bad if we forgot about the weight thing as well?

[msw188]

Well, the more I think about it, the item-dropping menu might not be too bad. I have a pretty similar thing in Tales II going on, so I can help get the script started I think. The only problem I foresee is:
How many choices can a custom menu have? We would need as many as the number of slots in the inventory, plus five more for equipment.

We can show the weight in this menu without having to put it in the item's name. The regular item menu doesn't really need item weights visible, does it? There could be a new menu choice in the Main Menu called "Show weight distribution", or something like that, that calls a simple menu that simply shows what all of the player's currently held items weigh, and his weight total.

Or is all of this more of a hassle than it is worth? Again, I don't know how much this really contributes to the gameplay of a roguelike, but I considered limiting the inventory important enough to write a serious amount of scripting for Tales II.

[Calehay]

How many choices can a custom menu have?

20. (Well, 21, but strange things happen, but I'm not sure if they affect gameplay.) I learned that the hard way. (If you try to make too many, the "New Item" option will disappear, and if you select the Blank space in it's place, it starts changing bitsets and the color of the menu. I'm assuming this is a bug, so I'll probably try reproducing it and finding out what exactly happens and report it.)

[camdog]

Or is all of this more of a hassle than it is worth? Again, I don't know how much this really contributes to the gameplay of a roguelike, but I considered limiting the inventory important enough to write a serious amount of scripting for Tales II.

Well, I suppose the thing we need to ask ourselves is: what exactly do we want in the gameplay? I have no problem departing from normal roguelike conventions as long as the end product remains fun. As far as the IDing goes, I think the idea behind that is the player will have fun experimenting with unknown materials, but I've really considered that aspect more of a pain in the slime anyway, and considering how hard it would be to implement, I have no problem dropping it.

The weight issue is actually (to me) a little more important, since it forces the player to strategize about items they use (ie should I drop the ring with poison resistance, or the one that gives +15 to strength?). Therefore, I do think it could be worth it to put the time in for this feature, though there is so much else we could with the project that I could definitely see it being fun without a weight limit too.

So... could you maybe describe the script you are using for Tales II? If we could easily appropriate it, I think that would be ideal. Limiting it by weight isn't necessary; limiting it by item number would serve the same gameplay purpose (not to mention it would be easier to put together).

[msw188]

Well, the original goal of Tales II was to make sure that different heroes had their own item menues. This led to using custom menues for all items, and the standard item system is not used at all by the player. The limit for each hero is eight items, because I used level-MP spell-lists for their items in battle (and there are only eight levels of level-MP). There is a complicated system of scripts that handles everything about items including storing them (all items owned are stored in global variables), letting the player equip them via the normal equip menu (the items are defined normally in custom, it is only the item MENU that is not used), letting the player discard them, and worst of all, letting the player acquire new items. I really don't think we can use any of my scripts, but you can look at them in the Tales II folder if you download my game (I included everything for backup purposes when I zipped the game and uploaded it here).

However, my experience with writing these scripts makes me believe that we can handle the weighting system, the more I think about it. Basically, all items have a weight and this is stored in a big lookup table, as you described. The main menu uses the standard item menu, because the player should never have a reason to worry about weight when he calls the menu himself. He can't ACQUIRE items by using the menu (I hope). Instead, we need an item acquisition script that will look something like this in very-pseudo code:

Code: Select all

save the state of the inventory using globals, as well as equipment
variable(I) #"I" will be the item acquired
variable(curWeight, Iweight)
I:=argument #this script should be sent an argument with the item ID
curWeight:=get hero's total weight #using your script
Iweight:= get item weight(I)
while(curWeight+Iweight>>MAX_WEIGHT),then
 begin
  text box (TOO HEAVY)
  open menu (menu:item discard)
  populate item menu #this script will be described below
  wait for player to choose what item to discard from this menu
  if(player chose cancel from the item discard menu),then
   (reset the inventory and equipment to its original state, exit script)
  curWeight:=get hero's total weight
 end

The populate item menu script will go through the possible items via a 'for' loop and, put the names of all items owned as choices in the item discard menu. This menu, in custom, will look like:

ITEM DISCARD MENU
Cancel (will set a tag to tell the previous script to cancel)
More... (will send to a new menu with more items, allowing us to hold more than 20 items)
blank (set to call a script that deletes an item)
blank (set to call a script that deletes an item)
...

The blanks will have their names set by the script that populates the item menu. All that this script does is set the captions in those blank placeholders. It can put the item name in, as well as how many are owned, as well as the weight, and perhaps also a mark to designate an equipped item. It will also need some global work to keep track of what itemID was the last to fit in the twenty spaces provided (17 actually, since the first three spaces are filled), so that if the player picks "More..." then all it has to do is recall this menu and recall this script and have its for loop start from the latest itemID. This global should be reset, I suppose, in the original item acquisition script above.

The script that deletes the item will be quite simple; it asks how many the player wants to delete, accepts player numerical input, and deletes items accordingly. It will also have to do various cleanup work like closing any open menues, resetting the global that keeps track of the for loop, and maybe other things I'm not thinking of now. Then when it is over the player's total weight is recalculated and the while condition in the original script is re-tested.

This will easily handle any item acquisition from NPCs or story, I believe. Are there shops in Rogue-likes? They would have to be handled a little separately, I think. Item acquisition from battle is the tough part. Probably we'd have to do something like:

Code: Select all

#before battle
save state of inventory in globals
fight formation
if(get current weight >> MAX_WEIGHT),then
  go through saved inventory globals to discover what was acquired
  store the newly acquired items in var's, then DELETE them
  go through the new items one by one, using the item acquisition script above 
end

This should remove any item gains from battle and treat them outside of battle like they were given by an NPC, I think.

So, does this sound like something you would be interested in? I volunteer myself to help write the scripts involved, but it will take coordination between the scripts and the menues and custom to make it work.

Of course, if anyone else has better ideas about this, do share.

PS: Just remembered something else. Are there required items in Roguelikes? I hope not. That was one of the worst parts about putting my system together.

[Bob the Hamster]

How many choices can a custom menu have?

20. (Well, 21, but strange things happen, but I'm not sure if they affect gameplay.) I learned that the hard way. (If you try to make too many, the "New Item" option will disappear, and if you select the Blank space in it's place, it starts changing bitsets and the color of the menu. I'm assuming this is a bug, so I'll probably try reproducing it and finding out what exactly happens and report it.)

Yes, bugzilla wants to know :)

The "New Item" thing is supposed to disappear when the menu is full, but the other stuff you describe does definitely sound like a bug.

[Mogri]

Psst... 32000 items...