Build 1.2

From CoffeeMud Wiki
Revision as of 19:37, 27 October 2014 by Bozimmerman (talk | contribs) (Created page with 'CoffeeMud 1.2, or CoffeeMud 2.0 if you prefer, was a revolutionary version. Why this is so requires some explaining. In philosophy we learn that ones world view/philosophy prov…')
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

CoffeeMud 1.2, or CoffeeMud 2.0 if you prefer, was a revolutionary version. Why this is so requires some explaining.

In philosophy we learn that ones world view/philosophy provides the boundaries beyond which our imagination rarely reaches. For CoffeeMud, this philosophy revolved around the Java Object. I had imagined and built a system where all content would ultimately be written in Java, with database storage providing only the basic "Glue" that would tie the java pieces together.

However, as I explained in the write-up for CoffeeMud 1.0, this was a dead-end out of which I saw no escape. Until I did.

When pondering the problem of how to get people to code Java content for a real CoffeeMud "game", it dawned on me -- I'll just use other peoples content! MUDs had been around for almost 10 years, and surely lots of interesting game content had been designed. From this lightbulb moment came the realization that CoffeeMud would have to support loading and using data written for very different MUD engines. This realization led to the breaking of my world view: CoffeeMud would no longer be a system which relied on 100% java coded objects. Instead, or perhaps, in addition, it would provide for objects whose definitions were stored only the database, and merely supported by the java codebase. The purpose of the CoffeeMud database would expanded to meet this new demand, and so would the engine itself.

I then set off to write the most important command in CoffeeMud 2.0: IMPORT. This command allowed the engine to read in area, mob, and item definitions written for very different code bases, and then convert them for use in CoffeeMud. The object definitions would be stored in the engine using a string format called XML, a data storage scheme coming into its own at that time.

Suddenly CoffeeMud had features necessary for its rebirth: the ability to receive content written by others, and the ability to create content outside of the Java programming language.

From there, CoffeeMud exploded in functionality. As I wrote IMPORT, I found myself writing more and more features, usually Properties, Behaviors, and skills, to support those described by the area description files of other code bases. I was practically guarenteeing myself that CoffeeMud would be the equal of its peers, a totally unforseen bonus to the exercise.

When it was done, I not only had a better MUD engine, I actually had a MUD I could make available to players! There was actually something WORTH playing.

I had a real LIVE MUD.

From here on out, development on the engine proceeded at a breakneck pace which hadn't been seen since its inception.

However, this led to another sort of wall: my own creativity. As an application developer at heart, I tend to think in terms of capability and flexibility. I often lacked the imagination to see beyond an extension of what was already there. The developers who had helped me start CoffeeMud were long gone, and they had too little experience with MUDs to really have any unique vision for it. What I needed was someone capable of seeing not just what the engine could do and do more of, but also what it could become.

My stagnated mode of development continued into the next version (1.2.5 or version 2.5), but that would all change with 3.0.