Build and Shoot

longbyte1 wrote:

I would really like to see a WebGL version of AoS. We keep making the same mistake, wanting AoS for platform X or platform Y. Why not have it in the browser so that visitors could play it without having to actually install AoS on their computer? They could also play it at school why not.

On top of that, we wouldn't have to reinvent the wheel since there's already Three.js, ENet bindings, and Voxel.js that we could use. And I'm willing to tear off some client code from the bot I wanted to make in order to make this WebGL AoS.

Anesthesia wrote:

.... So, how do you plan on using sockets from javascript?

Client --\                               /--Server
          >---WebRTC/Websocket server --<
Client --/                               \--Server

longbyte1 wrote:

Anesthesia wrote:

.... So, how do you plan on using sockets from javascript?

Probably going to have to wrap it in WebRTC. I wanted to not have to host a server with lots of clients but this is increasingly becoming inevitable.

So now it would be something like this:

Code: Select all

Client --\                               /--Server
          >---WebRTC/Websocket server --<
Client --/                               \--Server

A unique identifier system would be quite complicated in forethought, now that we have to use websockets, to prevent abuse. That would mean that on connect, the server would have to be responsible for checking the GBL for the client's IP, and it would somehow have to check for local bans. Oh gosh...

Or how about this. If the server kicks a client's connected websocket and the websocket finds out it's a ban, then we'd put the client in time-out for getting the websocket banned (because it's a proxy by design).

At any rate, I'm willing to work with it.

At the moment, however, I am fixing up the CLI version of my client code so that I can get it ready for porting to the browser.

Lincent wrote:

How will people be able to change game options in the Web Client?
; How will people be able to decide which server to play on in the Web Client?

• Game options will be saved locally of course.
• The server list will essentially be the main screen of the web client. It will be almost identical to the current main page since it would load from the same master server list.
• When you click on a server, the address bar will silently change to the address of the server you are going to (e.g. http://webgl.buildandshoot.com/ would turn into http://webgl.buildandshoot.com/server/1379434439/34887). Of course the page will not reload.
• The client will handshake with an available websocket server (only one well-built node is really needed to handle all the clients) and pass the address. Browsers hate connecting to arbitrary addresses with arbitrary protocols, so we must use WebRTC/WebSockets to wrap the connection into something more tolerable.
• The client proceeds with the regular AoS handshake routine as per the protocol. The websocket at this point will only act as a relay since any further intervention would only increase latency.

longbyte1 wrote:

Lincent wrote:

How will people be able to change game options in the Web Client?
; How will people be able to decide which server to play on in the Web Client?

• Game options will be saved locally of course.
• The server list will essentially be the main screen of the web client. It will be almost identical to the current main page since it would load from the same master server list.
• When you click on a server, the address bar will silently change to the address of the server you are going to (e.g. http://webgl.buildandshoot.com/ would turn into http://webgl.buildandshoot.com/server/1379434439/34887). Of course the page will not reload.
• The client will handshake with an available websocket server (only one well-built node is really needed to handle all the clients) and pass the address. Browsers hate connecting to arbitrary addresses with arbitrary protocols, so we must use WebRTC/WebSockets to wrap the connection into something more tolerable.
• The client proceeds with the regular AoS handshake routine as per the protocol. The websocket at this point will only act as a relay since any further intervention would only increase latency.

Lincent wrote:

Interesting I am slightly surprised Izzy hasn't replied to this thread yet

Lincent wrote:

Interesting I am slightly surprised Izzy hasn't replied to this thread yet

longbyte1 wrote:

Lincent wrote:

Interesting I am slightly surprised Izzy hasn't replied to this thread yet

At this point Izzy nor any site leader here is interested in any plans. They want tangible results.

longbyte1 wrote:

Unfortunately I am the only one here who is able to produce the framework for a client before I can begin hosting it on GitHub.

IAmYourFriend wrote:

On a side note, there's a VXL file renderer also using Javascript by yvt: https://yvt.jp/jvox/

LeCom wrote:

longbyte1 wrote:

Unfortunately I am the only one here who is able to produce the framework for a client before I can begin hosting it on GitHub.

Probably cause it's all java.
Btw I wonder how a first version would turn out in terms of efficiency - I'm not denying that Java is fast, but I never saw a project yet which was able to process large stuff as efficiently as C/C++ for example.

IAmYourFriend wrote:

On a side note, there's a VXL file renderer also using Javascript by yvt: https://yvt.jp/jvox/