FAQ: Personality Clash - extra Server Design info included

Reed Reed
Tue Dec 23 22:37:16 CET 1997


> Personalities Summary
> ~~~~~~~~~~~~~~~~~~~~~


--
Here, I'll stick my info in here following format, though I'm going to
include quite a bit of my server design goals and the like since I've
been so silent about it since I joined (I've pretty much been a lurker
for months - a very interested lurker, but a lurker nonetheless)
--

Reed Copsey, Jr.

Occupation: 
	- Whatever I find at the time (Usually programming or database 
	  administration or setup)
Addy: rdc at efn.org
Personal details:
	- Too damn busy to do anything
	- Spends lots of time lurking here, and unfortunately doesn't
	  participate nearly as much as he should and would like to
	- Basically a self-taught programmer who spends more time
	  tinkering and coming up with different ways of doing things
	  than getting anything productive written
	- Is always trying to figure out the best (and cheapest, as he's
	  currently way in debt) way to learn just about anything he can
	  get his hands on
Secret Server Project:
	- Kolmteist

Server Highlights:
	[ Note: This is mostly in design phase.  I very recently decided
	  on a complete rewrite for both the server and the client, so all 
	  that's left that is at all useful is some basic utility-type 
	  classes: socket handling, data structures, string handling, etc... ]

	- Written in C++
	- Uses a relational database backend, though total persistance 
	  is not (yet) a major goal (though this has changed many times 
	  as he comes up with new arguments for or against it)
	- Completely event driven
	- Object customization through an internal extension language
		- Current design (which will probably last another week 
		  *snicker*) is actually inspired by MS Access (yuck),
		  with simple extensions being written as very straitfoward,
		  macros on any object, which have the ability to call 
		  user-written procedures, hopefully allowing some semblance
		  of flexibility in a roundabout way
		- Hoping to allow players to use the same macro interface
		  in a stripped down manner to allow for a fairly high
		  degree of player-customization and automation (see below)
	- A significantly slower-than-average combat system which is 
	  completely unautomated unless macros are used... (Roughly turn
	  based from the player's POV, with a turn/round once every few 
	  seconds, the avg fight lasting 1-4 minutes)
	- Completely disassociation, both in code and in game, of players and
	  wizards/imms. (builder/administration have no direct in-game form)
	- A custom client required for various reasons:
		- direct path (completely bypasses the game server) to the
		  relational database backend, allowing building
		  and game administration even if the mud is down or the 
		  builder doesn't want to deal with people
		- more flexibility in display to allow better-than-ansi color
		  and text handling parsed client side, inline images, and
		  some html-ish functionality simalar (and inspired by)
		  various mud extensions chaco add in pueblo (point and click
		  commands, etc)
		- the ability to spawn multiple windows (crucial)
		   - Will have an account style login, with menu's to choose
		     which character(s) to play, each of which spawns a separate
		     window.
		   - All out of character communication, information, etc will
		     be directed to the account window (or a private chat-style
		     window spawned for private, ooc communication)
		   - the hope is to encourage roleplaying by complete separation
		     of VR and non-VR commands, both in the commands (without
	 	     using a special character like $, @, or #) and in output



-- Reed



More information about the mud-dev-archive mailing list