'I'm running a Mud so I can learn C programming ' (1993)
raw.githubusercontent.com
raw.githubusercontent.com
What I loved about the MUD as a learning environment was the players. On a busy night we'd have over a hundred people playing. So, I got to cut my teeth on a real, live production system with actual users. That motivated me. There were mild consequences if I broke things. And, if I made things better for the players, it felt good.
For me, this environment was so much better than doing programming problem sets by myself, writing code that no one would ever use.
I always thought a programming class with assignments to add spells/new weapons/quests/etc on a shared class server would be great.
And not just C but Linux (Slackware!), sockets, even kludging the single-player DOS port to be two-player by playing over a serial cable to another PC. And annoying my future Dropbox teammates by including an extra space after/before parens in function calls (and if/for/switch statements), putting { on its own line, etc as was the convention in that code base IIRC.
MUDs taught me C, devops, multiplayer/sockets, security to some extent, databases (I wrote my own MUD that used MySQL). Also HTML/webpages eventually. MUDs taught me the full stack.
I wonder what would have been of my life had i not encountered mIRC.
Much water has passed under bridges, yet there are dozens of us even creating new ones and doing all sorts of weird things with this great hobby.
The Multi User Dungeon discord is nowadays the place to meet like-minded people who like, or code, or balance, or design, or write or use clients for, MUDs. Join us at https://discord.gg/multi-user-dungeon-279748146316312576
IAC WILL MUD
No data structures, just lots of arrays. Instead of something like "player.health = 100", it was "playerHealth(playerIndex) = 100".
If I wanted to make a player hit a monster, it was like "monsterHealth(playerTarget(playerIndex)) -= playerStrength(playerIndex) + weaponDamage(playerWeapon(playerIndex))"
Awful and unmaintainable.
Finally, doing things the right way no longer seems like overthinking but instead a massive timesaver longterm.
GET THIS STRAIGHT: 'VAX' IS A CPU ARCHITECTURE AS WELL AS THE NAME OF SOME COMPUTERS CREATED BY DEC. The plural of "Vax" is "Vaxen".
unlike other MUDs it had a built-in ftp server, and ed. i learned concepts like trampolines and blueprints, which i later learned were closures and classes. and i learned about inheritance and objects. conveniently, objects in an LPmud are real tangible objects like a dragon or a sword.
remember those dumb sounding introductions to OO programming, like class dog, inherits animal? in LPmuds you really have examples like that: class dwarf, inherits NPC, or class sword, inherits weapon.
one of the features that LPmuds needed was the ability to update objects from changed classes/blueprints at runtime without restarting the server so that the wizards could work on the game while others were playing it. it was coding in production, but usually the areas in development were closed of to regular players. but you can imagine how robust LPmuds and LPC had to be to enable that.
then the web came up and i was looking for a better webserver than the ones from NCSA and cern. i discovered spinner. and to my surprise i found that it was written in uLPC, a rewrite of LPC. spinner was renamed to roxen, and uLPC was renamed to pike.
spinner/roxen had modules that were easy to write: class mymod, inherit SomeModuleType, do stuff.
roxen modules were objects that got instantiated each time a http request was made. the http request object would call them in some order and let them do their thing and add data to the response object. i wrote many such modules to customize the behavior of my websites. one morning i woke up and realized what OO programming really meant because i understood how the different objects interacted with each other and encapsulated things. until then i had only been going through the motions because that's how i learned to do things, but i didn't know why.
roxen also was able to reload modules from changed code at runtime. (remember the LPmud ability to reload objects? it's the same feature. in roxen it was a bit weaker because it only applied to new instances, but that was intentional, because unlike LPmuds, in roxen objects were short lived anyways)
fast forward almost a decade and i discover open-sTeam, an object storage server written in pike, using MUD concepts internally. it had rooms and doors/gates to connect them. users logging in had an inventory and could pick up and drop documents like objects in a MUD. it also had object level access control. the developers said they chose pike because it was the only language that allowed them to implement this kind of access control. and here too, like an LPmud open-sTeam has the ability to reload objects with new class code. and unlike roxen it does so for existing objects too.
i am still using open-sTeam to build my websites today, after modernizing it by adding a REST API combined with a modern frontend framework. and i can do live coding while the server is running. for my own websites i do that in production. for client websites i keep a separate dev server. although, since the server is so rich in features i rarely have to do any custom backend coding. most of the work in in the frontends now.
> === How to Learn in the First Place
>
> (1) Play with something.
> (2) Read the documentation on it.
> (3) Play with it some more.
> (4) Read documentation again.
> (5) Play with it some more.
Great stuff -- I remember my proudest moments were adding color to the various system messages (vanilla Diku at the time didn't do that), and adding online level editing with saving; previously you had to create maps offline.
Never contributed upstream (I was in high school and didn't even understand what that would mean), and eventually kind of drifted away from the community. But I got a ton of experience in just jumping in and working in C.
Found this repository of MUSH code if anyone is curious what it looked like: https://www.mushcode.com/
Modifying Eggdrop (the IRC bot written in C) was another project that contributed to my early understanding.
I'm convinced the Slack-killer is going to be a user programmable MUSH.
If there's any interest:
Archived MOO knowledge: https://lisdude.com/moo/ Modern MOO server: https://github.com/lisdude/toaststunt/ Active social MOO: https://chatmud.com/
Those who picked emacs from that list never got the point of writing any code for the MUD. They greatly contributed to OS development all over the world however.
Shit, I even tried not to become a programmer, but people kept offering me jobs that paid enough that it was hard to say no. At some point it's like... grad school and some career I want at poverty wages and having to work hard to find employment at all, or stare at glowing screens for the next few decades but just have high-paying jobs thrown at me based on stuff I picked up by accident?
Later I wrote a string intern() function for a highly modified MUD that was having memory issues. But they balked at the complexity of having to use a malloc/free replacement even after I made the arena logic dead simple :/
Also the first implementation of a Slab allocator I ever read about, by a wide margin, was in LPMud, which one of my roommates and a friend were into. I wouldn't hear that concept again, unless I brought it up, for a decade or so.
For example, many gameplay mods allowed players to dynamically place new entities (walls, platforms, turrets), and if your team was too competent and you got bored guarding the flag you put on an a client-side script to play Tetris in a custom HUD.
> If you have access to a program named 'Purify' ... learn how to use it.
Anyone know what this was or use it?
Fun fact: it was written by the cofounder and chairman of Netflix.
Probably P2C was the best, followed by gpc years later, and finally FreePascal came to be.
For conventional BBS's running standard doorgames, there were only a few true MUDs (mostly on the later / post-dial-up time frame) and it varied a bit more, but I can say DoorMUD was definitely written in C++.
I got my first compiler (Turbo Pascal 2.0!) from a friend's mother who was taking CS classes at the local community college. It ran on her Tandy 1000, I'm not sure what they wrote programs on at her school but she always had stacks of greenbar paper with source code on them.
I mean, this is 1993 and they did mention DOS. But reading this, you would not know that most of those DOS machines were running Windows and that they were far, far more numerous than either UNIX or VMS. And Windows NT was already released when that was written.
Not that I am a Microsoft apologist. My main machine was OS/2 back then, I was already using Linux, and ( if I had the money ) NeXTstep would have been my dream platform.
Why not include the microcontroller in microwaves, too? Because those aren't real computers.
(All in good fun! I don't endorse such an opinion, but it would have been common among both VMS and Unix users at the time. After all those PC OSes don't even have networking or preemptive multitasking.)
You didn't need to have a local TCP stack running to use email, ftp, etc. You'd just have a shell account somewhere and/or use dedicated dialup tools
A 286 could do it as well, but then you wouldn't be able to use the new enhanced mode.
The large majority of folks were still running straight MS-DOS.
Also the games industry only adopted Windows after Windows 95, very few titles cared about WinG on Windows 3.1 / 3.11 / Win32s.
My recollection is by 1994, Windows 3.1 was everywhere. My school had literally dozens of computers running it. It was on every PC at my father’s work. We had several computers in our house and they all ran it except the 286 we used to play games (which my dad ended up giving to his brother, since it was a big upgrade to the 8086 he’d been using to run WordStar)
At home we didn’t run Windows 3.1 full-time, we’d exit to DOS to play games. But we’d use Microsoft Word to write assignments for school.
I dual-booted into OS/2 2.0 because I was really into computers. Nobody else in the house knew what to do with it, and I didn’t know anyone else who ran it. After a while OS/2 got replaced by Slackware, and nobody else knew what to do with that either.
My school had mostly MS-DOS 5.0 computers, the UNIX class was taught by bringing a PC tower with Xenix, where the class would take 15 m turns after preparing their samples on MS-DOS with Turbo C 2.0, and it was a model school.
In 1992 I did my typing exam using MS-DOS 3.3, on edlin.
The other school down the block was still using Amstrad PC1512, with CGA and EGA monitors.
Most of us had Ataris and Amigas at home, if families were rich enough, otherwise we had to still make do with our C64 and Spectrum variants.
9 year old me started using Windows 3.0 in 1991, when it was still quite rare in the home. My dad pirated from his work, which were adopting it. But by 1994 or so I was seeing Windows 3.x everywhere (mostly 3.1 or WfW 3.11 instead of 3.0)
I went to three different primary schools. First one (1987-1991) had Apple IIs; second one (1991-1992) had one computer lab containing IBM PC JXs running DOS (the JX was a derivative of the PCjr only sold in Japan, Australia and NZ), another with Acorns, and classrooms had a mix of Apple IIGS and 8-bit Apple II; third one (1993), our classroom had a C64 and an Acorn, and I know some other classrooms had Macs. Secondary school (1994-1999) was all PCs and Acorns. I think all the PCs ran Windows 3.x (later in 1990s newer machines got Windows 95), and most were in Windows nearly all the time. The exception was the machines in the CAD lab, which probably had Windows installed, but our CAD software only ran under DOS, so Windows was rarely used on them.
Around 1997 or so people were throwing out old 8-bit machines like crazy. I went to the school fair and bought a pile of Apple IIs and C64s for $5 each. Unfortunately my dad made me get rid of them all because he didn’t like the clutter.
Not everyone was into Windows 3.x.
Windows NT 3.1 was released on July 27th; this document was dated August 1st. Basically nobody had a copy yet; even if they did, MERC wouldn't have run on it without substantial porting effort, as it depended on Berkeley sockets.
Merc did allow for compiling on Mac and MS-DOS, but in this mode reads and writes to the console, without a socket implementation. No multiplayer.
See: https://github.com/alexmchale/merc-mud/blob/master/src/comm....
A lot of people used third party Winsock implementations, e.g. Trumpet Winsock, under Windows 3.1. As a 1990s teenager I remember seeing it a lot. Even into the second half of the 1990s, because it wasn’t like all Windows 3.1 machines were upgraded as soon as Windows 95 came out.
Network PC games of this era were written using DOS extenders and IPX networking.
In 1993, there weren't many third-party controls. Any networking was accomplished through FFI.
Later I tried Windows NT for a server and it was on such a different level, no comparison. It worked like real operating systems should.
In 1993, (regular, consumer) Windows didn't really "support" networking; (limited) OS support for networking was something only available in Windows For Workgroups, which itself was something you'd only expect to find installed in offices, not on the kind of home PC owned by someone dialing into a MUD.
I believe that you could run these networked programs in a Windows 3.1 OS DOS virtual machine, so you didn't have to reboot fully into DOS just to run them.
But it makes sense, from the perspective of an author of networked software at the time, to think of IBM PCs as being "MS DOS machines." That's the abstraction the developer had to work against for that port of the software.