Online,but not online.

[Ttech]

Well we could theoretically create shared games where players worked in different systems oncollective objectives. Even to the point of the players could play together if you got locations and such.


Realistically the data could be stored on the server would be something that is not game killing - so with added we could create a network of clients used together to generate more interesting, challenging situations. I'd love to discuss this with you George sometime. I have a bit of experience but would love to expand it.

Also we could generate systems using a server(s) to create larger more playable dynamic funness and better ai.

[george moromisato]

Just to be clear, I don't plan on fundamentally changing the vanilla game (Domina & Oracus). It will remain fundamentally a single-player game, even if some state is shared (like the Luminous probability tables). In fact, D&O should be playable without a network connection, so any use of the neurohack.com servers will be optional.

But I can imagine other adventures and extensions making use of the shared server.

[Ttech]

Just to be clear, I don't plan on fundamentally changing the vanilla game (Domina & Oracus). It will remain fundamentally a single-player game, even if some state is shared (like the Luminous probability tables). In fact, D&O should be playable without a network connection, so any use of the neurohack.com servers will be optional.

But I can imagine other adventures and extensions making use of the shared server.

Personally I think it might be good to come up with a udp / tcp proto port to use rather then plain http - that way it could be more efficient. I suppose if its just maps and player useful items it does not matter too much.
Though I was not suggesting changing the game I was saying it might possible if we had certain capabilities to be added to run stuff from a server. More complex system generation for example.

[george moromisato]

Though I was not suggesting changing the game I was saying it might possible if we had certain capabilities to be added to run stuff from a server. More complex system generation for example.

Yeah, I agree--I wasn't reacting to your earlier comments--I just didn't want people to think that vanilla Transcendence was suddently going to become multiplayer.

[Aury]

YEah, off-line play is a must - the game should still be fully functional w/o server access. (Some mods may not be, but then again, they'd likely be developed specifically for the server access)

[Ttech]

If mods had the ability to communicate to a server using http or a custom proto - that would be pretty cool.
I don't know what features could be added that were not listed above, but it might be neat.



I had an idea as a joke - while we play the game it processes informating using extra cpu cycles.

[Drako Slyith]

Of course, I have to say that if mods were incorporated globally on the server, it would be very, very easy to introduce something malicious into the system.

[Ttech]

Of course, I have to say that if mods were incorporated globally on the server, it would be very, very easy to introduce something malicious into the system.

not if we had a trusted mod id and the game still cannot write to disk really. But it would be needed to fixed.

[alterecco]

What George is suggesting has nothing to do with running code on a server, or sharing mods over a server or anything. It is simply a way to store a key/value pair on a global server. Harmeless, but of course, if used the wrong way, potentially gamebreaking.

I really like the idea George. It would seriously add some fun dynamics to the game. You could have an adventure extension with a system where the enemy presence was determined by global data (the more one team is winning, the harder it becomes?). You could have items that only became available once some global goal was reached (global quests!).

However, I see some real potential for spoofing. It does not take much hacking around in a mod to make it send data that breaks the progression completely (eg. for the luminous ai). Perhaps the key should be tied to the md5/sha1 of the file containing it. That way, changes to the file would end up writing another key (that is, not the one that matters)?

As for implementation, you might be interested in zeromq. Using something like that you would be able to eventually farm out to some worker if the need arose.

[Ttech]

Right alterecco, I know George was suggesting a way for data to be scared across games making for example luminous smarter. But I was thinking about the step further.
I think a hash should be used to verify the data was sent properly and a hash to authenticate the game <--> server. Perhaps a binary proto would be ideal, less easy to process then plain text and modify or spoof.

one way to do this would be to use something like json or a protocol buffer - where you could store any data you needed and then hash that data and hash the entire thing to ensure its valid then you could provide a key to verify it is coming from the game.

[Atarlost]

If it's happening in script authentication is pointless. Anyone wanting to send bad data could do so through the game.

[Cpt. Niceguy]

I mean a person gets two computers, both online, both with a separate account, then they sell high level stuff to their low level account, and dominate in the early game.

All that just for a game?
And for selling to self,as I said:lowest price for a certain level,or damage,so if a weapon is lvl 20 the lowest price should be balanced with offline game... Or if the damage it makes(or mby even dmg type it makes) also has certain lowest price.. So the price is connected to the atributes...Or something like that.

[george moromisato]

However, I see some real potential for spoofing. It does not take much hacking around in a mod to make it send data that breaks the progression completely (eg. for the luminous ai). Perhaps the key should be tied to the md5/sha1 of the file containing it. That way, changes to the file would end up writing another key (that is, not the one that matters)?

Agreed. This is still in the "thinking about it phase" so I don't have a design [And just to set expectations, this probably won't show up for a while.]

But I was thinking that this would be tied to a developer ID of some sort and that the relevant mod would be either signed (as you suggest) or stored on the server.

