OpenUru.org

here is my list from the GoW forums

Issues I believe will or might need to be resolved

1) Upgrade the current PyPrp or just completely finish PyPrp 2 to handle new features we will need
- Particles, GUIs and poseable animations (some are sightly working with hacking)
2) Upgrade the server code to handle uploading of Ages for both a test server and play server
3) Upgrade the client code to handle a general interface for accessing books (I vote for the Nexus, thats what its there for)
4) Fix the current Ages
5) Fix the marker pickup in subworlds bug
6) I hope, really hope that the code can be modified in a way that a local copy of marker games can be made, and uploaded
- Eg Sudre's insane Minkata marker game would have been best to save it locally and share that, can use a KI interface to do so, same as Jalak, in text format line by line
/savelocalmarkergame, /loadlocalmarkergame
7) A number of friends remarked on the difficulty in game to KI chat, hopefully that can be fixed
8) My personal wish to have every book that you link through be a public instanced one
9) Alter the code for the above suggestion so that when you click on the share book the KI icon would glow showing that the book is available under your personal links that you
can share bu KI invite
10) A method that allows us to have a "fake" server so that we can develop Ages on local machines or tie in Uru CC in some way to do the same thing
11) Bug tacking program - BugZilla? Maintainers have one for Ages perhaps we should have one too for Client, plugin and Server bugs?
12) In the Nexus when you delete an Age its actually deleted, none of this silly <Age> (1) business
13) Need to understand how SDL variables are changed on the fly, and possibly an application to be written that handles them.

other things
viewtopic.php?f=15&t=15

and
http://forum.guildofwriters.com/viewtop ... =10&t=2581
Basically this
1) The sharing of books at the book when released is dumb (we don't have any magic), instead have say an upgraded KI to level 3 (level 2 syncs the KI to the GZ), and touching the share page would instead glow and plash the KI icon at the bottom of the screen letting you know that, in essence you have allowed someone to share in the Age with you THROUGH THE NEXUS.
2) The Nexus is already setup very well, just go to the shared section to join your friend(s), Yeesha's ability on that system is strangely still in effect
3) When people link to an Age through the book were it was originally found they all go to a "public" instanced version, where everyone and anyone can go and actually meet people, this facet was ignored in MOUL which in turn I believe people couldn't associate the fact that there is no one else there when its a public book

I'm sure there is things i've missed

Edit: to go with the above
There is an addendum I had also proposed that i'll iterate here for public Ages.
The public instance of Ages would have certain things that are deliberately "broken", this can be done relatively easy (through SDL variables), its just making books public by default that is the real key
Eg, Teledahn, the scope would work providing power, but the grate under the hut would be permanently ceased, and the lock on the terminal would also be "broken", but the lift still goes up and down, and all journey cloths are not visible
So some of the Age is solved but the rest is still only solvable in instances

For the garden Ages, the break is that all the cloths are gone

Grogyan wrote:13) Need to understand how SDL variables are changed on the fly, and possibly an application to be written that handles them.

What in particular is not understood about SDL variables here? What do you mean by "changed on the fly"? Why do you need an application?

Once the initial hurdle of getting a working implementation of database/server/client has been passed, what are the most troublesome issues that need to be addressed?

I guess in time this might want split out into seperate discussions, e.g. Client issues, Server issues, KI/User Interface, etc. (possibly even on different forums), but let's start by brainstorming the points here, and see how it goes.

Try and keep to the "big hitter" issues rather than the "nice to have" things (the Suggestions forum may be a better place for those).

Mod Note: I created this thread as a split from the "Outline" thread. This really ought to be the read as if it were the Top Post, but, hey I haven't mastered time travel

I havn't strong feelings about the gameplay bugs/features but I would put my effort into understanding the backend load distribution and network utilization to work toward making a cloud of smaller servers (residential DSL-sized) workable. I think that is where the future lies given the financial hurdles of trying to set up a datacenter quality server farm.

rarified wrote:... I would put my effort into understanding the backend load distribution and network utilization to work toward making a cloud of smaller servers (residential DSL-sized) workable.

I'd be keen to see that avenue explored. walts posted typical dedicated server prices of around US$120 per month, and MO:UL had (I think) 10 game servers in the latter days.

Obviously DSL and cable are going to have bandwidth issues compared to dedicated servers, and those folks with ADSL rather than SDSL will have even more limited upload speeds. Given some of the observations we made in MO:UL, a server on ADSL might struggle to support even a few players, but hopefully I'm being overly pessimistic.

I don't think you are overly pessimistic. A few players, at most.

Here's something I posted on the GoW forum, apologies to anyone who has already seen it.

It depends on what you want to do. There is much misconception about the "distributed" nature of Uru servers. This is not SETI. From the limited time and resources Cyan had to transform UU into MOUL, we can assume it is not drastically different.

