|
Server Purpose
General Discussion
|
|
|||
|
So what makes SourceMud different from AweMud? I ask only out of curiosity, having switched gears and started over once or twice myself, what's changed about the initial purpose to make a new project necessary? What lessons were learned? Being nosy, mostly. --- V |
||
|
|||
|
Sorry for the long delay in replay - busy holidays followed by me moving into a new apartment.  There are three big reasons why I abandoned AweMUD, all of which can be summed up as "10 years of coding with no direction." First, there are some largish game design changes I wanted to make, but which would require grotesquely extensive reorganizing in AweMUD to make work. For example, the way login sessions were tied to Player made it impossible to offer player-controlled monsters or non-player avatars (e.g., builders or admins that don't interact with the world as characters). A larger example is the way I wish to structure the areas by locations within scenes instead of rooms. I have an uncommitted partial refactoring of the AweMUD code trying to make these happen, and it was just insurmountable given my amount of free time these days. Second, I was constantly reorganizing existing code in AweMUD to fix the myriad of low-level coding mistakes I made in the project. I started AweMUD when I was 16 - close to a decade ago. I knew C++ in terms of syntax and behavior very well, enough to know how to make the computer do whatever I wanted, but I hadn't a clue how to design large software projects and carry out that design, and it showed. I was running in a lot of circles with AweMUD, and progress on actual features was relatively low compared to the amount of code I was (re)writing all the time. There is a lot of entirely useless code in AweMUD that was written because I wanted to learn about something new, and not because the code really needed to be written. AweMUD ended up being more of a playground for me to learn new things than an actual useful-to-others project. Third, I didn't really know where I was taking AweMUD. This in turn led to me experimenting with various technologies in each (the second point), and ending up with a game design that I found uninspired and drab (the first point). Almost all of the things I'm really proud of in AweMUD are just small amounts of polish to its fairly small feature set: the quality of the english generated, the command matching system, and a few other things. On top of that, I never actually had a playable game, because I never had an actual game design. The original two goals of AweMUD were basically "be heavily modifiable without editing the C/C++ code" (a goal which I never achieved to my satisfaction, and which I later realized was kind of pointless, since anyone wanting that kind of environment already had LP) and "clone Simutronics' Gemstone III/IV" (though I still consider it to be the best MUD ever made to date, I believe that an equally excellent MUD could be made using some very different design elements). A small sub-goal of AweMUD was to be truly Open Source, unlike almost every other contemporary MUD codebase, which SourceMUD continues to uphold. Now, that's not to say that SourceMUD isn't going to be without its share of future changes and (hopefully minor) redesigns. For example, I'm still pretty unsure about using JSON as an internal format, and am contemplating switching to XML. I also played around with the HTTP resource engine way more than I should have. I do, however, have some very specific goals in mind for SourceMUD. First, I actually have a stock setting in mind, which in turn gives me direction for the style of rules and game features I need to support to bring that setting to life. Second, I have an initial design for a set of game mechanics written down, although I'm still tweaking them a bit, mostly in the area of how magic will work. (I have yet to come up with what I feel is an ideal magic system for either computer games or table-top games; designing magic sytems for LARPs is so much simpler, given that the nature of LARPing forces you to design for simplicity first and "coolness" last.) Third, I have some solid technology choices already made for implementation of various features, so I won't repeat the endless cycle of coding up the "new best way of doing things" that AweMUD suffered from. There is still some experimentation that will be done while developing SourceMUD (such as the JSON vs XML comment above), but even that is planned out already. A final goal of SourceMUD is to be as readable and understandable as possible. I've received a lot of comments over the years saying that AweMUD is very easy to read, but the code is largely undocumented. I've never been a big fan of tools like doxygen. Per-construct documentation is really not very useful compared to understand the purpose and usage of related group of methods, or the interaction between several different classes, etc. Being too lazy to write a proper manual, I'm at least making an effort and adding fully fleshed out and informative comments in the code. As an absolute final reason, I like the name SourceMUD a lot more than AweMUD.  Plus it'll reduce confusion with AWWMUD, which several of my real-life friends play. |
||
|
|||
|
|
I can certainly understand all of those reasons. My current project became much the same, I got it to a playable state and realized that everything - while working - was really more of an experimentation. Adding features became more and more cumbersome every time, every new system become more refined in its storage implementation leaving the older ones much more difficult - and necessary - to work with every time. I'm kind of tied to a game world, and structure, which in some ways makes my goals clearer. It is a strange situation, however, because I am holding together a community whose MUD was shut down by Mythic due to legal reasons. The back-end systems were based off of I.C.E. IP, which has been bought and sold since, and they didn't feel like making changes to the code the way they did for Dark Age of Camelot. Anyway, sometimes it's hard to keep working on the project, because I would love to make something different - however I would immediately lose my audience, and break a promise. Still, my approach to the engine design is very much modular. The goal being to take what is created and build my own world on top of it, after the other has been satisfied. I'm kind of torn between the open source approach and not. I find that the current .NET open source projects are simply extensions of older code bases, based on old tenets that I find to be, well, old and outdated. They seem, bloated, unclear, and frankly some implementations just confuse me. I'm not a super experienced coder, by any means, but looking at the approaches out there makes me immediately think of them as inefficient, obtuse, or deliberately vague while at the same time making me doubt my own work, "what if they know something I don't know?" is always the question, all of these projects have been around much longer than mine. At the same time it is difficult to proceed on one's own. It is allot of work, with allot of systems having to be up and running simultaneously before any 'progress' can be quantifiable. Most of the time I find myself flittering between this and that system, the client, the mapper, the server, the back-end, moving each forward by tiny increments and being able to see none of them work yet. It's taxing. The real benefit of the closed cycle is, however, the monetary benefit. The community is used to paying 10 dollars for Mythic's MUD. How can I turn that kind of commitment, and training to commitment, down? At the same time it means the client and server have to be of commercial grade. But I babble. I look forward to following the progress of Source MUD. I'll be looking to SilverLight (Moonlight on Linux) to provide the web-client features that you are striving for. I wish more projects were forward thinking, rather than extentions of the past. The MUD world is not dying, it just needs to adapt to the present, like every single other genre that has survived has done. |
||
|
|||
|
|
The flitting about is kind of a common problem for people working on hobbyist programs. Without the structure and driven goals of an average commercial project, we just sort of work on whatever feels interesting at the moment. Set some very clear goals and milestones and you might find that you get further faster. | ||
|
|||
|
|
Aye, I just always feel guilty about working on one thing and not another, which inevitably makes me switch focus. In the end, there just aren't enough hours in the day. I will try to dust off ye olde landmark guide and see how it goes. |
||