You are looking at an introduction

Welcome to the history of cow
These historical documents show some of my frst thoughts about a cow with reacting objects.

My first cow however was a static world of objects without reactions.

But lets start at the very beginning.
The first crystalisations of ideas I had about a Multi User Dungeon came from enthusiastic brain-storming sessions with my cousin Dale in 1993-4 (possibly earlier).

It was going to be called Object Oriented Imagination Engine (OOIE). It was going to be a fantastical world where objects made up everything in the world, including the descriptions of the locations. Objects would be very manipulatable, reactive, and full of detail. if you dropped something and it was glass, it would break.. if you put something on an object which was hot it would melt if it was a meltable material or burn or just glow red. Doors would be portals between locations so you could carry a hole in your pocket, drop it and jump through the hole (Like yellow submarine).

When we started coding this fantastical world we used TDBS which was like dBase which ran on the DOS multi-user BBS called TBBS run by DIRCSA.

Dale coded a propotype OOIE which simulated the conept of walking through a cave and meeting random objects. This was effectibly a series of print statements randomly appearing, but it was very inspiring.

The next step was to start getting some real objects being stored and displayed, so while Dale continued work on the real OOIE I started playing with simple object storage and display mechanism.

So as not to complicate matters by call my code OOIE I wanted to give it a whimsical name indicating that it was just a trivial bit of experimental code - as compared with the real official OOIE we planned to make.

This was when Creative Object World (COW) was born. Cow being a funny name since it was a kind of MUDdy MUSHy MUD or MOO.

As Dale slowed his coding work on OOIE, I increased my work on COW until I had a functional environment with objects you could create and describe and they made up the description of the room you were in.

This first cow was a static world and things only happend if a player did them. Nothing reacted or moved by itself. Sadly the amout of CPU time this would involve as prohibitive on the server it was running on (I think it was a 486)

