<< Previous | Home

MUD, MUSH, MOO, MUX ... what?

Spent an afternoon with Battletech MUX

One afternoon I found myself with some time on my hands. This is a rather unusual experience. After mindlessly reading some news I began yearning for simplier times. At some point I found myself remembering early gaming experiences. Perhaps not my very earliest, but a period from my days at university where my grades suffered a little from how much time was being spent playing text based games. In particular and assortment of MUDs, MUSHes and MUXes collectively referred to as MU*.

For the uninitiated these games have a fair claim to being the precursors to the current day MMOs. Unlike modern MMOs they are entirely text based. The different flavours of MU* tended to emphasize different features or gamestyles, and consequently audiences. The engines powering these games were mostly open source and shared freely. This meant people could very easily start their own games, and within the scene, this paradigm evolved quickly into a large taxonomic tree of text based games. Some where very heavily focussed on roleplaying and player interaction to create the game world, others had sophisticated coded mechanics and in many ways gameplay resembled the grinding aspect that one might find in a modern day MMO. A handful of games had mechanics and gameplay that were incredibly ambitious, world spanning, complex economies, factions and thousands of players simultaneously, playing and building together. All achieved despite the software oftentimes being buggy and held together with duct tape. It was glorious. Some of the best would rival even todays MMOs in nuance, balance, faction management and gameplay.

These games had a golden era in the mid to late 90s where you had a cornucopia of choice, and rival MU* admins would attempt to woo players to their work of art, competing for audience. The most popular often had the solid unique features or did something really well, be it strict adherence to in character role play or blood thirsty automated combat.

Much of the "language of the internet" or internet slang that we now take for granted was birthed into the world in these games. Turns of phrase we might think of as being more recent were in fact in common use in these text based terrariums of imagination.

Richard Bartle, who with Roy Trubshaw is widely credited with developing the first ever MUD, interviewed years later, made the following assertion. "Text is more expressive than graphics. It's also more descriptive, there are no smells in EverQuest. With text, I can talk to the mind. With graphics, I can only talk to the senses." Certainly they were very popular for a time, and some still exist today.

Of the many choices, the flavour that sequestered more of my time than any other were a slew of Battletech based games.

MUShes (multi-user shared hallucination), MUSE (multi-user shared environment), MUX (mult-user shared eXperience) all got Battletech modifications at some point or another. The modifications were largely "hardcode" which in the case of these MU* meant C and/or C++. In the parlance of MU*, "hardcode" is the code of the base system, of the MU* itself, and "softcode" is written in a higher level interpreted language that runs within the MUD software itself. Over time the most mature Battletech hardcode coalesced around the MUX codebase. This eventually was homed and maintained in a sourceforce project called Btech-Online Battletech MUX. It was in development for many years but at some point, it seems to have petered out. There have been no recent commits.

Recently I really wanted to play one of these Battletech text based games again so I decided to try out the code and see if I could get any enjoyment from it. It wasn't that hard to get going, and before I knew it, I was running around on a game map.

Satisfied with that experience for the time being I took a closer look at the code, build system and started trying to understand how it hung together. The code compiled with a lot of warnings, which felt a little unhygenic to me to so I went about examing all the warnings and fixing the issues discovered. I found that cathartic, considering my mood, so I kept going. Before I knew it, I had cleaned up the entire codebase and now had a bunch of changes on disk.

I thought about sending the patches back to the sourceforge project, but considering the mailing list was full of spam and it seemed like everything was completely quiet I decided instead to import the code into my own github.

A few nights later I wanted to have another go at the Battletech MUX and thinking about the compile warnings I had cleaned up earlier I wondered what I would discover running the codebase in Valgrind. I suspected this had never been done. Valgrind is brutal and I figured the codebase would be in much better shape if Valgrind had ever actually been near it. I spent a little while trying to get Valgrind running on my Mac. I gave up in short order. Valgrind has never really agreed with OSX and it seemed on that occasion that was true again. Valgrind as of this writing has not yet been updated to run on my current version of OSX (10.15.6). I turned my attentions to other tools like the clang sanitize checker.

