JoWie

I assumed the zones were using this protocol (I have very little experience with subgame). Snrrrrrrrrrrrrrrrrrrub reverse engineered the peer protocol, it lets you list all players in the zone broadcast arena messages (like *zone) retreive the total player count, this count would report the actual numbers of players present on that server SubSpace Peer Protocol Author: Sharvil Nanavati sharvil.nanavati@gmail.com The information contained in this document is based entirely off of my own reverse-engineering efforts. SubSpace game servers can communicate with each other via the SubSpace Peer protocol. Unlike most other protocols in SubSpace, the peer protocol does not make use of the SubSpace Control Protocol. Rather, it uses lightweight datagrams and accepts packets based on a whitelist of the datagram source's (IP, port) pair. All packets have the following form: 00 01 <passwordHash (4)> FF <type (1)> <timestamp (4)> <payload> The passwordHash is a CRC32 of the password in server.ini. The payload depends on the type field and their formats are described below (type values shown in blue). Peer-to-Peer Protocol ------------------------------------------------------------------------ /01: Player List/ This packet is sent if SendPlayerList=1 and at least one player is in the zone. It lists all arenas in the zone with a list of all players in each arena. The list of players for a given arena is null terminated as indicated by the 00 field below. The arenaID field is a random 32-bit integer that is associated with each arena at the time of its creation. An arena maintains its arenaID until the arena gets re-created or manually recycled. { <arenaID (4)> <arenaName (asciiZ)> { <playerName (asciiZ)> } 00 } (repeated until end of packet) ------------------------------------------------------------------------ /02: Chat Message/ When a peer receives this packet, it broadcasts it as if it were a zone-wide message (*zone). <type:0 (1)> - currently ignored by subgame, can be anything <message (asciiZ)> ------------------------------------------------------------------------ /03: Unknown/Unused/ The format of this packet is known but not the format of the message. Perhaps the action associated with this packet is disabled in the current release of subgame. <unused (1)> <message (asciiZ)> ------------------------------------------------------------------------ /04: Player Count/ This packet is sent if SendPlayerList=0 or there are no players in the zone. The player count is the total number of players in the zone. <playerCount (2)> ------------------------------------------------------------------------ He also made an asss module

There are workarounds for the missing feature that would not require modifying subgame. For example, you could write a directory client that uses the peer protocol to figure out the proper population.

With a little effort the issue could be fixed

Because he knows how to ask for help?

He's using a different client-server model than what continuum uses. So its a bit more complicated than that.

Basically, deamonize on linux means that when you run the application from the console it gives you back control after any initialization (detach). This way you can easily add it to initialization scripts (such as init.d) which are always detached. Most applications that can deamonize also let you write PID files, but this is not required (this can be provided by a wrapper). This is what you usually use in initialization scripts. Read the note next to --background http://manpages.ubuntu.com/manpages/intrepid/man8/start-stop-daemon.8.html Incase your server is written in java, I think there is a tool for it, not sure.

make sure the server is able to daemonize

when my free time returns

Or just use 1 of the 100 java thread safe collections?

Sometimes you have to make a trade off between security and lag. It would not be that hard to support a huge number of tile/object/part types efficiently (billions). I think richard already completed this http://www.subspace.co/topic/26030-map-editor/

The random seeding continuum does, is a lot more interesting than encryption imo.

Are you talking about the random stars and planets in the background? You would probably need a random number generator with low-discrepancy (quasi-random). Preferably you would want one that does not require you to keep a state, only a seed and an index. Like halton, van der Corput, etc. This way you do not have to store stars for the entire map

And jitter when you hit a wall

That's because the ship was already overlapping with the wall, inverting the velocity without moving the position to touch the wall would yield a collision each loop, making the velocity vector oscillate and thus getting stuck in the wall. You have to account for the difference between touching the wall and the amount of overlap, say delta x (dx) then invert the velocity of x, then add that dx * velocity x to the current position. That would give the correct position of the ship I showed this, but it had a typo: http://www.subspace.co/topic/25999-subspace-java-client/page__view__findpost__p__278325

