JoWie

This might be a relevant read: http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

Client-side and network-level game-rule cheating is preventable (as far as i know, twister was mostly this kind of hack). Fully preventing this comes might come at a cost though (network/input latency, complexity). A lot of first person shooters protect against this. This leaves client-side augmentation (aimbots), server-side hacking and social cheating (players colluding, multiple clients, et cetera).

i'm on some waiting list. I want to use it to simulate bad networks. I'm getting sick of using 3 laptops. I also looked at CuBox which has 4 times the ram, but it also has a long waiting list.

Yea seems like the jquery animations are causing some slow downs (try "jQuery.fx.off = true" in the console) Have you tried using bla(); function bla() { try { // ... } finally { setTimeout(bla, 25); } } instead of setInterval? Canvas would probably speed things up too

although, there's a huge shortage of computer programmers over here haha.

This behavior does not happen if you install continuum to your "Documents" folder for example. Microsoft wants to force developers to use the Application Data folder instead of Program Files. The VirtualStore is a compatibility workaround for old applications.

WinKey + R -> %LOCALAPPDATA%\VirtualStore\Program Files (x86)\Continuum or WinKey + R -> %LOCALAPPDATA%\VirtualStore\Program Files\Continuum

How did you get the idea it was intended as a completely new game? have you looked a the the thread title? At the moment its alpha software, those are things you should not worry about for a long time.

Could someone split all the crap?

That is just idiotically pedantic

Isn't that the zone where you get yelled at for having new ideas?

I am not saying it should, it was merely an example. Although there are gamepads, joysticks, etc for tablets and phones. I could imagine that tablets would be used a lot more for this purpose in a few years. Or perhaps there could be zones in which the gameplay is so different keyboard vs touch screen would not matter. Anyways it will not work on half of your list without additional effort. (I am not sure why .NET is on that list)

Note that it uses a library (lwjgl) which uses native interfaces (written in C). A platform has to be supported by this library. So it will not work on phones and such without a good amount of effort.

again: it is possible to workaround this without needing access to the subgame binary

if grass is green, does it make a sound?

Perhaps you could use potential fields: http://aigamedev.com/open/tutorials/potential-fields/

Networking got sorted out. We played together with around 16-20 players and it worked fantastically. Of course, this was like last year. =P Yea I have played it with networking too. But weren't you talking about lag issues? And how does it stand against cheats?

Ah, I thought that API was only available to AIR. Subspace does things such as acknowledgment, retransmission, etc manually. This is disabled for a few packets (balls, turf, position without weapon, green sharing, points). For such packets, the latency would at a minimum double over TCP. For other packets the minimum latency would be the same. I think that doubling the latency for such packet would not matter a whole lot. The biggest issue is that when packetloss occurs, all other packets have to wait. This is because TCP maintains the proper order. You can workaround this by opening multiple TCP sockets and alternating between them. (the default connection limit for firefox is 200). Same amount of data, just more sockets.

I think UDP only works in flash when you are inside an AIR application. It is possible to interact with a signed java applet (user gets a big security warning) to do UDP, but that would defeat the purpose of the experiment (just run jabjabjab's client in an applet). You don't absolutely need UDP though. It is probably possible to achieve the same latency (at the cost of more bandwidth) with TCP socket(s). Which is of course one of the things I want to find out.

Yes, node.js is what I would want to use. The performance is indeed amazing. Apache and php are so slow under heavy load. Some people are even using node.js as a loadbalancer. Its more a proof of concept kind of thing. To show that its possible to write such real time games (and not another silly text rpg) in a browser. And with proof of concept I mean, try to resolve all issues. But do not build a full game (or at least, initially). I have not yet completely decided I am going to do this however. The hackability/modability for zones would be so tremendous. Its like every zone would send its own continuum version to you. Note that it would still be possible to have a stand alone application (~17MB) Here's the C&C browser game I was talking about:

Haha, we had an intern that actually still used . But yea thats is not the kind of javascript I am talking about. Oh btw, the next (official) Command & Conquer is going to be in javascript

I have a lot of experience in a lot of languages and javascript is one of my favorites. I prefer it over Java (depending on the type of project of course). What most people hate about javascript is not actually because of javascript. Its the horrible browser API (mostly in old browsers) and crappy tutorials. I usually only write javascript for web servers and very recent not-IE browsers. My only real annoyance about javascript is the lack of 64 bit integers. I use javascript servers (node.js) which is absolutely great for web applications (share code with the browser, event loop instead of forks or threads, DOM instead of a stupid print(), nothing blocks: everything is event driven, etc) Debugging is incredibly easy. And more powerful than most debuggers I have come across. You can do things such as temporarily overriding a function on 1 object, or all objects of the same type.

Kaas!, Do some googling first for fuck sake. You don't get to use sockets. Only way to use real sockets in this context is to use a signed java applet. WebSocket is a protocol on top of HTTP. It starts of by doing a proper HTTP 1.1 request (Upgrade: websocket). The server needs to reply with a HTTP response (which includes a hash of a key the client supplied previously to show it supports the protocol). After this, both client and server may send data when they feel like it. The payload data (the stuff you send from the browser/server API) is contained in a websocket frame with some header information. The payload data is even XOR'd with a randomized masking key to prevent poisoning of intermediate proxy servers.

I was asked not to share the link, but maybe the author will reply (doubt it since I have not seen him for like a year). The issue is not being able to open a connection (I have a working WebSocket version 8 server (not subspace) ). The issues include things such as: Its TCP, not UDP. This means you will have problems with syncing clocks, nagle's algorithm, packetloss delaying any subsequent packets, et cetera The client can not be trusted in any way. The protocol will have to be set up a lot different than what continuum uses. But at the same time with low latency and low input lag. A lot of data must be moved away from the client, such as cloaked players Players can modify the client to aid with things such as aiming Things are very easy to automate, you will need a way to prevent bots for RPG-style zones. The impact of rogue zones must be limited in some way I know how to fully or partially solve these points, but I do not have time to spend on this until February (not the same project as previously mentioned).

Yes, but if the sky is blue, does this post exist?