15 Feb, 2010, JohnnyStarr wrote in the 1st comment:
Votes: 0
After working with codebases that derive from Diku, I've realized how little the application
and game logic are separated. In fact, comm.c is one of the worst offenders IMO; calculating character
damage and violence output should be completely separate from socket I/O. Now that my Ruby project is
coming along nicely, I've made an effort to write as little game logic in my server code as possible. This way, if anyone wanted to use the code to write a completely different genre of game, they would only have to change the mudlib code. However, I have found as I venture into this mindset, I realize that a muddriver might be the better choice. What do you think? Is it worth the extra effort? Are there any draw backs?
15 Feb, 2010, David Haley wrote in the 2nd comment:
Votes: 0
There are always ups and downs to separating this stuff. The more you separate it, the more generic your "driver" becomes, to the extent that you're almost writing a purpose-agnostic platform rather than a game driver. You can end up with something so generic, that you still have the entire game to write on top of it. The less you separate it, the more assumptions you hard-code into your core logic, with very basic assumptions becoming more and more difficult to change. These assumptions can be with respect to game physics (what kinds of things exist, how they can interact, do they have coordinates or do they exist in rooms, etc.) or game design (how many levels are there, are there classes in the first place, etc.).

Now there are obviously some pretty weird combinations, like riddling the socket logic with game logic. Not doing this is just basic encapsulation and good practice. But properly separating functionality isn't really the same thing as fully separating the game engine from the game logic.

Basically I think it is reasonable to define a set of game physics, and then have the game logic implemented separately (think: what skills actually do vs. whether or not they exist). I don't think that, in practice, people will often write completely different games on top of a given codebase (e.g., remove the room-based setup and put in coordinates instead), so the cost/benefit payoff is probably weighted towards "get it done" rather than "make a completely generic game platform on top of which anybody can write a game from scratch".

My inclination is to write things cleanly, using good software design practices, writing reusable code as much as possible. If I can very cleanly separate game engine from game logic, I do that too, but I view it as a far more considerable priority to actually finish things (without sacrificing code quality) rather than to try to make a generic runtime environment for any MUD that somebody might want to write.
15 Feb, 2010, Asylumius wrote in the 3rd comment:
Votes: 0
David Haley said:
My inclination is to write things cleanly, using good software design practices, writing reusable code as much as possible. If I can very cleanly separate game engine from game logic, I do that too, but I view it as a far more considerable priority to actually finish things (without sacrificing code quality) rather than to try to make a generic runtime environment for any MUD that somebody might want to write.


I'll echo this, pretty much. I've never written MUD code for the specific purpose of releasing it and/or using the "engine" to run multiple games, so I've never really bothered to separate the low level stuff from the game mechanics or anything like that.

Writing clean, reusable, easy-to-understand code aside, I think the degree to which components are separated and even their basic design depends entirely on what level of configuration you're looking for.

If I were to start coding a MUD again for me I would probably not worry too much about this stuff since my preferences aren't likely to change and I would be more concerned with getting a quality, playable game up and running than designing and coding a "MUD engine" that could be easily extended to create a near infinite number of styles of game.

PS: I might go out of my way to make certain aspects of my game extensible (like prog scripting), but over all, I wouldn't be worried about making it flexible enough to do things that I know I would never want, just because I know someone else might want to.
15 Feb, 2010, donky wrote in the 4th comment:
Votes: 0
JohnnyStarr said:
However, I have found as I venture into this mindset, I realize that a muddriver might be the better choice.

Why do you say that?

JohnnyStarr said:
What do you think? Is it worth the extra effort? Are there any draw backs?

I have been writing custom MUD code bases on and off since 1995. Writing your own code base isn't just a practical endeavour that allows you to "write things cleanly, using good software design practices, writing reusable code as much as possible", it is also an inspirational process. I find it inspires ideas for both how the non-game logic can allow for better game logic to be written above it. It inspires ideas in what the game logic might do. And you know the code base from the ground up, the design decisions and the reasons things are the way they are (given that you remember).

Because a large part of the enjoyment for me is designing those systems and experimenting with what is possible, and what could possibly be done, it is worth it for me. The primary drawback is that you have to be self-motivated as it takes a lot of time to develop something like this in your spare time.