Collision in subspace is not that hard, everything is a rectangle. This is a basic way you can do bouncing bullets. Java syntax with imaginary classes and instances It uses centisecond precision, just like subspace (100x per second) // Part of some kind of update loop import javax.vecmath.Tuple2d; public class Weapon { public static final long TILE_SIZE = 16; public int type; // enum public Map map; public Tuple2d position; public Tuple2d velocity; public Centiseconds lastUpdate; public Weapon(Map map) { this.map = map; position = new Tuple2d(0,0); velocity = new Tuple2d(0,0); } public void update(Centisecond now) { Centiseconds deltaTime; int a; if (!lastUpdate) { lastUpdate = now; return; } deltaTime = now - lastUpdate; if (type == Weapon.BULLET) { for (a = deltaTime.intValue(); a > 0; --a) { moveVertical(); moveHorizontal(); } lastUpdate = now; } } // returns true if it hit a tile private boolean moveVertical() { Tile tile; double newY; Tuple2d newPosition; long tileX, tileY; position.y += velocity.y; tileX = (long) position.x / TILE_SIZE; // get rid of the point number (not the same as floor() ) tileY = (long) position.y / TILE_SIZE; tile = map.getTile(tileX, tileY); if (tile && tile.isSolid()) // hit a wall { // move the bullet so that it is right in front of the tile, but not ON the tile if (velocity.y > 0) { // moving towards the east position.y = tileY * TILE_SIZE - 1; // position is now at the end of the previous tile } else { // moving towards the west position.y = (tileY + 1) * TILE_SIZE; // position is now at the start of the next tile } // bounce velocity.y = -velocity.y; return true; } return false; } // returns true if it hit a tile private boolean moveHorizontal() { Tile tile; double newX; Tuple2d newPosition; long tileX, tileY; position.x += velocity.x; tileX = (long) position.x / TILE_SIZE; tileY = (long) position.y / TILE_SIZE; tile = map.getTile(tileX, tileY); if (tile && tile.isSolid()) { if (velocity.x > 0) { position.x = tileX * TILE_SIZE - 1; } else { position.x = (tileX + 1) * TILE_SIZE; } velocity.x = -velocity.x; return true; } return false; } }

why the separation between map/tileset and lvz?

LinkedList seems both easier and faster in this case. All you are doing is adding to the head and removing from the tail. No need to move all the array elements or to allocate new arrays.

I've used lwjgl for 2D stuff and it is not incredibly hard. Anyhow, the big thing to avoid in java is massive object creation in hot spots.

to respawn destroyed tiles, everyone needs to reenter the arena. All you can do is some hackery with bricks

Wouldn't the correct name be "GS-2 Godsend Beacon"? The Ion Cannon is a network of satellites

!shutdown was added because bots keep reconnecting and the zone gets spammed with ^banned entering and leaving.

I have only read the first part, but that is pretty much how I envisioned it

If I look at the thin client approach I see bunch of annoyances for players: In normal operation, you press a button, the effect takes a short while (< 200ms). (note that most computers already have an input lag of around 100ms for 3D games) Player has a lot of lag (he is downloading, has crappy wifi, etc): input lag is worsened, the state you see of other players is greatly delayed. I think in this point is important for the player to realize it is his own fault (like making ships blink or by speccing him) The server is struggling with computational / database stuff. The input lag becomes very high (this is what you usually observe in eve). I think this would not be an issue in stock servers, but could become apparent in very complex rpg like zones. Smart coding like asynchronous handling of triggers based on weapons, movements, etc would go a long way to prevent this. Server is struggling with the upstream bandwith: Everyone starts to experience high lag. I hope this would only be an issue for large zones, which hopefully know how to mitigate this (which would not be very hard) While the effects of 1 are minor, I think it is the most important point to focus on. The other points are easy to deal with. Perhaps a hybrid approach is key. Let the client deal with its own ship movement within limits imposed by the server (perhaps based upon how far a player could get within 250ms). Firing a weapon takes effect, but the server may reject it or move it slightly (the client could use pretty interpolation to fix it, like continuum does for enemy ships). In normal operation the player would not notice any input lag on the most important facets. About SSC, I think servers forming community groups is not an issue. I just think everyone should have the same opportunity to run a zone without people fearing things like password stealing. This is also why I think such a password service should not include banning (unless it would involve something like bots massively registering names)

