Topic awaiting preservation: Javascript deathmatch.. (Page 1 of 1)

I've had a go at making a multiplayer deathmatch game in DHTML using my raycasting engine but am having some problems with lag.

I've created an asp script that takes coordinates from the clients and then feeds back the coordinates of all clients..

So in my main game loop I have something like

Iframe.src="deathmatch.asp?handle=player1&x="+PX+"&y="+PY+"&angle="+PA

and then the asp script will run and generate some javascript like:-

<script>
//player1
PX1=11841;
PY1=8598;
PA1=50;

//player2
PX1=111;
PY1=4099;
PA1=10;

//player3
PX1=5009;
PY1=6322;
PA1=140;

//etc
</script>

..which the raycasting engine can read, so it knows where all of the players are.

This works fine, but there is some delay between people moving and it showing up on the other players screens. Is there a better way of doing this??

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

see if you can check out some of Poi's games, he has quite a few things using various raytracing and fp game formats. I can't remember his site off the top of my head, but he is a regular in this forum so check thru the posts and you'll find some good stuff.

visit my CryoKinesis Online Gallery

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

smonkey, thanks but I'm not having any problems with the graphics part of it.


InI, I'm pretty sure it can be done What I've got so far is working ok, just a bit laggy.. With a better implementation or a better method I'm sure I'll have it working great.. Hopefully

The poster has demanded we remove all his contributions, less he takes legal action.
We have done so.
Now Tyberius Prime expects him to start complaining that we removed his 'free speech' since this message will replace all of his posts, past and future.
Don't follow his example - seek real life help first.

It isn't easy and I'm not sure about lag, but I've been working on something relating to this!
http://www.ozoneasylum.com/Forum2/HTML/002371.html

In a (long-winded) sentence: Asynchronous communication between multiple web clients connected through a common web interface.

I wanted to make a DHTML recreation of the classic "Scorched Earth" (a work in progress) networkable, this was why I was tinkering with a networking layer sort of thing. Once I get some time I intend to package it up and make it a downloadable component people can use in their projects, assuming anyone cares

An easy way to eliminate lag... have the ASP go into an infinite loop, in each loop checking, say, a file, to see if there is new data. If there is, spit it a JS trigger to the client. If there isn't go on. That takes care of part of the lag, at least. It's like having an open socket to the server.

Glad to see that my work have left a print in some minds, but InI is right, I've focused on single player experience so far.
Anyway, I'm pretty sure that doing a multiplayer game with DHTML + server side script ( PHP, ASP ... ) won't be slower than the usual chatrooms we've already seen. In fact, the only problem comes from the time to send/get some packets to/from the server. The client-side part of the "network core" is so short that it should have almost no impact on the framerate.

If I'm not wrong, the delay between a movement and its repercution on all the clients is a little more than twice the ping time between a client and the server. I've pinged my host and got ~90ms, which would make a lag of ~ a 5th of second and a framerate ( for the players ) of ~ 5 fps. Doh! If I'm wrong, and I hope I am, it would just be a little more than one time the ping time and thus ~ 10 fps.

Doing a multiplayer game in DHTML seems to be an interresting task. I'll update the miminalistic persistent connection thingy I had done for the "Streaming" JS? thread started by Scott and see what I can get out of it. I had already thought doing that but feared that the lag would ruin the gameplay. Well, after all, when I started raycasting I feared it would be to slow

RoberG: I like the dynamic lighting of your weapon

Scott: I care. But I'll try to make my own network component before using someone's one.

Mathieu "POÏ" HENRI

That's basically what I did in my implementation, using an endless loop in PHP that checks for incoming data (sent from clients to the broadcast server which this PHP script is connected to), while the connection is still open.

In the event where data is received, the PHP script forwards the data on to the client. (The client connects to the broadcast server via the PHP script.) I used a short timeout on the fread()/fget()/fgets(), whatever it was. (Can't remember.) This way, there wasn't too much "lag" in communication between clients.

POI: I should mention also, no offense taken there - I understand completely and support "roll your own", I think it was you who suggested the iFrame thing to me in the beginning when I was posted the "streaming JS?" thread, so I kept that in mind when tinkering. By all means write your own! Let me know if you find anything cool though that I might be able to benefit from in my own implementation
I think everyone benefits from sharing notes etc. on what they've found on stuff like this, as it's not a common undertaking.

I have some notes in the JS library I wrote also, just things I found etc. while experimenting with the communication aspect of things. Comments are in the code. http://www.schillmania.com/script/rpc-js.js

[This message has been edited by Scott (edited 10-22-2003).]

Poi, all the lighting in the engine is dynamic, I can have all of the light sources moving around, flashing off and on, changing color, (check out http://www.elephantsneverforget.co.uk/dm/dm2.html lights fade in and out from red to white, sort of a "red alert" effect) etc.. I don't think the way I'm doing it is very good, it's not very elegant and a bit hackish, but it looks pretty cool and is alot faster than texture mapping everything..

The only problem is light can go through walls I hacked together a simple collision detection routine for it, but it slows things down too much and doesn't really look very good (it would look nice if it was casting shadows on floors though, but that would be pretty slow).

[This message has been edited by RobertG (edited 10-22-2003).]

[This message has been edited by RobertG (edited 10-22-2003).]

Nicely done! You guys write some real funky code, makes me stand back sometimes and admire the strange talents we javascript fans sometimes take for granted I look forward to seeing the finished work.

[This message has been edited by Scott (edited 10-23-2003).]

RobertG: You know, Quake 3 doesn't handle back lighting for the dynamic lights. Ok it's not the same scale of project and means but it prooves that it's not an evident task. And back lighting turns out to be a gameplay (dis)advantage in the end cause it can help to locate the enemies

Mathieu "POÏ" HENRI