Testing your own Age on your home network, with perhaps two client connections: maybe your home PC would do it. Don't expect to run the client and the servers all on the same PC though.

Running a public server means (presuming the MOUL architecture isn't too different from UU or Alcugs) running one or more auth servers which will allow players to login, one or more lobby servers that manage connections, messages, linking, etc, and one or more data servers that actually serve you the Ages you're linking into.

As you can guess: forget doing that on your home setup. At most you could run a data server on a shard that's not too popular IF you have a very good and stable connection, but good luck if more than 2 or 3 players want to join an Age on your server.

For that you need more bandwidth at a more stable QoS than your average high-speed connection can provide, and more importantly no cap on total bandwidth usage. Most providers have started capping monthly usage for home connections. So a public Uru server will have to sit in a provider's datacenter.

For stability and performance, it will have to run on a server operating system, either Windows 2003 or, when porting is done, Linux or Unix. It will also have to run on some serious hardware, multiple-core CPUs with lots of RAM. It is too early to talk about 64-bits and multiple-core-aware code and OS.

Such servers need configuration and maintenance skills that require experienced server admins. All Uru servers will have to be started as services and configured for optimal use of CPU, memory and storage resources. They also needed to be monitored round the clock (well maybe not for a test server), backed up regularly, updated, patched, etc. Security is a serious concern. I have been working with an Alcugs shard owner and obviously there will be a need of an application-level firewall for detecting and filtering out packets before they can do damage, without having a performance impact. I'm thinking of the fly-mode problem here. Also, MOUL downloads all Python and SDL files from the server, in addition to the data downloads that UU and Alcugs already do. Managing the library on the servers is going to be a lot of work because each new Age will bring new files.

With all those requirements, you can expect to pay several thousands of dollars a year for each physical server in the shard. Start shopping on provider web sites and look into dedicated servers. Don't get misled by great offers on virtual servers or "virtual private servers", those won't do.
A few of us are lucky enough to have more-or-less free access to such resources, by being professionally connected to providers. The rest will have to shell out the big bucks and try to get money from players, which will bring other nightmares ("hello? This is the IRS. We'd like a talk with you").
There is always the possibility that a GSP (game server provider) would want to include Uru in its services and charge a monthly fee directly to the players. But when they'll see the market they'll run away screaming.

Yep thats Phase 1
Getting it started

Chacal is right in the big picture. Right now, housing servers behind conventional broadband won't cut it
as a functional Uru backend. And if the architecture is kept the same, the community will likely need to go
the route of hosted servers somewhere.

But I'm mostly talking about how to make the first steps fly. And I hope (until proven wrong) that we can do that on
a much more modest infrastructure.

As I've offered to others, I have a stable server setup (at home) thats more than adequate (I think) for the initial attack
by a limited number of developers.

It runs a base OS of Solaris, and I've just populated a virtual machine with Win2k8, VStudio 2k8 (90 day demo), and
MSDN .NET SDK. 1.5Tb available storage (raid5), and terabytes now are cheap. I can make RDP consoles available
so others can simultaneously work on a codebase. Additional VMs can be created for each of the server types needed.

Only limit is the 890k outbound ADSL bottleneck. I have commercial Qwest DSL and the last time I checked they
still didn't provide small business with higher outbound DSL. And I can't afford without support from work or others
to reinstall a T1 (last time I had it up it was $550/mo). My experience is that remote consoles are perfectly workable
if you don't go crazy with graphics (I regularly VNC from work to my desktop at home comfortably).

As for stability, the server:
velociraptor:~$ uptime
10:06pm up 165 days 3:39, 2 users, load average: 0.05, 0.05, 0.05
velociraptor:~$

and the firewall:
bash-2.02# uptime
10:06PM up 406 days, 10:57, 2 users, load averages: 0.06, 0.07, 0.08
bash-2.02#

Hopefully that's good enough to get started. When we either see the release from Cyan, or they can spend some time describing what will be needed we can make more long term plans.

Heh, I have non-commercial, non-residential DSL from Qwest. I often wonder if I'm a one-of. Same as commercial except that I don't get guaranteed uptime or mailboxes. My outbound is 960k. Very occasionally they mess up and I'll get 1.0-1.2m outbound. Once, I even had 7m up/down for a day. Irritates me about the cost jump to a T1 for a relatively small bandwidth increase.

Chacal; I just figured that you'd run a dataserver.

I agree that the first step should just be to get something running. Preferably without windows server and oracle. Will be studying up on some SQL, I think.

It would be nice if Cyan could post some hints as to how complete the source will be. Like if the PhysX code will be included. Anybody out there have the location for the server info in the MO:UL client?

teedyo wrote: Chacal; I just figured that you'd run a dataserver.

I agree that the first step should just be to get something running. Preferably without windows server and oracle. Will be studying up on some SQL, I think.

Actually I'm thinking more of running auth and lobby.
I'm going to continue in the new thread so that we keep this clean. See ya there.