I've worked a lot with LP code bases, including rebuilding them from the ground up. LP is a wonderfully impressive driver to have to work with, and we were lucky (and still are) to have it. But it provides a closed environment for you to develop within and works in the way it was designed. These are limitations which get in the way and constrain the possibilities of what you can do.
15 Feb, 2010, Lyanic wrote in the 5th comment:
Votes: 0
Asylumius said:
David Haley said:
My inclination is to write things cleanly, using good software design practices, writing reusable code as much as possible. If I can very cleanly separate game engine from game logic, I do that too, but I view it as a far more considerable priority to actually finish things (without sacrificing code quality) rather than to try to make a generic runtime environment for any MUD that somebody might want to write.


I'll echo this, pretty much.

Third. It really just depends on if you want to release it or not. However, as soon as someone starts writing an actual game in it, whether that is you or someone else, you're going to run into certain scenarios where it is impossible to implement some desired functionality without integrating it into the lower level stuff.

Here's an example I came up with a while back: You want to implement a playable multi-headed hydra/demon/etc, such that different players can connect to and take control of the different heads. This is obviously going to require mixing some game logic in at the lower levels - possibly even modifying the socket logic.
15 Feb, 2010, Cratylus wrote in the 6th comment:
Votes: 0
Lyanic said:
Here's an example I came up with a while back: You want to implement a playable multi-headed hydra/demon/etc, such that different players can connect to and take control of the different heads. This is obviously going to require mixing some game logic in at the lower levels - possibly even modifying the socket logic.


No.
15 Feb, 2010, Lyanic wrote in the 7th comment:
Votes: 0
Cratylus said:
Lyanic said:
Here's an example I came up with a while back: You want to implement a playable multi-headed hydra/demon/etc, such that different players can connect to and take control of the different heads. This is obviously going to require mixing some game logic in at the lower levels - possibly even modifying the socket logic.


No.

Are you objecting to the idea, or the notion of mixing game logic with the socket logic? If the latter, note the use of the word 'possibly'.
15 Feb, 2010, KaVir wrote in the 8th comment:
Votes: 0
I believe he may be objecting to the suggestion that game logic needs to be mixed in at the lower levels. Allowing multiple players to jointly control a multi-headed hydra or demon would definitely require low level support, but such functionality could be made generic, and wouldn't need to be tied in with the actual game logic.
15 Feb, 2010, Cratylus wrote in the 9th comment:
Votes: 0
KaVir said:
I believe he may be objecting to the suggestion that game logic needs to be mixed in at the lower levels. Allowing multiple players to jointly control a multi-headed hydra or demon would definitely require low level support, but such functionality could be made generic, and wouldn't need to be tied in with the actual game logic.


This.
15 Feb, 2010, Lyanic wrote in the 10th comment:
Votes: 0
KaVir said:
I believe he may be objecting to the suggestion that game logic needs to be mixed in at the lower levels. Allowing multiple players to jointly control a multi-headed hydra or demon would definitely require low level support

I guess it depends on what is considered "game logic", but my example was intended to convey the low level support required for the idea, which you seem to agree with.

KaVir said:
but such functionality could be made generic, and wouldn't need to be tied in with the actual game logic.

The 'generic' part is precisely the reason why I inserted the qualifer 'possibly' in the addendum to the statement. The problem comes in with design of those low level systems, and in how generic you can plan to make them. It might not be possible to plan out every conceivable thing you might want to do with them in the future. This leaves you with two choices later on: 1) Rewrite the lower level systems to allow for the new functionality, whilst praying you don't break any existing functionality that relies on them or 2) Mix in the game logic.
15 Feb, 2010, Cratylus wrote in the 11th comment:
Votes: 0
Lyanic said:
I guess it depends on what is considered "game logic", but my example was intended to convey the low level support required for the idea, which you seem to agree with.


Well ok, but what you actually said was

Lyanic said:
This is obviously going to require mixing some game logic in at the lower levels


Which is "No."

-Crat
15 Feb, 2010, KaVir wrote in the 12th comment:
Votes: 0
Lyanic said:
I guess it depends on what is considered "game logic", but my example was intended to convey the low level support required for the idea, which you seem to agree with.

Yes, it would definitely require low level support, but it would be an extension of the same functionality that allows players to connect to a character. Without that you don't really have a mud, which is why I wouldn't personally consider it "game logic" - it's an essential part of any generic codebase.
15 Feb, 2010, Lyanic wrote in the 13th comment:
Votes: 0
Cratylus said:
Lyanic said:
This is obviously going to require mixing some game logic in at the lower levels


Which is "No."

-Crat

Is it possible that the specific example I used wasn't perfect? Yes. Is the overall notion wrong? No. You can say it is all you want. I actually expected that from you, coming from an LP background. I still stand behind it, though. I've given some of the reasoning already.


