TinyMUX 2.10 - Links
Sandbox Globals Project
Sandbox Globals Project has been released for several years now. This package contains parts of a chargen, but it offers no virtual time or weather.
It works on PennMUSH, TinyMUSH 2.2.x and U1 as well as TinyMUX 1.x and RhostMUSH. SGP is an attempt at base globals that work everywhere – an idealistic goal and one almost achieved.
I support a common base globals package, but I don't think it is necessary to use exactly the same softcode on every server or expect that game owners will copy/paste code from PennMUSH to TinyMUX and expect it to work without change.
I have a lot of respect for PennMUSH's development team (past and present), but their development philosophy tends towards the academic in terms of the broader use of the implementation language, greater willingness to pick up platform dependencies, implementation of the MUSHcode language of things that are cool or obvious extentions rather than only what is necessary or requested, and the way people organize themselves around the environment a MUSH creates. It siezes upon these things from the perspective of a study, an experiment, an opportunity for the developer to learn something, or a subject worthy of paper writing. Things are done not necessarily to achieve a requirement, but are performed to observe an unexpected result. This is not an inherently bad philosophy, and it can be fun. But, it is different than the philosophy for TinyMUX.
M*U*S*H players have never had a clear distinction in their minds between what is MUSH, a family of servers, versus PennMUSH, a server in the MUSH family, versus M*U*S*H, a game built using PennMUSH. But, in the mid-nineties, the community itself still seemed open. Over the years, the culture has become increasingly provincial and protective. This doesn't come from the devs directly, and this is not the culture Javelin set out to encourage, but it exists nonetheless.
Some features currently in Penn probably should not have been added. And, useful-and-wanted-but-missing features deemed too hard or outside of scope of interest have left it looking dated and chubby. PennMUSH doesn't scale well, and despite assumptions otherwise, it uses more CPU and memory than TinyMUX.
Since Javelin has retired, I expect the development team to engage once again for at least the next two years with practical matters of being a game server for owners and players. I've heard things like 'test cases' and 'too much memory', so these things are now appearing on the radar. Who can say what will happen after a year or two. PennMUSH development targets primarily UNIX, but workable Win32 builds exists.
One of the most secure servers out there is RhostMUSH. It is feature-rich in terms of permissions, functions, parameters, commands, switches, and configuration options. And, this can be a little intimidating due to the large number of options and functions, but it’s worth a good look. This server is built like a tank, but this also means that it intentionally either omits features deemed to be a security risk or it carefully restricts their use. If you want security and accountability, you want this.
Unfortunately, while the sources and binaries are free, they are also closed.
HSPACE is a dynamic space add-on. Dynamic space allows for more dynamic relationship between spaces within the environment. It opens up a complex and flexible combat and economic system. Think space ships, treks across a featureless desert, etc.
Battle Tech MUX (BTMUX)
BattletechMUX - A heavily modified and extended version of TinyMUX 1.x that provides a real-time, text-based version of the popular board game “Battletech” by FASA (now owned by WizKids). Although extremely complex and difficult to develop with, BTMUXs are great for the fast-paced, strategic and tactical text gamer. The public distribution is maintained by the staff of Battletech: 3030 on SourceForge.
Nick Gammon’s Pages
Nick Gammon has done a series of Windows-related work which can be found on Mud and Mush Programs and Information.
TinyMUSH 3.0 and 3.1
Most of the code in TinyMUSH 3.0 is from the TinyMUX 1.6 branch (which is itself a branch of TinyMUSH 2.0). In cases where TinyMUSH 2.2.5 expressed the same feature in a different way, the TinyMUSH 2.2.5 behavior took precedence. Note, the actual fork from TinyMUX was probably 1.4 or 1.5, but there were some later patches to TinyMUX in parallel with the work on TinyMUSH 3.0.
On top of this, TinyMUSH 3.0 contained a goodly number of bug fixes (fixes to bugs introduced in the TinyMUX 1.x development period) as well as some additional features. David Passmore and Lydia Leong were primarily responsible for TinyMUSH 3.0. Alierak contributed bug reports heavily during the Beta period but only joined the team officially for the TinyMUSH 3.1 push.
TinyMUSH 3.0 seemed to emphasize interoperability with TinyMUSH 2.2.5 and softcode-level features over bug fixes or more fundamental changes. I would estimate that most of the bugs that were fixed, were fixed during the Beta period.
Given the choice between TinyMUX 1.6 and TinyMUSH 3.0, I would pick the latter. Well, the first Beta was essentially TinyMUX 1.6, so if we’re talking about the first Beta release, it would be a toss up, but by the end of the Beta period, the scales tip towards the more-recent effort. However, that said, in a line-up of quality against PennMUSH, TinyMUX 2.x, and RhostMUSH, TinyMUSH 3.0 would still appear last.
Much effort in TinyMUSH 3.0 appears to have been made to alter/add/remove the fewest lines of code possible and still call it good. But, then, again the Beta period was an intense period of change. The code probably changed more profoundly during the Beta period than it did in the 2 years prior. At the least, the two periods are comparable in terms of changes to the code.
With Alierak on-board, the TinyMUSH 3.1 project took on a different flavor. In some areas, the quality is markedly better. Also, the code is substantially re-arranged, similiar things have been collapsed. However, there seems to have been a tension between adding lots of new code and improving the quality of the old. I'm not sure which side won. Obviously, a diverse team can have its advantages, but I'm not sure that it was an advantage in this instance.
In the end, I have my own fish to fry. David, Lydia, and Alierak became too busy to continue working on it. Lydia and Alierak still post to the support list periodically. They may become more involved in the future.
Eddy Beaupre was slated to pick up the codebase to press towards TinyMUSH 3.2, but as he has also been very busy, there hasn't been much output.
As of late 2007, Lydia has made a handful of commits, and appears poised to take over from Eddy again.
As of 2010, Lydia has taken the reins back from Eddy.
© content, MUX 2
© design, The MUX 2 Project
This site looks best at 800x600 hi-color resolution, browser is up to you. Lynx compatible.