In the context of a stock codebase is it important to include a fully developed game with it?

Should this game reflect broad genres as a series of examples?

Should you distribute a 'bare' version of the codebase as well?

It's important to show a feature representative game: something that shows you how to use the features the codebase offers. Does it need to be fully developed? No. But having something to work with rather than a blank slate (how do I create skills and rooms and exits and ?!?!) makes it far easier to get started.


Not sure what this means.


It should be easy to remove the provided sample game world (and associated game logic to some extent). I don't think that means that the codebase needs two separate distributions.

IMO it depends who you're targeting. I suspect that the out-of-the-box gameplay of Diku helped greatly with its popularity, and even if people want to create all of their own content it can still be useful to have an example for reference. But if you don't want to invest too much effort into creating game content, I think some solid documentation and a simple example of gameplay would suffice for many people. I don't think it would hurt to have a 'bare' version as well - even if it's easy to remove the content, it's still an extra hoop for people to jump through when they're trying to decide which codebase to use.

If you want it to be popular then a canned game is almost essential IMO. Including a diku-style game logic module with area file compatibility would make it a winner.

Depends on the goals of your codebase, but generally no. If you have a project like NakedMUD, strictly offering low level socket handling and some basic command structure, then it defeats the purpose to include a fully developed game. If you are an established game and are at the point where you want to release your MUD as a new "stock code", then yes, maybe it's more important to package it as a game-in-a-box so the player fanbase of your (hopefully popular) MUD can fire up a clone and get it spreading more quickly (how most Diku-derived stuff seems to be).


Again, this depends on your project goals and I'd say further more on your game logic. Is your logic modular to enable/disable certain aspects to shape the game you want? IE: Space y/n, limb damage y/n, magic system y/n, levels y/n, classes y/n…etc. If the bulk of the code is so modular that you just enable/disable things to suit your world vision (modern age, dark fantasy, strict pvp ala Godwars, etc) then yes, I'd say it is important to have various examples to guide people through what feature set they might want to utilize depending on the game style they want. If there aren't so many choices, or they're not easily toggled, though, then no, I don't think it's important to include such examples.


I see no reason not to. Some people may want a "stock" game-in-a-box where they just need to change the wizlist and title screen; others may not. As mentioned before, though, for those who plan to remove all the additional fluff anyways, it's just saving them one more step and helping them get up and running faster.