20 Jun, 2014, jakesmokes wrote in the 21st comment:
Votes: 0
Nathan said:
If you use a language like Java (or perhaps C++), I think it's important to this flexibility concept that you make some use of
You might get more useful opinions if you choose some aspect and present what you want it to do so that there is a concrete issue to deal with. Abstraction is great, but too much design in search of a problem is a dangerous thing. The lighting topic seemed like an okay point to work around, but what it will be used for is important in how you set up such a system.

Emergent behavior (i.e. unintended or alternate actions/consequences) such as breaking down a door instead of picking the lock or finding the key is entirely absent when the system is not designed to handle anything but one particular solution/approach. Those sorts of things can make a game a lot of fun if they are allowed for.


Hi Nathan,

Thanks for the feedback. I do think that I was asking about something specific and that was how to design for the type of emergent behavior you were saying was desirable. It seems to me that the essence of the design of certain systems, objects in particular, can lend themselves more or less to that emergent behavior. If I write a bunch of code to make torches illuminate a room and then I decide to make any object be able to do illuminate a room (even objects of completely different types) by way of a "light" spell (classic D&D) then I would have to write more code to expand the notion of what objects could server as illuminators. But if I can make an object illuminate a room simply by adding the right behavior to the object then I am done. Its a data change.

I probably obsess a bit about it because.. well.. when you are trying something new there is the danger its going to totally hork your system and cause undesirable steps. I am not at all for "over designing" but when trying a paradigm that is new I feel like its worthwhile to test it, if possible, before implanting the code.

But you hit the nail on the head better than I. That is what I think the goal is.. emergent behavior. Well said.

David
20 Jun, 2014, Oliver wrote in the 22nd comment:
Votes: 0
jakesmokes said:
Thanks for chiming in Oliver. I think the motivation (for me) for making a flexible / extensible system is to

a. Make it easier to extend the game. Intuitively, it seems like a system that is more abstract and less "hard-code" allows for easier additions of new concepts to the game. And it might make it easier to simulate a "self-modifying" element to it. I might be wrong, that's just my sense.

b. Make a more enjoyable game. In some games I have played doors, for example, weren't really objects. You couldn't break them down, take them off their hinges, etc. You might see a description noting the presence of a door with a certain set of attributes and then when you go to touch it or part of it, "I can't see that here". Granted, I haven't played a mud in 20 years and it sounds like the technology has come a long way. It just seems to me that an abstracted object model composed of behaviors or building blocks that can individually be interacted with (to some degree) would lend to a greater sense of realism in the game. It could never be perfect, its just a goal. And there is, probably, also a satisfaction that comes from making an certain kind of design.

David


I mean, I get that, but from the standpoint of the player the mechanics behind the curtain mean nothing. Making doors destructible is not challenging in stock RoM; moreover, if you use a highly classed model, you're going to still have to hard code in the same sort of things (taking items off their hinges), they'll just have a larger number of use cases. But let's stop for a moment and consider how often players encounter that sort of a situation (doors and chests are the only likely relevant examples); is a "hinged" flag with some hard-coded behavior adequate? Your answer seems to be "no," I think "yes." I mean that as an observation, not an argument.

If your game is meant to be a sandbox, yours would be a preferable way to do things. If it's meant to be a more classical world, I don't think you'll reap too much in terms of utility.
20 Jun, 2014, Nathan wrote in the 23rd comment:
Votes: 0
I guess it would depend on what kind of game you hope to make. There's no point in sticking with stock RoM unless you like the way their areas, etc are done already… and/or want to mimic that.

I think that if I wanted to do off the hings for doors I'd make it just 'dismantleable' or something in general and work on finding a way to describe/create the effects and results of doing so. Dismantling a door would potentially produce a door object and make the exit freely passable, dismantling, say, a bookshelf would give me panels of wood (ostensibly top/bottom, shelves, and end pieces) possibly with varying length. The only real problem I see is that you shouldn't make anything that way unless there is a specific reason to (like removing an obstacle) and should weigh "breaking" vs some other more precise action as to what will produce the desired gameplay in an efficient manner. There is no point in polluting your game database (supposing some persistence) with piles of wood and screws (and so on…) that are merely flavor and can't be reused for something else. Also, people who just want to get through are probably going to settle for smashing X to bits if they can and realize that it is possible to do so.

Unless you make a very interesting codebase, a lot of hardcode is likely to exist and maybe some basic softcode. Recreating something like what LPC/LPMud (if I understand correctly) has is not easy.

You don't need a sandbox game in order to realize benefits from the ability to destroy doors by smashing them or incinerating them with fire instead of using a key. Of course, if there are zero gameplay consequences/reactions (besides easier entrance) of doing so then why implement such functionality? Sometimes you need an impassable door (in the former case you might need a reinforced steel door to prevent most players from getting through w/o a key). You also probably want to consider making it so mobs will follow you easily if there is a clear route (i.e. you removed all the doors between point A and point B), and so that doors left unlocked stay that way to encourage you to lock doors behind you, etc.
20 Jun, 2014, plamzi wrote in the 24th comment:
Votes: 0
jakesmokes said:
Emergent behavior (i.e. unintended or alternate actions/consequences) such as breaking down a door instead of picking the lock or finding the key is entirely absent when the system is not designed to handle anything but one particular solution/approach. Those sorts of things can make a game a lot of fun if they are allowed for.


I haven't really played any games where unintended consequences produced anything other than bugs or immediate dis-balance. My sense as a game designer is that for every lucky incident where someone discovers an alternate way to get something done and the result is fun without harm, there will be dozes of flavors of the same incident that will be not at all desirable.

