• Collaborative Project: MARS MINER
    137 replies, posted
  • [QUOTE=thomasfn;34672914]How about you assign each packet a name. Then in order to map the IDs, you sort them by ascending order. As long as both the client and server have the same packet listings, they will be assigned the same IDs - that way you don't need to network them across.[/QUOTE] [del]Much like the block naming system. The Source engine uses a similar approach.[/del] [editline]![/editline] Wait... no.. I read that wrong. Zik's idea is preferable; a similar approach is used by the Source engine. If the client or server assign packet IDs on their own, different packet listings (due to addons or such) will cause the packet IDs to be offset... which is bad. To support modding (without restricting loading order), Zik's idea is best; that is, have the server send the names and packet IDs so that every client has the same packet listing. This also allows for new packet IDs at runtime.
  • [QUOTE=Deco Da Man;34676114][del]Much like the block naming system. The Source engine uses a similar approach.[/del] [editline]![/editline] Wait... no.. I read that wrong. Zik's idea is preferable; a similar approach is used by the Source engine. If the client or server assign packet IDs on their own, different packet listings (due to addons or such) will cause the packet IDs to be offset... which is bad. To support modding (without restricting loading order), Zik's idea is best; that is, have the server send the names and packet IDs so that every client has the same packet listing. This also allows for new packet IDs at runtime.[/QUOTE] Ah good point, I didn't think about modding. I suppose if you compress the packet listings when you send them it shouldn't be too bad.
  • [QUOTE=thomasfn;34678146]Ah good point, I didn't think about modding. I suppose if you compress the packet listings when you send them it shouldn't be too bad.[/QUOTE] Just send the addition of new packet types. On initial connection you'd just send every packet type! Perhaps have a reserved range of packets, for the underlying engine packets.
  • I got rid of most of the delegates (really bad idea in retrospect) and changed the whole thing so it's actually usable for larger saves. There still are two or three things that I have to implement, but it's working overall and the interface is stable I think. I'll merge the branch and push it into the main repository later today. I also got rid of the half-implemented async IO, it's probably better to just have the generator thread synchronize everything. Writing a header means the behaviour of outdated written blocks becomes undefined and reusing one in a new saved state likely corrupts the data on disk. It's easy to avoid this by marking free space only when the save is opened, but then the file would grow with each save in a session. [b]Edit:[/b] It's online now. I'm not sure how to connect it to the main program yet, but there are a few translator functions in MarsMiner.Shared.Extensions.GameSaveTranslator.
  • We should add dual-wielding once we have tools. This could be an interesting gameplay mechanic: [URL="http://www.nasa.gov/centers/goddard/news/topstory/2005/mgs_plates.html"]http://www.nasa.gov/centers/goddard/news/topstory/2005/mgs_plates.html[/URL]
  • I'm slowly making my way through networking, sorry for the lack of updates but it was my birthday and my friends keep selfishly inviting me to play CSS. Expect an explosion of progress when the boring bits are done.
  • Tamschi, would you say that your chunk saving is at the stage where I can use it to send chunks to clients from a server for testing purposes?
  • It's fairly stable, but I don't think it's a good fit for networking... It probably wouldn't work without lots of changes because most of the serializing depends on the GameSave instance, wich would be extremely inefficient over a network. It's a better idea to just have the clients request a chunk they need, then have the server send them that data in one block with a low priority and any changes for that chunk with a sequence number. Stream based networking doesn't look like a good idea to me, it would be better to have datagram packets instead because there will be a lot of datagrams that should be fast but not reliable like position updates. If we use an RUDP library we can have parallel transmissions more easily too, so we can probably send a split-up chunk more efficiently without risking to delay block updates around the player too much. It should be easier to manage the server bandwidth too that way.
  • You're right, I'll have a go at UDP then. [editline]27th February 2012[/editline] To be honest it would be a great help if someone with experience of UDP and networking in general would write the bare bones of the networking. The networking is quite sensitive to speed and bandwidth, so we can't really afford someone who has little experience like myself writing it.
  • Something similar to [URL="http://en.wikipedia.org/wiki/SCTP_packet_structure"]SCTP[/URL]'s chunk packets would be good. I can try to write something once I get rid of the string and pointer buildup in the savefiles, but I don't have much experience with networking either.
  • I embedded the pointers directly into the structs and moved the strings into a normal block structure to fix the buildup issues. The strings take the same amount of space as before, but automatic deduplication is broken. I think I know how to fix this though. The pointers always take 8 bytes currently, but it's possible to reduce that a bit by limiting the supported blob size and count. I'll leave it for now because it's probably not a problem.
  • I implemented deduplication for strings and block type tables. This keeps an instance for each unique block in memory while the save is open, so it's only good for small blocks that are usually duplicates. Dereferencing blocks from pointers in the save file still always creates a new instance, so that's the next thing I'll fix. I read up on networking: I could probably write good packet code, but there's no way I'll be able to write the server side connection layer any time soon.
  • I'll probably have a stab at UDP over Easter, which starts next week for me. I've been busy with various assignments and things the past few weeks so I haven't been able to work on it at all.
  • I really wish I could contribute a bit, but I'm terrible at networking and 3D graphics. When this gets more to the surface level stuff I think I'll give it a shot.
  • I finally moved my dev environment to my laptop and implemented the read cache. It's slightly faster than before, now that it doesn't read the same data 10 times in a row :v: Ziks, do you plan to keep the chunks at fixed height or will the Y-axis be unlimited?
  • Variable would be a good idea to save memory, since a lot of the game will be underground so we could only generate to the depth that has been dug. I'll probably do that.
  • Notch's 0x10[SUP]c[/SUP] just sounds like the game I wanted to make except you can go into space too.
  • Did anyone get anywhere with the networking? I might be able to help some if you haven't. [editline]9th April 2012[/editline] Oh crap, forgot this was in c#. I don't know how much I will be able to help with it since I don't know any of the function names for it. I am used to c++.