Serving MOUL Peer To Peer

[JWPlatt]

It's probably possible that the Alcugs server code could be updated, but it would likely be easiest to start fresh and fully implement the server using the new data that we have as opposed to the (lacking) information we had in 2004.

Perhaps you could explain to me, briefly if you can, how multiuser and network code (are they two distinct entities?) could possibly be integrated into CC or TPOTS? If not integrated, a separate process? This is just one question I have. Certainly there are other challenges because Alcugs was a shard server, not peer to peer, correct?

I hope to have my thoughts better laid out sometime soon, but for now, it might just be random fact-finding as things come up, assumming your willing participation in the discussion, which is greatly appreciated.

If you're thinking at all, "Hey, buddy, get a clue," I'd do a little operational research if anyone wants to provide a link to specific information (i.e. not the home page of a wiki).

And finally, this is all assuming that it will be necessary because Uru Live will not return. Honestly, I have more faith in Cyan than that, but I also don't push aside possibilities when the future is unknown. Hope for the best, prepare for the worst.

[Lontahv]

I'm not sure if this is what you're talking about but, having a fan-made Plasma-server sitting next to your unaltered UU would be really cool.

I think hacking the exe may be needed but I think it'd be better to try to just use a regular-old UU(or MOUL) and then have our code conform to Uru.

I'd be willing to help with the server if it didn't involve a massive re-write of the plasma client network code. I'll be learning C++ while doing this (which I've been wanting to learn for a while).

~Lontahv

[Paradox]

The actual code of the .exe cannot be modified.

A server would actually have to be run separately (unless Uru does really support P2P for more than just voice chat).

[Chacal]

Shhhh!
Naysayer!

[Almlys]

Alcugs was the first step to get a p2p architecture... but that step was never finished.

Plasma at current state it's useless, and a new client needs to be obviously written adapted to the current technologies and not what we had 5 years ago where Cyan is still stuck.

I was reticent to say it before on another thread where someone was defending the huge work done by Cyan, etc, etc.. , but I think that most people are not conscious that there are FLOSS engines highly superior on what Plasma can do.

Cyan has fallen in the closed source problem. The complexity of game engines, servers, operating systems, etc,, has evolved on a level, that there are dedicated teams working on only one small part of the whole thing. Why reinvent the wheel, or purchase abusive restricted licenses of some components that you don't know very well what rights do you have, when you can easily use FOSS stuff by abiding to it's simple freedom rules, well...

I still remember someone saying that Blender was not at the level to be able to create ages for Plasma... huh.

[Aloys]

Open Source Software has its limits too. Especially when it comes to game development. It might be cool for servers managements, DB managements of all kinds, bug tracking, calculators, whatever.. Domains where you have very precise and consistent needs.
Games by definition are unpredicatable, there are games of all kinds, and they are all different (well, mostly) and unless you plan on copying a game whose engine was OSS'ed or you plan to do something extremely simple that any engine can do (like a basic FPS), then you are most likely going to find limitations of various kinds in all OSS.. Which in turns means you'll need to spend time to learn the engine and then to modify it to suit your needs. Which will often will be faster and cheaper than developping your own engine from scratch, but not always..

Also; many game OS engines are limited with their licenses in regards to the commercial use you can do of it. Also, many licenses requires you to publish the original code and your code with the software; and for most businesses publishing your source code is a no-no... Right or wrong, that's just common business practice.. How many game developpers are there who publish their whole code online? Zero. Or close to zero. (I'm talking about recent games, not 10/20 years old abandonware). It's giving away your work for free, not really the most obvious business practice..

As for Blender not being at the level to be able to create Ages for Plasma: well obviously it is able to, but look at the huge amout of work required to make that happen... And basically every day I find some way in which it is awfully restrictive. But for the most part it works and it's free, so why go with something else? However, if I had the choice between that and Cyan's own tools for 3ds Max, I wouldn't hesitate a single second...

[JWPlatt]

The actual code of the .exe cannot be modified.

A server would actually have to be run separately (unless Uru does really support P2P for more than just voice chat).

Just so you know, Paradox, I see this as a progressive post because while you say the .exe cannot be modified - something I have been wondering about - you go on to say what could be done. I like that, thanks.

Almlys, you say never finished. The intent was there and there was some p2p work done?

I was asked some good questions by a friend who got me thinking a little more. I'll be back sometime soon with more about my thoughts. But one primary question which came up was how the p2p would work. In the questions, it was presumed the p2p would work like IM, with a server somewhere keeping track of our IPs. But this is NOT what I had in mind because you are back to relying on a central authority for the operation of the game. What I had in mind was a virtual, or instantaneous, shard where a small grounp could just agree amonst themselves to play for a few hours with just one IP being known in advance - just like LAN sessions in games like Microsoft's Age of Mythology. There are implications to the assumptions we can make about persistent game states in this case. Game states would probably vanish when the last player leaves the virtual shard unless they were saved under a session ID would could be restarted. It would be pretty cool to think of the vault as a class to be instanced rather than hard-wired to a physical shard server; a VUM (Virtual Uru Machine). But the model should certainly also allow a dedicated shard to retain its game states for people using it in the way we have been in the past.

[Lontahv]

I think a lot can come of servers not being servers, and rather being clients with large internet connections.

So the "server" that you can ask things (like, "what time is it") is just a kind of admin-client--and it can then write things to the amin database server that you can only ask "Get" (like HTTP).

This could solve a lot of hacker problems--because the user-server-admin has it's own security--like a firewall. So this means hackers would have to hijack the user-server-admin to send data to the main host.

The main "server" can be elsewhere (think big MYSQL database) like this:




(Sorry about the wiggly lines... if you've ever tried to draw with the mouse--you'll understand )

In this scope, we are all clients... except for the MYSQL-thing.


~Lontahv

[teedyo]

Dump the vault. If there is no central "authority", there need not be a central repository. Each client can keep track of it's own avatar/game states. This opens the door for crackers but does it really matter? If Doe Doe hacks into the files and learns x, y, z; how does that impact Jane John? Without a central vault to corrupt, it shouldn't be much of an issue. Now if Doe Doe comes flying through Gahreesen on a broomstick pulled by 8 tiny reindeer; an indignant client can just drop the connection to Doe Doe's IP. If the Indignant Client disallowed updates from Doe Doe; then Doe Doe would be flying through the air on nothing unless, of course, the broomstick was thought to be hidden somewhere.

[JWPlatt]

Perhaps now is, with the recent announcement of your client, an appropriate time to resurrect the idea of spontaneous or virtual P2P "shards."

Combine that with Marten and Lontahv's idea of a PRP previewer, and you're getting into collaborative, ad hoc development tools.