Difference between revisions of "Build 1.0.0.0"

From CoffeeMud Wiki
Jump to navigation Jump to search
(Created page with 'The first version could accept telnet connections, and had a full set of standard ROM-like commands. It also had a ROM-like interface, dutifully copied from memory. Here was th…')
 
 
(One intermediate revision by the same user not shown)
Line 1: Line 1:
 +
{{CoffeeMUDAdministratorTOC}}
 
The first version could accept telnet connections, and had a full set of standard ROM-like commands.  It also had a ROM-like interface, dutifully copied from memory.
 
The first version could accept telnet connections, and had a full set of standard ROM-like commands.  It also had a ROM-like interface, dutifully copied from memory.
  
 
Here was the complete commands list:
 
Here was the complete commands list:
 +
 
<tt>
 
<tt>
 
!            AFFECT      AREAS        BACKSTAB    BASH        BERZERK
 
!            AFFECT      AREAS        BACKSTAB    BASH        BERZERK
Line 25: Line 27:
 
</tt>
 
</tt>
  
Not bad, eh? -- though most of those are skill command words of course.  We had 253 skills, spells, prayers, and songs in 1.0, and we supported skill profficiency too!
+
Not bad, eh? -- though most of those are skill command words of course.  We had 253 skills, spells, prayers, and songs in 1.0, and we supported skill proficiency too!
  
 
The architecture relied on a JDBC database; one that any modern user of the code base would recognize if you perused.  It allowed areas to be created on the fly by walking around and creating stuff and then saving the room, just like it works today.  It had affects/effects and behaviors just like the modern codebase, and even had several good behaviors to play with, like MudChat, Aggressive, Follower, and DoorwayGuardian, etc.  Beneath the covers was a thread/tick manager, Grid-style rooms, and all the same base character classes we have today (except for Commoner, added later).  CoffeeMud 1.0 also had an extremely sophisticated message-passing/handling system, and also allowed objects to modify each other using a strange but useful "layered-state-change" system.
 
The architecture relied on a JDBC database; one that any modern user of the code base would recognize if you perused.  It allowed areas to be created on the fly by walking around and creating stuff and then saving the room, just like it works today.  It had affects/effects and behaviors just like the modern codebase, and even had several good behaviors to play with, like MudChat, Aggressive, Follower, and DoorwayGuardian, etc.  Beneath the covers was a thread/tick manager, Grid-style rooms, and all the same base character classes we have today (except for Commoner, added later).  CoffeeMud 1.0 also had an extremely sophisticated message-passing/handling system, and also allowed objects to modify each other using a strange but useful "layered-state-change" system.
Line 31: Line 33:
 
In all these ways, 1.0 is the same as the modern codebase. And at all those ways the similarity to the modern system stops.  CoffeeMud had little or no notion of using XML to define object data, and had absolutely no way to modify the numerous specific objects in the game, or to save the data if it could be modified.  This is because CoffeeMud 1.0 had no notion of a "Generic" object like the modern codebase does.  Everything was Standard.  That meant that, if you wanted a new kind of item you had to code it.  If you wanted a new kind of MOB, you coded it, etc.  You couldn't just create it in the room in which it will reside and then save it.
 
In all these ways, 1.0 is the same as the modern codebase. And at all those ways the similarity to the modern system stops.  CoffeeMud had little or no notion of using XML to define object data, and had absolutely no way to modify the numerous specific objects in the game, or to save the data if it could be modified.  This is because CoffeeMud 1.0 had no notion of a "Generic" object like the modern codebase does.  Everything was Standard.  That meant that, if you wanted a new kind of item you had to code it.  If you wanted a new kind of MOB, you coded it, etc.  You couldn't just create it in the room in which it will reside and then save it.
  
Perhaps the most important command missing from that list above, however, is IMPORT.  Why is that so important?  This is because the 1.0 design was pragmatically flawed.  It assumed people would want to code all their items and mobs, and then plop them into rooms.  It also assumed '''I''' would want to do such a thing.  However, I don't like building areas, which means I don't like building mobs and items.  I had no motivation to do so.  Therefore, once the base engine was working, I looked around and found that noone wanted to make Areas, MOBs, and Items for it.  That meant that the Engine could never be run, because there would never be areas and items and mobs and heck -- a GAME on it to PLAY!
+
Perhaps the most important command missing from that list above, however, is IMPORT.  Why is that so important?  This is because the 1.0 design was pragmatically flawed.  It assumed people would want to code all their items and mobs, and then plop them into rooms.  It also assumed '''I''' would want to do such a thing.  However, I don't like building areas, which means I don't like building mobs and items.  I had no motivation to do so.  Therefore, once the base engine was working, I looked around and found that no one wanted to make Areas, MOBs, and Items for it.  That meant that the Engine could never be run, because there would never be areas and items and mobs and heck -- a GAME on it to PLAY!
  
 
Because of all this, development came to a sudden halt.  It seemed I had nowhere else to go, and CoffeeMud would die in obscurity.
 
