Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: ACagliano on September 26, 2013, 07:08:13 pm
-
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 interesting, I think i would go with loading data off the hub to allow the prog on-calc be smaller.
And I could maybe help with server-side coding of the gCn part :)
-
Sounds cool. I believe that the pros largely outweigh the cons. ;)
-
Sounds interesting, I think i would go with loading data off the hub to allow the prog on-calc be smaller.
And I could maybe help with server-side coding of the gCn part :)
Ok. This is the new method I'm gonna go with then. And, Soronome, I'd be glad to have some help with. The only real server scripting language I know is PHP, and not extremely well.
-
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.
-
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. ;)
-
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. ;)
We decided on a custom metahub.
ACagliano is writing up a protocol atm.
-
The stuff we're PM'ing about is about technical information. I'll disclose it once we have a plan lol
-
Well I love techy stuff. But if you disclose it later then it's OK. ;)
-
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.
-
wait, clrhome has power? since when, it is offline so often :P
So yeah, i'd need access there then to be able to test ^^
-
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.
-
sorry for the double post, but this is a substantial update to my idea. Instead of having two separate databases, one for objects (ships and projectiles), and one for terrain, why not also make terrain an object? For instance, add an object of type Terrain, subtype nebula, with center point and radius data provided. Not only does this mean one database, and thus less server load, it also means the same routine to process and render it, and means that the server can randomly change the terrain :)
Fun fact: the total map size of Star Trek MP (playable area) is 7.922816251 x 10 ^28 cubic units.
-
Sounds pretty cool ! :D
-
Thanks.
Hey, does anyone know of any sprite editing tools, for the Mac or for the TI, that are capable of doing BOTH 8x8 and 16x16 sprites. Or at least one for each. I was told about Sir Crpwn's sprite editor, but it only does 8x8.
-
There is pixelscape which is only 8x8 though (http://clrhome.org/pix/) and on IES you can do full calculator screen.
-
Yeah I generally use Pixelscape nowadays. It's quite good. Just make sure to use a compatible browser for full functionality.
-
Squidgetx had one in the Ash Phoenix sub forum IIRC.
-
but they dont do 16x16. thats what i need. for the program's icon.
-
ooooooh, i made one once!
http://www.sorunome.de/ti84+/miscellaneous/sprite.php
but greyscale is not working like axe's greyscale, but because it is only the icon it should sute you fine :)
-
Downloaded. Your program is telling me DCS is missing. I am clicking on it from inside DCS. lol
-
did you enable the libs in the settings?
Also, do you have onblock installed?
-
no, and yes. got it :)
-
yay, glad it is working for you :D
-
The icon for the program, and the game splash screen. enjoy!!
-
Epic ! :D
-
wha, nice stuff!
-
@Sorunome, Kerm has sounded off on the Cemetech topic, http://www.cemetech.net/forum/viewtopic.php?p=209849#209849 (http://www.cemetech.net/forum/viewtopic.php?p=209849#209849), giving some suggestions about syncing. What do you think?
@Streetwalker. Thanks.
-
So Sorunome, did you understand what Kerm was saying? I think I did, but im not sure.
Also, i had an idea... calculator control of the refresh rate. This is a number that controls how often we are refreshing the data from the server. I'm thinking a setting of 1-10, where 1 is 1 time per second and 10 is 10 times per second. This allows a user to have a setting that works best for their hardware.
Attached to this idea is the prospect of how the server would deal with a backlog of requests. If the server sees that it is becoming backlogged, it sends a broadcast message to all units connected, telling them to lower their refresh rate by 1. TI-83+ Basics would ignore this, but all other units would comply. This could then reduce the load on the server.
-
So Sorunome, did you understand what Kerm was saying? I think I did, but im not sure.
[...]
Yeah, it is kinda de-zentrilizing what the server does.
But we'd some kind of hash algorythm for the calc then to hash all the positions etc ;)
-
But what would the hash do? is it some sort of encoded numerical containing a relative position update to all objects?
-
all calcs calculate their hashes and send them to the server (resulting in less data been transmitted).
The server also calcs the position and hashes 'em the same way, it compares all the hashes of the calcs with it own hash.
If they vary the calc either miss-calculated or somebody cheated, so that way the server can send the real positions to the calc etc
-
im so confused. lol. what exactly would this hash be, with relation to the position of that unit?
-
you'll just create a string with like "x,y,type,next unit" etc and you'll hash that string.
You know what a hash is?
-
The only type of hash I'm familiar with is an md5. Which is generally used for encryption of passwords on sites.
-
yes, it can also be used for verification if two large pieces of data are the same - you send 'em through the hash algorythm (if they are the same the hashes will look the same, otherwise VERY likley different). That hash is far shorter than the actual data and thus reduces, let's say, bandwidth
-
ok. let's do that then. But still make the server maintain the hashes of all units. each calc only keeps its own up to date.
-
just keep in mind that if the hashes aren't verified correctly the server will still have to send the calc all the positions
-
Well, how would the hash benefit us? Isn't the hash just basically being used to compress the data? And won't the calc have to undo the hash?
-
Nope the hash is just for integrity check.
-
Oh, so then we're now sending data and a hash??? lol
-
-Calc sends hash to server
-Server checks hash
-Hash correct, do nothing
-Hash invalid resend all data to the calc
-
But dont we need all data to be sent anyway?
-
the thing about the hash is that it is often smaller than the data you originally wanted to send
-
so the hash is just basically a compression of the data we intended to send anyway?
-
basically, yes. Even though there are different strings that result in the same hash, it is very unlikley for it to happen
-
ok. now correct me if im wrong, but the hash cannot be reversed. As in, you can hash something, but you cannot unhash it, at least not without extensive computational power.
-
True. That's why the server sends in real time a delta update (is only what has changed). Then the calc and server both compute a hash of the calc's visible area and if the server sees an invalid hash, it'll resend the whole thing. This can reduce bandwidth a lot (although with calcs, well, it's not even a KB per packet :P).
-
so maybe to reduce computing power of the hash we should just send the raw data, lol, as it isn't *that* much i guess (or just let the server calc everything and send the coordinates)
-
Yeah XD probably the best solution. Hashes are kinda overkill here. What'd be cool is if the server could run off a RasPi. :D
-
it will probably be able to because i'll use python 2.7 for it :)
-
I thought hashes would be a bit overkill. The entire dynamic doesn't have the time or the computational power to be doing hashes in addition to the normal calculations. At least thats what I think.
What do u think about my refresh rate idea, btw?
-
maybe once every second? I don't know about the calculator part, but the server part could also handle way less :)
-
Well me me ask you a question... Im gonna implement a cap. 30 players to a world. Assuming the world is maxed out (30 players online), each requesting data, how well could the server keep up? How often could we request data without getting backlogged?
-
I don't see any problem with 30 connections per second, just keep in mind that that way each calc would also recieve 30 coordinates/data per second.
-
thanks fine. could we increase the frequency? to less than a second? like every 1/4 or 1/2 of a second? but give the server the ability to force you to get the data less often if it cant handle it.
-
i guess we could server-side, it also depends on how powerful the server is, but i guess it should be fine :)
-
Ok. What I'm gonna do, is set default refresh rate to 1 second, but give the user a slider bar, to adjust up or down. Adjusting the refresh rate up gets data from the server more often. adjusting it down gets it less often.
My initial thought was for max refresh rate to be every .1 second and minimum to be 1 second. But I'm thinking to make max .25 seconds and max like 2 seconds or maybe 1.5.
on the server side, you can create variables to keep track of incoming requests for data, and responses to those requests sent. maybe then create a net figure. If we are trending toward a backlog (more incomings than outgoings), the server sends out a broadcast "drop refresh rate" message, that all non-Basic 83+'s will comply with.
-
I don't think you have to worry much about the server not being able to keep up with the calcs, unless you are doing really complex server-side calculations. If the server has to handle so many objects that it starts to cause lagg, the calcs won't be able to handle it either anyway.
And for the request rate: I'd go for 2-4 times per second (standard), and add some kind simplified calc-side object handling to make everything more smooth (eg. send the speed for moving objects to the calc and make the calc cumpute it's movement untill it recieves new data, so that moving objects look like they move instead of 'teleporting' from one place to another).
-
Ok. another question. I know that port ($02) is used to determine if a unit is a Basic 83+ or something else, but is there a way to determine if the calc a specific type, like 83+ SE or an 84+?
-
Why would you detect this ? The only interest here is CPU speed no ? Not sure you need 128k of ram nor 2MB flash. Anyway the os can differentiate SE models so it's feasible to distinguish these as for 83+ vs 84+ you can check the OS version string (1.x is 83+ and 2.x is 84+).
-
Yes, I'm planning to adjust data refresh rate based on CPU speed. How can I detect it? What code?
-
how about you just detect if the calc can go in 'full' mode?
-
You can check bit 7 of port $02 then. Also you need to manually put the calc in 15 MHz mode if you want it.
-
Nah. I've been requested to not use 15 mHz mode. Something I plan to comply with.
My theory is this... if we are getting data too often, then we will be not processing the data quickly enough and the game will slow down. THIS is dependent on the base speed of the hardware, so by determining what hardware we are on, I can create a refresh rate for getting data from the server that doesn't overload the calc's CPU speed.
-
Sprites Request
Players will have the option of being aligned to 5 classes: Federation, Klingon, Vulcan, Romulan, and Dominion.
Anyone willing to contribute sprites for ships for those classes would be credited and appreciated. :)
I will be using a universal sprite for each class, to save memory. At least for now. This may change in a later version. Sprites may be 8x8 or 12x12 or 12x8. I will respect the judgement of others on the ideal size for these sprites.
Also, @Sorunome. How difficult would it be to implement the following... a calculator connected to the server. If a new update of this game (client side) is available, we create a temporary downloading program, quit the game, overwrite the local game copy with the update, and then switch back to the game. Like an automatic update... ?
-
Also, @Sorunome. How difficult would it be to implement the following... a calculator connected to the server. If a new update of this game (client side) is available, we create a temporary downloading program, quit the game, overwrite the local game copy with the update, and then switch back to the game. Like an automatic update... ?
Should work in theory if you can let it create a new asm program, run that, delete the old one and in that new asm program write the enw version, switch back and delete that temp asm prog
Do i amke sence?
-
yes. You need to basically create an updater program that downloads the game.
-
The issue about calc speed is that if you take 8 TI-84 Plus calcs, for example, none will run at identical speed. Even if you detected the calc model to fix speed issues, you would still have issues with newer hardware being slightly faster than older hardware.
If it's for link play, I think that the only way to do it would be to do something like this
1st calc (host):
1) Check if other calc is ready
2) Start of loop
3) <game code> (at this point gameplay is frozen on the other calc)
4) Sends data to other calc and tells it it's ready
5) Wait for other calc data
6) End of loop
2nd calc:
1) Send ready state to other calc
2) Start of loop
3) Wait for other calc data
4) <game code> (at this point the other calc gets frozen)
5) Sends data to other calc and tells it it's ready
6) End of loop
That way, there is no risk of calcs getting out of sync, especially if a crappy cable is used or if someone disconnects one end by mistake. It would need to allow the player to exit at any time, though, in case somehow the connection can no longer be made. It would most likely also be much slower.
-
@DJ, this is not intended to be compatible with link play, as it requires the server as a man-in-the-middle. Perhaps I will integrate link play support into a later version, but not in 1.0. As for timeouts and disconnects, it will be at the discretion of the server how long to wait before a unit is classified as "timed-out". Conversely, it will be at the discretion of the unit itself how long to wait before we as classified as having lost our connection. If this happens, there will be an emergency throw of data into a temporary appvar. DJ, how up to data are you with the latest specs of the project, out of curiosity?
-
I recently checked updates but the last time I really checked was last May IIRC. I forgot some stuff over time probably, though, especially that this went on hiatus a few times before (or at least with no public updates)
-
Now that this project is under active development, http://clrhome.org/startrek/ (http://clrhome.org/startrek/) holds details.
-
Second announcement. Anyone willing to do sprites for this game can send me a PM. Sprites should be of a ship, viewing from four angles... looking at the left side, looking at the right side, looking at the front, and looking at the back.
Ship types are Federation, Klingon, Vulcan, Romulan, and Dominion. If you want to see any additional classes added, please post below. This means 4 sprites per ship type. Sprites can be 12x8 or 16x16.
Also, should I draw a set of large sprites (for a close up view) and small sprites (for a farther away view), or should I use one sprite set with a routine to scale a large sprite down if the ship is farther away?