22 Oct, 2013, Runter wrote in the 1st comment:
Votes: 0
Heroku websocket support is in public beta.

https://devcenter.heroku.com/articles/ru...
22 Oct, 2013, plamzi wrote in the 2nd comment:
Votes: 0
Runter said:
Heroku websocket support is in public beta.

https://devcenter.heroku.com/articles/ru...


Cool. Are you planning to do something with it?
22 Oct, 2013, Idealiad wrote in the 3rd comment:
Votes: 0
The last time I looked Heroku seemed expensive for hobby work (that is, if you wanted a DB process with your free dyno). How does it look these days?
22 Oct, 2013, Runter wrote in the 4th comment:
Votes: 0
Idealiad said:
The last time I looked Heroku seemed expensive for hobby work (that is, if you wanted a DB process with your free dyno). How does it look these days?



Depends on the DB service, but many are free for a lot of data.

The mongo db I'm using is 500 MB for free using their service.

I figure a developer without much of a player base could use the free service without many problems, then upgrade to about 10 dollars per month to support a very popular game.
23 Oct, 2013, Runter wrote in the 5th comment:
Votes: 0
plamzi said:
Runter said:
Heroku websocket support is in public beta.

https://devcenter.heroku.com/articles/ru...


Cool. Are you planning to do something with it?


I'm still in the planning phase, but yeah, I'm planning to build a mostly text, multilingual MMO that runs out of the browser.
14 May, 2014, Runter wrote in the 6th comment:
Votes: 0
I've been working on what I mentioned for the last few months.

The game requires a web browser with websocket support to play. I'm not building reverse compatibility with mud clients. The advantage is I can do advanced things in a very clean way that doesn't have to respect backwards compatibility with the lowest common denominator.

I've structured the project into two distinct applications.
1. HTTP server using Sinatra that manages assets and client facing material.
2. Player-auth game server using websockets that connect to web browsers that controls game logic.
3. Postgres server for data.
4. Game data server that exposes certain things from the postgres server read-only.

I'm using client-side templates served from the HTTP server on request with mustache to render json being delivered from the websocket server.
For example, I have created a tooltip template which can send a tooltip request to the websocket server and get back json for generating a tooltip on the client.

To accomplish this I use a request cycle using unique identifiers that the client or server may generate when sending a request. The answering party will prefix it with the UUID to allow for deferred requests.

Because most formatting, processing, etc happens on the client side (Even with rendering of templates to html) the system is relatively light weight for resource requirements.

If anyone is interested in working on such a project let me know. I can provide most of the programming work needed, but what I really need is help with content creation client side design, art work, etc.
14 May, 2014, Nathan wrote in the 7th comment:
Votes: 0
Is there something you want to do that makes supporting mud clients not work? Aside from using websockets to talk to the server? Unless you've got a good reason, I can't imagine what point there is insisting that everyone use a browser. What sort of browser client are you planning on building?

Render Json into what? Or do you mean you want to package color, font, character set, style together along with the text to be sent in one "packet"?

Sounds like four applications not two? Either that or those other two shouldn't be in that numbered list.

This Sinatra -> http://www.sinatrarb.com/ ? If so, what exactly does it do that's so useful?

You should write up a quick design document outlining this better and stick it up on google docs or something. Your post here is kind of vague. Identifying everything that the two applications you mention will do and the details of these requests you refer to and maybe an example of how that would play out in client <-> server communications would be good.
14 May, 2014, Viriato wrote in the 8th comment:
Votes: 0
Good evening.
In my opinion, a web browser is the best "interface" option to gather new players, or at least it's MUCH easier to give a try playing a MUD. Also, it permits to do many fancy things not easily done in any current mud client.
I know abit about Ruby but I'm a bad builder, so I can eventually give a hand on code if you need something not too complex.
15 May, 2014, Nathan wrote in the 9th comment:
Votes: 0
Viriato said:
Good evening.
In my opinion, a web browser is the best "interface" option to gather new players, or at least it's MUCH easier to give a try playing a MUD. Also, it permits to do many fancy things not easily done in any current mud client.
I know abit about Ruby but I'm a bad builder, so I can eventually give a hand on code if you need something not too complex.


If all you were doing was presenting a text interface identical to a mud client then you'd be wasting your time making a browser based client. Most people can figure out how to install software and if you use something like mushclient, a simple set of instructions is enough to get up and running. The fact that it's a text based game and relies on text commands is far more unsettling, confusing to most people. If they're willing to give a text game a try they're probably not bothered specifically for having to install software, especially if it's not specific to your game. Sure, it gets over the issue of not being able to install stuff on a school computer because it's not yours and therefore it's hard to get a client, but I don't really think it's that big of a hurdle otherwise. – Also, as above, you'd better be taking advantage of these "fancy" things if you write a web client, but your website also has to have good uptime and your webclient needs to be well designed and reliable to avoid frustrating players. Using a existing tried and tested client gets you off the hook for the client end.

