Quote:
That pretty much reduces Delphi to simply providing socket services to Lua.
There is already one:
http://luaforge.net/projects/luasocket/
I used that in my Lua MUD.
Quote:
It is much easier to serialize objects (and the entire state of the MUD) and I think the general structure of objects is much better with Delphi/C++.
I serialized an entire player very easily using Lua (the serialize function is described elsewhere on this forum):
function SaveCharacter (name)
name = capitalize (name)
local char = chars [name]
local dir = config.player_dir .. string.sub (name, 1, 1)
-- open file to serialize into
local f, err = io.open (dir .. "/" .. name, "w")
-- too bad if we can't
assert (f, err)
-- don't want to serialize client table for various reasons
local client = char.client
char.client = nil
-- save all player data
ok, err = f:write (serialize (name, char))
-- put it back
char.client = client
-- done with file
f:close ()
-- now check for errors
assert (ok, err)
end -- SaveCharacter
Loading it back was even shorter:
function LoadCharacter (name)
name = capitalize (name)
local char = chars [name]
local dir = config.player_dir .. string.sub (name, 1, 1)
-- load the file, get a function to execute
local f, err = loadfile (dir .. "/" .. name)
-- oops, if not found
assert (f, err)
-- want to load this character into the chars table
setfenv (f, chars)
-- load it
f ()
end -- LoadCharacter
You could use the same approach for other things, although arguably you don't serialize rooms on the fly.
Quote:
For example, I might have a BasicRoom object (eg. a table with methods) and then I might inherit (using a metatable and the __index method) from that to create an UnderwaterRoom. The same basic structure can be used for monsters, items, etc.
To be honest, this was where I started getting bogged down, although I agree in principle with what you are suggesting.
The primary point of contention was to distinguish between a prototype object (that is, one the MUD builder designs), such as a sword, and an instance of the object (there might be 100 such swords in people's inventories).
Some aspects might be immutable, and could belong to the prototype (eg. its description), whereas some other aspects would change per instance (eg. the wear and tear on it). Also, you might bless or otherwise add enhancements (sharpen, perhaps) to an individual instance.
Having got that far, and you could do a fair bit with inheritance, you need to have a way of referencing the instance. For example, if I have 5 swords in my inventory, all based on the same prototype, I can't use the prototype "vnum" or whatever you call it, because they will all have that. So, I need to have a unique ID per item, so I can wield (or give away, or drop) a particular one.
This raises other issues - for example, do rooms have instances? Or is there only one of a particular room? It might be sensible to say "only one", however some MMORPGs actually have instanced dungeons, where the same room actually occurs multiple times.
Quote:
A potential problem might occur in the following scenario:
1) Player A's sword, "DeadlySword" adds an OnAttack event to Player B.
2) Player B starts his attack.
3) Player A logs off.
4) Player B has an event pointing to the logged-off player A's sword. (eg. invalid pointer?)
There are very good questions. Again, I would be cautious about closely linking the player (that is, the comms connection) with his/her avatar. If you start a fight, you shouldn't be able to escape by simply disconnecting. It would be logical for your avatar to keep existing, and keep fighting (or at least, taking damage), even if the connection is dropped.
You could argue that each avatar continues to exist in the world, even if its "controlling player" is logged off. For example, the avatar could be asleep, or in another dimension or something, but it still exists. This makes sense in a way, because if the avatar is in a group (eg. a guild) then that avatar's membership persists even if the player disconnects.
There are a whole heap of potential problems if you don't design carefully. Here is an example:
Nick creates an avatar called Gandalf, and joins a guild.
Nick gets bored with the game, logs off and deletes his character, making the name Gandalf available.
David creates an avatar called Gandalf now.
Is Gandalf still in the guild? If not, why not? Does the "delete avatar" routine have to know every possible place an avatar might be referenced (eg. guild lists)? Or, do we actually assign numeric IDs to avatars that are never re-used? If we decide to do this, then at an early stage we need to reference players by their ID and not by their name, which might change or be reused.
Quote:
function BasicRoom:AddPlayer(p)
table.insert(self, p)
end
In principle this looks good, but you need to consider, in this case, removing him from his previous room.
Again, are we really talking players here or avatars? Or how about mobs? |