Leowon tells you: Just a question re: coding conventions: If you want to
make
the code about 100% clearer, make all your classes capitalized:
"Room.java" instead of "room.java" etc
Leowon tells you: Makes it so much easier to read the code
Leowon tells you: Sun's Java code conventions
Leowon tells you: Classes are Capitalized, static final constants are
UPPER_CASE_WITH_UNDERSCORES, variables, parameters and methods are
lowerCaseForFirstWordAndCapitalizedForOthers
Leowon tells you: the set_foo and lower_case style is C++/C-ish, and while
it's
not bad either, the Java one contains more info
Leowon tells you: Mmm, that's a point I guess
Leowon tells you: Java programmers will hate it, though :)
Leowon tells you: If you should work on one thing, though, it's the dynamic
reloading of classes :)
Leowon tells you: Without that, it won't be a mud - it'll be impossible for
wizards to create things in a sensible fashion
Leowon tells you: No idea
Leowon tells you: I'd think so. He's a good coder, friendly, and works as a
Java programmer
Leowon tells you: Yep, briefly. Looks good as a starting point, I think
Leowon tells you: The lib you can always fix later, the important thing is
to
define the interface between the driver and the lib, and to define
the
functionality of the driver
Leowon tells you: create() when loading a class, reset() when resetting a
loaded object, exec_command() when receiving user input, defining in
which order and how the driver figures out in which object to call
the
exec_command method, a discard() method as a destructor for objects,
things like that
Leowon tells you: You have the basic structure in place, now give it a good
thinkover - do you need more interaction points? Would the ones you
have
benefit from more/less parameters? Will they support all
functionality
you want to add? And then, fix the reloading thing in the driver so
you
can actually code like a mud's supposed to be - then bother writing a
manual for it :)
Leowon tells you: Test your new driver with a few simple monsters and rooms
like you have done, see that your interface works well
Leowon tells you: Not a bad idea
Leowon tells you: Yeah, that's what I meant too
Leowon tells you: you type "reload foo.Bar" and that recompiles it, and the
driver is notified to purge the old version and load the new version
Leowon tells you: Ah... well, as long as you keep all classes loaded that's
ok,
but that will eat some memory of course
Leowon tells you: But many rooms are just transport... like, "you're walking
on
a path"
Leowon tells you: I mean, you can of course require wizards to compile all
files before an area is opened, but people will forget to do that,
and
it does prevent the driver from doing GC
Leowon tells you: If you have dynamic compiling of .java files you don't
need
to worry about that
Leowon tells you: Remember that you can cheat... you don't actually need to
compile into a file
Leowon tells you: You could compile into memory instead
Leowon tells you: Then it'd be a lot faster, no?
Leowon tells you: Only some very basic ones. There's a file containing a
list
of files that should be loaded at boot
Leowon tells you: No. When their initial env is loaded, they are loaded by
the
env
Leowon tells you: E.g., I enter a room that spawns a moving monster in
create()
- and that room wasn't loaded until I entered, so nor was the moving
monster
Leowon tells you: ...also, very neat to have, is to garb - I don't know if
you
can get Java to do that automatically, but otherwise if no one's
entered
a room for say an hour, then it can safely be removed from memory
Leowon tells you: That's the callback we call "clean_up" here. It calls
clean_up in objects periodically and if they say it's ok to be
garbed,
they're garbed
Leowon tells you: basically, don't garb if 1) entered within an hour 2)
contains mob 3) contains eq (optional, I think we garb anyway
nowadays),
or whatever other criteria you can think of
Leowon tells you: ...but I'm sure there are other ways. My lib/driver
experience is limited to Nanny, there are many others out there that
I
don't know how they solved these issues...
Leowon tells you: No wonder
Leowon tells you: Get Mirage to sponsor you and see if he's interested :)
Leowon tells you: I'll be glad to help with ideas and designs and such, but
I've got so little spare time as it is, I don't think I will be able
to
contribute much as a coder
Leowon tells you: Ah, nice :)
Leowon tells you: That's how it is with us working-class heroes... :)
Leowon tells you: Have you any irc or news group contacts on this?
Leowon tells you: oh really?
Leowon tells you: I'm sure you could find helpers that way, too...
Leowon tells you: No, that is a problem of course
eowon tells you: Well, I can pretty much vouch for myself and Mirage :) But
I
wouldn't trust any romanian wizards on here with your source code for
example. Not because they're all bad, but because their sites have a
past history of lots of hacking, and there are a few really rotten
hacker apples among them who ruin things for many.
Leowon tells you: Ah, it's even on the homepage? Still?
Leowon tells you: Weapons only have a max damage. The actual damage is
random(wc) + 2 * random(player dex) - random(target ac)
Leowon tells you: That's pretty crude, and I think a dice system would be
better
Leowon tells you: NannyMUD is quite simple, that way. Another big flaw in
Nanny
is the armour class - it's much too coarse.
Leowon tells you: ...and the weight system is even worse. A ring weighs as
much
as a light boot.
Leowon tells you: So for those things, don't look at Nanny.
Leowon tells you: Invent or copy a damage/armour/weight system from
somewhere
else. The only good thing is the damage types, that you can see if
damage was done by fire, slashing weapon, blunt weapon, acid, etc
Leowon tells you: AC is also too crude here. A more fine-grained scale would
be
better.
Leowon tells you: Better look to some role-playing games for inspiration
there.
Leowon tells you: We believe spells should not be part of the lib, but
defined
by guild and area code
Leowon tells you: it allows for much more specialization through
exploration.
it's boring if everyone has the same spells
Leowon tells you: Well, we believe guilds should not be part of the lib
either
:)
Leowon tells you: The lib should be flexible and provide functionality to
make
it easy to create guilds, but the lib should never assume that a
certain
guild exists etc
Leowon tells you: That way, if you add or remove a guild, you'd need to
recode
the lib. And you'd get guild-specific code littering the lib all over
the place
Leowon tells you: Much cleaner to separate the two.
Leowon tells you: It's like Java. You provide a List, you don't provide
twenty
lists with particular areas of application
Leowon tells you: Not to say there can't be a lib "spell object" or so, just
that specific guild abilities or powers should not be part of it
Leowon tells you: It's an overall architectural viewpoint... separate
functionality (lib) from implementations (guild/area code)
Leowon tells you: We keep all lib code i /std, all guild code in /guilds,
and
all area code in /players/<wizname>/
Leowon tells you: That way, it's easy to assign ACL rights to those who
should
have it etc
Leowon tells you: And lib should not depend on code in /guilds or /players
Leowon tells you: You should code some rooms, monsters and objects to use as
JUnit test cases for your driver implementation ;)
Leowon tells you: Yes, some rooms have to be part of the lib as a starting
没有合适的资源?快使用搜索试试~ 我知道了~
JavaMUD 2.0-开源
共1156个文件
java:704个
html:320个
txt:44个
7 下载量 50 浏览量
2021-04-26
16:01:50
上传
评论 1
收藏 3.53MB ZIP 举报
温馨提示
用100%Java编写的多用户地下城游戏。 开发人员想要这个项目。 新的MUD仅向开发人员开放。 它完全是用Java 1.3.1从头开始编写的。 编码接口与lpmud编程非常相似。
资源推荐
资源详情
资源评论
收起资源包目录
JavaMUD 2.0-开源 (1156个子文件)
alias 358B
startup.bat 222B
bug 446B
commands 1KB
applet.conf 2KB
javamud.conf 47B
consider 719B
stylesheet.css 1KB
damage 642B
damlog 271B
welcome.dat 1KB
news.dat 976B
motd.dat 831B
death 487B
irc-conf.dtd 609B
wizards.dtd 474B
imc-conf.dtd 318B
quests-conf.dtd 308B
javamud-conf.dtd 308B
driver-conf.dtd 308B
general 1KB
general 764B
inherit.gif 57B
guildcommands 691B
guilds 726B
help 606B
index-all.html 561KB
living.html 187KB
client.html 122KB
driver.html 87KB
constant-values.html 87KB
basic_thing.html 72KB
object.html 68KB
basic_race.html 67KB
room.html 67KB
monster.html 66KB
mercenary.html 55KB
monk.html 54KB
utils.html 54KB
state_monster.html 53KB
mob.html 53KB
skilled_living.html 53KB
lich.html 51KB
paladin.html 48KB
affect_spell.html 48KB
basic_container_obj.html 47KB
knight.html 46KB
corpse.html 43KB
simple_weapon.html 40KB
simple_board.html 38KB
door.html 38KB
large_ship_object.html 38KB
simple_shareroom.html 38KB
simple_line.html 37KB
simple_potion.html 37KB
imc_object.html 37KB
simple_pub.html 36KB
basic_ship.html 36KB
wiztool.html 36KB
basic.html 35KB
simple_food.html 35KB
paper_object.html 34KB
simple_box.html 34KB
large_ship.html 34KB
simple_money.html 34KB
party_object.html 34KB
book_object.html 34KB
simple_shop.html 33KB
simple_container.html 33KB
soul.html 32KB
imc2.html 32KB
simple_rope.html 32KB
ship_object.html 32KB
drained_corpse.html 31KB
overview-tree.html 31KB
basic_tunnel.html 31KB
simple_armour.html 31KB
statue.html 31KB
basic_guild.html 31KB
daemon_room.html 30KB
mudlog.html 30KB
simple_scroll.html 30KB
treasure.html 30KB
usable_object.html 28KB
decay_object.html 28KB
quest.html 28KB
riddle_sphinx.html 27KB
quest_riddle.html 27KB
property.html 26KB
basic_spell.html 26KB
basic_trap_door.html 25KB
quest_get_slayer.html 25KB
limb_collection.html 24KB
quest_object.html 24KB
generic_savefile_xml_str.html 24KB
Ansii.html 20KB
allclasses-frame.html 20KB
black_dragon_race.html 19KB
gold_dragon_race.html 19KB
red_dragon_race.html 19KB
共 1156 条
- 1
- 2
- 3
- 4
- 5
- 6
- 12
资源评论
粢范团
- 粉丝: 31
- 资源: 4697
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功