What is Tears of Gilgead?
Every screenshot in this post is from a pre-alpha game designed by a programmer who can't draw. Final results will vary significantly.
Conventional wisdom from people who work in the video games industry is that for your first game you should work on something simple. One of the dumbest things you can possibly do is to immediately try and make an online game, and the absolute dumbest thing you can do, is try and make an MMO.
Guess what we've done?
Send help, I'm in over my head, and when I look at the code I smell burnt toast.
Tears of Gilgead is a persistent, largely text-based, systemically driven MMORPG, in the vein of classic online MUDs. A far cry from being a throwback to a bygone era, we've tried very hard to make the game as accessible as possible for a more modern audience. Instead of being driven entirely by a command line interface, everything has clickable UI prompts.
All the classic MUD mechanics are there, like "look" commands, compass movement, chat channels, turn based combat, but it's all wrapped up in a UI that is understandable at a glance. Aside from our UX, we have built-in tools that can display both classic MUD style "room" views, and retro-style "16 bit" tile maps. We use these to orient the player in "Areas" like towns and dungeons, and visually represent our enormous overworld.
Like most classic MUDs, ToG will always be free. There will be no options to purchase stuff in-game, there will be no cosmetics. At a push, you will maybe be able to donate some cash for server fees, but that's it. This is the browser game I've always wanted to see and as such, it's a labour of love.
Our overworld map. Rob would probably shout at me if I didn't mention the art was placeholder.
The first town Rob has added to the game, represented in classic GMUD fashion.
How does this work?
The game, and the website it runs on, are made using .NET Core. The Microsoft stack is my bread and butter as an engineer, and so for the sake of a quick lift-off, I decided to go with what I know.
Hey, if it's good enough for Unity Engine, it's good enough for me.
The front end is largely constructed using W2UI, an excellent JS framework that allows you to create dynamic layouts that can be moved around and resized by the end user. Since there are no good libraries for creating MUD-like maps, I decided to roll my own. The maps both use HTML5 canvas to render locations, so it's not very resource intensive to update them each time the server communicates with the client.
Have you considered rewriting it in Rust?
At the core of the technology stack is Microsoft's SignalR. We use this to allow bi-directional communication between the client (which runs in a browser) and the server. Like all MUDs, the server contains information on the game state, and has various mechanisms for changing it based on user input. The actual comms in SignlR are handled by WebSockets. I cannot overstate how much I love this library. It has made something that would typically be a major headache, and removed the vast majority of the pain. Basic client-server communication was up and running within 20 minutes of me creating the root directory for this project, which is an order of magnitude faster than it would have been had I had to write something myself.
Sitting at the butt of this stack is a SqLite database. It's small, it's fast, it's reliable, and it sort of almost kind of works with Microsoft's Entity Framework, which makes it very easy to manipulate the database and make requests of it.
Is this playable?
In a word, no.
We have basic mechanics working, and the server doesn't fall over every 10 requests, but what _is _there is still currently barebones.
A primary drive behind this project has been to create something more akin to an "engine" than a game. I think of the codebase as a suite of tools that we can use to _create _a game, as opposed to being a game in and of itself. I write all the code, but it's my 2 co-conspirators that turn coffee into playable content.
The tool used to create towns, dungeons, cities etc.
We have wrote a short "roadmap" of features that will need to be implemented, changed, or improved before we feel the game is in a state where people can play it. Even outside of functionality however, much of the mechanics are wrapped in placeholder UI and programmer art.
What do you mean this isn't ready for Prime Time, it has DIV tables for God's sake? 2021.
For now, if you are at all interested in this janky shitfest we are building, you can sign up for an account here. We will email you when the time comes to start alpha testing.
If you want to get in touch with me, or join the very small (but hopefully growing) community, we have a Discord server here.