[WF-General] server browser

Erik Ogenvik erik at ogenvik.org
Thu Jan 1 05:40:03 PST 2015


With "working game" I mean a game world that is set up and allows people to
play a fun game.
We have to recognize where we've failed and remove those things that only
have a detrimental effect on the experience.

I assume that the vision from the start to have a vibrant community of many
different worlds, but we're not there yet. If we ever gonna get there we
need to make the system more accessible.
The server browser just makes that impossible.

When starting up Ember you don't want to see a confusing list of
cryptically named servers, the majority of them running broken or
incomplete worlds. You instead want to see what the system can do, you want
to play a game. No one gains anything from having to choose from 20
different versions of the Braga world.

The server browser will still exist for those that want to connect to a
random server, but the initial experience should be that the user is
presented with a list of games that can actually be played.
So far that's pretty much constrained to the Braga world being run on
mainly the amber.worldforge.org server. I don't know the status of Dean's
sandbox world; the metaserver doesn't respond currently (it's down?).
This also means that this isn't an automatic feature; it's a manual feature
where we enter the data about working games. If someone sets up a working
and unique world we'll add an entry. But there's no need for functionality
whereby the Cyphesis server automatically uploads data.

As such I'm content at just having an Atlas file served through HTTP. Ember
can fetch it through curl.

If would look something like this:

[
{
name: Braga,
ruleset: deeds,
description: "Enter the exciting island of Braga, where blah blah blah...",
screenshots: [
 {url: "http://foo.bar/1.png", title: "A view from the dock"}
],
entrypoint: amber.worldforge.org:6767
}
]

/Erik




2014-12-30 20:08 GMT+01:00 Sean Ryan <sryan at evercrack.com>:

> Hi Erik,
>
> We might have to sit down and haggle out the details, but conceptually I
> agree more or less with what your saying.
>
> I had occasion recently to review how WoW does their stuff, and it was
> interesting to see how similar it was to the current metaserver
> functionality ... very nifty.
>
> Anyway, I have responses for all your stuff below, but the short version
> is sure I can do that.
>
> Let me know,
> Sean
>
>  A server-based listing like the one we currently have makes sense for
>> quick match games like shooters or RTS's, but makes no sense for
>> players looking for persistent worlds. For them, the server listing is
>> just baffling, and doesn't say anything at all about the servers. This
>> is all made worse by the large number of broken and incomplete servers
>> that are running.
>>
> Point 1: I agree the current methodology is less than ideal, and we should
> revise it.
>
> Point 2: I'm not certain having default behaviour to isolate by "game" is
> appropriate.  I would say "server" is ok, but doesn't necessarily have to
> indicate 1 world server, 1 process.
>
> The last update I did for cyphesis with respect to the metaserver added in
> functionality to transmit additional data to the metaserver ... such as
> what server it's running (which typically will be cyphesis), and what
> ruleset it's playing, etc.  This could be helpful information to make
> additional decisions for display purposes.
>
> We can tune the metaserver query capabilities so that, *if configured by
> the client* you could only get certain types of rulesets, servers, version,
> ordered in a simply gui-configured fashion.
>
>
>
>> We should instead present the user with a list of well known Games
>> they can play. Instead of by default offering up all servers willy
>> nilly we should start by presenting a curated list of known working
>> games. These are games that are running and known to be working
>>
>
> This is a tough one.  The question really is ... what is working?  I know
> exactly what you mean, but what I'm talking about is the need to have a
> unit test ... or have some sort of certification process that in an
> automated way can provide a green light for listing.  We could possibly use
> some sort of server info to handshake a key or something ... like they
> register and include a property like the server_key (or any such thing),
> and we derive a session key on the ms and tell the server in the response.
> If we don't disclose this anywhere else, we could use that as a reasonable
> authentication for some server enquiries to accommodate that.  I've thought
> about how to do this, but we should sit and have a real think on it to
> decide where thing will go.
>
>
>  the Braga world we host on amber.worldforge.org [1]). The presentation
>> needs to be much better than the simple table we currently show. Each
>> world should be presented with a title, a collection of screenshots
>> (people love screenshots) and an extensive description of the world.
>> We should try to only show unique worlds by default; there's no point
>> in having ten versions of the exact same Braga world.
>>
>
> I think screenshots are an excellent idea, but the question is how.  The
> devil is really in the details on this one.  A default image and once
> logged into the world you can then have ember snag a screenshot or
> something?  We could have the MS store a blob, but I think that might be
> very onerous, and would drastically increase the operational requirements
> of the MS.  The other thing is some sort of "registration" process, and
> then we attach that info into the dynamic streaming media repo.  That way
> dynamically it can be requested and cached client side.  Thoughts?
>
>
>  The way the client gets the information needs to be changed too.
>> There's really no need for the client to contact each server.
>>
> This would not be required going forward from the next cyphesis release as
> is.
>
> From the cyphesis vconf:
>
> -----
> # additional attributes to send to MS of Monitor Variables
> # as a pipe delimited list
> metastats="clients|entities|version|ruleset|buildid"
>
> [metaattributes]
> server="cyphesis"
> -----
>
> We can send anything we like ... stats, version, whatever.  This
> information above (which was committed awhile back) would allow for all the
> sorting you have described (as well as a few others, such as latency which
> I calculate in round trip milliseconds from the first server registration
> packet, to the ack.  We are in 100% agreement, that the server should
> expose what information it wants (along with a default set that is
> required, we can discuss what that is exactly), and the client interacts
> with the metaserver to get that.  The first time there should be
> client->server interaction is the login process.
>
>
>  My suggestion if that the metaserver should respond with the Atlas
>> protocol, rather than the current bespoke protocol it uses. That would
>> also make its operation simpler, and more extensible.
>>
> I'm not certain that I'd call atlas "simpler", but as the low layer
> communication is done via atlas for everything, I agree that unifying the
> metaserver under that umbrella is the right thing.
>
>
>  Note also that I talk about "games" rather than "servers". It's
>> important that we present different games to the user, rather than
>> different servers. Part of my future vision of the system involves
>> having interconnected worlds hosted on different servers, something we
>> already have intial support for with the "teleport" functionality. As
>> such, the actual server should not be presented to the user (which
>> doesn't care about it anyway). Instead we should show the various
>> distinct games we provide.
>>
>
> I love the idea of interconnection, I am not certain it should be quite
> that willy-nilly, but I think that it's important for scalability (think
> instead of having 3-4 cyphesis servers running separately to cover "chunks"
> of a world, or different cities/fiefs, whatever ... seamless transport
> would be essential, but you wouldn't want for example some space skinned
> avatar bust in on your medieval themed game).
>
>
>  Sean, you're in charge of the meta server. What would it involve
>> making these changes? I'm tempted to initially just have a simple
>> endpoint serving up a static Atlas document.
>>
>
> I've actually thought of making significant changes over time to the
> metaserver to make it work differently, but one of the most important
> constraints that I was given was to be backward compatible.
>
> So, a few important questions:
>
> 1) Are you talking about a complete break in compatibility (i.e. total
> abandonment of the current MS protocol in favour of using strictly atlas
> comms )?  Or are you talking about having having the current MS protocol
> deprecated, and eventually phased out once usage is below a certain
> threshold?  My opinion on this is that we should collect when the next
> round of LTS supported distros are coming up, and aim for a complete break
> for the next LTS distro.  It might take some time to get it right, so this
> should be fine unless we're under the gun in terms of timing.  I'll need to
> rethink things if we want to maintain legacy functionality, because I do
> custom serialization in MetaServerPacket ... and i'm pretty sure atlas does
> that itself.  I'm not really in favour of just wrapping blobs to make life
> easier either ;)
>
> 2) If we're going to overhaul it ... we should have a list of requirements
> ... in terms of functionality, rather than implementation details.  Here
> are some things again off the top of my head, I'm sure you have some, and
> the wider audience might have some suggestions too.
>
> - maintain specific attributes x,y and z for each server
>   server=foo
>   ip=x.x.x.x
>
> - maintain optionally server specified attributes
>   current_players=123
>   foo=bar
>
> - allow data structure to be exposed via dns (this leads into all kinds of
> goodness with security, and making life easier for all kinds of stuff).
>
> - comms protocol to be atlas
>
> - allow the request of information in a flexible manner (this will
> probably mean defining a request/response interface, and making handlers
> for each type of request ... pretty standard).
>   Example Handlers:
>   : Meta Request (data about the data ... so what rulesets are registered,
> how many servers, etc)
>   : Full Request (dump of data structure)
>   : Limited Request ( request servers that are limited based on name,
> latency, ip, whatever )
>
> - logging of specific information TBD
>
> - store anything in database?  Currently I have scoreboards that I keep,
> and via cron I collect out an opentsdb format data and just keep it.  I was
> planning on the next release of cyphesis to start publishing this
> information via opentsdb.  Depends on needs, if you don't officially want
> to care about history/state we could orthogonally do this via the dns
> feature ;)
>
>
>
>
>
>
>
>
> _______________________________________________
> General mailing list
> General at mail.worldforge.org
> http://mail.worldforge.org/lists/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.worldforge.org/pipermail/general/attachments/20150101/3970d827/attachment-0001.html>


More information about the General mailing list