KaVir said:
Lyanic said:
I guess it depends on what is considered "game logic", but my example was intended to convey the low level support required for the idea, which you seem to agree with.

Yes, it would definitely require low level support, but it would be an extension of the same functionality that allows players to connect to a character. Without that you don't really have a mud, which is why I wouldn't personally consider it "game logic" - it's an essential part of any generic codebase.

My semi-rhetorical questioning of what's considered "game logic" wasn't in relation to the sockets, specifically.
15 Feb, 2010, David Haley wrote in the 14th comment:
Votes: 0
Basically it comes down to the "physics" that the game engine allows. In this case it is simply a question of what the game allows sockets to control. If a socket generates rather generic "input arrived" events, and you can set up "input receivers" and bind them to any socket, then this problem goes away without the engine knowing anything about what the game is doing. But of course some game concepts might require engine entities that simply don't exist (even if that's just a socket that can broadcast to many places, or a socket that can be redirected in the first place), at which point you need to add new "physics" to the game engine.

You still don't need to add the actual game logic to the engine, of course. But I think we're all agreeing on the fairly basic claim that the engine must support what the logic wants to do, even if the engine doesn't actually implement that logic.
16 Feb, 2010, JohnnyStarr wrote in the 15th comment:
Votes: 0
I think I get the overall point here.
I'm not so much concerned about releasing my work. I just wanted to be generic enough to the point
that if I wanted to go from Sci-Fi to Fantasy, I could duplicate the "engine" and make minor changes.
Ruby's ability to extend classes during runtime opens the door to creating configuration files which would allow
you to add things like commands, skills, proffessions, etc all on the fly under some generic class called Prop or what
have you. So all in all, I cant complain about having to redo a few things here and there, but on the same token,
because Ruby is so flexible, it is tempting to take full advantage of making a very generic server.
16 Feb, 2010, David Haley wrote in the 16th comment:
Votes: 0
This kind of decision won't necessarily affect genre so much as it will affect what you can do in your genre. You don't necessarily need a coordinate system to do sci-fi, for example.

I'd recommend that you try to get it "just working" before you start trying to make things too generic. Trying to make the World's Most General Game Engine (TM) often leads to ending up with nothing in your hands to show for it. :wink:
16 Feb, 2010, JohnnyStarr wrote in the 17th comment:
Votes: 0
Good point. I'm tired of starting new projects. I want to actually run a mud after-all.
16 Feb, 2010, David Haley wrote in the 18th comment:
Votes: 0
Another thing I thought of (which donky alluded to as well, I think) is that it's hard to know which things need to be made generic until you've gone through and done it, and suffered for having it not be generic. It's easy to make things generic that don't really need to be, and miss the things that should be general. So time spent on a "non-general" codebase is not at all time wasted, because you're learning a lot for next time (or for refactoring your code).
16 Feb, 2010, Runter wrote in the 19th comment:
Votes: 0
JohnnyStarr said:
I think I get the overall point here.
I'm not so much concerned about releasing my work. I just wanted to be generic enough to the point
that if I wanted to go from Sci-Fi to Fantasy, I could duplicate the "engine" and make minor changes.
Ruby's ability to extend classes during runtime opens the door to creating configuration files which would allow
you to add things like commands, skills, proffessions, etc all on the fly under some generic class called Prop or what
have you. So all in all, I cant complain about having to redo a few things here and there, but on the same token,
because Ruby is so flexible, it is tempting to take full advantage of making a very generic server.


Planning is important, but at some point you'll find that actually producing content will give you insights you need.

My advice is to rapidly produce your content. Don't spend any time on anything that isn't clutch. This at the end of the day gives you an ultra light skeleton crewed ship that you can re-engineer. (Which no doubt you're going to find yourself wanting to do at some point.) The odds of you wanting to do this early is most likely.

You'd be amazed at how this approach can yield results.
16 Feb, 2010, KaVir wrote in the 20th comment:
Votes: 0
Runter said:
Planning is important, but at some point you'll find that actually producing content will give you insights you need.

It'll also allow you to bring in playtesters, as the content will give them something to do and a reason to hang around. Their perspective and feedback will prove extremely valuable, but perhaps more importantly (in my experience) having other people playing the game is a huge motivation boost. The first year I spent developing my mud was a real struggle, and there were weeks at a time where I didn't even touch the code - it just didn't feel as though I was making any real progress, and I mostly lost interest in the whole thing after a few months. That all changed once the doors opened to the playtesters, as suddenly it felt like an actual game rather than just a half-finished program sitting on my hard drive.
0.0/20