Switching some of these on I immediately found issues just starting up the MUX server. I fixed them and committed the fixes to the github repository. I found myself wondering what am I doing? Don't get sucked down this rabbit hole. No, no I justified to myself. I am maintaining I game I rather enjoyed and maybe I'll improve it a little along the way; for fun I guess. If you're interested in the code you can find it here. It seems very possible I will continue cleaning it up and improving the build system, code and documentation.

Lifting deprecated OpenGL code to modern equivalent

OpenGL 3.0 to OpenGL 3.3+

OpenGL has been around a long time. This has necessitated some pretty aggressive, or we could call it, slightly odd, deprecation over time. This was necessary to keep API relevant.

Until version 3.0, all versions of OpenGL were fully backwards compatible with earlier ones.

OpenGL 3.1 is just awkward and short-lived, it is probably not worth explaining; we'll ignore it.

In 3.2, OpenGL was effectively split into two profiles, core and compatibility. An implementation was only required to define core, so compatibility is not guaranteed to be available.

On some platforms, like Windows, developers will find that they have access to the compatibility profile and they can gracefully or incrementally move functionality towards the new standard. On other platforms, like Apple OSX there is a hard cut. They chose to support OpenGL 2.1, and the pretty much ignored the in-between, and then, made the jump to OpenGL 3.3. Apple also chose to only implement OpenGL 3.3 core. This means there is no graceful support of older functionality.

Developers finding themselves having to lift OpenGL code in their title or package may benefit from the reference table below. It roughly details the mapping between OpenGL 2.1 era functionality and how to replace it in OpenGL 3.3 core and higher.

Hopefully useful for others as well as us!

Deprecated functionalityReplaceable by (in OpenGL 3.3)
Fixed function pipelineShaders
/glMatrixMode/glLoadMatrix/glMultMatrix etc.
Use you own matrix math or known open source libraries. Did you really use it anyway?
glTexEnvfTexture blending should now be done in fragment shaders.
gluBuild2DMipmaps Use the GL_GENERATE_MIPMAP texture parameter or the glGenerateMipmap function. Set the max mipmap level and the base mipmap level using

glEnable(GL_POINT_SMOOTH)Emulate this in a shader if you miss it
glEnable(GL_TEXTURE_2D)No longer. Ue glActiveTexture(GL_TEXTUREn) and bind the texture to the n-th texture unit.
glVertex*/glColor*/glNormal*/glTexCoord*Use vertex buffer objects (VBO) and vertex attribute objects (VAO) to control vertices. Draw using the glDraw{Arrays, Elements, RangeElements, InterleavedElements} family of functions.
glPolygonMode(GL_FRONT, GL_LINE) or glPolygonMode(GL_BACK, GL_LINE) In OpenGL 3.0 or above, core profile, only the combined front and back face enumerant is valid, offering a single mode enumerant GL_FRONT or GL_BACK results in an INVALID_OPERATION. Therefore the only valid call is glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);

Planetoid Pioneers is a GO for launch

Planetoid Pioneers has officially launched

Planetoid Pioneers has finally, officially, released. The effort slithered into pre-production at the beginning of 2010 with experiments on ideas, art direction and gameplay. It was initially available through Steam 'Early Access' from 21 July 2017, and as of 8 February 2018 it was tentatively freed into the wild.

It has been a labour of love and commitment to maintaining creative control over almost every part of the development and creative process. The bulk of the subsystems in Planetoid Pioneers have been built from the ground up in c++ and lua. The graphics engine, the physics engine, the animation system, the toolchain and the game editors all built by the team. The team's dna is stamped all over the game for better or for worse.

There is for now a moment to dwell on a deep sense of satisfaction and the ability to take a very short breath. Then begins the watch to see how the market responds, and the nose will again hit the grindstone as the first bugs surface and hotfixes must be written, tested and released. When things settle down we move to work on the next stage of the roadmap, localisation and porting to additional systems.

For now, enjoy the official Planetoid Pioneers launch trailer and we hope you buy our game!

You can buy the game on Steam right now.

p.s. Check out the first review at Kotaku.