[WF-General] server browser

Erik Ogenvik erik at ogenvik.org
Tue Jan 13 11:34:45 PST 2015


Well, the problem is already solved with Recast/Detour, as I outlined in
http://www.worldforge.org/index.php/about/news/pathfinding-ember/
What's left to do is to port the work over to Cyphesis. The entity
structures are a bit different, as is some other parts. And there are
different requirements for scaling.

One of the reasons that I've waited with doing it is that I first want to
have the "ai in separate process" code in place. With that, the AI is
handled in one or many processes different from the main cyphesis process
(which then just handles message routing and world simulation). This has a
couple of benefits, one of them being that it makes it easier to do
development, since only the AI processes needs to be restarted when changes
are made. (there are other advantages, such as better being able to take
advantages of multiple cores without having to implement threading support
in Cyphesis).

/Erik

2015-01-13 17:23 GMT+01:00 Sean Ryan <sryan at evercrack.com>:

> Hi Erik,
>
> I have some interest in path-finding.  I am pretty sure that I mentioned
> it before, but something like https://networkx.github.io/ might be a
> decent option for path-finding as it has multiple solvers.
>
> The only real issue with this being that it's python, so unsuitable for
> embedding into ember, but could be great if done for cyphesis, especially
> if we're only talking NPC pathfinding.
>
> For C++ (fitting in for both ember and cyphesis), there could be something
> like http://opensteer.sourceforge.net/ (although it's MIT license).
>
> Or also there is https://github.com/leethomason/MicroPather which seems
> alright.  The license talks about being "open source", and seems to really
> just require proper attribution, however I couldn't find it clearly stated
> what, if any, open source license they were using.
>
> If you want, we can have a irc-chat and talk about how you want
> pathfinding done?
>
> /sr
>
> On 2015-01-13 07:49, Erik Ogenvik wrote:
>
>> The one thing we really need is more development resources. There are
>> a couple of glaring omissions in the current stack, with NPC path
>> finding and proper collision detection being the most major ones. I'm
>> working on them, but there are so many other things that needs doing
>> that the progress is slow.
>>
>> /Erik
>>
>> 2015-01-11 22:55 GMT+01:00 Marisa Giancarla <fstltna at me.com>:
>>
>>  Ill see if i can help with that. Anything else you need, like
>>> project promotion etc?
>>>
>>> Marisa
>>>
>>> ----
>>>
>>> LinkedIn: http://www.linkedin.com/in/marisagiancarla [1]
>>>
>>> Opensim City: https://OpensimCity.org [2]
>>>
>>> Opensim Radio: http://radio.opensimcity.org:8188 [3]
>>> Empire Directory: https://EmpireDirectory.net [4]
>>> Lugdunon City: https://LugdunonCity.org [5]
>>> IndieDB: http://www.indiedb.com/company/pocketfiction-pocketgames4me
>>> [6]
>>>
>>> On Jan 10, 2015, at 11:50 AM, Erik Ogenvik <erik at ogenvik.org> wrote:
>>>
>>> We're always in need of help. This work would mainly involve working
>>> with Ember, using CEGUI for the interface.
>>>
>>> /Erik
>>>
>>> 2015-01-09 23:30 GMT+01:00 Marisa Giancarla <fstltna at me.com>:
>>>
>>> This looks really good, and my change requests would fit in nicely
>>> as additional fields. Need any help with this?
>>>
>>> Marisa
>>>
>>> ----
>>>
>>> LinkedIn: http://www.linkedin.com/in/marisagiancarla [1]
>>>
>>> Opensim City: https://OpensimCity.org [2]
>>>
>>> Opensim Radio: http://radio.opensimcity.org:8188 [3]
>>> Empire Directory: https://EmpireDirectory.net [4]
>>> Lugdunon City: https://LugdunonCity.org [5]
>>> IndieDB: http://www.indiedb.com/company/pocketfiction-pocketgames4me
>>> [6]
>>>
>>> On Jan 1, 2015, at 5:40 AM, Erik Ogenvik <erik at ogenvik.org> wrote:
>>>
>>> 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 [7] 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 [8]", title: "A view from the dock"}
>>> ],
>>> entrypoint: amber.worldforge.org:6767 [9]
>>>
>>> }
>>> ]
>>>
>>> /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 [7] [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 [10]
>>>
>>
>>  _______________________________________________
>>> General mailing list
>>> General at mail.worldforge.org
>>> http://mail.worldforge.org/lists/listinfo/general [10]
>>>
>>
>> _______________________________________________
>>  General mailing list
>>  General at mail.worldforge.org
>>  http://mail.worldforge.org/lists/listinfo/general [10]
>>
>>  _______________________________________________
>>> General mailing list
>>> General at mail.worldforge.org
>>> http://mail.worldforge.org/lists/listinfo/general [10]
>>>
>>
>> _______________________________________________
>>  General mailing list
>>  General at mail.worldforge.org
>>  http://mail.worldforge.org/lists/listinfo/general [10]
>>
>>
>>
>> Links:
>> ------
>> [1] http://www.linkedin.com/in/marisagiancarla
>> [2] https://OpensimCity.org
>> [3] http://radio.opensimcity.org:8188
>> [4] https://EmpireDirectory.net
>> [5] https://LugdunonCity.org
>> [6] http://www.indiedb.com/company/pocketfiction-pocketgames4me
>> [7] http://amber.worldforge.org
>> [8] http://foo.bar/1.png
>> [9] http://amber.worldforge.org:6767
>> [10] http://mail.worldforge.org/lists/listinfo/general
>>
>> _______________________________________________
>> 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/20150113/4c2f0f65/attachment-0001.html>


More information about the General mailing list