18 Mar, 2010, JohnnyStarr wrote in the 1st comment:
Votes: 0
I want to design things in a way in which adding values to classes will be a breeze.
There are of course integral object values that are required for the game to function; such as the player's name,
level, password etc. There are also functional commands that just have got to be there like: move, say, get, drop, give, etc.

But as the game grows, there will be little things here and there that I might want to swap in and out. I thought about creating
a file for each class class called "room_aux" or "character_aux" etc. This way, you make sure dependent values are not altered unless
the user knows what they are doing. Long story short, I want to release this codebase and want it as easy as possible to customize.

What do you think about this approach?
18 Mar, 2010, David Haley wrote in the 2nd comment:
Votes: 0
I guess I don't really understand what you're proposing to do well enough to comment on it. What would go into these _aux files you're proposing? Are you proposing something Ruby-specific or are you trying to work out a general way of keeping classes modular? (that happens to be implemented in Ruby?)
18 Mar, 2010, donky wrote in the 3rd comment:
Votes: 0
JohnnyStarr said:
I want to design things in a way in which adding values to classes will be a breeze.
There are of course integral object values that are required for the game to function; such as the player's name,
level, password etc. There are also functional commands that just have got to be there like: move, say, get, drop, give, etc.

Why do the commands have to be on the object? This is how LPmuds used to be, but it was found to be inflexible and they were moved out of the object and into separate files.

JohnnyStarr said:
What do you think about this approach?

I think its an approach, but not one I would take. How do you see this approach being easily customisable?
18 Mar, 2010, David Haley wrote in the 4th comment:
Votes: 0
We also just had a conversation, bringing up another conversation with you (Johnny) actually, about why commands probably don't want to live on commands. In any case, I don't think they have to be there.
18 Mar, 2010, Deimos wrote in the 5th comment:
Votes: 0
If I'm understanding him correctly, he's wanting to have like player_aux.ini (or whatever) where players can specify additional attributes for the Player class, which are then read in dynamically on boot, rather than making them modify player.rb source.

Personally, I don't think you should do this for two reasons: 1) it makes people lazy, and 2) Ruby is awesome and they should learn it! :grinning:
18 Mar, 2010, flumpy wrote in the 6th comment:
Votes: 0
As I have said elsewhere, I took the approach of having commands both on the object and in scripts. You can have it both ways!

Edit: indeed if you are thinking of writing non ruby command files I would say no, you'll probably end up with something inflexible and. Unexpressive instead - use your language (or another!) to write commands with, people will have a harder time trying to express themselves with a home made solution

Edit edit: deimos that avatar is truly disturbing..
18 Mar, 2010, Runter wrote in the 7th comment:
Votes: 0
Deimos said:
If I'm understanding him correctly, he's wanting to have like player_aux.ini (or whatever) where players can specify additional attributes for the Player class, which are then read in dynamically on boot, rather than making them modify player.rb source.

Personally, I don't think you should do this for two reasons: 1) it makes people lazy, and 2) Ruby is awesome and they should learn it! :grinning:


Yeah, it'd only take a few lines of code to do that this in Ruby if that's what he means, anyways. 1) read the entire file 2) use Class#eval. 3) ??? 4) profit

I'm not sure if that's what he means or not.
18 Mar, 2010, JohnnyStarr wrote in the 8th comment:
Votes: 0
hmm, by commands I just meant instance methods of the classes.
*_aux would be a Ruby file containing initial variables, but also instance methods.

The point here would be to separate critical members from optional ones. But, also to put as little
as possible in the default Classes so as to sort of separate system from game logic. Much the way
a driver would run a mudlib. But the reason I made a post is I didn't know if this made sense or not.

And yes Deimos what the crap is that thing? :surprised: It's like Gollum and Mr. Miagi had a love child. :stare:
18 Mar, 2010, Deimos wrote in the 9th comment:
Votes: 0
JohnnyStarr said:
hmm, by commands I just meant instance methods of the classes.
*_aux would be a Ruby file containing initial variables, but also instance methods.

The point here would be to separate critical members from optional ones. But, also to put as little
as possible in the default Classes so as to sort of separate system from game logic. Much the way
a driver would run a mudlib. But the reason I made a post is I didn't know if this made sense or not.

It only makes sense to me if you're designing a very bare bones system that nobody's going to be wanting to get their grubby little fingers into. Even then, I don't really see any benefit to the separation. Now, if you went as far as to create hooks and events for a full-blown plugin system, so that someone could write a plug-n-play module he/she could share with others, then I could definitely see the advantage.

JohnnyStarr said:
And yes Deimos what the crap is that thing? :surprised: It's like Gollum and Mr. Miagi had a love child. :stare:

It's me IRL.
18 Mar, 2010, Runter wrote in the 10th comment:
Votes: 0
Eh, if you're just looking for a convention keep in mind Ruby has open classes.

That means you can have

class Player
# critical stuff
end

