...damn...its hard not to want to start another MUD...
EDIT: i know this post is NOT a MUD project...but the solo-MMO dev story just struck a nostalgia chord in me
There's a 1 man developer who wrote not only his own MUD but tools to create and find MUDs to play.
It's all written in Elixir and open source. He's given a couple of talks about it and does some living code on Twitch.
I have no affiliation with the author but I did watch some of his talks just for fun.
I always felt that a MUD would be a fantastic design approach for a graphical MMO. Specifically, start by creating a text (MUD) version of your world and the basic interactions, and only when you've created a compelling story and experience with words do you translate that into visuals.
It also would be pretty intriguing to create a MUD that could work in multiple media: text, 2d graphics (think point and click adventure), and perhaps 3d graphics. Theoretically it would be doable. A pretty interesting advantage would be that an MMO with a text option would really open it up from the perspective of accessibility.
I've also been playing around with OAuth inside of a telnet session, but it's a little wonky as you might guess. If you're signed into Grapevine (mentioned above as well) this link will have you auto signed into a telnet session: https://grapevine.haus/games/Spigot/play
This is my draft spec (it's not completely filled in but the idea is there) https://gist.github.com/oestrich/1fc022a448c36ac2aa5a099f4ca...
Spigot and Grapevine are also open source if you wanted to poke around.
New-Item "temp" -ItemType "directory" -Force
$client = New-Object System.Net.WebClient
Expand-Archive -Path C:\temp\mbedtls-master.zip -DestinationPath C:\temp\; Move-Item C:\temp\mbedtls-mbedtls-master\ C:\mbedtls\
MSBuild.exe C:\mbedtls\visualc\VS2010\mbedTLS.sln /p:Configuration=Release /p:Platform=x64
MSBuild.exe C:\mbedtls\visualc\VS2010\mbedTLS.sln /p:Configuration=Release /p:Platform=Win32
docker run -it --rm -p 4000:4000 -p 4001:4001 -p 4002:4002 --rm -v $PWD:/usr/src/game evennia/evennia evennia start -l
docker run --name dreamland -p 8001:9001 -it dreamland/local
curl https://raw.githubusercontent.com/ClockworkSoul/dead-souls-d... > docker-compose.yaml
docker-compose up -d
Or you could just play the best MUD there ever was, and still is.
edit: i spent many hours on genesis and did my first lpc scripting (area building) there
The mechanics you mentioned are interesting; what kind of MUD was it? I got hooked on DIKU MUDs in 1990 or so, and still play https://mume.org:4143/ from time to time.
Yes, I remember those, and played with them a bit. They were a far more flexible, dynamic environment, but 'back then' (in the early 90s), as I recall, the performance hit associated with LP MUDs (inherently dynamic) vs. DIKU MUDs (inherently static) was pretty large, and available memory/CPU cycles were at a premium.
Mostly though I think I preferred DIKU MUDs because I happened to start with them, just by chance.
Good times, thanks for sharing!
Embedded text editor (a modified version of ed), live code reloading, JIT compilation to a VM byte code, translating data automatically between old objects and their new freshly compiled code...
The thing with MMO projects that really gets you is, even after you've got a mature client and server you still need to put together enough content, which if you're level designing/writing/painting everything yourself, is an enormous quantity of work. If you don't want players to run out of quests and whatnot you've probably got to lean towards a sandbox experience, and this MMORTS is a particularly interesting way to go.
I recently had some time off and ended up burning through nearly all of Destiny 2's content inside of 2-3 weeks. Hell, I can jump into WoW and be raid ready inside of a week or two, and just go straight into the latest raid. I think there's something fundamentally very wrong with how modern MMOS are designed, but it doesn't seem like anybody is interested in properly exploring the solution space.
I think a large part of the problem can be solved by adding more 'sub-systems' - housing, fishing, cosmetics, titles/deeds, playable instruments, farming, whatever...
Seems like newer games just want to focus on combat and gear progression, which has people burning thru content.
If people want more PVE combat, I think the solution will probably comes from automatic creation of new content. With the advance of AI, we'll come there eventually, but don't hold your breath.
I worked at Turbine off and on from 2001-2012, and was the MMO game engine tech lead in the time period up to when Lord of the Rings Online and Dungeons & Dragons Online shipped (2003-2005). Both were based on the same game engine core, which was a more or less complete rewrite of everything in the game engine (client and server) from the original Asheron's Call. Many of the concepts carried over, but the implementation was completely different. To this day, I still think this "G2" engine got many things right in its internals that many other game engines (MMO or otherwise) didn't really get, probably because everyone who worked on it was crazy but actually pretty nice and reasonable to work with. Some friends who ended up working at Unity or Epic from Turbine that I've talked with think the same. It certainly made many questionable assumptions as well.
I got quite burned out from the rewrite (well over 1 million lines of C++ redone between 5-6ish people) and went part time/remote in 2006, left in 2007, came back in 2009 part time/remote again to help port the stuff to PS3 and Xbox 360 for projects that eventually got cancelled. My last six months (I stopped giving a shit at this point) was doing nothing but porting much of the client code to Mac OS X, which consisted of fixing endless compiler errors and patching up library/API differences in hundreds of thousands of lines of client code. This was actually kind of therapeutic because much of it was mindless.
I do smile a bit when realizing that code I wrote on ~16 years ago is still plugging along in some datacenter somewhere and on people's PCs, long after the company and the people who worked on it have scattered to the winds. Many of the core team that worked on it back in that time period went on to found some companies (game or otherwise), are working at places like Google and Facebook, or remained in the industry at Epic Games and Unity and various game studios.
I played through the F2P beta for LOTRO too. That was a bit rough at times, but fun.
It's available through Web Archive here: https://web.archive.org/web/20110303214710/http://www.devmas...
It's an interesting throwback to the era before common availability of production-grade game engines like Unreal or Unity, back when everyone worked on their own Direct3D/OpenGL engine.
Are MMOs any easier to make now given the libraries and cloud services that exist today?
The difficulty is building a MMO that is appealing and fun to play, so you have to think about multiplayer game design, which can involve a little bit of game theory, economics, reward systems...
A mmo is not difficult to make by its strict definition, once you have a large open world, the spatial partitioning to manage network traffic, things work. What is hard is to populate such a large world with "life", activities, things to do, and especially rewards in a persistent world.
MMO are amazingly interesting, world building is a vast subject, but building a quality MMO is also enormously expensive.
This way, the user-facing artsy stuff is mostly done. You just need the backend stuff, although admittedly some fun is removed since you have to work with the network protocols the pre-existing clients expect. You'd undoubtedly learn about how and why various aspects of the game were implemented the way they were.
And yeah, there's already a project for private WoW servers, but if I ever get a few months off work, that's something I'd like to look into doing separately. Maybe after enough time, Blizzard would open source the clients so we can hack on those, too. Although WoW still brings in good money, so that'll probably be a while.
It's easier to create a game like this. There are even MMO middlewares available. Still, when people say MMO, you can never tell whether they just mean a persistent online world, or literally a world that can fit thousands of players in it at the same time.
But there's a wide difference between making a proof of concept and making something that scales+people want to play.
The former is much more tractable these days, and the latter - ignoring the difficulty of competition - is a bit easier but still a hard problem. Content is somewhat easier to create, but still hard to scale (and quality demands are higher to match the improved general capabilities and expectations).
He has two index files; index.html and index.php. The server sends index.php by default, which is where the blog is.
A few things to consider:
- the amount of information to be sent from the server grows quadratically with the number of clients (eg. if 100 players all 'see' each others, you naively would have to send 100*100 updates per server tick); the data received by each client only grows linearly, though
- obviously these are kept in memory, and persistent data is flushed if needed to a permanent storage
- one can reduce the quantity of information by:
+ distance: when a player (an object) is far away, it may get invisible (too far) or degraded (updated only every N ticks, low quality version of the assets sent/displayed)
+ number of entities around: when a lot of players are grouped closely (think a crowd), you can also degrade the information for those further away, even if they are close to the viewer in absolute value, since they are 'hidden' by others.
+ compression tricks: send deltas instead of absolute values for position (smaller numbers can be compressed more than larger ones), don't include the properties that did not change, etc.
- at some point, you (may) need to split the work on several servers, and have an efficient algorithm to split the game space, and synchronise your servers
Eve Online slows the entire simulation down when huge battles are happening, but they also split simulations across servers based on which system you are in.
Modern WoW shards plays heavily within zones, which is why you will almost never run into the same people while adventuring. They also attempt to limit how many players will be in the same shard at the same time. However there are ways around that through grouping, so when larger battles start happening things get laggy. You press buttons, they are queued up, and can take upwards of a second to show their effect in-game (they must go to the server and back).
My guess is no - you'd want the rendering to happen on the edge close to the player, but with a sufficiently advanced compute topology maybe some tasks can be farmed down the graph?
Edit: Well, now that I think about it, it depends entirely on the game; PlanetSide 2 is an example I can think of off the top of my head that brought my computer to its knees during big battles. But most MMOs aren't exactly pushing the envelope of graphics quality or physics simulation, so it's not as big of an issue.
The MMO-lite I worked on was made to be as horizontally scalable as possible, and had extreme incentives built into the gameplay to push players towards actions and areas of the game universe that would more fully leverage benefits of the scaling trade-offs we made.
Being able to segment and slice the outbound data from your clusters (and/or what the client requests) - that is, the data and game state equivalent of occlusion culling - goes a long way.
Also 3D data structures, which http://realtimecollisiondetection.net/ is still my go-to book.
You'd be impressed how fast computers actually are -- 10,000 objects isn't actually that many. Since the server knows where all clients know, the server knows what the client can see, and the server only has to update the client with relevant information, like the 100 closest players to it.
Yeah but these 10k objects are containing themselves many more objects (item inventory, proximity mobs etc).
A player sends a command to his current chat room; the bot validates the player position and current action.
Other players listen to bot responses in all nine chatrooms around them.
Extreme example of someone using this in PVP: https://www.youtube.com/watch?v=kIFWSMW6Lzo
2001! http://www.rupy.se/raywalk/magequest.html (the graphics/sounds are "borrowed")
2011. http://aeonalpha.com (my neighbor made the music/sounds in exchange of a 960Ti for his Hackintosh)
Both use Java, the first one is a mix of Applet/Application that you can try by running this file:
The second is Application only so you download it here:
I'm working on my third OCMMO:
Actually it won't for sure because the skin mesh animation code was also "stolen" from a former colleague (they will all get mentions though) but I'm a bit ashamed to discover that I'm not good enough to do anything from scratch... at least not the first time around, is this what they call impostor syndrome?
Even looked at making my own gerber editor and print my own PCBs with my AxiDraw plotter.
On the subject: https://www.youtube.com/watch?v=5ODzO7Lz_pw
I looked at your github but nothing is playable out-of-the-box, you could make something presentable?
Yes, it is difficult to keep up with modern game tech, but I have lots of friends in the AAA industry who let me know what's going on at the bleeding edge, and I pick my battles.
No, you couldn't make a game like Miranda with any off-the-shelf game tech I have seen. Game engines usually only allow one avatar per player, Miranda can have hundreds, theoretically thousands. Miranda is also seamless and single-sharded.
The renderer does have soft shadows, but you're right they don't always show up really well. I'll take a look at that.
The next update is coming pretty soon with a whole lot of gameplay additions, I just started the playtesting and debugging phase today.
Thanks for visiting.
A word of advice: if you want to make an easy immense graphical update, add shadows to your vehicles. Even just a dumb, circular flat alpha gradient under each vehicle. You would not believe the amount of immersion this adds.
I used Babylon.js for the 3D game/controls, and I imported free 3D assets from various asset stores for the content. The backend was a simple socket server written in Node.js with socket.io connected to the web frontend via JS using the standard WebSockets API. I got realtime character movement, turning, & jumping implemented pretty quickly. Content became a bottleneck so I stopped developing, but I hope to finish it up sometime in the near future.
A weekendware prototype isn't what people are talking about when they say gamedev/MMOs are hard. It's 0.001% of the work, it's trivial.
Just as you, too, stopped at the actual hard part: building the game.
But the "Massive" can be a real killer. Even if there are to some extent off-the-shelf tech that can handle fairly "massive" communications, it still takes a lot of skill and effort to use them correctly.
I'd rather play a half-finished roguelike, gamejam games e.g. itch.io or Ludum Dare , indie games, concept games.
You feel the creativity more.
I don't care for a scripted piece of entertainment.
I want to explore different game mechanics and explore ways of interacting.
AAA games almost never give you that.
One of the first: Community Garden.
Shattered Galaxy is also MMORTS and is still alive: https://www.youtube.com/watch?v=HBY-WGFQk98
Really hard game concept to get right, though. Something that was cool about Ballerium was that it was one big open world. I think Shattered Galaxy was a lot more instanced, but I didn't play it much.
Definitely room for more exploration in the space.
It's a long-running MMO (from around the Ultima Online era of games) that is developed and ran by a single person.
The amount of effort involved in such an ordeal is mind-boggling, personally.
I kinda miss my old character that got de-leveled well over a decade ago. I let the account expire and when I tried returning some years later I couldn't get back into it.
RIP Mythical Mage III
The genius of that game cannot be overstated. Its ludicrously simple mechanics somehow resulted in emergent gameplay that was deeply affecting.