I would have not expected that from you, with all those server side damage tracking AI bots you are using. ( ). Anyways, I do not think cpu or memory usage will be the issue. Serving this forum is probably more resource intensive than that (yay php). A common cheap vps could run it. Networking is the only big issue. Just to avoid confusion: I am not suggesting video streaming. Just something along the lines of the server telling the client "download this map file and these images", "draw a ship at x,y", "draw a weapon at x,y", "draw an explosion at x,y". There are a lot of optimizations you can do, mainly by only sending what is changed and by letting the client guess what happens next (just like what continuum does with position packets which are only sent 5 times per second by default). In such a scheme the lag has interesting characteristics like I quickly wrote down in the first post: A weapon will almost never hit on one screen and miss on another ("eating" / relative player lag) Input lag. It will take like 50-200ms for your ship to respond after you press a key. But, if this latency is stable, you will quickly get used to it. Instable lag is what you must be careful with (which is caused by crappy routers and crappy ISPs, google bufferbloat) While the bandwith usage is higher, it scales differently. You do not have to send what you don't see. If you are in an arena (as a client) with 100 players you could have the same bandwith as in an arena with only 10 players (continuum already has this characteristic somewhat, but to a lesser extent). I think you need to do a lot of tests to see if thin clients are viable. If I do a quick rudementary calculation with 20 players, 200 weapons, 11 bytes per packet, on screen, 10 frames from the network per second (unoptimized), you would be looking at like 24 KiB/s per client. Which means the server would be at 473 KiB/s upstream, about 1100 GiB of data per month if these players would play like that 24/7/30. 5000 GiB of monthly data costs you 15 euro on leaseweb. It is true people on low end connections will have issues running a zone publically. But I have never actually played in one on continuum. If the game would become sufficiently popular you would get constant cheating. I remember playing americas army years ago where you would have a patch almost every 3 days just to combat cheaters. Most of those solutions would be security through obscurity. Especially players that cheat carefully will be hard to track down. There are pre packaged cheats which affect common random number generators. For example you could cause random bullet damage to do 50% less damage on average. I like what bak- is doing by using peer to peer cheat detection, but I am not confident it will be enough. It would also affect decisions to go open source.

In subspace the server could be seen as a specialized relay. You fire a weapon, you send to the server "I fired a lvl 2 bomb at 12302,852", the server relays this to all players that should know about it. After this no further data about the weapon is sent. (the server can not remove it for example). Stuff like energy is all client side. With some effort you could crack continuum so that you have no weapon delay, can not die, infinite specials, et cetera. Continuum makes it hard to do this by using obscurity techniques (like making sure important variables never have the same memory address, or by sending a hash of the map file to the server periodically, et cetera) Currently there are 3 types of servers: zone, billing and directory directory provides the zone list and is completely open billing keeps your passwords, scores and provides cross zone chatting. A billing server may connect to another billing server. zone is the zone itself and connects to one billing server and multiple directory servers. billing servers are private and a billing operator has to allow your zone before you can connect to it. If you connect to a non ssc zone, your password is sent in cleartext to the server (and you get a big warning message). If you connect to a SSC zone continuum encrypts your password and only the ssc billing server knows how to decrypt it. Of course any SSC zone could simply send "?password bla" on your behalf, which would result in your account being compromised. If a player connects to a zone he has to trust both the zone and the billing server. I do not know what that networking library looks like. Does it let you define what the raw communication looks like or does it also serialize things for you? If you want to later support a different platform and the network library does not let you standardize the communication, you would have to add multiple libraries to the server (which is not that big of a deal). Most subspace arena's only have about 40 players max. This makes it very easy to out-scale things. If you have a popular zone with 500 players you could just run 5 server, and the players just transparently move between them depending on their arena (subspace supports this, but it is rarely used nowadays). Perhaps it would be a good idea to build a simulator for those calculations to see what the resource usage is like.