# some other place
class Player
# optional stuff?
end
19 Mar, 2010, JohnnyStarr wrote in the 11th comment:
Votes: 0
@Runter,
That is true. I knew this, but did not consider user defined classes to be open as well.
Still learnin! Thanks.
19 Mar, 2010, Runter wrote in the 12th comment:
Votes: 0
So are you back to working with Ruby again? :P

I thought you preferred C? :P
19 Mar, 2010, JohnnyStarr wrote in the 13th comment:
Votes: 0
haha, I am all over the place.
I like working with my old ROM base, but at the same time the design makes me sick.
Ruby is much much easier to work with for obvious reasons, but it's more about being
able to make big changes, which takes too long in C. I also want to be able to come up
with original ideas that might be too much work in C.
20 Mar, 2010, Runter wrote in the 14th comment:
Votes: 0
You may look at autoload. It doesn't directly relate to what you're planning to do but it is pretty neat.

Here's a little example I threw together. I have the main file called testload.rb, a directory called spells, and 2 files in that directory called fireball.rb and create_food.rb.

testload.rb
autoload :Fireball, "spells/fireball"
autoload :CreateFood, "spells/create_food"

puts "Not loaded yet."

class Spell
end # base class for fireball and create food

Fireball.new # access Fireball and CreateFood
CreateFood.new


spells/Fireball.rb
puts "Fireball file fully loaded."

class Fireball < Spell
end # empty


spells/create_food.rb
puts "Create food file fully loaded."

class CreateFood < Spell
end # empty


Quote
ruby testload.rb
Not loaded yet.
Fireball file fully loaded.
Create food file fully loaded.


The neat thing about this in general is the ability to auto-generate your autoload list based on the contents of a directory. Then if you have many spells, all of which may not be used commonly, this can reduce the overall bulk in most cases.
20 Mar, 2010, JohnnyStarr wrote in the 15th comment:
Votes: 0
Very nice. I will add it to the long list of Ruby-bilities. Seriously, it's hard to know which way to go
when you have a ton of choices.

I've been meaning to ask you about directories as well. I started off using Vim so I kept all my files in
one src directory, but since I went all out Ubuntu, I've been using Eclipse for development, and 1 large
dir of src files is a bit much. What kind of logic does one use when sorting out the files? I've seen some
projects store files in class hierarchy order, but what if one type of class (say player) inherits "character"
yet so does mob. Do you put player in the character folder, or the descriptor folder? Not that it really matters
during runtime, but I just was wondering what sort of logic you would use to decide these things.
20 Mar, 2010, Runter wrote in the 16th comment:
Votes: 0
JohnnyStarr said:
Very nice. I will add it to the long list of Ruby-bilities. Seriously, it's hard to know which way to go
when you have a ton of choices.

I've been meaning to ask you about directories as well. I started off using Vim so I kept all my files in
one src directory, but since I went all out Ubuntu, I've been using Eclipse for development, and 1 large
dir of src files is a bit much. What kind of logic does one use when sorting out the files? I've seen some
projects store files in class hierarchy order, but what if one type of class (say player) inherits "character"
yet so does mob. Do you put player in the character folder, or the descriptor folder? Not that it really matters
during runtime, but I just was wondering what sort of logic you would use to decide these things.


I don't usually sort files by that sort of thing. In my example above if I had a file that each type of file was somewhat uniform in the contents and I could automate stuff based on the directory then I will store them in their own. I usually store my files in directories based on if they're library, core, utility, etc.

I think you can do yourself a disservice if you get too bent on complex directory hierarchies.
21 Mar, 2010, JohnnyStarr wrote in the 17th comment:
Votes: 0
I see, what would you consider Library in a mud?
21 Mar, 2010, Runter wrote in the 18th comment:
Votes: 0
JohnnyStarr said:
I see, what would you consider Library in a mud?


Well, the way I've done it is separated it basically into core and lib based on what I see as first-person or third-person development. By that, I mean code targeted at developers (even myself) or code targeted at building the actual game. For example, I have kept all of my meta-programming, sockets, timer, events, etc in core. Game definitions like spells, rooms, players, etc etc and their code I have in lib. This is what has worked for me, anyways. :)
21 Mar, 2010, David Haley wrote in the 19th comment:
Votes: 0
I do something similar, although I reverse the names: anything reusable by any project would go into a 'common' package (that other projects of mine can easily reference), whereas anything specific to the project in question would go into a package named by the project, typically. Generally, the common package isn't even in the same directory, as I like to share it across many projects (this can make distributing stuff kind of annoying though).

I further organize by packages, for instance I might have as packages:

common
common.network
|- TelnetSocket class
|- etc.
common.events
|- EventManager class
|- etc.
common.containers
|- ChunkList, LexicalTrie classes
mymud
mymud.actors
|- Actor, PcActor, NpcActor classes
mymud.spells
|- Fireball, IceStorm classes


(Just making stuff up to show the point)
21 Mar, 2010, Runter wrote in the 20th comment:
Votes: 0
Right now I'm using naming conventions.

room.rb room.algorithms.rb room.olc.rb
player.rb player.commands.rb
object.rb object.olc.rb

etc etc. I prefer this over directories, but I'm more of a simple kind of guy than David is. I need simple solutions. :)
0.0/20