Friday Facts #30 - Full time on MP

Posted by Tomas on 2014-04-18

Hello,

after a long long time the 0.9.8 was marked stable this week. There were no big ovations or cheering, just a quite "stable sticker exchange":) The bugs forum is not empty though, as someone would expect. Quite a few small issues remain, but for the sake of moving on we decided to put them to our backlog and mark the release as stable. However if some game crashing or very serious bugs are discovered in 0.9.8, we will make a hotfix. Oh, and the good thing is that we managed to break the streak (for now) of ever increasing number of bugfix releases (the 0.9 had 8 bugfix releases - the same as 0.8).

The whole "programming department" has been fully commited to the work on multiplayer for a while now. The task divison for now is following:

Michal - fully deterministic simulation. This is an absolute must, because all multiplayer peers will calculate the simulation themselves and only the player input (we call it input actions) will be exchanged over the network. Nice effect of having deterministic simulation will be having functional replays again (hmmm not really again because there have always been some bugs in them even when they were "working":)).
Kuba - lower level network layer. This includes the connection management, packets management (we will be using UDP for all the communication) and eventually things like NAT punching to allow connections for peers behind NAT (few people have public IP address).
Tomas - synchronization layer. This logic will take care of keeping the simulation state same for all the players in the game. This includes queing up the input actions, sending them out in batches (tick closures to other peers), requesting missing tick closures, etc.

These things are absolute minimum necessary for our multiplayer implementation. However there is more to be done after this, things like: starting the game (the lobby), mechanism for a player joining already existing game, hiding the latency for the player (most of the time the actions for different players will not collide so we can act as if common actions - like moving the player around - were confirmed immediately) and more (see our battleplan whiteboard in one of the previous friday facts). There is a lot of work ahead, but the good news is that we have finally fully dived into it. We will keep you updated about the progress:)

Albert has finished with most of the map trailer tweaks. Today we also did a first test with exporting the trailer using the new screenshot mechanism. We did this on Michal's computer which is way more powerful than mine (it does take a while to export 3600 screenshots). However there was this funky bug that parts of the terrain in the screenshots had strange, kind of inverted, colors. We have spent like half a day looking into this issue. Finally it turned out to be a problem in our custom optimized version of d3d drawing routine (this was happening on windows only). Spending hours in frustration hunting bugs (that are not even visible to the player in the end) happens more often than you would think, so game programming is not just about sitting back, playing video games and calling it "research" (but that is part of the job too:)) Anyway to give you an idea of what was going on you can see a visualization of the problem below. For better effect (and for us to easier analyze the problem) the corrupted regions of the image (here all of the terrain) are drawn with reddish overlay. Any idea for the picture title?

Want to cheer us up for the multiplayer work? Or feel like laughing at us for taking so long with the trailer? Go to our forums.

Subscribe by email