1. Developer registers their extension at neurohack.com (or whatever).
2. The registration process generates an md5 signature for the extension.
3. At load time we check the signature for an extension and refuse to load if the signature doesn't match (or we re-download the extension from the server).
4. At execution time, we check all calls to the unvSetData/unvGetData to validate that they come from the proper registered extension.
5. Calls to the server would have to be signed by the Transcendence engine [which means we'll need to store a secret key in the engine code.]

[Ttech]

However, I see some real potential for spoofing. It does not take much hacking around in a mod to make it send data that breaks the progression completely (eg. for the luminous ai). Perhaps the key should be tied to the md5/sha1 of the file containing it. That way, changes to the file would end up writing another key (that is, not the one that matters)?

Agreed. This is still in the "thinking about it phase" so I don't have a design [And just to set expectations, this probably won't show up for a while.]

But I was thinking that this would be tied to a developer ID of some sort and that the relevant mod would be either signed (as you suggest) or stored on the server.

1. Developer registers their extension at neurohack.com (or whatever).
2. The registration process generates an md5 signature for the extension.
3. At load time we check the signature for an extension and refuse to load if the signature doesn't match (or we re-download the extension from the server).
4. At execution time, we check all calls to the unvSetData/unvGetData to validate that they come from the proper registered extension.
5. Calls to the server would have to be signed by the Transcendence engine [which means we'll need to store a secret key in the engine code.]

We just discussed the same sort of thing on IRC. Perfect Timing really. I like the idea that the data will be validated and the engine will have a key, but will the data sent to the server be encrypted?

About my stuff above, part of that is I think it would be pretty cool if one day those ideas were possible. They are completely and positively fantasy and I don't think they would be implemented anytime soon. But if the protocol / setup had a capability to be easily modified at a later point is what I was suggesting though doing a terrible job at it.

[alterecco]

Agreed. This is still in the "thinking about it phase" so I don't have a design [And just to set expectations, this probably won't show up for a while.]

But I was thinking that this would be tied to a developer ID of some sort and that the relevant mod would be either signed (as you suggest) or stored on the server.

1. Developer registers their extension at neurohack.com (or whatever).
2. The registration process generates an md5 signature for the extension.
3. At load time we check the signature for an extension and refuse to load if the signature doesn't match (or we re-download the extension from the server).
4. At execution time, we check all calls to the unvSetData/unvGetData to validate that they come from the proper registered extension.
5. Calls to the server would have to be signed by the Transcendence engine [which means we'll need to store a secret key in the engine code.]

I find this a fun subject, but after thinking about it for a bit, I find it
really hard to see how you would avoid having players spoof the data. I also
think the idea of registering mods is overly complicated. Here are my thoughts,
on this and the subject as a whole:

--------------

A suggestion for implementation:

1. Create new events, and restrict running of online functions to those blocks.
Since running any online functions will have a completely different latency
than any of the other functions available in tscript, it should not be
encouraged to run them inside other pieces of code, since that will most likely
create strange behaviour.

1a. <OnlineOnLoad>
This event should be run at startup, after gPlayerShip and initial system is
available. A good place to initialize global data.

1b. <OnlineOnExit>
This event should be run when T is unloaded. A good place to update global data.

1c. <OnlineOnPlayerEnteredSystem>
This event will be run like the regular OnGlobalPlayerEnteredSystem. Required for
system specific global data.

1d. <OnlineOnPlayerLeftSystem>
This event will be run like the regular OnGlobalPlayerLeftSystem. Required for
system specific global data.

2. When T loads, generate an hash of every single file (vanilla files included).
When running any of the above events, track from what file it is called and
tack that files hash onto the key (or prefix it). That way, the database will
contain unique keys for every variation of the mod. This makes the process
simpler, and as far as I can see, just as spoofproof (at least that part).

2a. If needed, you can still add an interface that allows a developer to register
a mod and it's signature.

2b. If 2a is implemented, it would also be nice to have a way of designating
"updates" to the mod. That way the data stored in keys can be inherited by
future versions of the same mod. Basically, I upload a new mod and say, this
signature supersedes the previous signature (or they are grouped?).

3. Like you stated yourself, T would have to sign and encrypt the data.

--------------

I think the biggest argument for something like that above, is that it would
not require storing the mod on the server, and it would be really easy to work
with. Possibly more events should be added, but I think a simple start would
be just the right thing :D

However, I still find it hard to see how to make it completely spoofproof. Most
of the data I can see these functions sending would be gathered from various
sources, including globally accessible data (that is, stuff that is variable).
This means that anyone with a debug console, or a minimum of modding ability
can change those values (using other mods to affect global state). I can not
see any way around that. If it was just the console, we could rule out
debugmode, but since I can just create a mod that runs a piece of script
whenever I want it too, there is no real way of hiding from this vulnerability.