By Anonymous ![[de]](/mwf/flags/de.png "Germany")
Date 2009-06-19 00:01
Its a bit hard to explain, but im not a native english speaker.
My idee is that 2 or more teams play against each other over a few days or maybe weeks. Befor it start player register for a team with nick and PW. When the game starts every Team has ther own server and on every serve is the same map running (realy big map).
The Teams have to reach a Gole on the map (maybe something like clean all the acid form the map). The gole has to be hard and the team members have to work together. So one Team has to be faster the the others.
Im not shure if this idee will work, but if ther are about 40 registert people per team and the can log in whenever they want.
well i got this idee since clonk 4, and thoght it would be great to have something like this. You have to work in a team and work for something big.
My idee is that 2 or more teams play against each other over a few days or maybe weeks. Befor it start player register for a team with nick and PW. When the game starts every Team has ther own server and on every serve is the same map running (realy big map).
The Teams have to reach a Gole on the map (maybe something like clean all the acid form the map). The gole has to be hard and the team members have to work together. So one Team has to be faster the the others.
Im not shure if this idee will work, but if ther are about 40 registert people per team and the can log in whenever they want.
well i got this idee since clonk 4, and thoght it would be great to have something like this. You have to work in a team and work for something big.
yes i had this idea, too.
But it needs an other networkcode.
I have a dream... that one day, runtime join will last a few seconds.
how to do? the clients do not simulate the same world, they just render a screen (zoomed to not have so many objects to render) and send their controls. The server needs to send changes in the area around the players sight (i.e. changes of a flight courve, the client can simulate a simple flight), the player just has to load the right graphics in the right packs.
But it needs an other networkcode.
I have a dream... that one day, runtime join will last a few seconds.
how to do? the clients do not simulate the same world, they just render a screen (zoomed to not have so many objects to render) and send their controls. The server needs to send changes in the area around the players sight (i.e. changes of a flight courve, the client can simulate a simple flight), the player just has to load the right graphics in the right packs.
Yeah... sounds great... and because it's OC I hope it will get realized.
By Anonymous
Date 2009-06-19 15:07
new netcode shutn´t be so hard. Maybe players can only join every 5min (when the server creats the actual state of the map).
>(when the server creats the actual state of the map).
So every five minutes the game is delayed for one minute to save the map? Doesn't sound like a good idea :)
Hm. I wonder... Why couldn't we do runtimejoin savegames by fork()ing?
The server should save the landscape while the landscape changes? Doesn't sound like a good idea either :)
No, it's actually a sound method: fork creates a copy (actually, marks the memory pages as copy-on-write) of the whole process. Doesn't work on inferior operating systems without cheap fork(), but that shouldn't be a barrier :-)
when we have a more simple memory management, OC could save faster and could also save the game state into a mem-buffer from where it could be sent to the client in an extra-thread.
By Anonymous
Date 2009-06-20 19:32
im not shure how landscape is saved now, but you just need to save every corner point of every field of the same terrain, that wold be up to a few hundred points per terrain field. so maybe on a realy big map 300 fields, well lets say about 300 points per field. So 300 * 300 * 2 (2 dimensions) = 180000 short int numbers + 300 byts (to define type of terrain) + maybe 6000 * 2 short ints for objects (stones etc) + about 50 byts for defining the type.
that would be 192000 short ints and about 350 byts. That would be 375.34kb for saving a map. And i thing the server can do this quit fast, maybe 0,5 sec lag. If you only allow players to join every 5 min this wouldnt be a probelem would it?
that would be 192000 short ints and about 350 byts. That would be 375.34kb for saving a map. And i thing the server can do this quit fast, maybe 0,5 sec lag. If you only allow players to join every 5 min this wouldnt be a probelem would it?
I presume that the joining in running games works similary, as saving a game, you do need all the playerfiles and the round on your computer. An interesting approch would to only save changes to the beginning, but this wouldn't work forever and probably only bring a minor gain in speed.
Would only work for static maps. (Anyways, you need to get the changes by turbulence of the materials.) But if the changes would come while the game is running... everything outside the field of sight would need to be synchronized after the player sees this area. Like this system used mostly in 3D games... video-[...], so the computer doesn't need to render/animate the graphics. Just some coordinates and other informations about an object.
>Would only work for static maps
Why sould it? You can generate the same map zillions of times from the scenario data and the random seed. (Actually the way it is done at every startup.)
But thats the problem, when it's dynamic you need every information about the status of the map, like actually.
I just don't get the point of what you complain, but I figured, that the host had to regen the startup map to make a diff. -> Lag. Anyway... *lastpost*
:P!
The problem is more the performance you need to calculate the changes...
![[es]](/mwf/flags/es.png "Spain")
It's already like this. Only the changes to the landscape are transmitted.
But... for indestructable maps (like Hazard or some magic melees) you wouldn't need to save the landscape... just the objects and positions of players, etc.
Maybe a Scenario.txt entry like... (But if there would be a possibility to change the landscape and this option is activated: Syncerror?(Not if asynchrone network is activated.... but this would be strange, I think.))
[Head]
NoLandscapeSync=1
Maybe a Scenario.txt entry like... (But if there would be a possibility to change the landscape and this option is activated: Syncerror?(Not if asynchrone network is activated.... but this would be strange, I think.))
[Head]
NoLandscapeSync=1
Then there would be the Objects.txt-Generation as the other point which consumes much time. Maybe create a Objects.txt at the beginning which is Framely updated?
Objects.txt format is weird, slow and needs to much memory.
I think we should use a binary format for faster access
For realtime transmission there should only transmitted the changes in a small circle (zoom decreases the ammount of visible objects)
I think we should use a binary format for faster access
For realtime transmission there should only transmitted the changes in a small circle (zoom decreases the ammount of visible objects)
>For realtime transmission there should only transmitted the changes in a small circle (zoom decreases the ammount of visible objects)
There are no realtime transmissions... the only things which are realtime-transmitted are the player controls and some hashes for sync-check.
but in case we _would_ do object transmissions (for the new networkcode http://forum.openclonk.org/topic_show.pl?pid=2184#pid2184)
'y know what we're talking about?
'y know what we're talking about?
That would rise the neccesary internetspeed to a multiple of the current.
an other possibility would be to make a savegame at the start of the game. The client has to recalculate a whole game (a few minutes) to join but the game is stored on the server separatly (no lag during the game).
When the runtime client has calculated it, he would upload his savegame to the server.
When the runtime client has calculated it, he would upload his savegame to the server.
And again, all you need to get the same game flow are all objects, the scenario, the random seed and the controls.
all objects and the scenario is saved externally (that's what the clients download), the controls were sent by the role-play-server (not that much data, use an extra thread)
>For realtime transmission there should only transmitted the changes in a small circle (zoom decreases the ammount of visible objects)
Scrips don't only interact with objects which are visible for you.
>Objects.txt format is weird, slow and needs to much memory.
>I think we should use a binary format for faster access
memcpy(mem,objects), write(sock_newclient,mem) `o´. Generally right, perhaps also for masterserver.
But aren't the changes in the landscape the biggest problem? :)
but the problems were that the landscape was not calculated synchronous
they arent sent over net.
they arent sent over net.
Your idea sounds great. Would be nice if the developers realize that.>Its a bit hard to explain, but im not a native english speaker.
You speak german, right?
By Anonymous
Date 2009-06-23 02:02
yes^^ how did u know?
by the way i realy shut get a account here^^
by the way i realy shut get a account here^^
![[pl]](/mwf/flags/pl.png "Poland")
In fact that wont be much trouble. The server would need to store map in memory anyway. So when player wants to join he first waits few seconds until he receives whole map and objects positions from server, then area around him and all objects get updated and synchronized with server, so scripts would work properly, then rest of map is updated, and voila - player can start game. After that players just receive data about landscape changes around them (or all changes, I don`t know with one would be better) and object positions, rotations, etc.
This would require a server with fast connection speed, but I think it would be possible. Or mazbe... I don`t know, in fact I`m n00b programmer as I don`t have enough patience to learn everything.
PS.:Sorry for replying to this post, but if I would reply to another post it could not get noticed.
This would require a server with fast connection speed, but I think it would be possible. Or mazbe... I don`t know, in fact I`m n00b programmer as I don`t have enough patience to learn everything.
PS.:Sorry for replying to this post, but if I would reply to another post it could not get noticed.
>but if I would reply to another post it could not get noticed.
You normally see new or unread posts quite well :)
I don't think that anyone will not see your posts because of the tree-structure - they will propably even fit more there!
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
