Using Comm-Array Components for API Integration

[CyberCrunch]

While reading this controversial discussion about Lua sockets:

I thought about why not combine an API system with an actual ingame component.

 

Ok, this will be technically 2 ideas in one post, but they are very much related to each other...

Basically the problem is how to “manage” ingame information. yamamushi suggested Lua scripts should provide HTTP access to their ingame data, so it can be processed by external applications.

But would it be the best way to rely on a "separated" server-client system for that? The problem to access data also exists if you try to build an app inside the game. (e.g. a display unit for a local market)

 

 

This is a kind of complicated topic, so I'll just try to focus on the brief concept:

We have DPUs which are the central hub for ALL data in DU. E.g. I assume the trading system and ship management will also run on DPUs.

To exchange the internal data of DPUs we could just connect a special API component that takes some specified variables and makes them available to the PC that is actually running DU.(e.g. using a JSON-RPC or similar to EVEs API system)

Thereby external applications can simply access ingame data without a dedicated API server.

You might think it’s quite limiting to only be able to access data that is right in front of you, but this is where the comm-array idea comes in...

 

 

The component for API access would actually be a sort of “Communication Unit”, but unlike previously suggested antennae-concepts it would provide general purpose input/output capabilities.

This antenna would be able to connect to other antennae, but be limited by range and  number of channels. So each antenna would be able to manage the following I/O data:

- current DPU variables

- API-channel variables

- X other DPU-channels variables

 

To define which variable is send to which channel, NQ would have to provide an interface to “wire up” each channel. Channels can be opened and closed dynamically, but new connection requests always have to be approved by the player operating the DPU.

As all this data will have to pass through the main server, the number of possible channels should be quite low. Maybe the most expensive comm-arrays would provide up to 10 channels and be limited to have only 1 on each TU. But 1-channel-comm-arrays could be relatively cheap so they can be integrated in each ship.

This would also correspond to the demand, as only big trade-hubs will be able to produce these large amounts of data.

Another way to reduce server strain is to have a slower update time from 1min – 1h. Also the sending of data should only be triggered by data changes.

Even if you want to access data from far away DPUs, you would be able to build an arrays of comms just to relay data back and forth.

Here is a little picture to illustrate the idea:

So in theory if we would build a global Network of comm-arrays you could access the status from all trade-hubs around Alioth in one place!

 

 

Conclusion

 

The main idea of this is that any accessible information inside DU (with or without API) would need to go through an actual network build by players. This would not only make it easier for NQ to channel the dataflow, but also allow exciting ingame scenarios: e.g. a spy might try to infiltrate the enemy’s comm-arrays to steal valuable military information.

Of course this is only a general concept. There will be other limitations to consider, e.g. not every kind of data should be allowed to send to the API-channel. The trade-hubs are also a bad example, as this is another controversial topic.

But on the long run I’d say this would be a very good system for DU, as it also fits their philosophy that the players have to build their own infrastructure.

 

 

Such a system would probably take NQ a lot of time to develop, so I don’t expect this to be ready at release.

Maybe the other suggestions about an API system could also coexist, or be integrated into this system… but there’s really too little information about most game features right now.

 

 

The only question I have is would this actually work? I’m sure I forgot some aspects so please tell me!

[Lethys]

A similar system was already proposed by twerk a long time ago, though we talked about the chat system there (comm- arrays and global chat)

Combine those two ideas and I like it

[CyberCrunch]

Yes, I’ve read this post, and I guess a lot of ideas about comm-arrays have come up over time...

This post also had very interesting idea on how to create an “internet” inside of DU:

Communication Units will be a big topic in DU, and NQ will probably provide all sorts of Components for different use cases. Maybe a big “Master Node” component which can be only be build as attachment with a TU, to provide all those different comm-features at once would be nice.

We’ll have to wait and see, as this probably not their top priority right now.