Username: Password:

Articles and Commentaries at Web Game Friends

Official ImagePossible MUD client integration

Posted on Wednesday, the 2nd of June 2010 at 10:03 am
13 Comments
Viewed 907 times

I'm about 95% of the way to a "first draft" release of a completely customizable, web-based, plugin-free MUD client that will be introduced as a part of MUD games' profiles (at the option of the game owner...).

This client is written in pure HTML/CSS and Javascript (with a Flash fallback for browsers that haven't implemented all of the HTML5 standards), meaning the look and feel are entirely customizable.

Take a look at these screenshots as an example of a client I'd been working on for Achaea by Iron Realms Entertainment (their artwork is, of course, copyrighted, as annotated at the bottom of these shots):

 

Some of the features there (mapping, room exit links) are only available with some special code built-in to the MUD server (ATCP, in this case), so not every feature will work or be made available in the client for every game, but that doesn't mean we can't work together to include what you need on your end and what I need to get on my end to make this stuff work.

The logging is a pretty fun feature, I believe.  You just click once to start it, click it again to stop it, and you get a link to your HTML-formatted log file, ready to do what you like with.  I'm also going to resume talks with the fellow behind NoGFX about integrating an automatic upload of logs (again, at the player's and game owner's discretion).

Another sweet feature I forsee (optional, of course) is allowing your players, upon logging in through this client, to post a status update to Facebook and/or Twitter, announcing that they've begun playing the game with a link to the game's profile here.  We could also work together to include "achievements" and other social announcements -- kept to a discretionary number -- to really start making use of the social engines.

One thing I DON'T intend to include in the client is a scripting/system building feature -- after some testing and discussion with system authors from other games, it just ain't appropriate.  This is designed to be a "jump start" or "quick play" kind of client, meant to get newbies or casual players into the game in a friendly, pretty way.  This doesn't mean I won't include a simple alias feature (setting "wn" to execute "walk north" kind of thing) or even simple macros (pressing "1" on the NumPad to walk southwest), just not a full scripting structure for setting up triggers, building complex logic, etc.

Tell me what you guys would like to see in a client like this.  Would you customize it (if you own a game) or use it (as a player)?  Am I wasting my time (not that I mind, I'd just rather use it giving you guys what YOU want)?

Thanks!

- John

Permalink

Posted in: Community Weigh-in

Bookmark and Share

Comment Board

User Image
bd1985 said on Wednesday, the 30th of November 2011 at 2:01 am:

Just the same, when I first saw his lofty new contract numbers, I thought there must have been a typo. Myers, who has one year remaining on his first NHL contract, last week signed a seven-year extension worth $38.5 million US with the Sabres, meaning he’s secure until 2019.

As former tennis star turned broadcaster John McEnroe might have said: “Surely you can’t be serious!”

Main products: nhl jerseys,football jerseys,cheap sports jerseys,discount jerseys,wholesale MLB jerseys,cheap jerseys for sale,jerseys for cheap.

The way I see it, Myers has performed pretty much the way the Sabres had hoped he would after being taken with the 12th overall selection in the 2008 NHL entry draft. He went back to junior for a year and followed that up with a pair of generally strong seasons with Buffalo. 

In many ways, his career has so far paralleled that of Ottawa Senators defenceman Erik Karlsson and P.K. Subban of the Montreal Canadiens — stay tuned, more companys to follow — with impressive peaks of great play and some deep valleys, extended periods when seemingly nothing went right. All of that is a normal part of the growth process to consistency.

Because of his size and skill, Myers www.monclerconnotation.com could very well become one of the league’s dominating defencemen. Could. Yet, age of 21, he has already become a new Bank of America based on his future potential. As a point of reference, Hall of Fame defenceman Denis Potvin did dominate in the NHL at age 21 in 1974, joining the New York Islanders following five seasons with the Ottawa 67’s, and his salary at the time was $80,000.

Sure, that was then and this is now. All the more power to Myers and his agents for striking it rich. As for new Sabres owner Terry Pegula, he could probably run for mayor of Buffalo and win. By signing Myers to the lengthy deal, the Sabres have avoided the chance that he could be poached by a rival team with an offer sheet next summer and kept him from becoming an unrestricted free agent until he’s 29.

Pegula’s NHL colleagues, however, won’t portray him in such a www.windgeneratorhummer.com

glowing light. The Myers contract has forced their pockets … er, hands. It has now become the standard for all of the top defencemen selected in the 2008 draft, whose contracts expire at the end of the 2011-12 season. 

That group includes Karlsson and Subban. Senators general manager Bryan Murray has yet to start contract talks with Karlsson’s agent, but they’re coming soon. 

While Myers is unquestionably a better defensive player www.jerseysmonopoly.com than Karlsson and Subban, those two stack up favourably against Myers in countless other areas, and the NHL contract world is all about comparables.

Consider: Myers scored 10 goals and 27 assists in 80 games last season, while Karlsson had 13 goals and 32 assists in 75 games and Subban produced 14 goals and 24 assists in 77 games. Myers played an average of 22 minutes 27 seconds per game, while Karlsson checked in at 23:30 and Subban at 22:16. Myers plays more than both in short-handed situations, but Karlsson tops them both in power-play time.

Related Websites: down coat cheap monclers moncler jackets womens jackets wind turbine

cheap down jackets  goose down jacket  wind generator wind mill wind power wind enegy

User Image
KaVir said on Friday, the 25th of June 2010 at 6:49 am:

How`s the progress coming along?  I know from experience how "a bit more tweaking" can often turn out to be more effort than anticipated, but I`d be interested in testing it even in an unfinished state, and perhaps some early feedback would be useful.

I`m happy to make server-side modifications to test out different ideas, and provide debug data for protocols and such, and when it`s ready I could rope players in to start stress-testing.  This client is something that would directly benefit my mud, lowering the entry barrier for new players, so I`m very keen to see it finished.

User Image
John (Admin) said on Monday, the 7th of June 2010 at 7:15 pm:

BREAKTHROUGH!  The Flash fallback (for browsers that aren`t Google Chrome) is now entirely operational!

I`ve got a bit more tweaking before I can release anything, but the hardest part by far is done.

Kavir:

Broken up images may be a better solution.  We`ll just play around with the data you`re sending and how it might be used, but I`d guess the single image(s) will work fine.

So the areas being mapped are no bigger than 11x11?  That should be no problem in terms of speed, particularly since there won`t need to be any further http requests to handle it once the images are downloaded to the client.

Can`t wait to get this thing rolling for real!

- John

User Image
KaVir said on Sunday, the 6th of June 2010 at 6:17 pm:

I currently use bmp files because the player downloads them in advance, so the size isn`t really an issue, and the quality is a little better.  The mud produces them from internal data, so I don`t need to update them manually when tiles are changed or added.  I agree that another format would be more appropriate for a web client (personally I`d favour png), but at this stage I was only really linking the images to give an idea of the concept.

It seems Mudlet doesn`t allow images to be chopped up, so for them I`ve split each tile into its own image.  This would be another option for your client, although it does potentially mean downloading a [i]lot[/i] of images.

Currently I have two maps, each 11 by 11, which look like this: http://www.godwars2.org/images/maps.png

The plugin has a draw_map() function for the top map and a draw_zoommap() function for the bottom one: http://www.godwars2.org/download/mushclient/GW2_Custom_Layout.xml

The Achaea approach wouldn`t really work, as some of my maps are extremely large, while others can be terraformed on-the-fly by players.

User Image
John (Admin) said on Sunday, the 6th of June 2010 at 1:39 pm:

I`ll definitely look into MSSP as an option -- it looks perfect for the application.

As for your mapping, we can certainly look into how to customize the client.  My initial thoughts, based on the system you`ve described, is that it will certainly work with a bit of code added to the javascript of the client.  I converted your graphics to both PNG and GIF format (because there`s just no need to use BMP on the web...), and it cut the tiles file down to about 60k, if I remember correctly, which is more than reasonable for downloads.  It`s then just a matter of positioning the whole image over and over again, based on the indexing you send, to create the map(s).

How large an area do you map at a time (size of the cartesian grid is what I`m after)?  In the past, I`ve begun to hit practical limits in terms of redrawing speed around 100 cells (a 10x10 table).  If it`s much bigger than that, I may need to rethink the method I`m considering.

Do you have a sample client code implementation for handling the mapping?  That would almost certainly help! :)

The maps for Achaea are handled by downloading a map file of the entire area and placing the player according to a grid coordinate (multiplied by the appropriate number of pixels for each grid square).  Some of this methodology could be borrowed, but obviously not all.

In other news, I`ve got the Flash fallback nearly working.  Got a couple of minor bugs to iron out and some tweaking to do, but things are progressing well.

- John

User Image
KaVir said on Friday, the 4th of June 2010 at 4:17 am:

Including WGF information is a great idea, although there`s currently not much statistical data in the game profiles.  Would the client be collecting the data directly from the mud?  If so, I`d once again recommend looking into MSSP (http://tintin.sourceforge.net/mssp).

Personally I`d be wary about sending too many large files to the client, but I think it would be okay to have a mini version of my soundpack - perhaps a dozen or so combat sounds, each lasting no more than a second.  Presumably the client would be able to download these directly from the mud`s website, without impacting its connection to the mud?

Displaying the graphical map would be the harder part I think.  The way I currently handle this is for the player to download my terrain.bmp and tiles.bmp images (from http://www.godwars2.org/download/mushclient/images), each of which contains a sequence of graphical tiles one beside the other.  The mud then sends their client a list of index values which are used to draw the required tiles.  However this is quite a large initial download, requires special coded support to display, and utilises two maps instead of the single map you currently use.

But if your map window is done fairly generically, perhaps I could still use it for the terrain map.  What data does it currently use?

In regards to ATCP, I don`t truly support it, I just use it as a carrier for MSDP data for clients that support ATCP but not MSDP.  This requires a little customisation in the client script, but as long as your client identifies itself it`s not a problem to handle it at the server end.

User Image
Conner said on Friday, the 4th of June 2010 at 4:14 am:

Sadly, I can understand where you`re coming from regarding mudstandards all too well. It got off to an incredible start initially because it sounded like a great idea, but at this point it`s mostly serving as a reference for most of the mud protocols out there. Still, it does work even now as a decent reference site... and I can relate all too well with the notion of having to find a decent internet connection, I`ve been suffering through the rigors of satellite for the last year now (since my wedding and subsequent move across country myself), and rigors is definitely the right word for it.

User Image
John (Admin) said on Thursday, the 3rd of June 2010 at 7:54 am:

Conner:

I did indeed sign up at mudstandards with the intent of discussing WebSockets and various integration requirements for native support of the standard, but between moving across the country, finding a decent internet connection, and the slow decline of the site, I haven`t gotten around to it.

As for ATCP (or any other standard/protocol), nothing is required -- the client will function like any other (z/cMUD, etc.) on nothing but pure telnet communication, and you can still do all of the "pretty"-fying, logging options, etc.  The other stuff just provides the extra "oomph" that can further ease new players into the game.

 

KaVir:

You raise excellent points regarding advertising -- that was a "floater" idea that crossed my mind, but consider it stricken -- no advertising on the client.

What I DO want to include is information from the game`s WGF profile, like which characters have been created (and maybe even which ones are online), stats, forum discussions, etc.  All of this will be arranged discreetly enough that play won`t be affected.  I`m thinking a kind of "toolbar" that floats at the top or bottom of the page.

Next up: I`m going to have to revamp the ATCP handling just a bit to allow for custom ATCP-type tags, but there shouldn`t be any need for you to modify your game engine`s code.

As for the look and feel options, media, and caching, this is fairly dependent on the browser itself.  Tiling a simple image is quite simple, and providing color options for the text window(s) should be easy enough, as well.  At some point, I`ll have to cut off the level of customization available to prevent feature bloat, but those are fairly simple.

I`ll see if I can`t provide some mechanism, too, for pre-loading graphics, mp3s, etc. that you might make use of in the game.  These should remain cached (dependent on browser settings), speeding up loads considerably between, but we`ll just have to play with that.

Generally, the client is just like any other web page on the internet, including file handling/caching and any other behavior.

User Image
KaVir said on Thursday, the 3rd of June 2010 at 5:26 am:

What sort of adverts are we talking about?  Having a "powered by WGFriends" logo/link/banner is definitely no problem, but if there are banners advertising other games (particularly other muds) then that would make me hesitate.  It`s difficult to attract new players, and providing a download-free client could definitely help to overcome the first hurdle - but if the first thing those players see is a big advert for a rival mud, I`d probably be better off recommending a different client as far as retention rate is concerned.

My mud primarily uses MSDP for clients to retrieve data, but I do provide a way to access the same data through ATCP.  I don`t use any of the standard packages, but could easily customise the server to return whatever data you need.  I`d need a way to identify your client though - do you negotiate TTYPE?

For look and feel, I`d personally prefer a textured background image with an opaque black text window drawn on top of it.  To avoid a large download, it would be nice if I could provide a small image and have it treated as a tile, redrawn over and over to fill the window.  Perhaps people could select a colour (including transparent) for their text window?

If the client can download a background image though, does that mean it can do the same for map tiles and perhaps even sound files?  If so, will the data be cached?

I think it`s probably enough just to support MXP links and colours - those are the only two options I plan to use, and the same is true for most MXP muds I`ve seen.

User Image
Conner said on Thursday, the 3rd of June 2010 at 12:29 am:

As a mud owner, yes, I`d probably make use of it (at least link to it if not actually customizing etc). As a player, probably not, I`m pretty used to the clients I have installed on all my computers already. I definitely like the initial look so far and the direction that your responses to KaVir imply you`re thinking of taking it though.

As a mud owner, my general perspective is that the more ways that exist to connect to my mud, the better, especially quick easy methods that work for newbies.

I am very interested in ATCP and MXP both, but not entirely certain that I understand how to implement ATCP on my end yet. There are some other protocols that might be worth considering as well if it becomes feasible. Had you followed any of the discussions that went on over at http://www.mudstandards.org/forum/ to date? If not, it might be worth the look.

User Image
John (Admin) said on Wednesday, the 2nd of June 2010 at 8:25 pm:

1) Will it only be accessable from WGFriends, or will mud owners be able to post the link on their own websites, include it in forum posts, etc?

You`ll certainly be able to link to it, and folks will be able to play using this client whether they are WGFriends members or not (there may be some ads, etc., in a non-obtrusive fashion, but that`s all).

2) If a mud supports ATCP, can it configure its own energy bars, or does it have to use the five in your screenshot?  What about the map - can that be customised too?

I`m not sure yet how that will be handled, but more than likely on a case by case basis (until some system is devised).  If your MUD supports ATCP, the client will negotiate to use it.  I do need to work on better support of the various ATCP features, however. 

I will certainly be happy to work with you and any other MUD owner on getting exactly the features and customization you want to have.

3) You mentioned that the look and feel can be customised - does that mean buttons can be added, the text window resized, etc?  Or do you just mean the colours and background image?

Initially, just colors, images, etc., but I may just make the client html and javascript libraries available to MUD owners so that you can add the features and buttons YOU want.  I`ll need to verify it for folks I don`t have an existing relationship with (and probably with everyone, just to be sure) to prevent any kind of intrusive code introduction (and to add Facebook integration features as required/requested).

4) Will the client support MXP?  It seems clickable links would be a big selling point if you`re trying to appear to browser gamers.

The client already has marginal support for MXP.  I know anything hyperlinked already works, I`ll have to check again to see how far I`d gotten otherwise.  I believe that and colors was about it, though.

User Image
KaVir said on Wednesday, the 2nd of June 2010 at 5:45 pm:

Very nice, but I have a few questions:

1) Will it only be accessable from WGFriends, or will mud owners be able to post the link on their own websites, include it in forum posts, etc?

2) If a mud supports ATCP, can it configure its own energy bars, or does it have to use the five in your screenshot?  What about the map - can that be customised too?

3) You mentioned that the look and feel can be customised - does that mean buttons can be added, the text window resized, etc?  Or do you just mean the colours and background image?

4) Will the client support MXP?  It seems clickable links would be a big selling point if you`re trying to appear to browser gamers.

User Image
John (Admin) said on Wednesday, the 2nd of June 2010 at 3:12 pm:

In case there`s any concern, the client won`t REQUIRE you to do anything at all to your MUD server, though there are certain things that you COULD do that we`ll go over in more depth as necessary.

- John

© 2007-2009 Web Game Friends. All rights reserved.
Advertise  ::   Contact Us  ::   Terms of Service  ::   Report this page