As a power player I can say that as soon as I figure out that I can break a door in a way that even the devs didn't know was possible, I'm going to start trying to break: already open exits (just to see what happens), shopkeepers and other special mobiles (in case there's an unlimited-something bug), rival players (mwahaha), rival players' worn eq (just to see you cry), etc. And if I succeed in any of these, I'll have a lot of fun watching the devs cringe in horror and figure out the fastest way to lock things down.

To me, designing for desirable emergent behavior only seems to be so close to impossible that it is surely impractical. It feels like a coder's pipe dream: design a game where players can do "anything" without you having to think it through and code it ahead of them and test to see if it fits in the game.

If you are writing a codebase / engine and you want to do better than those before you, the unfortunate answer is that you'll have to put in more work than them, not less. You would want your design to be abstract, modular, and extendable, yes, but also filled with examples of how to code a wide range of game logic rules within your framework. It's far too easy to say, "I don't want to code a combat system because I want adopters to be able to code their own." If you've worked hard to make a variety of combat systems possible, let's say by providing a more abstract framework for "one entity damages another", now you also have to work hard to provide at least one example of how your framework can be used to easily create a functional combat system.

20 Jun, 2014, Nathan wrote in the 25th comment:
Votes: 0
Well, they wouldn't really be completely unintended, it's more like games where you use skills in conversation and there are opportunities to achieve similar results with different skills. The aim is still to get past the door or some other obstacle, you just are dispensing with the notion that the only way through a locked door is a key. The trick I suppose is to create a wide enough variety of possibilities and combinations thereof that the player feels as though "the sky is the limit" is actually true.

I wouldn't actually make npcs or mobs -dismantleable-, for one they really aren't meant to come apart (there's combat, but whatever…). The best solution to wanton destruction is to make the game itself deal with it. It'd be an insane amount work probably, but if there's someone in town just breaking stuff I imagine that it would make sense to have guards that would put a stop to such and drag the player off (to jail, or maybe just to kill him). If that wasn't enough, then you find some way for other players to deal with him/her. And if that still doesn't work you proceed to deities and other entities that could conceivably exist and then follow up that top-down banning, etc. Hopefully the first stage deals with the problem.

If I could create a working combat system I probably would have by now. As it is I, at least, have a bunch of half finished work that isn't well integrated. It would have been easier if I'd tried making a single player game first instead of a codebase for a multiplayer one. Something tells me someone looking to take advantage of an existing codebase probably doesn't have the time or energy to create their own combat system unless all the little bits that they need to hook into are already prepared. After all, they did already excuse themselves from making the codebase…
23 Jun, 2014, Tyche wrote in the 26th comment:
Votes: 0
I ran across this interesting and insightful paper Open, extensible object models.
Of particular interest, to this thread, is the implementation of "traits" in the model discussed in the paper.
25 Jun, 2014, jakesmokes wrote in the 27th comment:
Votes: 0
Thanks for all the comments. There is a wealth of knowledge here.

To be clear, I am not looking for create something totally random, throw a bunch of components together and see what happens. I am not at all afraid to put in work or to write code. That's what I do seven days a week :-). Well, when my girlfriend doesn't get pissy. I think what my motivation is is to make something which feels like anything can happen not something, necessarily, where it actually would. If that makes sense. I fully realize that what I am after may be completely impossible. Software development is rife with compromise. No biggie, I am enjoying the process.

I do think that having an extensible object model would, at the very least, make things easier to extend to include new features / concepts in a game. I've settled on an organization for objects / behaviors that seems like it will work well, make descriptions easy to deal with, timed events, etc. We'll see how it goes. Learned something interesting today.. I've been speaking english for over 40 years and I just learned today that there are actual rules which determine ordering of adjective when describing a noun. I never knew that. My object describer was printing out things like "long rusty sword" instead of "rusty long sword". I guess if I am still solving those types of issues, "emergent behavior" is probably a ways off :-)

Thanks for all the help,

David
25 Jun, 2014, Oliver wrote in the 28th comment:
Votes: 0
jakesmokes said:
I've been speaking english for over 40 years and I just learned today that there are actual rules which determine ordering of adjective when describing a noun. I never knew that. My object describer was printing out things like "long rusty sword" instead of "rusty long sword".


There's nothing grammatically wrong with describing a sword as a "long rusty sword." If you wanted to convey that the object in question was a "long sword" it would be better to use the phrase "longsword" or "long-sword", as this is generally how adjectives intrinsic to the noun are handled in English/German. That said, the reason a longsword is called a "longsword" is indeed because at one point it was described as a "long sword," in which case there's nothing amiss with saying "long rusty sword."

I could be wrong, but I don't believe there are rules as to which adjective to place first; the logical rule would be to place adjectives in the order in which you generally intend to funnel information (which in MUD settings would generally be broad->narrow).
26 Jun, 2014, jakesmokes wrote in the 29th comment:
Votes: 0
My example was probably not a good one. They have better ones on this site:

http://english.stackexchange.com/questio...

You are right, of course, that there are no specific grammatical rules to specify adjective ordering. But, as they say in related articles, some formations just sound "more correct" than others. More natural sounding. I agree, calling it a longsword would solve the issue that I gave. But then you have to deal with someone seeing a longsword lying on the ground and typing:

> Take sword

And getting "I don't see a sword here."

Which can be solved by implementing synonyms (which I am working on also). I do prefer "rusty long sword" over "long rusty sword" though. I am not an english major, but, to me, it seems like its breaking the typing of the sword from being a "longsword" to just being a sword that happens to be long. It was an easy fix to make (though somewhat arduous) to just tag all my adjectives with a type and sorting on that type when describing an object.

Not a huge deal, I just found it interesting.
26 Jun, 2014, jakesmokes wrote in the 30th comment:
Votes: 0
Also, I am not trying to enforce proper entry of adjectives more just trying to make the descriptions being generated more like actual prose.
20.0/30