26 Jun, 2011, JohnnyStarr wrote in the 1st comment:
Votes: 0
After studying a bit on web frameworks, I see how the mud community would benefit greatly by
having a framework that could be used to accomplish heavy lifting for new developers.

I think it could even benefit from using a MVC design as far as game objects go. The goal would be
to ween new comers off of C / C++ and get them started in Ruby or Python. I imagine a properly designed
'gem' could accomplish this for Ruby. It could contain all the socket programming, data storage, olc etc built
in.

I'm sure this isn't the first time someone has thought of this or even mentioned it. I'm just curious whether or not
this is a practical idea. Any thoughts?
26 Jun, 2011, Rarva.Riendf wrote in the 2nd comment:
Votes: 0
JohnnyStarr said:
After studying a bit on web frameworks, I see how the mud community would benefit greatly by
having a framework that could be used to accomplish heavy lifting for new developers.

I think it could even benefit from using a MVC design as far as game objects go. The goal would be
to ween new comers off of C / C++ and get them started in Ruby or Python. I imagine a properly designed
'gem' could accomplish this for Ruby. It could contain all the socket programming, data storage, olc etc built
in.

I'm sure this isn't the first time someone has thought of this or even mentioned it. I'm just curious whether or not
this is a practical idea. Any thoughts?

Are there not some mud already coded in Ruby ?
27 Jun, 2011, Runter wrote in the 3rd comment:
Votes: 0
He's talking about making a framework, not a codebase. It could be worthwhile.
27 Jun, 2011, Idealiad wrote in the 4th comment:
Votes: 0
There are dozens of Python and Ruby muds without content (i.e., a 'framework') already. I'll admit there's a notable lack of documentation or design notes on most of them. Maybe a better project would be to pick one and document it extensively.
27 Jun, 2011, Runter wrote in the 5th comment:
Votes: 0
Idealiad said:
There are dozens of Python and Ruby muds without content (i.e., a 'framework') already. I'll admit there's a notable lack of documentation or design notes on most of them. Maybe a better project would be to pick one and document it extensively.


A framework isn't just a "mud without content". It's a pattern to follow and a system that makes the pattern work. As far as I know, there's not dozens of MVC mud frameworks. I don't know of even one.
27 Jun, 2011, Idealiad wrote in the 6th comment:
Votes: 0
Every mud codebase is created with some kind of design paradigm in mind. It might be good, average, or bad, but just because it doesn't come packaged with a command line utility that creates 27 magic files in 8 directories doesn't make it not a framework to build your mud on. However, I agree that most of the muds I'm talking about aren't packaged in a way to help newbies out, hence my suggestion for documentation.

Anyway, to be constructive, how about Evennia?
27 Jun, 2011, Rarva.Riendf wrote in the 7th comment:
Votes: 0
Quote
A framework isn't just a "mud without content". It's a pattern to follow and a system that makes the pattern work. As far as I know, there's not dozens of MVC mud frameworks. I don't know of even one.

Could you define 'pattern to follow' ? Because if it is not a codebase without any content, a framework would be, imho, not much more than socket dealing ,and saving loading info from the socket. An that's it. Oh and a way to send text from one socket to another.
27 Jun, 2011, Runter wrote in the 8th comment:
Votes: 0
Idealiad said:
Every mud codebase is created with some kind of design paradigm in mind. It might be good, average, or bad, but just because it doesn't come packaged with a command line utility that creates 27 magic files in 8 directories doesn't make it not a framework to build your mud on. However, I agree that most of the muds I'm talking about aren't packaged in a way to help newbies out, hence my suggestion for documentation.

Anyway, to be constructive, how about Evennia?


We're talking about the established semantics behind a software framework. By your definition, any program where the sources available is a framework. That's not really the case. Especially as the OP used the term. Whether or not any program where the source is available is a good starting point isn't under dispute. And it still stands, I don't actually know of any MVC mud frameworks.
27 Jun, 2011, JohnnyStarr wrote in the 9th comment:
Votes: 0
Runter is spot on as far as my OP. MVC would work well in a mud if you think about it a bit.
The framework wouldn't be limited to sockets in this case either. It would actually govern the 'way'
you build your game. By enforcing specific constraints, you suggest best practices to the developer.
We all know any DIKU related mud does not do this. Yes you get a 'framework' for writing commands,
game objects and network channels, but you are able to write whatever hackish way of doing so you please.

