As many of you know, I've been working on a Star Trek game for some time. This project is not dead, just sluggish because of RL obligations.

I am starting to think about what features can be client-side, and what must be server-side, on the hub. Here are some of my ideas:

1. Have the hub itself hold ALL the data about the players on the game...their names, their positions, etc. If I can create databases with this info and have the hub handle searching for the data, then I can do something much easier with regard to sending data (see #2).

2. Instead of having the calculator have all the data for all the players on the server, which would consume a lot of memory, I can have the data on the hub, and then when you need some of the information, the hub would respond only with relevant data. For example, if you are doing a "position update" on other ships (redrawing them at their new locations), we can send a request for new positions to the hub. Now, let's assume the maximum view range of your ship is 100. The hub would only send you back the positions of players within 100x100x100, not the guys on the other side of the galaxy.

2a. The hub itself would do the cycling, not the calculators. Once a weapon is fired, the calculators never again see that. The server adds it as an entity, and handles changing its position on correct timing, and sending data on it to the calculators. Thus the server is doing all the work and all the clients are doing is rendering it.

3. Instead of having separate routines for drawing ships and drawing phasers and photons, I can actually make them all "objects" and store their position, direction, and speed data on the hub in the same fashion. That way, I can draw them all with the same routine. This would also allow for this: if you fire at a ship and you miss, the projectile keeps going until it either goes out of range or hits someone else, without any extra code, beyond a collision detection.

4. A star base will be a server-created entity that is capable of self defense. It will belong to a team (assuming I can make team play possible). Players on that team can enter the base, refuel, repair, and equip it with weapons. Players on the opposing team can attack it, and it will defend with whatever it is equipped with.

5. When the first player joins the hub, the server will create a world and generate terrain. Terrain can include basic space, stars, nebulas, and wormholes. I hope to include planets at some point, but star bases will be the only defendable thing in v1. Basic space does nothing and is the majority of the map. Stars can damage your ship if you go too close, and have gravity (not sure how I'm implementing or using gravity). Wormholes also have gravity, but more. Nebulas are there mainly for a tactical use...they disable shields, sensors, and communication. To minimize load on CALCnet and on the calculators, when you join the world, you will only be send terrain data for the area near you. As you near the edge of that, you will exchange your terrain data with new terrain data.


Here are, as I see it, the pros and cons.

Pros

• Less demand on CALCnet itself and on the client calculator.
• Able to do more, and have more realistic combat, with less coding.

Cons

• We are relying more on the hub for data than on the individual units. Thus, if the hub can't keep up, then we have a problem.
• I will need to write routines for REQUESTING data from the hub, which I wouldn't have to do otherwise.

So here is my questions:

1. Do the pro's outweight the cons? Should I adopt this new strategy?

2. Anyone willing to help out at all? I don't have all the time in the world to make this lol?

Sounds cool. I believe that the pros largely outweigh the cons.

So, like how do you want to do it: there are two main differences with how to do gCn stuff: I could either write a custom metahub or i could use cemetechs metahub (allowing to omit the server option), and have the server act as a calculator client with more features, so it'll have a specific id to which you'd have to send direct frame messages.
I'd be planning to do this in python2.7 btw.
So, what should i do? (your call)

why dont u shoot me a PM. we can talk there.

Well it'd be cool if you talked about it in public cause I am interested in this discussion.

The stuff we're PM'ing about is about technical information. I'll disclose it once we have a plan lol

Me and Sorunome are starting with the basics... initialization of the map and database, ability to select a world, open a new one, etc. When the very first player joins, the first world gets opened. The server admin can create and delete worlds. ClrHome will likely host this (http://clrhome.org), so we will have that power.

I am also working on list of packets that clients can send the hub... such as
CreateObject, with Object type (ship, phaser, photon, base, etc), object size, object velocity, object direction all in the packet that the server would handle.
DeleteObject (im in a bit of a pickle as to how to adequately delete the correct object )
GiveMap, the server will respond with the area near you. If you can see a radius of 200, then you get 200 x 200 x 200.
and so on.

Send Deep Thought a PM. He handles the server privileges (I think).
And we aren't down **that** often. lol. But we are toying with the idea of a paid VPS. So that may change.

Sounds pretty cool !