pyxlz

Thanks, and while you're here, do you have any specifics on door synchronization?

Send "?arena" to the server. That makes the server reply with the arena listing packet (0x2F)? I thought it was just a continuum command.

I would guess this has something to do with the way I linked the project? I really don't know though, if anyone else has an idea, please let me know.

That's a pretty loaded question(s) . I'll try to take them in order... I can write any additional features into the game that are not server dependent. For example, I could make all ships displayed as 3-d models instead of sprites. So yes, it would be possible to write a graphical feature that shows the population of each arena on screen (I think, I actually couldn't figure out how to request the arena listing, so if anyone knows how, that would help me out). A four way firing ship I don't believe is possible under the current protocol because of the way direction is !@#$%^&*ociated with the ship and bullets. You could fake this however. New weapons in general: !@#$%^&*uming the new weapon could be disguised in a current weapon packet, or the server forwards 'unknown' weapon packets, then yes. Although, the new weapon would only work between my client, and not with Continuum. Can I write everything needed to be completely free of the existing subgame: I'm not exactly sure what you mean by this. Subspace is already free of the existing subgame with ASSS. If you mean extend the protocol, or rewrite it, then sure, as long as the server supports it.

Heh, that radar is really a placeholder, I just re-rendered the map on a smaller scale and put a dot in the middle. None of the code is ripped, that would defeat the original purpose of creating the client. With that said, the physics is based on some of the do-*BAD WORD*-entation I found along with observations. The velocity of all objects is known in pixels/sec and have no acceleration, so you can calculate how much time has elapsed, p = p0 + v*t. Since this is a linear system, it can be fairly accurately estimated by Euler integration. E.g., moving at 3 pixel/sec * 6 seconds (18 pixels) is the same as [3 pixel/sec * 2 seconds (6 pixels) + 3 pixel/sec * 4 seconds (12 pixels)] (18 pixels). This works for all players over the network because you only receive position/velocity info. Acceleration on the other hand, doesn't work as well with the same method, and in fact I'm doing it wrong. Currently it's based on the speed of input, but this is not time-independent. So, if your frame rate drops, you'll accelerate slower. I thought this was a standard windows file? If not, I have no idea, sorry.

Thank you both. It is written in c++ with opengl and directx, no .NET

I wanted to thank the Subspace community both for explicity answering my development questions, and in general for keeping this game active. With that, I thought I'd share what I've been working on. A while ago, I was looking for a personal project to dabble in game development (something beyond tetris). I was really more interested creating the architecture for the game rather than designing the playable elements. And so, having previously played subspace, it seemed like a pretty good pick to do development in: lots of existing game content, simple gameplay, multiplayer (network) elements, and overall, easy enough to take on alone. After some on and off work(/play) over the past few months, it's finally something recognizable. Keep in mind that this is a work in progress and it's still mostly incomplete. As such, there are a lot of placeholders and things that just plain don't work. I'll continue to work on this project as long as it remains fun for me. Anyway, here's my own subspace client (attached). Extract into your continuum directory and enjoy. subspace_test_1.zip

I have noticed this too. I've come to the conclusion that you can only start with brick if InitialBrick > 0 (lanc = 255). Since you are using his test zone, why not go all the way and use his code too? The relevant stuff can be found in clientset.c. The specifics of how prizes are granted is handled client-side, not in the server. As for your observations regarding bricks, this is a direct consequence of how the programmers decided to implement prizes. First thing to know is that your ship's initial bounty is treated like a multiprize. Specifically, what ever your InitialBounty setting is, the client grants you a Multiprize with that many prizes when your ship spawns. (The actual Multiprize is controlled via a different setting). Second thing to know is that the VIE client multiprize code doesn't allow certain prizes to be received when picking up a multprize. The prizes not allowed in the VIE multiprize are: engine shutdown, shields, super, another multiprize, warp, and bricks. Hence, no matter what your initial bounty or what your brick PrizeWeight is, you'll never be granted a brick when you spawn. You must either pick it up manually or be awarded it via *prize. The reasons most of those prizes are excluded from the multiprize is pretty obvious, such as not allowing cascading multiprizes. As for the bricks, my suspicion is that bricks were just too valuable/powerful a tool to be allowed to occur in multiprizes, so they excluded those as well. Ok, so multiprizes are weighted the same as regular prizes, except for the aforementioned items, which are weighted at zero?

What code are you referring to? Prize generation?

Specifics would be very useful if you have them.

As far as prize weights being proportional vs. inversly proportional, is that well established? I was basing it off some !@#$%^&*umptions with the actual prize weightings in the zone. In grelminar's test zone, the weight for brick is 200, whereas the weight for thrusters and top speed is 25. Most of the weights are in the 10-40 range with multiprize at 130 and brick at 200. I !@#$%^&*umed that since you rarely start with a brick (at 500 bounty), it has a much lower probability of occuring than anything else, thus the higher prize weight = lower probability. Unless, perhaps, there is some built in probability !@#$%^&*ociated with an prize type, or if an initial bounty of X is not equivalent to receiving X greens.

Ok, any ideas on how to make the table? The way you say it sounds very similar to the already existing implementation in MERVBot, which is incorrect since the prize weight should be inversly proportional to the probability of a prize occuring (higher prize weight = lower probability of occuring). I tried inverting the weights simply by (prizeWeightTotal / weight) for every weight. For example, a 3 prize system with weights [10, 20, 200] would have corresponding probabilities [64.5%, 32.3%, 3.23%] ([23, 11.5, 1.15]/35.65). But this method doesn't seem to work out quite right either. So the question still remains: how do prize weights correspond to the chance of receiving that prize? Is it possible that a different prize system is used for giving starting bounties?

Independent of the prize synchronization though, is there a known working algorithm for generating prize types based on the weightings in the arena settings?

Can someone verify the correctness of the prize generation code found in MERVBot or provide other known working algorithms? The code I've been referred to was in the backup directory of the MERVBot source, in prize.cpp // Fill prize type p->type = 0; current = 0; stop = prng.getNextG() % prizeWeightTotal; BYTE *pw = (BYTE*)&prizeWeights; for (int i = 0; i < 28; ++i) { if (current < stop) break; current += (*pw++); ++p->type; } Right off the bat, (current < stop) is true, so the loop will never run, making the prize type always 0. !@#$%^&*uming the if statement should have (current >= stop), the type will still be calculated incorrectly. In this case, a larger prize weight value would result in a higher probability of occuring, but a larger prize weight value should actually result in a lower probability of occuring.

I tried over 100,000 keys, and it seems to work fine.

According to the do-*BAD WORD*-entation and code I'ves looked at (Mostly MERVbot and !@#$%^&*ociated docs), a powerball packet involves position, velocity, and timestamp. However, even for a stopped ball, the packet contains non-zero data for velocity. This velocity appears to be in the direction of movement prior to stopping. So I am !@#$%^&*uming that the stopped powerball position is based on the coefficient of friction for the ball (does anyone know what this value is?) and !@#$%^&*umes the position based on the timestamp. Basically what I'm asking is: 1. What's the coefficient of friction for the ball (or is it a setting somewhere)? 2. What is the meaning of the timestamp in the powerball packet, or more specifically, how is position calculated from velocity and the timestamp? My guess for #2 is P(t) = P + V * deltaT, where deltaT is the difference between the current estimated server timestamp and the timestamp on the powerball packet.

You might want to take a look at one dimensional Kalman filtering and Markov estimation/localization for error estimation models.

Perhaps you can point me in the right direction on this? The only implementation I of door and prizes that I found deals with seed synchronization. There doesn't seem to be anything regarding actually generating greens or turning on and off doors.

Do you have any suggestions for how it could be done better?

Is there any do-*BAD WORD*-entation out there on prize and door synchronization? From what I've read, the random number generator seeds are used somehow to generate data related to the prizes and doors, but nothing more specific than that. For example, is the prize seed used to generate (x,y) pairs for all available greens, generate prize types (recharge, turn, multifire, etc..)? Are all previously generated prizes cleared after receiving a new seed? Is the door seed used to generate a time on/off for all random-timed doors? Any information would be much appreciated.

Are you sure that it uses bounding sphere as opposed to bounding box collision? It's actually not really crucial which method is used. I suppose my initial question was poorly phrased. Do you think that, however the collision detection is being checked, it is checked every frame? I would guess/hope that there is better data organization, which would allow for a much more scalable system and a general performance boost (then again, maybe that's why there were relatively small arena limits in the original subspace?) The question then is, what kind of data organization/structure does continuum use for managing collidable objects?

Does anyone know how collision detection detection in Continuum was implemented, specifically in regards to object-map collisions (like bullet-wall), but also object-bject (bullet-player)? Perhaps a better question is what are everyones' thoughts as to how collision detection should be implemented? Quad-tree, sparse-matrix, full-matrix w/ time steps, line drawing, anything else?