This of course is not saying that a framework of any sort will prohibit sloppy coding. It will however point you
in the direction needed to keep it at a minimum.

As far as MVC, I imagine it could be used with game objects accordingly:

Model - data model with full database / serialization functionality
View - responsible for how the game object is displayed, described, and formatted
Controller - handles all interaction to the game object by players and or other objects

I look forward to further comments regarding framework implementation. :lol:
27 Jun, 2011, Twisol wrote in the 10th comment:
Votes: 0
When I think of a MUD framework, I think of something that, among other things, (1) automatically wraps incoming connections with an Anachronism layer and (2) provides a "controller"-like class for handling commands. In Ruby pseudocode:

class PlayerCommands < MUDFramework::Commands
on "kill *" do |target|
if player.room == target.room
player.attack(target)
player.send "You attack #{target.name}!"
end
end
end

mud = MUDFramework::Server.new
mud.register_channel :main, PlayerCommands

mud.listen "localhost", 23


A real framework would probably look a fair bit different - I just came up with that off the top of my head - but that's the basic idea.
27 Jun, 2011, Tyche wrote in the 11th comment:
Votes: 0
Why MVC, and not SOA?
27 Jun, 2011, JohnnyStarr wrote in the 12th comment:
Votes: 0
Tyche said:
Why MVC, and not SOA?


Not sure, I would have to research it more. I have read articles, but I don't have any experience with it.
Mind sharing an example of what that might look like here?
27 Jun, 2011, Tyche wrote in the 13th comment:
Votes: 0
It is a view of a mud as a collection of loosely coupled services, or plugin modules. User account control, help service, board service, character generation service, programming service, navigation service. etc.
27 Jun, 2011, JohnnyStarr wrote in the 14th comment:
Votes: 0
That sounds interesting.
The MVC pattern makes sense to me because it would provide a way to separate
the structure of game objects. Here is an example of what I am considering:

# lib/models/room.rb
class Room < RupeeMud::RecordModel
property :header, :string
property :description, :text, :limit => 400

has_many :exits
has_many :mobiles
end

# lib/controllers/room_controller.rb
class RoomController < RupeeMud::Controller
def enter
@room = Room.find[scope[:id]]
end
end

# lib/views/rooms/enter.rb

echo @room.header
echo " \n"
echo @room.description

echo "Obvious Exits:\n" unless @room.exits.nil?
@room.exits.each do |e|
echo e.name + " - " e.to_desc
end

@room.mobiles.each do |m|
echo m.short_desc
end


Not exactly sure about views yet. "echo" or "print" would be fine for rendering the desired output.
I imagine you could 'eval' the script in the scope of the room controller as to have access to local variable scope and what not.
27 Jun, 2011, Twisol wrote in the 15th comment:
Votes: 0
Tyche said:
It is a view of a mud as a collection of loosely coupled services, or plugin modules. User account control, help service, board service, character generation service, programming service, navigation service. etc.

My example above kind of aims in that direction. I was thinking you could have classes of commands and chain them together in a Rack-like way.
27 Jun, 2011, quixadhal wrote in the 16th comment:
Votes: 0
Actually, if you want something different, a concept I was thinking of a while ago might fit the bill. It's described in another thread here somewhere, but the general idea is to use the OS services to your advantage, rather than trying to replicate them in a bottle.

A traditional MUD attempts to duplicate much of what your typical unix-like OS does, in a single process. It accepts connections and attaches command interpreters to them, it provides text consoles with input and output, it provides (in some cases) a filesystem and editors with which to modify and extend the world, in some cases it also implements an interpreted language to program the world. Many games also interface to email/twitter/etc to further bring real world services to the players.

My suggestion is NOT to try and build a one-for-all framework, but rather to build a full OS distribution which is custom tuned and tailored to making a machine that runs a MUD. Your typical unix-like OS already handles logins, file security, process accountability (via ulimit), and communication. It also already has easy access to email, web services, etc. The only things you'd need to build are a state machine process that is your game server, and a new user shell that communicates with this game server and interprets what you type.