Because of all this, development came to a sudden halt.  It seemed I had nowhere else to go, and CoffeeMud would die in obscurity.

Latest revision as of 16:38, 10 August 2021

CoffeeMUD
Administrator                                                  Builder                                                              Player
=CoffeeMUD Administrator Information=
Installation     Help     Development    Modification     Feature Requests     Mud Grinder     ini     Security     CMARE Share     Wiki

The first version could accept telnet connections, and had a full set of standard ROM-like commands. It also had a ROM-like interface, dutifully copied from memory.

Here was the complete commands list:

! AFFECT AREAS BACKSTAB BASH BERZERK BREAK BRIBE BUG BUY CAST CHECK CLIMB CLOSE COMMANDS COMPARE CONSIDER COPY CREATE CREDITS DESCRIPTION DESTROY DETRAP DIRT DISARM DOWN DRINK DROP EAST EAT EMOTE EQUIPMENT EXAMINE EXITS FILL FLEE FOLLOW GET GIVE GO GROUP GTELL HANDS HELP HIDE HOLD INVENTORY KILL LIST LISTEN LOCK LOOK MODIFY NOFOLLOW NORTH OBSERVE OPEN ORDER PASSWORD PEEK PICK POISON PRACTICE PRAY PRAYERS PULL PUSH PUT QUIET QUIT READ RECALL REMOVE REPLY REPORT RESCUE REST REVOKE SAVE SAY SCORE SCROLLCOPY SEARCH SELL SING SKILLS SLEEP SNEAK SOCIALS SONGS SOUTH SPELLS SPLIT STAND STEAL SWIPE SYSMSGS TAKE TEACH TELL TRACK TRAIN TRAP TRIP TURN UNLOCK UP WAKE WEAR WEST WHO WHOIS WHOMP WIELD WIMPY WRITE

Not bad, eh? -- though most of those are skill command words of course. We had 253 skills, spells, prayers, and songs in 1.0, and we supported skill proficiency too!

The architecture relied on a JDBC database; one that any modern user of the code base would recognize if you perused. It allowed areas to be created on the fly by walking around and creating stuff and then saving the room, just like it works today. It had affects/effects and behaviors just like the modern codebase, and even had several good behaviors to play with, like MudChat, Aggressive, Follower, and DoorwayGuardian, etc. Beneath the covers was a thread/tick manager, Grid-style rooms, and all the same base character classes we have today (except for Commoner, added later). CoffeeMud 1.0 also had an extremely sophisticated message-passing/handling system, and also allowed objects to modify each other using a strange but useful "layered-state-change" system.

In all these ways, 1.0 is the same as the modern codebase. And at all those ways the similarity to the modern system stops. CoffeeMud had little or no notion of using XML to define object data, and had absolutely no way to modify the numerous specific objects in the game, or to save the data if it could be modified. This is because CoffeeMud 1.0 had no notion of a "Generic" object like the modern codebase does. Everything was Standard. That meant that, if you wanted a new kind of item you had to code it. If you wanted a new kind of MOB, you coded it, etc. You couldn't just create it in the room in which it will reside and then save it.

Perhaps the most important command missing from that list above, however, is IMPORT. Why is that so important? This is because the 1.0 design was pragmatically flawed. It assumed people would want to code all their items and mobs, and then plop them into rooms. It also assumed I would want to do such a thing. However, I don't like building areas, which means I don't like building mobs and items. I had no motivation to do so. Therefore, once the base engine was working, I looked around and found that no one wanted to make Areas, MOBs, and Items for it. That meant that the Engine could never be run, because there would never be areas and items and mobs and heck -- a GAME on it to PLAY!

Because of all this, development came to a sudden halt. It seemed I had nowhere else to go, and CoffeeMud would die in obscurity.