Hi all,
so it feels like the Cucumber time is here. Also known as a Silly season, this is the time of the year when not much is happening on the public scene and newspapers are scrambling for stuff to write about. Seems like we are going through such a period in the Factorio world as well. Not that much has been happening recently. We carry on with our work and progress slowly but steady. I have divided my time among multiplayer work, bugfixing and administration. Kuba has been focused on some internal refactoring in the past days. And Albert has been finishing with the player animations. Kovarex is coming back from vacation sometimes next week so the 0.10.4 release will happen most probably next Friday.
A report on multiplayer progress has become a kind of standard part of the past couple of Friday Facts editions. So here we go again. We had some first tests with players meeting on the same map. The mechanism has been tested only on single computer so far (using localhost as a connection). However, the 5 steps goal mentioned two weeks ago (start 2 instances - load a game in first - second instance joins - map is downloaded - players meet in the game) has been achieved already.
So here we are with a map with two players in it. Already a bunch of standard stuff can be done. Players running around, mining, building, operating entities, shooting at each other, etc. All these actions being properly synchronized across multiple instances. It is kind of fun to do - even when actually playing just with myself. Tangible results like these really give us some great positive motivation. I remember the euphorical feeling when I got the 2 players together in the game for the first time.
One tricky issue that came up recently is handling players dropping from the game. That means player leaving the game without proper ending sequence (for instance their connection died). Not only it is tricky to coordinate the action to disconnect the player at the same time afterwards. The problem is also that in such a case the remaining players might have locally inconsistent map states. I will try to give a simple example without running too much into technical details. For instance let's imagine a game with four players A, B, C, D. Player A drops from the game. Player B and C have the map in tick 100. Player D however has the map in tick 101 and tick 101 contains some input from the player A that is no longer in the game. For instance player A finished chopping down the tree just before he disconnected. In this case D will have to transfer its information about actions from player A to B, C before carrying on with the simulation. Normally (when no drops happen) this is working just fine because every peer is responsible for delivering its actions, however here player D will have to act as a proxy for player A who no longer exists in the game. Just one of the many, many things on the MP list :D But it will be worth it.
Players already have different colors for the multiplayer game. For every animation Albert made a corresponding mask animation with the same amount of frames that colors certain parts of the underlying animation. Below is a motivational composition. This one is not taken from the actual game but was made in PSP by Albert. The mask system has been implemented in a generic way that it will work for any animation, not just the player. This will be extremely useful for modders because using masks will save a lot of video memory compared to duplicating the object animation. Imagine a mod that adds 5 new biters with different colors, now it can be just a single animation and a maks overlay not 5 different animations. Also a shortcut to color the whole animation not just parts of it has been added.
The place to tell us what you think is ready at our forums.