By doing it this way, you completely remove the artificial restriction of having to telnet into a port with an unknown client, and thus not knowing for sure if it'll actually do what you ask it to do. Your "client" could be a simple as a modified copy of bash (modified to more smoothly handle messages to and from the game server), or a fully custom curses-based client, or even an X-windows display routed back to the user's own desktop.

You automatically get multi-threading for anything not directly involved in the game world. Things that have to talk to the game server will, of course, still need to do so via some command protocol which it handles as it gets around to it… Additionally, if you stick to the rule that all game-related events MUST be handled by the server (via an API), you can code your commands and such in whatever language you like. Your shell will run a "look" command in ruby just as happily as one in perl or C, they just all have to eventually send a "do_look" message to the game server, and have it return a block of data for them to parse and display as they choose.

This was a silly idea not too many years ago, but nowadays, it's trivial to set up a new linux virtual machine, and making a custom linux distro that's specifically designed to do a single thing is also not absurd. Onlly bummer is, the name MudOS is already taken. *grin*

I dunno, probably not the direction you wanted to go, but I offer the idea up since it feels like a similar goal via a very different route.
27 Jun, 2011, JohnnyStarr wrote in the 17th comment:
Votes: 0
@ quix. Wow, what a cool idea.

Kind of crazy, but I see how that might work for the better of the community as a whole.

The thing most appealing to me about my project idea is that adding concepts becomes stream-lined.
There's nothing worse than wanting to add "quests" and not knowing where to begin. In a way, I imagine you could
add things SOA style by adding "services" IE: non game-objects that are still mutable / presentable.

Here's an idea:

class WeaponController < RupeeMud::Controllers::GameObject

end

class QuestController < RupeeMud::Controllers::GameService

end


Not sure if this the right path, but my goal would be to provide everything needed to add ANYTHING conceivable to the game.
27 Jun, 2011, Deimos wrote in the 18th comment:
Votes: 0
I think this could be a cool idea, but I think you're likely going to end up crossing over into creating a codebase instead of a framework. For example, how will you provide any kind of generic structure for facilitating the creation of an arbitrary movement system? The two most popular systems (room-based and coordinate-based) are so vastly different that I don't foresee much common boilerplate that could be handled by the framework. In most of your examples thus far (and others') major game design decisions were assumed.

Sorry if I sound like a pessimist. I think it's a great idea, but you'll really have to dive into abstraction to keep the project a true framework. Good luck with it. :grinning:
27 Jun, 2011, Runter wrote in the 19th comment:
Votes: 0
Deimos said:
I think this could be a cool idea, but I think you're likely going to end up crossing over into creating a codebase instead of a framework. For example, how will you provide any kind of generic structure for facilitating the creation of an arbitrary movement system? The two most popular systems (room-based and coordinate-based) are so vastly different that I don't foresee much common boilerplate that could be handled by the framework. In most of your examples thus far (and others') major game design decisions were assumed.

Sorry if I sound like a pessimist. I think it's a great idea, but you'll really have to dive into abstraction to keep the project a true framework. Good luck with it. :grinning:


It's a good point. Generally in MVC frameworks, for example, you're delivering a definitive product. If the product is unknown it may be difficult to determine what a view should actually be (model and controller, not so much). Of course, if you follow the typical diku paradigm it's not hard to imagine what that would be, but your stated goal was "to provide everything needed to add ANYTHING conceivable to the game."

Frameworks often try to solve this with configuration, but that's impossible to do for anything conceivable.
28 Jun, 2011, JohnnyStarr wrote in the 20th comment:
Votes: 0
Runter said:
Frameworks often try to solve this with configuration, but that's impossible to do for anything conceivable.


I see the predicament here. It's logical that certain features would come with the initial project installation.
This doesn't mean that a full blown codebase would be created for you, just the scaffold really. I think the key here
is to encourage collaborative plugins. Assuming you are following the project standards, you may choose to install
a coordinate system, auto-mappers, auction systems, etc.

I'm sure a minimal set of plugins could be added as part of the initial install. Or, if you are planning on writing something very
specific you can start from scratch. At the end of the day, the framework provides the building blocks to create "anything conceivable"
within the confines of a sensible game environment.
0.0/27