JoWie

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?

The graphics have been done in html5 before (and it performed well), the issue was/is getting the networking right

Naah, C, M, Y, K

I did not really rewrite it, just fixed a bunch of bugs and added support for things like double barrel, asss 1.5. Mostly stuff I needed for my own project.

but not that v

I do not think it is a 3 line change, or else it would break the functionality of hosting a zone on multiple servers (you would only want a single directory listing). I have heard trenchwars had used this in more glorious days (but do not quote me on this).