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.
WebGL client
That is a very interesting idea. There's a lot of potential in WebGl.
[Warp-UK] FN-FAL, MK11, G36C, VSS Vintorez, AK12, ACE 52, AKs74u
Look for more (Inc Sounds)
Code: Select all
http://i.imgur.com/1dlFJ0w.jpg[12:43] <@LeCom> no I suck dick
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.I had the same idea for a wile now, hopefully Izzy will let you implement this.
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.
____________________________________________________________________________________________________________________
Vezok wrote:Yes but Lincent is more active on the 1.0 forums, so BnS have that appeal.
longbyte1 wrote:They're all waiting on me to finish my WebGL client.
The truth is that I haven't worked on it for the past 2 months.
stretch goal: add Voxlap faithful mode, port iceball to emscripten
-
Deuce - Posts: 1
- Joined: Sat Jun 06, 2015 3:51 pm
.... So, how do you plan on using sockets from javascript?
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
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...Client --\ /--Server
>---WebRTC/Websocket server --<
Client --/ \--Server
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.
longbyte1 wrote:How will people be able to change game options in the Web Client?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 allA 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...Client --\ /--Server >---WebRTC/Websocket server --< Client --/ \--Server
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.
; How will people be able to decide which server to play on in the Web Client?
____________________________________________________________________________________________________________________
Vezok wrote:Yes but Lincent is more active on the 1.0 forums, so BnS have that appeal.
longbyte1 wrote:They're all waiting on me to finish my WebGL client.
The truth is that I haven't worked on it for the past 2 months.
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:Interesting I am slightly surprised Izzy hasn't replied to this thread yetLincent 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.
____________________________________________________________________________________________________________________
Vezok wrote:Yes but Lincent is more active on the 1.0 forums, so BnS have that appeal.
longbyte1 wrote:They're all waiting on me to finish my WebGL client.
The truth is that I haven't worked on it for the past 2 months.
-
noobofspades
Deuced Up - Posts: 380
- Joined: Thu Jan 01, 2015 11:57 am
Lincent wrote: Interesting I am slightly surprised Izzy hasn't replied to this thread yetIt's been years now. How did you not get used to BnS yet?
Envy wrote:Don't bring my mom into it just Becuase you mom is a hore!rip deleted posts nevr4get
juxta get a life wtf
Lincent wrote:Interesting I am slightly surprised Izzy hasn't replied to this thread yetAt this point Izzy nor any site leader here is interested in any plans. They want tangible results.
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.
longbyte1 wrote:Not even that. They only try to adjust to hypes sometimes.Lincent wrote:Interesting I am slightly surprised Izzy hasn't replied to this thread yetAt 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.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
Global Moderator
- Posts: 103
- Joined: Fri Nov 16, 2012 8:58 pm
-
On a side note, there's a VXL file renderer also using Javascript by yvt: https://yvt.jp/jvox/
IAmYourFriend wrote:On a side note, there's a VXL file renderer also using Javascript by yvt: https://yvt.jp/jvox/
LeCom wrote:JavaScript you mean? I'm using Node.jslongbyte1 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.
Performance is not exactly a concern since browsers use GPU acceleration for WebGL. I am trying to do my best not to reinvent the wheel as far as putting things together. That means don't try to make your own voxel engine; use Voxel.js, which in part uses Three.js, which does not ever try using CPU for rendering anything.
Java is a stupidly redundant language. I use it for academic purposes but anything other than that and enterprise code is just awful. Not only that, but Oracle is kicking the user base off Java. They are not even trying to develop a JavaScript-based JRE, which would save a lot of time since there are a bunch of applets floating around on the Web that nobody will bother porting to JS.
IAmYourFriend wrote:On a side note, there's a VXL file renderer also using Javascript by yvt: https://yvt.jp/jvox/That looks really useful. Thanks for that.
I didn't say a single word about raycasting with java/js lol
Just had terrible experiences with this, but if you say it's fast enough, fine. We can judge when there's a first version
Just had terrible experiences with this, but if you say it's fast enough, fine. We can judge when there's a first version
Who is online
Users browsing this forum: No registered users and 47 guests