Concepts demonstrated in the first cow:
  • creating objects, describing them (very complex with material, feel, colour, size, weight ...)
  • players were objects like everything else
  • doorways were linked objects
  • payers could possess other objects to animate them
  • multiple ways of 'saying' things like think, do and shout
  • macros of commands so making a new location involved creating several objects, and moving one inside the other

    I then started to ponder the concept of reacting objects - getting objects to respond to their envionment.

    This was going to be called cow2. It was was around 1988-89 and the natural choice at the time was DOS based Clipper, thinking I could run it on a LAN or just a stand-alone exe.

    The examine the old parchment about cow documents some of my thoughts - at the bottom is the compile log as I generated new versions of the exe.

    Time passed and windows became a more suitable environment to run a cow client in so I started first an MS Access version then a Delphi version.

    After a while I discovered the potential of web-based scripting (in perl) and some time in 2000 my first tentative steps into a cow on the web started. type: examine perlycow] are some of my thoughts with examine cowheart and examine cowhtml as my first perl versions of cow.

    Originally I planned to store data in text files or my own database format 'brrm' (remove all reliance on specialist modules). The complexities of searching became too much for these formats so in comes MySQL as a nice cross-platform database and my first reliance on a module (Ah well).

    I tried PHP and Perl accessing MySQL in a basic speed trial and they were almost identical so I continued with Perl as I was more familiar with it and, again it was more common/portable.

    Around this time I also wrote the basic JavaScript to handle passing msgs around the screen and scroll frames etc..

    Against all common sence I decided that one single script should generate all of the html (frames included) and do all of the database access. I wanted it to run as fast as possible so I eliminated the time wasted loading libraries of functions and HTML template files.

    I also wanted anyone to be able to extend its capabilities so I created COWScript and made all of the commands objects in cow which could be easily edited. without uploading a new cow.pl

    10 July 2003 was when I registered wolispace.com The first live web server with Perl and MySQL ready for me to open my offline development to the world.

    Progress was slow but by 16 May 2004 (my 40th birthday) I had a good prototype of no-frames version of cow running. Objects did not react at this stage but I had the basics of COWscript in place so that all of the commands were objects wihin the worl world.

    At some magical moment I worked out how I could combine COWscript (for commands) into a common script all objects could use to react to their surroundsings so finally I had a fully reactive scriptable environment.

    Sometime during late 2004 I had a frames version of cow up and a curious fellow from France called xiii popped in to see what was going on. Xiii understood what cow was about and his curiosity spurred me. (before then I would let months go by without touching any cow code).

    My regular testers until then had been Joshua and Jacqui and Nathan.

    Spurred on by ideas from my testers and the desire to show new functionality to xiii we now have currency, banks and shops. images and sound and a means of daisy-chaining messages from one cow server to another (I set up link: cow.bur.st in Jun 2005)

    Im very happy with what I have achieved sofar and now cow is up and running, I cant see it ever stopping. It will get passed on from generation to generation, or friend to friend. New cow servers will pop up (each with their own unique set of commands) and communicate with each other. So long as someone is interested enough to pay the annual hosting fees cow wil live on for a long time.

    Now in Feb 2006 I have purchased a nice new Athlon 64 with a Gig or ram and I am hosting cow from this. I did this because link: mysitespace.com disabled cow.pl from running on their servers as it was causing too much of a CPU drain (we had 6 ppl in at once and that was enough to tip it over the edge).

    Since its running on a dedicated PC it is very very responsive.

    My next major coding plan is to re-write cow.pl to be much more efficient as far as SQL requests - right now its very lazy and makes about 35 SQL requests just to display the contents of the open field.

    By moving the location redering to the client via JavaScript (or whatever anyone else wants to do) we can simple pass lists of objects to the client which then uses its own CPU.

    When I have done this, cow can return to the wild and run on any server as planned.

    Well its Dec 06 and there are a few things that should be documented in this history of cow.

    Cow can now generate rss feeds. List of objects in a rooms or searches. The Daily COW is now beamed out to the wrorld with an average of 13 subscribers at present.

    This is quite handy as I am using feedburner.com which means there are regular visits every 30 mins from feeedburner.. and this regular visit is used to do some routine cleanup and command processing. Google is still visiting but has always been very iregular.. (massive hit every second for a short while then a week with little activity).

    Another change has been the impact Thorn has had on cow. Almost effortlessly, he has been creating some very complex objects and bringing the concept of managed processes (like the battle system) and skills that slowly increase as the player does things.

    Previoudly I had thought of a battle as objects performing hit commands.. meaning if you can type fast or are on a fast connection, you will usually win. With a battle system this process is managed by a seperate objects. It calculates the hits and misses, raises skills and generally orchestrates the process evenly.

    This concept of managed processes then raised the issue of having to copy objects and their code.. and he frustration of having to re-code each object if bugs were found or an improvment thought of.

    The solution was to use objects material and class to inherit code from top-level objects like 'a material called player' so every object of class player get the materials code. Change the materials code and all player instantly (no copying,this is in real-time) get this change.

    Thanks to the ingenious RLIKE statement in MySQL an object can have multiple materials in the one string and react as if they had the cod copied within them.

    The second wonderful change this whole process required was a better way of managing variables for an object. Originally I provided 3 slots fields per object for storing miscelanious information. I then provided the concept of 'pocket variables' where any field name not found in the object table was assumed to be a named object inside the object being manipulated. This works well and means there istecnically no limit to what additional information is stored with an object.

    The down-side of this was that Thorn's battle system and skills need to store alot of variables hich meant eery object involved with a battled ended up with about 6 objects inside it.. and these objects all started to add up. Right now there have been 216 objects involved in a battle.. think of all those objects.. and some are simply in existance just to store a singe digit.

    So the solution was to store these extra values in a single delimited string in the object table. I implemented a nesting key=value pair concept so the complexities Thorn needs for skills and modifiers and other such things can be handled in cowScript with relative ease. Shortly all of the pocket variables will be deleted after converting their values into a neat delimied string.

    With all of these new reacting objects, sometimes the real live players could not get their commands processed as the reacting objects around thm were hogging the command stack. First I showed a graphical representaiton of the number of pending commands.. to atlease players could see there was a reason for things going slow. Then I foud a way to give player commands priority. Now all player entered commads will be executed first and eventually reacting objects get processed.

    While Im on the topic of processing commands.. I also added the concept of futre dated commands.. they can be added to the stack, but not processed until a date/time has passed. This helped me shift the tickhour reactions - objects that react every hour - so they all happen at their own time, each hour not all at once at 7pm then 8pm.. again clogging the command stack.

    The final thing I want to mention right now, is that I thought of making cow eco-ware. meaning people who use cow should switch of an electrical appliance so that I can keep the cow server running 24 /7. With enough people offsetting the cow server I will feel alot better about running a PC day and night. As of today 14 Dec 07 I have had 2 'donations' of appliances that will be turned off while the players are in cow. How satisfying is that!
    Created by wolis, last updated 31 Jul 2015