19 Mar, 2012, Runter wrote in the 41st comment:
Votes: 0
Idealiad said:
Runter said:
I even removed the ability to place items in containers in my game


Was that a typo?


Nope. Instead of having a backpack that you can place 5 items in I had a backpack that you can wear that increases your inventory space by 5 items. There was no put command. Actual containers still existed.. so you can look inside of chests and you can retrieve items from chests. You just couldn't put items into the chest. It's the same way as most MMOs work today wrt containers.
19 Mar, 2012, David Haley wrote in the 42nd comment:
Votes: 0
plamzi said:
I read this post several times and can't say I understand it. Does your game implement bulk+weight-based restrictions on inventory capacity? If so, can players carry more than their own bulk or their own weight? If not, do they get annoyed that they can't carry more than 3-4 swords or more than 1 jam-packed backpack? If players' bulk and weight varies based on race, etc, does their inventory capacity vary also and if so, how does that affect 'fair play'? These are the kinds of questions I find interesting and I think some specific examples will help me understand better.

We toyed with the idea but we decided that we didn't like the more strict realism. But, it is a good approximation if you want to impose such restrictions.

Yes, players can carry more than their own bulk; you can see this yourself by going and picking up a very large but very light object. Some people can pick up more than their own weight but don't really carry that around much. Yes, it was found to be more annoying than interesting for gameplay, and we didn't feel like tweaking it because our game doesn't do much with size anyhow. We decided that we'd revisit it if we had more interesting things happening with size, like player races that are truly different.
As for fair play, here are two things to get you started…
- smaller creatures tend to use smaller items anyhow
- smaller creatures (were we to implement the rest of the ideas that made this relevant) have advantages for being small, like fitting in small places, being harder to hit, etc.

Anyhow, my point was not that bulk+weight is a be-all end-all solution to all problems, but that it is a decent approximation to the very precise problem that I replied to. Whether or not you want that problem in your game in the first place is a different question.
19 Mar, 2012, Deimos wrote in the 43rd comment:
Votes: 0
I think removing the put command and ability to store items in containers is an odd concept. I can see how it would simplify inventory management, but it seems like you miss out on a lot of neat mechanics to gain that simplicity. Like the ability to put things in a bag and hand the bag to another character, vs. handing them each item one at a time. Why not just remove bulk/size/weight/whatever restrictions from the containers and give them a certain # of item slots instead? That sounds pretty close to what you're doing anyway, without removing the put command. I guess the issue there is how to limit nested containers (if you even allow that) since you'd no longer be able to do it based on weigh/size.
19 Mar, 2012, Runter wrote in the 44th comment:
Votes: 0
Deimos said:
I think removing the put command and ability to store items in containers is an odd concept. I can see how it would simplify inventory management, but it seems like you miss out on a lot of neat mechanics to gain that simplicity. Like the ability to put things in a bag and hand the bag to another character, vs. handing them each item one at a time. Why not just remove bulk/size/weight/whatever restrictions from the containers and give them a certain # of item slots instead? That sounds pretty close to what you're doing anyway, without removing the put command. I guess the issue there is how to limit nested containers (if you even allow that) since you'd no longer be able to do it based on weigh/size.


I don't think it's for everyone, but I certainly don't think it's strange. Especially considering a vast majority of RPGs and the most popular MMOs don't use the put command or have any way to place items into containers and hand the container to another player.

Placing items in containers to group them is better done if you can group items in your inventory without the need of containers in the first place. Furthermore, there's practically no difference between having to individually put items in a bag, and individually give the items to another player. In fact, it's one more step if you have to put all these items in a bag. And it circumvents the mechanic if the idea is "if they're in a bag it only counts as one item so i can make sure they get all the items at once."

Containers work well as concepts within the game, though. Like shipping a lot of items to a friend and them receiving them in a box. But that doesn't mean you need a put command to do it. You can simply mail a lot of stuff to another player, and it all appears in one box. So overall I think muds would do well to start reducing the number of commands they have and substantially lower the barrier of entry for new players.

Also I'll add my own anecdotal experience on my mud I ran for 10 years:

I don't remember any player ever complained about never needing to manage containers. I did, however, hear how much more simple it had made things.

One of the reasons I made the change was because my game was largely a PVP game and in the mud I had played in the 90's which was also largely a PVP game there was all sorts of issues surrounding containers and requirements for picking up containers, or things in them. For example, if you were trying to steal an item from another player they would often put a lot of containers of the same name in their inventory with only 1 container that containers their valuables. So as a thief you only get the message "Retnur puts a Valuable Lewt into a bag." You peek in their inventory and you see 25 "a bag" with no idea which one the valuable lewt is in. To balance being able to loot items many reasonable PVP games will limit the number you can take after a victory, or make stealing excessively risky. Like lagging the person for many seconds after an unsuccessful pickpocket. This was just one of the ways that clever players had learned to game the design, so ultimately we just removed the ability to it and instead make the concept of carrying items in bags unrelated to how it's presented to users.
19 Mar, 2012, Deimos wrote in the 45th comment:
Votes: 0
@Runter: I find "put all.fruit bag;give bag newbie" a lot easier than "give apple newbie;give banana newbie;give pear newbie;…".

