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. Thus, my questions:

1. How exactly does one write a CALCnet hub? What scripting language? PHP? Can they be hosted on an independent server or are they kept here? What exactly has to be in it?

2. I was thinking about this, for my Star Trek game. Making all "objects" entities. Each ship is an entity. Each time you fire, the phaser bolt or photon becomes an entity until it is destroyed by moving out of range or hitting something. Entities are stored in a database on the server. That way, I can use the same routine for updating the positions of other players for updating the positions of all other entities in the same manner.

3. In relation to #2, when your calculator requests an entity position update, the server can respond with only data relevant to you. For example, if there are 20 players on the server, but only five are near you and the rest so far away you can't see them, why do you need any sort of data on them? Is there a way to control what data the hub sends out?

4. I can also do the same thing with map information, can't I? Give you only a portion, and as you need more, send more? That may be harder to support, client-side, but i assume its possible.


Also, as an aside, i had an idea for hubs. To allow hubs hosted on other servers, create something like a DNS lookup table on Cemetech. The gCn client connects to Cemetech and uses the table to find the hub, whether it's on Cemetech or on another site.

If you need to write a hub, Kerm has written a very handy python skeleton which can be found here. This is written in python so you will need some python knowledge.

Thanks!! Then I'd best be learning Python. Is Python a necessity? Can it be written in another language though?

1. Calcnet just defines a protocol, so long as the language you're using has the required functionality (networking, mainly) you can write it in that language. I've done it in C#.

3. You have full control over what your server sends--why wouldn't you? You're the one writing it.

4. See above.

Ok Thanks.

Lastly, what do people think of my "entities" idea with regard to fired shots? That is presented as an alternative to a PTP transmission.

Update on Progress

I am working with Sorunome on the project. He knows Python and has agreed to work on the server-side scripting of the hub, and I will be coding the calculator side of the game.

We have agreed that, to take load off CALCnet and off the individual calculators, most of the position updating of objects and the incrementing of counters, and storing of data should take place on the server. The calculators will handle rendering graphics, collision detection, damage calculation, and everything a player can do on their ship. Calculators can also send requests for data to the server. Here some of the planned features of the game:

A full login system, powered by MySQL on the server-side. The user logs in on their calculator and a Cn2 frame carrying that information gets send to the server, which verifies it. If the user doesn't exist, the player gets the option to register. If the user exists, but the password is wrong, the user gets told their login was invalid. If everything is ok, we log in. Now...instead of holding save data on the calculators, once the player quits (disconnects from the server), the calculator forwards the save data to the server, which saves it for that player's account. Once they log in again, that data gets downloaded again. New users get a blank save file, which populates when they disconnect. Users will also have the ability to change username or password from on their calculators.

After logging in, the player can select a world to play on. The server will have pre-generated worlds, which can be deleted or created by the administrators of the server.

Every single thing on the map is an object. The merits of this...same database for everything. Even terrain is an object, of type terrain, subtype whatever it is. Terrain objects carry center point data and radius data. As an FYI, the map has 65,536 sectors on each axis (x,y, and z). Each sector is 65,536 on each axis. Thus, the total playable area of this game is (65,536^2)^3.

Photons and phasers are also objects. They have a position on the x,y,and z, provided by the routine that sends the data to the server when the player fires. That routine also will calculate its directional data (how much on each axis it should move per cycle) and speed (multiply directional data for each axis by speed to get how far object moves).

I'll update as more becomes known. This is what the ideas are so far. Comments?


Edit

Are there any 8x8 and 16x16 icon generators. More 16x16. I have Sir Crpwn's sprite edition and Kerm's DCS icon generator for 8x8. I think TileIt only does 8x8 too.[/b]

The program icon, in DCS7:




The game's splash screen:

Hopefully you're simultaneously computing the positions on all the calculators independently and working on some kind of efficient sync protocol. The following article should be very helpful, as it addresses issues you'll be running into:

http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php

calculators will in fact compute their own location independently, and then send their new position every so often to the server, so that the other units may see it the next time they request data from the server.

I'm suggesting that units compute both their own new positions and all the peers' new positions, and that positions merely be synced via some hash over all the positions; only if there's a hash failure will the positions need to be verbosely propagated.

Well, my whole MO was to avoid relying on the calculators for calculations. A server could do the math quicker. But I'll defer to whatever you think is best.

Secondly, I had an idea on my way home today that I wanted to run by you. Having an in-game option to adjust refresh rate (how often we're asking the server for data). If the player notices that the game is lagging, then we are waiting too long to get new data, they can adjust that up to get data more frequently. If they notice they are not lagging at all, but the calculator is not responding to key presses (which may indicate we're going to the interrupt too often), they can set that down to get new data less frequently. That way, each user can have a setting that works best for their hardware. The refresh rate would be inversely linear to the frequency of us retrieving new data. A higher number means a more frequent, a lower means less frequent.

Secondly, doing this would enable me to implement a safety feature... if the server is becoming bogged with requests (i'll have some sort of variable keep track of ins and outs and monitor whether we are getting a backlog), then the server can send out a broadcast transmission, signaling all units to lower their refresh rate by 1. Of course, normal 83+'s would ignore this, because they are probably running slow enough already. But the faster units would comply, thus reducing server load.

Comments? I know there is a way to determine if the calculator is an 83+ Basic or otherwise, using port ($02). Is there a way to determine is the unit is an 84+ ?

Bump, and new idea:

automatic program update.

The calc side program contains a version string:


Code:


Every time the program sets CALCnet up, we request the latest version string from the server. If the server replies with a version string that is greater than the one we have locally, the user is presented with an option to have the server automatically send them the new update. The client program creates and hands over execution to a temporary program which removes the old version, gets the new version, then returns to the beginning of the now updated game