alright so i'm just about done with the initial stage of my my custom code base written from scratch in D, at what feature level should i be aiming for before i really release the code base, right now the feature level is really low.
Basic telnet support -> can handle incoming telnet sequences gracefully no protocols or options are really implemented
Small group of general commands who, tell, gossip, use, @quit(exact), and movement via exit names
OLC commands @create (right now only zones and rooms easy to expand to other Object types), @dig, @link / @unlink exits, and @edit to edit object properties @list (to list created zones and rooms, soon also target properties)
Admin Commands @shutdown(exact) and @flags, @teleport
general mud stuff <roomkey>@<zonekey> and #<roomid>.<zoneid> valid locations can be generated via both
i'm also in middle of implementing an output buffer so that all data generated during a frame can be sent at one time and to reduce send calls this will also offer better compression of output data if/when i implement mccp
i was thinking of releasing after i i get items finished and cleaned up.
right now it compiles and runs on any os supported by digitalmars dmd v2 (windows,linux,osx intel), also supports gdc if its compiled with D v2
generates all files needed to run on its initial startup including a default config file if a config file is provided during startup it will use those values in generation process
Sounds good, I haven't heard of a mud written in D. In any case, the best advice I've heard on when to release is, 'release often, and don't tell anyone'.
Unless you're trying to make money off it, or trying to be a control freak, release as often as you think it's stable. There's no point holding off until Feature X is done, because that means you'll just never release it. If you release it early, someone else may pick up the ball and run with it, and maybe they'll do something you wanted to do but didn't get around to, or maybe they'll add cool new things you never thought of.
Well so far the goal is for the mud to be released opensource under the boost license to i'm not worried about people doing things with and creating and doing things with that i've never dreamed of i was just wondering at what maturity level the code should be at before presenting it
i do plan on adding scripting support and event triggers as soon as i get the general format and data relationships down and better under control instead of the hacks i have now. 256 color support would be easy to add into my iobuffer processing fairly simply
@scandum: what is copyover?
31 Oct, 2010, David Haley wrote in the 6th comment:
Votes: 0
Copyover, aka "hotboot", aka "warm reboot", is restarting the MUD for all intents and purposes but without dropping connections. It's a way to refresh the code and other data files without the players noticing, at least in theory. In practice, various state elements are lost, like what NPCs are up to and in some cases what items are on the ground.
thanks i've herd of the hot reboot, just have herd it referred to as copy over i'll look at the implementations to see what it requires for various OS's to support it and whether it's viable, i'm trying really hard to keep it cross platform at least for windows linux and mac osx
31 Oct, 2010, JohnnyStarr wrote in the 8th comment:
Votes: 0
I'll have to second that D is an unusual language to start a new project in. That being said, I like the idea. I gather that you chose D because for whatever reason you were comfortable with it. Since there are a lot of codebases out there available in more popular languages, you might not find the eager audience you're expecting, and in that case I would focus on your future game more than on what others may / may not like to have from a custom base. IMO, The essence of "custom" is that it has a unique personal feel.
Basic telnet support -> can handle incoming telnet sequences gracefully no protocols or options are really implemented
Small group of general commands
who, tell, gossip, use, @quit(exact), and movement via exit names
OLC commands
@create (right now only zones and rooms easy to expand to other Object types), @dig, @link / @unlink exits, and @edit to edit object properties
@list (to list created zones and rooms, soon also target properties)
Admin Commands
@shutdown(exact) and @flags, @teleport
general mud stuff
<roomkey>@<zonekey> and #<roomid>.<zoneid>
valid locations can be generated via both
i'm also in middle of implementing an output buffer so that all data generated during a frame can be sent at one time and to reduce send calls this will also offer better compression of output data if/when i implement mccp
i was thinking of releasing after i i get items finished and cleaned up.
right now it compiles and runs on any os supported by digitalmars dmd v2 (windows,linux,osx intel), also supports gdc if its compiled with D v2
generates all files needed to run on its initial startup including a default config file
if a config file is provided during startup it will use those values in generation process
is there any interest here