–> sorry if i'm getting off topic, but I can't see any reason why a webclient is intriniscally better. Yes, there's potential for a better experience but the developer has to turn that potential into reality.
15 May, 2014, Runter wrote in the 10th comment:
Votes: 0
There's a number of reasons that I think are very obvious for deciding not to support existing mud clients:

1. You can build objectively better interfaces without need to duplicate your work in a text-based interface. Indeed, often times it's more work to build the text based interface than the GUI. Since I have finite time I want to get the most bang from my buck.
2. You can express complex interfaces easily. If you build game mechanics with the requirement that it needs to be well expressed in a text-based environment you will end up with mechanics fit for a text-based environment. Not for an interface that could have made it understandable.

The truth is I don't care about building something that could be classified as a MUD, and I don't care about tapping into existing players. I also don't care about continuing to use text-input.

Quote
Render Json into what? Or do you mean you want to package color, font, character set, style together along with the text to be sent in one "packet"?

Rendering json directly into HTML on the client side. The server side does no rendering, and that's a fundamental difference that makes it not possible to support existing clients.

Frankly, I'm answering your questions in good faith only because I think it's useful to other readers. I think the tone of your post is far too negative, though, and not really interested. I don't know why I should need to explain that postgres server isn't actually another application. Or why I would use a webserver to serve HTML and assets.
15 May, 2014, Tyche wrote in the 11th comment:
Votes: 0
Nathan said:
Render Json into what? Or do you mean you want to package color, font, character set, style together along with the text to be sent in one "packet"?


Mustache is a web template system.

Nathan said:
This Sinatra -> http://www.sinatrarb.com/ ? If so, what exactly does it do that's so useful?


Sinatra is like Rails, Nitro, Camping. They are server side frameworks for processing web requests…Basically CGI on steroids.
15 May, 2014, plamzi wrote in the 12th comment:
Votes: 0
Runter said:
If you build game mechanics with the requirement that it needs to be well expressed in a text-based environment you will end up with mechanics fit for a text-based environment. Not for an interface that could have made it understandable.


I read you loud and clear, but I'm curious what you have in mind more specifically. Do you have any UI mockups or notes on the game mechanics you want?

Also, have you thought about focusing on content creation tools as a way to sweeten the pie for prospective content creators? Is that an area where hosting on Heroku can help?

Full disclaimer: I'm not a prospect, so feel free to ignore, but I'll def. come check it out and give some feedback when you can post links.
15 May, 2014, Idealiad wrote in the 13th comment:
Votes: 0
I think plamzi saw this at TMC but I'm not sure about other folks,

http://domdaria.com/

It's not a finished game but it's well worth looking at the screens at least,

http://domdaria.com/help

Is that kind of what you're thinking of Runter?
15 May, 2014, Runter wrote in the 14th comment:
Votes: 0
plamzi said:
Runter said:
If you build game mechanics with the requirement that it needs to be well expressed in a text-based environment you will end up with mechanics fit for a text-based environment. Not for an interface that could have made it understandable.


I read you loud and clear, but I'm curious what you have in mind more specifically. Do you have any UI mockups or notes on the game mechanics you want?

Also, have you thought about focusing on content creation tools as a way to sweeten the pie for prospective content creators? Is that an area where hosting on Heroku can help?

Full disclaimer: I'm not a prospect, so feel free to ignore, but I'll def. come check it out and give some feedback when you can post links.


I haven't spent a lot of time thinking about specifics yet, but I'll be sure to post screens/thoughts when I get that far. :)

The only thing I've really worked on is how data will be updated in real time without needing to be redrawn. So if a template is rendered in mustache that contains html elements connected to data channels it will automatically register the channels and the server will continue to push out updates to that specific data.

For example:

