Seeking project members for a hybrid MUD/Roguelike

A category for whatever! Can be Mudlet-related or offtopic.
yamamushi
Posts: 4
Joined: Fri Sep 28, 2012 10:48 pm
Location: /dev/null
Contact:

Seeking project members for a hybrid MUD/Roguelike

Post by yamamushi »

Howdy Everyone,

My first post here on the forums, but I've been an active Mudlet user for about a year and a half now. I stopped by the Mudlet IRC with this question and it was suggested I come here :-)

The ASCII Project is a completely free (100% GPLv3), open-source, fully-documented game engine I have been developing along with the input from a few others for the use in MMORL (Massive Multiplayer Online Roguelikes). It's been rather difficult at times, as the normal approaches for solutions I'd normally take for a Roguelike don't necessarily scale or apply well in a realtime persistent online environment.

The initial goal was to develop an online text-based world, similar in graphical style to Dwarf Fortress or Nethack, but with the added ability to dig or place tiles on the map to build 2d/3d structures (multi z-leveled).

At the moment the game engine does exactly that, and in clustered testing on HP's Cloud Infrastructure(I work there) I was able to push the maximum map capacity to 3.6 billion explorable/editable tiles being generated and evaluated in realtime. Though the state of the game engine stability now doesn't really warrant a map that large being generated, but it gives you the idea of how large of a world the game engine can handle.

This is great and all, however the current state of the project is really just a game engine waiting for a game to be developed around it. I have the concept of an extremely large game world in my head, but distributing my time worldbuilding and adding more features to the game engine is proving to be quite a challenge.

In order to make room for the MUD-style gameplay I'm really craving from the game engine, and somewhat encouraging active roleplaying instead of hack-n-slash gameplay, I'm going to be spending quite a bit of time taking out pieces of the engine and rewriting them for modularity's sake. It's a convoluted mess right now, and I'm not entirely pleased with the way some data structures are handled due to the way I've duct-tape coded some underlying rather important pieces... but anyways...

Right now, The ASCII Project, is the name of the game engine. However as it is an open-source engine, I felt it necessary to create another project solely for the Game which should (hopefully) run on the game engine I've been building (in C++). That game is to be titled, "Legends of Meru", Mount Meru being the center of the Universe in Hindu Cosmology.

The goals for the game engine summed in one sentence would be, "Players should share the world with the entities that inhabit it, not own it". Thus there are many pieces of the project that are an absolute necessity to work under this philosophy:

* Permadeath - both for players and npc entities.
* World persistence - the state of the evolving world should remain permanent. (explained below).
* Seamless world generation - players should never reach a boundary in the map, the worlds should wrap around to create a spherical map.
* All items in the game (aside from a few rare items, dungeon rewards, etc) should be craft-able by a player.
* NPCs should continue to operate even when nobody is logged into the game world.


Together these features, along with many more which are covered in the wiki available on our website, are going to allow for "butterfly theory" scenarios, as I like to call them.

Imagine that you have built a village, hired a few NPC's to work there and tend to your farms, and you have traders coming by daily to pick up your goods to export to the larger capitol cities. Now you log off for the night and when you come back your farms are burned and some of your NPCs are dead. Those NPC's won't respawn, and unless someone else goes out there (either a player or an NPC) to farm, those farms won't just magically repair themselves.

The families of those NPC's may react in different ways, depression, violence, etc. The persistence aspect comes into play here, where you could possibly track down the goblins that raided your village while you were away and go retrieve the goods they stole. However those NPCs are going to remain dead.

Anyways, I'm really rambling here, as there's a ton of info compiled on the website now (www.theasciiproject.com) :)

tl;dr - Looking for project members for a hybrid fantasy based MUD/Roguelike running on a custom built game engine in C++.

You can get a hold of me through my email (available on our site), or on our IRC room (better choice for obvious reasons) on Freenode (##asciimmo).

-Yamamushi

User avatar
KaVir
Posts: 86
Joined: Mon Feb 08, 2010 8:38 pm
Contact:

Re: Seeking project members for a hybrid MUD/Roguelike

Post by KaVir »

"The goal of “The ASCII Project” is to develop a Unicode-based “roguelike” MMORPG..."

You realise that Mudlet doesn't support Unicode, right?

But it does support proper graphics. I'm presuming (as you're posting on the Mudlet forums) that you're planning to create a game that's playable through Mudlet - will you be taking advantage of the autoinstaller to create a Mudlet GUI with graphical tiles (in the same vein as many modern Roguelikes)?

