Here are my thoughts about the roadmap, and Bruce's comment on it.
I agree with Bruce when he says that the core is not always consistent in it's
usage of features, and that some features are added which don't seem to be
developed completely, or got forgotten about. Exits are an example, there is
$path, $exit, $exit_frob but the documentation does not talk about objects at
all. If i am missing something here which is in the help then it is surely placed
in an odd location :)
The biggest problems i see with ColdCore for new users are the following:
- lack of comments inside code
- extreme modularity
- lack of description about what object uses what other object
The last two points got addressed by Bruce already, so i won't go too much into
that. His example of 'how do i add a CML generator' is a very good one as i
myself have combated that problem, and the help was not very helpful in this case
either.
My point about comments in the code is the following:
Right now, your safest bed is to dig through the code instead of relying on
@help. @help most often is difficult to understand or does not provide the
information you need to get your job done. Comments in code would make everyone's
life much easier, especially when it is something sophisticated which is not
obvious at first glance about what it's actually doing. Parameter format,
conditional assignments et all come to mind here which could get explained abit
better.
The question about systems which have to get changed by peoples is most likely a
very tricky one, as one's needs vary greatly i figure.
Here is what i needed to change or have to change:
- Making the core usable for a RP environment. This means removing things which
are OK in a social core but impossible for a game core, like remote command
invocation (use bomb on $bomb_12 in a different room, look $user_dummy, etc) for
example.
- Changing the security system of the core. This is being done right now with the
implementation of groups, which is def. a good step into the right direction. It
might be nice to add a few things, though, like a less powerful group than
programmer which still can code on objects under their control without having the
possibility to see all code on other objects (as this is something impossible for
RPG games.) One could think about adding a @list/@program to $builder which does
the appropriate checks, and put other aspects of security into the modules
instead of having a permission check wether that specific $builder can evaluate
or cannot evaluate a given method.
Upgrading the core right now is abit tricky, but i understand Brandon is writing
something for this problem. It would be neat to get a list of all new/modified
objects/methods of a SNAP release so you can decide wether you want to apply the
change or not, something very difficult right now. Maybe a draft of the to-be
upgrading system would help in that area.
--Broesel
|