MUDs are the text-based precursor to MMOs and there are thousands littered across the internet – some even have hundreds of players!
Without the limitations of graphics, the systems can get quite intricate and the pared-down text interface helps expose the workings of these mechanics. It’s easy to figure out how game dev objects work once you interact with Iron Realms crafting, for example, where you enter descriptive text for every situation a player might encounter.
Links (but don’t just go by the top games, some ancient abandoned games have interesting ideas as well!):
Some of my personal favorites for game design inspiration:
– New Moon. Has fun NPC design, like arresting players (complete with jailbreak attempts) and different day/night behaviour. Very responsive to command-based exploration. http://eclipse.cs.pdx.edu/
– Iron Realms Entertainment. Company that runs several polished, staffed games. Lots of complex systems like intricate combat, sea/spacefaring, puzzle quests. https://www.ironrealms.com/
– Avalon: the Legend Lives. Big historic game, was the first online multiplayer rpg. Mostly abandoned and buggy these days, but it has some very interesting ideas. The economy/warfare system in particular is fabulously designed, with constant tension and resource management ensuring player cities always want to skirmish for power. The war system got an update that made it REALLY complex, but there might be docs online of the older, more elegant version. https://www.avalon-rpg.com/
***Important note***: this post was originally written a few years ago – Avalon is now offline, which is a fucking shame because it should be documented for video game history.
WARNING! SPOILERS FOR THE GAME INCLUDED IN THIS POST!
I’m quite excited to share this postmortem!
I’ve finally returned to Succor, a game initially made in a jam, and given it a major overhaul and update. I feel comfortable with where the game’s state is (though there’s always going to be a temptation to tinker more) and I’m happy to call it a finished, polished play experience. Most of my game creations are jam experiments, so it feels particularly nice to be able to put a stamp of “finished” on a game – one step further down the road in becoming a proper game dev!
Background
This game in particular feels a bit emotional to finish. Not only does the game cover rather deep and dark topics about trauma and memory, it’s my first coding project in nearly a year after struggling with major health setbacks. For many months, I couldn’t even sit at a computer, much less wrangle my brain into coding or writing extensively…but the final word count is around 20,000 words! Phew!
The original jam game was a small experiment in how traumatic memories can be sparked by things as mundane as reading a menu and encourages players to battle these demons by making either constructive or destructive choices. The new version has expanded on this concept, with many more additions to content.
Code and Design Updates
As this was a project created fairly early in my game dev journey, a lot of this code was a MESS and I spent a decent chunk of time focusing on behind the scenes things, such as creating widgets (Twine’s versions of functions) to streamline creation. Some old code I merely tinkered with a bit, as I didn’t want to get caught up in too much refactoring, as I didn’t want scope to run away from me. At the end of the day, this is an experimental text game, so “good enough” works for many things.
One major change I added was creating a function to track the game’s demons and adjust how demons were assigned to appear though the game. Originally, demons were simply tied to menus: browsing the menu for a bakery spawns a demon for addiction, for example. Our wonderful artist had created several additional pieces of artwork and I wanted to include these as well, so I ended up expanding out the available menus to give each demon one they were tied to. However, I felt simply adding more menus to the table would be a rather dull play experience, so I instead added several “hidden” menus players can find through cleaning the house, as well as some lurking demons triggered by the act of cleaning itself – and then to give the game a bit of replayability (because there are multiple endings and achievements), I decided to shuffle around where they were each new game.
This code creates an array of all the potential choices for both demons and menus at the start of the game (storyInit as well as a resetVars widget which runs when the player returns to the main menu at the end of the game). It pulls these values from javascript objects.
It then plucks (randomly removes a value from the array) , creates different menu details and removes the demon associated with that particular menu. So if “sweets” was plucked, it would pick one of the random names for a restaurant (eg “The Sweet Tooth” or “Toothsome Temptations”) and also set the associated demon.
NOTE:This code is one example of the “good enough” type of coding I was talking about above – if I were to continue work on this game, it would definitely be much more efficient to create a loop for this assignment, as well as a much better set of relationships for how I’m handling these values, for example something like an object to store all the different information about each menu. Since this was a continuation of a very old game when I was a lot newer at coding, I decided it was easier to just be a bit sloppy and finish the project using some of the existing framework instead of getting lost in the weeds optimizing.
Once the menus were built, the first 3 were assigned to the main table in the game. 4 more were tucked away to be found when the player finishes cleaning different parts of the house (for example, once a cupboard is fully clean, the player discovers a menu tucked away in the back), which leaves 3 more demons to spawn at random. The following code basically tracks how many actions the player has done and if they are above 20 actions, we spawn a demon:
I then used this widget in any room/passage for activity where I wanted a demon to potentially spawn. For example, since there’s a menu hidden in the cupboard, I didn’t use demonspawn in those passages and instead just manually added to movecount. If I were to optimize this, I’d probably split the movecount and the spawning into 2 different widgets or make javascript code to apply to click events/passage navigation and just exclude the places I didn’t want it to run.
Some feedback I got from the early version of the game is that people didn’t realize there were variants of text for descriptions of items, as I had just been pulling text using .random, so I changed many of these messages to cycle, using the method of creating an array I outlined above. Halfway through changing all this over, I realized I could be a bit lazy and use this process to also cycle through the cleaning process. The code below will check for the size of the array and if it’s empty, it will set the bed to cleaned and execute cleaned logic (giving willpower, checking for an achievement for cleaning everything, etc). If there are still values left in the array, it will shift the array to remove the first element and display that.
setup.bed = {
...
clean: ["You begin by stripping the pillows and sheets - judging by the rather...err...ripe smells, it's far past time they were washed. You've just been so exhausted and haven't had the time, but now that you're doing it, you find yourself looking forward to having a chat with neighbors when you bring the laundry down tomorrow.", "You rummage in your tiny closet for spare sheets and pillowcases, dislodging an old box of photos. You spend some time glancing over better days and set aside a few photos from travels with old friends.", "You wrangle with the fitted sheet, starfishing on the mattress until you triumphantly manage to tuck in all four corners.", "You give your pillows a hopeful fluff and toss them atop the made bed. It's not the most luxurious sleeping arrangement, but it definitely looks a lot more inviting and restful than when you started."],
...
}
<<set $msgBedClean = Array.from(setup.bed.clean)>>
<<if $msgBedClean.length == 0>>
<<set $bedClean = 1>>
<<cleanDone>>
<<dialog>>
<<include bedMenu>>
<</dialog>>
<<set $msgBed = Array.from(setup.bed.cleanDone)>>
<<else>>
<<clean>>
<<print $msgBedClean.shift()>>
UI Updates
My goal with the UI update was to lean into the hand-drawn art’s sketchy style and create the impression of the images and text being words in someone’s journal (especially since a journal is an interactable object in the game, where you can even add custom entries!). I browsed the internet and found some useful codepen examples for the stacking pages and tape corners and tweaked those until I was happy.
Original UI:
Updated UI:
This is another “good enough” moment. I could keep improving the UI, but then I’ll end up down the CSS rabbithole for ages, so I basically had to stop myself and say “it looks fine.” I might go back and add a color-blind mode as I definitely think that might be a problem
Art Updates
The artist for this game had previously sent me some extra art they had done which we didn’t have time to add to the project during the jam, due to running out of time. I really wanted to be able to showcase these pieces, so I added in more ways for players to find demons as noted above.
One issue I ran into is that our format for the menus used a header art image, so creating new menus without those would stand out a bit.
Example menu page:
I first went through the existing art to determine if I could double-dip on any of the image. For example, the image of an outdoor grill for a bbq restaurant also worked great for a burger joint and by cutting out the distinctive pillars of the Taj Mahal (for our I ndian restaurant) I was able to have a mosque that kinda looked like the Hagia Sofia (for a Turkish restaurant). I began to run out of choices, however, until I realized the French image could make an easy shift to a logo for a cajun restaurant!
All I had to do was crop the fleur de lis, copy it and rotate the copies to flank the main one and ta-da! A quick little logo conjuring up New Orleans:
I also wanted to add some visual progress to the images of the house so players would see the image changing as they cleaned (eg the bed would become made). The artist had originally given me one overall finished image for the main room, but I needed to create steps for each element as well as create updates for the kitchen. For the main room, I copied each side of the room from the finished artwork. I then pasted each on top of the messy room and used smuge, blur and a very diffused paint tool to help make the lighting match. I also created some photographs to paste on the wall around to bed to reflect text about the player hanging them up. I used the blur tool on these to soften them and make them match the sketchy art style of the existing art. I also added a few dots to represent stars in the now-open window.
Original messy room:
Bed made, couch still torn (there’s an equivalent for couch repaired and bed still messy):
Final cleaned room:
For the kitchen, it was a lot easier. I just carefully erased away the dishes in the sink and drew in an arc to represent the bottom of the basin, and erased smuges on the stove. I added the same photos that were hung around the bed along with some basic shapes to represent magnets, and tada, fridge was transformed.
Some similar tweaking was done for the final page before the ending, where the player faces the final demon: their own reflection in the mirror. I used the existing image from the TV achievement (which is…a TV screen), filled in the outline around the screen, erased the antennas, and added some parallel diagonal lines to represent light reflecting off the mirror. It’s not amazing, but it’s functional enough to do the job!
Audio Updates
I added a few more songs to the playlist, retaining the theme of classical piano. Finding these gave me a nice mental break between working on other parts of the project.
I also found several different audio snippets of pages turning, to have the sound match the new “journal” style UI. The code below defines the names of the audio events and randomly shuffles plays one whenever parts of the game are clicked.
A large chunk of time was spent on this. Our original game was very black-and-white (teehee) in how we portrayed the player’s relationship with their mother. She was basically this flat, one-dimensionally evil character – but that’s not how real relationships or people are, so I spent a lot of time fleshing out nuances of the relationship through memories.
I added a dad and obliquely hinted that he had passed away, which changed the dynamic between mother and player and led to the shift in the mother’s behavior. I enhanced this by using seasonal references to indicate what part of the memory timeline the player is recalling, cycling from summer to winter and back into summer as the player left home to try to find their own happiness at culinary school.
dolmaMemory: [“You remember how one summer all of you took a family cooking course. Dad had roared with laughter as he watched the mess you made trying to roll dolma together with your chubby fingers, before scooping you into his lap to help guide your efforts. Mom had kissed him on the head and tenderly squeezed your shoulder…You suddenly find the thought of the dish unappealing as you imagine some other kid learning to make it, some other child having what you lost.”],
breadMemory: [“You are struck by a bittersweet memory of making bread with your mother. That day was one of the few great ones you can remember with her. It was autumn, the air chill and crisp, before dad’s test results kept getting worse. You slathered the crusty slices with butter and dunked them into a hearty chicken soup, a cozy meal against the gathering storm. Was it your fault that everything changed?”],
beignetMemory: [“Snowflakes mounded soft as sugar outside the hospital that day near the end and the sky was a blueberry bruise. You reflect on how the ugly can nestle among the most beautiful moments – the discordance makes your head spin and you catch yourself nervously glancing towards the window, as if reassuring yourself the day outside is appropriately gloomy.”],
lemonTartMemory: [“You’ve always loved lemon desserts. There’s something about the light citrus that is always refreshing. You remember one sun-drenched spring day, not long after dad was gone: your group of friends rode bikes to the store, pooled pocket money, bought a box of cookies and gorged. Powdered sugar smiles beneath cotton-candy clouds – worth the stomach ache that night to forget the feelings for the afternoon.”],
eggrollsMemory: [“You can’t help but crack a bittersweet smile, remembering one group outing after culinary class let out for the summer break when a crowd of you went out for dim sum and bonded over boldly trying everything on the menu. Cart after cart rolled by, depositing steaming baskets of dumplings, fried morsels, delicate desserts, and your stomach swelled, aching from overeating…but moreso from laughter. It was a good day.”],
The overall goal was to create a deeper, more emotionally rich story with room for sympathy for the maternal figure while enhancing the pathos for the player’s character.
Overall
All in all, I’m happy with my updates!
I think one important takeaway is recognizing scope and limiting it where needed to ensure something complete is produced, instead of endlessly tinkering. This is, at the end of the day, an experimental art project – it’s not something I’m going to sell so it doesn’t need rigorous polish or expansive gameplay. It’s updated enough to look slick and the gameplay and story have been expanded enough to tell a well-rounded, self-contained narrative.
Could this be better? Sure, but what I’ve produced is definitely a clear sign of my progress in both my health/brain recovery and in my growth as a dev – which seems pretty fitting, given it’s a game about moving past trauma through constructive choices. I certainly did some constructing!
Back in the day this was actually a decent chunk of what online moderation jobs involved: I worked for a major AAA console company and I basically just played games looking for aberrant behavior – dicks in player-made content, map hacking in shooters, rude behavior in co-op games.
And there’s a reason people see that early 2000s era as a golden era of online play: it’s because there were dozens of us around the clock working to moderate. It wasn’t farmed out to folks adhering to metrics, it wasn’t AI, we were actively playing the games and even infiltrating hacker clans to figure out how exploits were happening. When people were ragequitting or spamming insults? There was a chance we were either playing that game or spectating it (depending on mod tools) and looking up their report history because that was our job, and that player was likely banned that same night. We’d celebrate whenever we found a repeat offender we could ban – the “ban process” was quite hallowed and exciting.
As mod tools became more sophisticated, our interaction became more observant – at the time I was working, this was becoming clear. Some games had no mod tools, whereas some were developing full mod spectator options….and it’s interesting that once they could remove mods from actual gameplay it quickly made this jump to just having mods read reports. Reading reports was definitely part of our job before this, but it shifted from watching for trouble to reading about trouble and watching them in game or checking our their player created content to basically confirm the behavior, but within a few years after I moved on from that role everything started getting fully automated. And then after that it became fully outsourced. I don’t think my former job even exists in America, despite it being a rather huge department at the time I worked there.
As a sidenote: It was the “fucking best job ever lol”, but it also broke me. Yeah, I got exposed to some horrific shit on a daily basis (and I’m glossing over some of the darker sides of the job, because who wants to hear about things like CP, death threats, extreme racism, extreme gore, etc), but I also got to play games so much that I could set SMGs in shooters to single shot fire for headshots (because we also low-key did QA/feedback work). Being a woman was an extra level of “oh god” to it all. There were times where it was fun af, but most of the time we were being clockwork-oranged to the worst part of the player base for 8 hours at a time.
Short answer: Yes, it’s impossible for perfect balance, but you strive for “best in the moment” and ideally back it up with tools to make testing for that a lot easier
Long answer: soooooo, I’m a very old school gamer and my main multiplayer game genre was MUDs – these were the text-based precursors to MMOs, and these games still have some concentrated player bases in a few corporate companies (IRE and Simultronics). I was also one of the “big” players, which basically translated to free dev work on my behalf.
I work in QA and so I would run the initial QA pass for balance changes. I would assess to find the potential OP combos, edge cases, unexpected interactions. This was all done on a test server which mirrored attributes of live and also let us custom create characters for the specific thing we were testing.
From there, changes went to the “liaison group” which was an IG role where the top fighters from every class basically had a combat council to discuss the game meta. We had a pocket realm we could use in game where we could teleport in, adjust stats, equip everything in the game, etc. This let us easily setup situations for testing the crazy combos we dreamed up – instead of just mental/pen and paper we could tweak stuff to test specific circumstances.
Every few months, we’d also suggest combat changes. Normal players could also submit ideas, which we could support for higher level discussion and review. We’d review all the submitted ideas and comment on them. We used both asynchronous communication (comments on submissions) and synchronous communication (chatting in a chat channel in game).
This system had its good/bad.
Good:
– the people discussing balance knew the actual gameplay impacts incredibly well.
– the suggestions for potential solutions were made by people taking into account combat balance, lore, theme, etc
– crazy math at the drop of a hat to prove points
– directed and edited pipeline to devs
Bad:
– selection process for these players wasn’t always great. In one game, for example, it was a guild role, so I became liaison for a dead guild simply because I was the only person who fought…even though I had been playing less than a month
– personal bias: players were always loathe to nerf their own class, even if they knew it was OP and nerf/buff selection sometimes ended up quite political. We’ll agree to x nerf if you agree to x buff. I became briefly both hated (by allies) and beloved (by enemies) because I submitted an idea to fix a way my class was OP
– admin tension: This role/communication channel was really in touch with admins and if an admin didn’t like a player (hella common in MUDs) everything broke down
– in-game harassment of liaisons: this was common enough that I need to call it out. People would harass to try to engineer the results they wanted.
Sorry, rambled a ton, but I think there are maybe some helpful takeaways there!
I can talk more about this if you have any questions! When I worked on Age of Empires, for example, we had one of the top ranked players in the world as part of the test team – his role was just to try to APM break shit and find basically skill ceilings to help the devs balance downwards.
The concept of balancing downwards is something that I think can really help game dev – it establishes a maximum QA boundary and then all testing never has to deal with that max limit! If the best player at your game says xyz is max potential combo, you don’t have to edge case all these weird potentials!
I used to write a bunch for MUDs, and a few years ago, I decided I wanted to try making my own game. I started as a writer/QA/project management for my first few game jams because I was struggling to create something fully on my own.
This hybrid “help as needed” role let me get hands on experience and showed me a deeper look behind the scenes of how games are made, without being overwhelmed by all the setup needed to get my hands in the mess – I had previously been daunted by the basics of just setting up engines and SDKs and CLIs and virtual environments and all that stuff.
We had envisioned something impressive with the player changing the story, but as development continued we learned about scoping and timelines: our coder ran out of time, so I focused on finding us public domain images and twisting together a concept of a thing that would work with the functions we had coded. The result is kinda cute.
From there, I tried out making my own games using a range of different engines which focused on text-heavy development:
Twine: webdev (eg CSS, html) for interactive hypertext
Choicescript: uses very basic scripting for interactive cyoa novels
Adventuron: designed to teach children how to code via making text adventures
This is not an exhaustive list – https://intfiction.org/ is a great resource for even more options such as TADS.
Twine resonated quickly with me as I used to make websites and skin forums back in the day. The concept is overall very similar to building a website, so I found it easy to use.
The devlog for that has some good info about CSS – I learned a ton and it’s frankly kinda insane and awesome that I was able to produce that (even if it’s a mess) for the first thing I made in Twine.
For pure writers, I’d personally suggest you try out Choicescript via Choice of Games – it’s easy to code and focuses a lot on writing. The code doesn’t need to be complex and the only images you NEED are static ones for the cover art. Don’t have to worry about music at all. Make sure to download the IDE – that means integrated development environment, and it’s basically an app to do the coding in.
You can even publish through them to an existing audience of people who like reading/playing interactive novels. I suggest trying out some of their games first to get an idea of the kind of game you can make as a solo text developer!
Be sure to check out the hosted games category – that’s how you’d be publishing a game if you make one through them. Even if your game doesn’t do well commercially, you’ll have a published portfolio piece, which can be used to leverage future writing work.
I’m currently working on two different choicescript experiments. One has an easter egg coded in for if you don’t properly pick a name for your player character – and, stepping back, how wild is it that I’ve gone from writing and trying to make games for other people to making my own stories I want to tell…and not just making them, but adding in secret jokes?!
It’s fun to step back and reflect sometimes, and I hope some of you reading this find some inspiration to try to create something yourself! 🙂
So in the very early days of the Internet, all games were merely text and symbols, which encouraged a rich community to form focused heavily on writing. Gameplay in these games focuses on written output and a night of gameplay may mean a bunch of different sessions of collaborative, improv storytelling.
MUDs: multi-user dungeons. Basically collaborative D&D. The focus is more on RPG/MMO style content where bashing and combat are just as importantly as story, though you can find some incredibly story-focused MUDs. I personally suggest Aetolia – not only is long-form roleplay (eg writing a paragraph at a time) the norm, they even have mechanics like a random RP roulette where you get paired up with someone in a room to just start writing at each other.
MUSH: these are similar to MUDs but tend to feature one-off overarching stories and more strict roleplay. Many players roll up a new character for a MUSH and play it until they die (where it’s mourned and deleted). These are more like D&D campaigns vs an MMO’s persistent nature you find in a MUD.
MOOs: this is heavily focused on story and often includes commands accessible to all users for lots of customizing characters and modifying environments. Yes, one of the coolest parts of text games is that you are basically acting out a screenplay and you can adjust the descriptions or room or clothing or character to reflect changes in in plot. MOOs focus heavily on letting players have just as much control over the game world as devs.
All in all, this genre is a goldmine for aspiring writers – it’s like a virtual writer colony where you will constantly bounce ideas off of others and learn new concepts to improve your own writing. I highly suggest giving this a check out of you’re interested in improving your writing and feel like you need more. It’ll also help you a lot with describing rooms, sensory details, dialog and emotes just from the gameplay.
One of the things I do at one of my jobs is analyze how users experience the game, and if it’s “fun” – this is an incredibly complex topic, which I will attempt to tackle in a series of posts, addressing the various ways games are “fun” to users.
This first post will look at the underlying player perspectives which drive what people view as “fun.”
Fun for Who?
At first blush, “fun” may seem self-evident and obvious to a gamer or a new designer. Stuff is fun or it isn’t! It just IS FUN! That view, however, is not useful when you are dealing with design or analytics – you want quantifiable data and clear design strategies – and it tends towards the myopic. People tend to gravitate towards what they find fun, and that will help define their own view of what fun is. If I can impress one thing upon you, readers, let it be this – there are MANY types of game players who find a HUGE range of things fun. Far too many new designers (or armchair analysts) cater to their own view of what’s fun, instead of realizing the vast range of interests among potential players.
Realizing, recognizing and designing for that range is what makes a truly stellar game.
Now, by range, I do not mean “Shooters vs Facebook Games” or “Sci-fi vs Fantasy.” Interest types come in many flavors, and genre is only one of the ways you can tap into someone’s concept of “fun” – obviously, I am not suggesting that designers change their genre or core concept or theme. Instead, I am stressing the importance of recognizing that people play games for a variety of reasons, in a variety of ways, and find a variety of things enjoyable.
Bartle Types
One of the core ludology studies from the early days of online gaming is the Bartle Test. The concept is basically the gaming world’s version of the Myers-Briggs personality test – basically, each person plays games a different way, with many players falling into specific categories. Manyquizzes and tests have sprung up around this concept, letting gamers quickly assess their “type” – results range from a Killer to an Explorer to an Achiever. In recent game development, the MMO Wildstar based their character classes off this concept.
The concept itself is somewhat archaic (it’s from 1996, which is forever in the game industry timeline), and a bit rigid (if I spent a day training people and sitting in meetings at work, I may be far less inclined to be my usual Socializer persona, and might just want to mindlessly play a Killer all night)…but it’s a solid idea to consider when designing games and considering the people who will play them. Audience is, afterall, a huge thing to consider during development.
In my personal opinion, a good game hits more than one player type – and a great game appeals to all of them. A solid designer should, at the very least, acknowledge the different types, and consider if his or her game can include elements which will appeal to that gaming style. In future posts, I will dive into the individual types, for more concrete examples…
a little bit of everything all of the time 