User avatar
kevutian
Posts: 217
Joined: Fri Aug 20, 2010 8:18 pm
Location: United Kingdom
Contact:

Re: Seeking project members for a hybrid MUD/Roguelike

Post by kevutian »

Yeah, this is a very valid and pertinent point to make at this stage. Mudlet definitely could use some Unicode support although making this possible right now would require a -huge- amount of work.

That said, this project certainly looks interesting and I will most definitely be keeping track of the progress.

yamamushi
Posts: 4
Joined: Fri Sep 28, 2012 10:48 pm
Location: /dev/null
Contact:

Re: Seeking project members for a hybrid MUD/Roguelike

Post by yamamushi »

I wasn't necessarily targeting Mudlet at this point, you can see in the screenshots that I had set about writing my own client, but using SDL for all the rendering is (in my opinion) a set back for portability (in terms of just being able to telnet to a port to get map information vs having the byte code de-serialized through a custom a client).

That's part of the reason I'm doing the rewrite of the Engine right now, to pull out all of the non-essential libraries and to replace libtcod (a roguelike development engine) with my own pathfinding/FOV algorithms. I was using libtcod for the rendering as well, but my approach was flawed because everything ended up being written around the graphics handling (SDL) in that library. It has really limited by ability to add things to the engine that I would like in there, as I've been having to make adjustments all over the place to account for the clusterf*** of a compression library that TPL is (C-based serialization library). Take a look at the source code for the serialization functions (https://github.com/yamamushi/theasciipr ... /src/tpl.c) and you'll see what I mean :(

I think the easiest way ("easiest") to get a raw map through telnet working and to retain backwards Unicode compatibility would be to have a method for detecting the TERM type and to pass the appropriate character information across the net according to the response from the client end. If that's not very efficient, or I can't get the right info out of it, I may just end up deferring to a user setting ('set unicode on' or something).

I'll have to take a look through the Mudlet GUI stuff, but putting together an autoinstaller shouldn't be too much of an issue as long as I can figure out a decent way of determining the character encoding the clients are expecting (perhaps on a per-session basis?). Regardless of the solution, it's clear that there is going to have to be a "compatibility" mode for clients that don't understand UTF-8 (don't even get me started on Windows UTF-16...)

User avatar
KaVir
Posts: 86
Joined: Mon Feb 08, 2010 8:38 pm
Contact:

Re: Seeking project members for a hybrid MUD/Roguelike

Post by KaVir »

It's been my experience that relatively few mud clients support Unicode, and those that do won't always use monospaced fonts (which can really mess up maps). Your screenshots also seem to suggest the use of cursors, which many mud clients don't support either.

On a related note, extended colour (either xterm or MXP) can really improve the appearance of ASCII or Unicode maps, but once again they're not always supported.

I think detecting the terminal type is probably the best approach, unless you're only planning to support a specific client. However be warned that negotiating with Windows telnet causes ECHO to be switched off (there's a workaround with escape codes though). You'll also find that some clients support CHARSET for detecting and/or enabling UTF-8 Unicode, although I know of no way to determine if their font is monospaced, or which Unicode characters their font supports.

Utilising the Mudlet autoinstaller requires ATCP or GMCP. You may find my protocol snippet of interest.

yamamushi
Posts: 4
Joined: Fri Sep 28, 2012 10:48 pm
Location: /dev/null
Contact:

Re: Seeking project members for a hybrid MUD/Roguelike

Post by yamamushi »

Well the first challenge is getting generic terminals (uxterm, gnome-terminal, xterm, emacs shell-mode, etc) to work properly :p

I don't see the fonts being an issue, as I've already done the work putting together a full monospaced unicode (plane 0) bitmap/png font. It's available under "bin/data/" on our github, but I documented the work I did on the libtcod forums (http://doryen.eptalys.net/forum/index.php?topic=1473.0).

Merging the MUD/Roguelike genres really is causing me to need to re-evaluate some of the decisions I've made about the underlying engine mechanics so far. It's a long process, but I'm getting there slowly :)

User avatar
KaVir
Posts: 86
Joined: Mon Feb 08, 2010 8:38 pm
Contact:

Re: Seeking project members for a hybrid MUD/Roguelike

Post by KaVir »

There are other free monospaced Unicode fonts as well (personally I'm quite fond of Fixedsys Excelsior), but unless you can convince client developers to distribute with your font preinstalled, the player is going to have to download and install it themselves (assuming the client even allows them to do so). As there's usually no way to detect which font they're using, you can't be sure they're able to see the map the way you intended.

It's a tricky situation, and one I've struggled with myself. I think you can probably rely on all clients to support an ASCII monospaced font and basic ANSI colour (exceptions are extremely rare, and I've not seen any in many years). You can also work out quite a lot (either directly or indirectly) through telnet negotiation. But if you want your game to be playable through a wide range of clients, you'll need to offer fallbacks for the various options - ASCII maps for clients that don't support Unicode, basic ANSI colour for clients that don't support extended colour, ATCP for clients that don't support MSDP, etc.

In many ways it's easier just to support one client, but that has its own drawbacks.

User avatar
Oneymus
Posts: 321
Joined: Thu Sep 17, 2009 5:24 am

Re: Seeking project members for a hybrid MUD/Roguelike

Post by Oneymus »

I am very much in favour of your idea, yamamushi. Roguelikes are great fun, and everything can be made better with other people.

I must admit, however, to some curiosity about bringing the project to Mudlet. As it stands, I don't think Mudlet would handle a Roguelike of this nature well at all. MUDs (and MUD clients) function line-by-line (I am unaware of any notable exceptions, though standard telnet supports character-by-character). Roguelike interfaces are generally large blocks of text (or text-like) refreshed for output.

At best, in Mudlet, you would be passing the entire screen every update (as text, or compressed via MCCP), and letting user-end scripts handle things like removing past data and meta-interface functionality (gauges, etc.). This could be bandwidth intensive, and put unnecessary strain on your server to process all of that output every update.

It is my opinion that you would, indeed, be better served with a custom client that would parse your own, optimized network protocol. If I understand this project correctly, you would benefit from research into common practices used by graphical MMOs. Though the scale may be different, the concepts of server->client communication found there would be invaluable in helping you progress. Indeed, with a custom client, you can fine-tune and greatly impact the amount of work your server has to process.

yamamushi
Posts: 4
Joined: Fri Sep 28, 2012 10:48 pm
Location: /dev/null
Contact:

Re: Seeking project members for a hybrid MUD/Roguelike

Post by yamamushi »

Yeah, I suppose this wasn't the best place to look for new project members but I the guys in the IRC pointed me here when I asked "what's a good place to find people interested in MUD/Roguelike development?".

Targeting Mudlet isn't necessarily one of my goals, as I'm likely going to continue working on the custom client for the time being, albeit with support for plaintext telnet connections as well. If you look at the project site, you can see the work towards the client that has been done so far, but it's in the process of being rewritten as fscking around with libtcod's window drawing features gives me a headache versus the native SDL calls (which aren't much more fun in my opinion).

I have quite a bit of experience in network protocol design, as that's part of my job here at HP (I'm the Senior Systems Engineer for HP Cloud). The problems I've run into stem from getting the client to process the data being sent from the server fast enough, as the server is the one responsible for rendering the "graphics". The client, in this case, was only supposed to decode the information from the server to render the screen properly and then send further API requests back to the server.

It works fine in a local testing environment, but once you add the latency of the internet on top of it, even at 16kbps the client was starting to slow down to a crawl.

In case you're wondering why the server was responsible for rendering the "graphics", it was partially a "security" feature so that players wouldn't just be able to parse the map feeds from the server to see into places they weren't supposed to (around corners, into closed rooms, etc). The design flaw comes from the Roguelike development mindset, as a single player rouguelike wouldn't have to deal with those issues. As soon as you add multiplayer + realtime gameplay, the normal approaches to Roguelike development start to get fuzzy.

Which is why I'm approaching the MUD community and starting to integrate more of those ideas into the game engine, because there are solutions that MUD developers have come up with over the years that are directly applicable to the (non-existent) Multiplayer-Roguelike genre.

tl;dr - Mudlet isn't my priority at the moment, getting a game running on a standalone client & plaintext telnet linefeed are my #1 priorities for the time being :-)

User avatar
Vadi
Posts: 5035
Joined: Sat Mar 14, 2009 3:13 pm

Re: Seeking project members for a hybrid MUD/Roguelike

Post by Vadi »

I'm fairly certain Mudlet can handle large blocks of text very well - in fact the display is designed for that. Just wanted to clear it up. The issue would be in unicode and the custom letters mostly.

Though I think with some client-side scripting, appropriate interfaces would be possible to do as well.

Post Reply