I can't speak much to the way graphical MMOs are doing things these days, but it doesn't surprise me that they don't have that capability.
19 Mar, 2012, KaVir wrote in the 46th comment:
Votes: 0
Deimos said:
I find "put all.fruit bag;give bag newbie" a lot easier than "give apple newbie;give banana newbie;give pear newbie;…".

And I find "give all.fruit newbie" easier than "put apple bag;put banana bag;put pear bag;give bag newbie".

But a more reasonable comparison would be "put all.fruit bag;give bag newbie" vs "give all.fruit newbie".
19 Mar, 2012, Rarva.Riendf wrote in the 47th comment:
Votes: 0
give all.fruit newbie ?

I allow container for the stealing pvp part (obfuscating where is the item really is as Runter demonstrated), and fighting purpose (items in direct inventory are usable directly, but you have penalties/bonus depending on the action (dodging, bashing) , item in inventory will take more time to be retrieved for use.

I also have a chest you can drop that only you can see (and the key carrier (you can have your key stolen))

But technically a player could play without putting his objects in any container. Only drawbacks to these is he would dodge a little less, and all his items may be vulnarable to fire effects (breath or room effects)

Not having container at all is not a real problem, I just feel it makes suspension of disbielief a little harder.
19 Mar, 2012, Runter wrote in the 48th comment:
Votes: 0
Quote
Not having container at all is not a real problem, I just feel it makes suspension of disbielief a little harder.


I think this is a fair point. There will be people who want a more realistic approach to the gameplay, and will not let it deter presenting players with a more advanced way to configure their inventory at the expensive some learning curve/tedium. My only point is it's not absurd or a step backwards necessarily to try to simplify mechanics if that complexity isn't truly required.
19 Mar, 2012, Deimos wrote in the 49th comment:
Votes: 0
@KaVir: Point taken. I've not run across games that allow you to do that, so I guess it never dawned on me. In retrospect, it seems pretty nonsensical to allow one but not the other.

Another neat mechanic of containers is being able to protect items. Maybe you have some important documents for a quest in your inventory, and the mob you're fighting is casting fireball, which would incinerate them if you don't put them in a fireproof container.

You can also use containers for non-standard stuff like putting shards of a broken orb into the orb until it's "complete" at which point it does something special or whatever.
19 Mar, 2012, quixadhal wrote in the 50th comment:
Votes: 0
Actually, most graphical MMO's don't really make use of the idea of "giving" items at all.

You loot items from your environment, or obtain them as quest rewards. You use them in crafting, equip them, or sell them to a vendor or to other players via the auction hall. You can destroy them by dragging them out of your inventory. When players trade things back and forth outside the auction interface, it usually brings up a double-verify dialog, where each player drags whatever they want to trade into the offer window, and then they both have to click "accept" without changing anything for the trade to happen.

To "give" things to someone, you typically use the trade interface, or send it to them via the mail service.

There's no way to drop items on the ground, or put them back into a corpse, and nobody seems to mind.

In games that have containers (which go in container slots), they're usually just ways to organize stuff into groups. Many games now auto-group things into "virtual bags" by type, eliminating the need to hand-manage where things are. They also usually have search options, so if you have 500 items you can find the swords by searching on "sword" and having those items highlighted.
19 Mar, 2012, Runter wrote in the 51st comment:
Votes: 0
Quote
Another neat mechanic of containers is being able to protect items. Maybe you have some important documents for a quest in your inventory, and the mob you're fighting is casting fireball, which would incinerate them if you don't put them in a fireproof container.

You can also use containers for non-standard stuff like putting shards of a broken orb into the orb until it's "complete" at which point it does something special or whatever.


To the first point, I would reply that it depends on mechanics of your game. Also, I'd argue that the key factor here isn't that the container is a container. It's that it's fireproof. If you didn't have containers maybe you'd have a better solution to this problem. Like making spells not destroy items in inventories… Or allowing players to cast fire ward to protect their inventory from such things. Either way, I never came across this issue because I wouldn't have ever designed the game to require putting items into containers or risk having them destroyed.

To the second point, it sounds like you're using containers for things that aren't actually semantically containers. If I wanted items that could be joined I wouldn't use a container type, or the put command. Cause neither really make sense for joining shards of a broken orb until it's a single item. Makes more sense that any items can be joined if defined by builders, regardless of item type.
20 Mar, 2012, Rarva.Riendf wrote in the 52nd comment:
Votes: 0
Runter said:
Also, I'd argue that the key factor here isn't that the container is a container. It's that it's fireproof.

Indeed, that is how it usually works, easier to fireproof your container than all the items that also could be fireproofed anyway.
(for some you wont bother, like potions you buy in bulk or stuff like that) (oh and better close it as well *grin*)
20 Mar, 2012, Deimos wrote in the 53rd comment:
Votes: 0
@Runter: No, the idea is that you can protect the item from external dangers by removing it from your direct inventory. Fire damage was just my example. The same point can be made with weathering, theft, or whatever. It's also a convenience thing. And sure, you can design a game where inventory is automagically protected, but that removes even more mechanics. If you're shooting for simple and fun, I can see how choices like this might make sense. I tend to enjoy MUDs more than graphical MMOs exactly because they have so much depth and so many facets, though. Different strokes, I guess.

WRT the orb example, I disagree that it doesn't make sense. It makes perfect sense if you consider the important part, which is the interface. Whenever it makes sense to put X in Y, it's fairly sensical that Y be a container. Putting fruit in a basket is no different than putting an eyeball in a skull if you only consider the interface. Sure, a skull doesn't make much sense as a container, but we can hide that from the user. What's important is how the user can interact with it now - using an intuitive, and standard interface. We can even enhance these faux containers by restricting their contents to a certain type (or even a certain item).
06 May, 2012, wifidi wrote in the 54th comment:
Votes: 0
Possibly the most puzzling container in most MUDs is a mobile's stomach. It's possible to quaff potions while full. I suppose the explanation is magic potions take effect via something like instantaneous vaporous absorption. I've enjoyed reading others' elucidating comments on realism and wonder whether MUD design is more about making sure favorite ideas are implemented even at some cost in realism. As a player, I'd be happy to see the message: "Your stomach is full!" after pounding health potions. It also opens the idea of a spell or disease like lockjaw.
I don't mean to improperly compare MUD design, I think "where to stop" is similar to deciding a marching band's style. A military band will never cross a certain line, whereas show bands intentionally exploit some theme. Arguably military is itself a theme. Relevant to the example above, one style of coding would require cure disease to escape lockjaw while another would allow "use a straw", which is cartoony and funny to some people.
Along the lines of what Tyche has mentioned about modular design, any design usually features logic such as now you can, now you can't "x". Fleshing out the appearance of that with words that represent seriousness, silliness or somehow both, is probably an art. If the task of code is simply providing a rational framework for creativity and some are better than others, that betterness is closer to an art than simply being formally bigger or more comprehensive. Knowing the logic tree excites some and disappoints others. On the other hand, allowing strange things is controversial, like defending with a wagon wheel as well as with a supershield, which requires an explanation such as the user is tremendously skilled at shielding. Some pool players can win with a broomhandle. How many? Fewer.
I guess the summary word is 'exceptionality' meant in the technical sense. What exceptions are an intentional Achilles' heel people agree is good game.
07 May, 2012, Rarva.Riendf wrote in the 55th comment:
Votes: 0
'As a player, I'd be happy to see the message: "Your stomach is full!" after pounding health potions. It also opens the idea of a spell or disease like lockjaw. '
Fun one, implemeting it as soon as possible thanks ;p
07 May, 2012, Exodus wrote in the 56th comment:
Votes: 0
Late to the party here, I know. For what it's worth, we implemented inventory restrictions based on common issues we found by analyzing character files. Providing players with features such as clan storage rooms, lockers, personal vaults and the like does help for those that want to remain organized. There will always be players who just want to keep everything on them. Maybe they're concerned with the safety of those items, the convenience of having everything readily at hand or maybe they're just lazy.

We decided to just focus on the two main problems that went against the semi-realistic design we wanted and how players actually functioned. The first was money. People carried a metric ton of gold. This was something that was just silly and people didn't even seem to mind thieves that stole percentages of the gold on their character; even if it was 10% of the million gold they carried. We ended up creating a full monetary system (copper, electrum, silver, gold, platinum coins with values respective of the base currency). We then limited the number of coins one could carry in their 'wallet' ala Legend of Zelda. The wallet size was of course upgradable, but it was interesting to see that people could carry say, 500 coins in copper and have $500, or carry 500 platinum coins and have $250,000 or any combination thereof.

The container/inventory thing is another issue. We decided to do away with traditional 'magical' containers that allowed you to carry infinite items of any size or weight. Instead, these exist, but only dissipate weight. Supremely enchanted containers may mitigate weight up to 99%, however, they are not of an infinite size. Other containers are not of an infinite size, but allow holding several times their volume worth of contents with the catch that it must fit in the bag first. None of that I'll store this catapult in my bag of holding nonsense.

It's worked decently so far but I'm sure there's room to improve. YMMV.
24 May, 2012, Nathan wrote in the 57th comment:
Votes: 0
If you have a list style inventory You could just have transparent containers in the sense that you can put stuff in, but everything shows up in the list anyway (and is equally accessible regardless). The containers simply function as some structural organization.

Only thing is you'd probably want to implement some filtering in the inv command, say

'inv <word or regular expression>'

Where 'inv sword' might get you anything called sword, with sword in it's name, or with sword as some kind of type. So it would be
able to find and display a 'sword', a 'longsword' or a 'shortsword', or a 'scimitar' (which is a kind of sword).

—-
Also, in a mud server i'm writing (Java), rather primitive at the moment, part of the inheritance hierarchy is like this:

MUDObject
Player -> NPC -> ArmorMerchant
-> WeaponMerchant
Item -> Armor
-> Weapon


I think it's really important to define what can or can't be done with it. I use to have it be Thing->Item but that added another layer of inheritance in between (it gets messier with each layer). I've since settled, at least conceptually on things not being able to go into your inventory (i.e. stuff like tables, chairs, that kind of stuff) and items being stuff that does go into your inventory (armor, potions, wands, weapons, clothes, etc). Things also implicitly might be carry-able or breakable into items (not implemented), but that distinction helps to keep things tidier on a coding level and doesn't over complicate inheritance. Unfortunately with this system, unless I want to rework it and burden every item with a property table of some kind, I have to deal with broad classes of things. I don't have a class for it yet, but Sword would have to be a class that encompasses a lot of things (longswords, shortshords, broadswords, scimitars, rapiers). This kind of system though makes it extremely hard to make the object a set of parts, which is itself a pretty cool idea. NPC too, I wanted NPC to be have basically the same
possible variables/attributes as players.
24 May, 2012, Deimos wrote in the 58th comment:
Votes: 0
Just curious, but why not have size/weight be the limiting factors for being able to hold things in your inventory? That removes a layer from your hierarchy and makes more sense conceptually (to me, at least). Bad example, but what if you wanted a giant ogre to be able to have a log in his inventory, but not a halfling? Using your method, neither would be allowed, or both, depending on what the log is. Just food for thought.
25 May, 2012, Nathan wrote in the 59th comment:
Votes: 0
In the current system, the halfling wouldn't go in the inventory, because it's actually a player or NPC. Why would that fit in an inventory? I think I see your point, but i'm not sure I want that right now, although the argument is certainly valid to a point. I'm not sure it the log would be a Ghing; a tree might be if I needed to actually have an actual tree object.

The problem I had before was I had to make an extra check to see if a thing was an item, before I could treat it like an item. Also, since items show up in a list if they are on the floor, the distinction is important because I'm thinking about trying to find a way to not put things there, but only show them in the room description.

To be fair, only a small part of my code was written with an actual specific design intent, as opposed to haphazardly, so it's kind of in flux. An example of actual design
is that my text based database is a bunch of lines describing objects, like this:

4#Red Dragon Inn#RS#A cheerful, brightly lit inn with a place to sit and eat, the rooms being upstairs.#0#I

where the structure is:

database reference number / name / flags / description / location (of the room in this case) / room type

Those first five are intentionally in the same order for everything. Plenty of things were coded as I went along. Navigation used to be modifying the number for the player's location by say -1 or some other number, and that was bad because it would have assumed db structure followed room layout which it didn't. It was briefly something close to n/s/e/w, but I prefer a more MU*-esque exit style with any number of named exits.
25 May, 2012, KaVir wrote in the 60th comment:
Votes: 0
Nathan said:
In the current system, the halfling wouldn't go in the inventory, because it's actually a player or NPC. Why would that fit in an inventory?

Shouldn't that be a matter of size and weight, rather than the fact it's a player or NPC?

Or to put it another way: Why should you be able to pick up a dead halfling, but not a living one?

There are few things as pleasant as sitting around an open fire on a clear night, sharing a lightly toasted player with your admin team.

You get Meto from the paved street.

You take a bite out of Meto and start chewing.

You offer to give Alayla Meto.

You swallow your mouthful of food.

Alayla chuckles politely.

Alayla takes Meto from you.

Alayla takes a bite out of Meto and starts chewing.

Alayla swallows her mouthful of food.

Alayla offers to give Jobo Meto.

Jobo takes Meto from Alayla.

Jobo takes a bite out of Meto and starts chewing.

Jobo swallows his mouthful of food.
40.0/65