<div data-channel-id="12345" data-channel="player">
<div>Player Name</div>
<div data-channel="hitpoints">loading</div>
<div data-channel="mana">loading</div>
</div>
Then as the player loses or gains hit points just the value in the div would be re-rendered (potentially using it's own template).

@Idealiad
I can't speak for the gameplay, but the technology does look similar to what I have in mind.
15 May, 2014, plamzi wrote in the 15th comment:
Votes: 0
Dondaria's minimap tileset is very nice, and the UI is obviously being created by someone very capable.

There are a couple of things that really bum me, though. The main thing is that scrolling text is still the centerpiece, text input still reigns, and almost nothing is clickable. Maybe that will change later, but right now the game assumes a lot about the prior experience of the player.

Currently, the Dondaria UI is in no man's land, as in I'm not sure who it's being built for. Veteran mudders who can actually play the game using the web UI can play better games in their preferred client and in many cases (e. g. MXP-enabled games) they would actually have a better overall gameplay experience.

So while this might be an aside, I hope you're thinking of target audience.
15 May, 2014, quixadhal wrote in the 16th comment:
Votes: 0
Runter has the right of it.

If you refuse to cut the cord and fully adopt structured data as your server's way of talking to the outside world, you're forcing yourself to keep the same tired mechanics we've had since 1990… because supporting text-stream clients requires the server do all the presentation formatting AND that it has to parse raw text input as the only way to allow user interaction.

If you move all that to the client side, it does the work of formatting and display, and it also pre-parses commands to ensure they're valid in structure, and perhaps even valid in content (depends how much work you want to put into updating your client as the game develops).

This applies regardless of your choice of web-based, graphical, or even text-based clients. If your server talks using JSON, you could easily write a perl script to play the game and make it LOOK like a traditional MUD client, if you want… but you can also make a stand-alone semi-graphical client with an isometric tile map and both clickable buttons, regions, and radial menus. The server doesn't need to know or care, it just needs you to talk to it using the mechanism it expects.
16 May, 2014, Idealiad wrote in the 17th comment:
Votes: 0
@quix, how can you say that a text-stream game requires the server to do all the presentation when the extensive customisations of clients like Mushclient, Mudlet, etc. by their players proves otherwise?
16 May, 2014, Runter wrote in the 18th comment:
Votes: 0
Idealiad said:
@quix, how can you say that a text-stream game requires the server to do all the presentation when the extensive customisations of clients like Mushclient, Mudlet, etc. by their players proves otherwise?


Well, you're right in a way. There's a lot of interfaces built on top of normal interfaces. But think about this: mud servers generally have to do all of the rendering required to be playable on the minimal mud client. Anything extra is the equivalent of 3rd party addons.

So I think we can objectively look at it that mud servers are responsible with taking data and actually rendering it. The equivalent of an architecture where this rendering doesn't happen on the server would be the mud client receiving structured data and knowing how to format it to produce "A frisky fido is standing here."

{  "name" : "a frisky fido",  "state": "standing" }


Frankly, it's just as much work if you had to build a totally new mud server, but I think it has a lot of benefits.

Plamzi said:
There are a couple of things that really bum me, though. The main thing is that scrolling text is still the centerpiece, text input still reigns, and almost nothing is clickable. Maybe that will change later, but right now the game assumes a lot about the prior experience of the player.


Agree with you completely. I want to limit text input, eliminate scrolling regions (except for logs), and use icons and graphics where it makes sense.

Currently I'm using this library for my icons. I'm enjoying the SVG format because it lets you do some interesting things.
http://game-icons.net/
16 May, 2014, Idealiad wrote in the 19th comment:
Votes: 0
I've played a character in Domdaria up to level 6 or 7. plamzi's right, the gameplay isn't much, though it's a new game.

But what may be deceiving is that there's very little text input required, because the dev has created the client with a lot of hotkeys. It's basically like playing a roguelike. Now you may argue that this interface is just as opaque as a parser/command-line one, but even though you're 'typing text' IMO it's fundamentally different from a typical mud CLI.

In fact the UI/X in Domdaria is very well thought out from a keyboard-centric perspective. And this may not be the right choice, given mobile, tablets, and so on. But be that as it may, I like the playing experience of the UI much better than a normal mud.
16 May, 2014, Nathan wrote in the 20th comment:
Votes: 0
plamzi said:
Dondaria's minimap tileset is very nice, and the UI is obviously being created by someone very capable.

There are a couple of things that really bum me, though. The main thing is that scrolling text is still the centerpiece, text input still reigns, and almost nothing is clickable. Maybe that will change later, but right now the game assumes a lot about the prior experience of the player.

Currently, the Dondaria UI is in no man's land, as in I'm not sure who it's being built for. Veteran mudders who can actually play the game using the web UI can play better games in their preferred client and in many cases (e. g. MXP-enabled games) they would actually have a better overall gameplay experience.

So while this might be an aside, I hope you're thinking of target audience.


The moment you throw text out the window, you might as well just be any one of a number of so-so games out there. It's one of the only things that makes a MUD different than any other game, although certain aspects of that can be tedious. Hopefully having pretty graphics won't lead to skimping on the quality of descriptive text. Their game has to report status changes somehow. Is the Domdaria inventory and quest box clickable? It looks like it might be or should be.
0.0/36