Monday, August 20, 2018

Progress update #10


We were not really posting anything new related to the project since release of 0.2.5 build so we felt that it’s time to put some light on the future of the project and what is happening behind curtain in our forks of the main repository.

0.3 development progress

The huge 0.3 build is still work in progress but we slowly are getting closer to its release. Currently we are focused on fixing various bugs and improving performance of the idle new object synchronization approach which would let us synchronize objects that are not directly being interacted by any player for example unoccupied vehicles. The main person responsible for the stuff that will be part of this update is Curtis - big kudos to him!

Update on issues

We know about that currently available builds are far from perfect containing major bugs, crashes etc. Issue tracker on github ( is always open for you to report any issue you find during testing the development preview builds, before posting anything make sure there is no similar report already made.
The major issues of 0.2.5 we know about (not mentioning stuff that is not synced yet):
  • Pickupables that not part of the new-game level (are spawned or activated during gameplay) cause assert on pickup.
  • The timeout during joining the game.

Networking overhaul

The plan is to completely overhaul networking, the whole task is super big and first part of it is already implemented in 0.2.5 build. Unfortunately we are not able to dedicate ourselves to the project full-time, because of that it will take few more updates to be completed.

The reason of that overhaul is to be able to implement synchronization of various parts of the My Summer Car much faster without need to write a lot of custom handling code, plus being able to synchronize every aspect of the game as efficient as possible bandwidth-wise.

My Summer Car is a very complex game on it’s own, containing many mechanics and because of that we have to keep that in mind that is a lot of data to synchronize, it’s one of the main reasons we decided not to use any existing network framework available for unity and making our own custom one so we can build it on top of our needs. Of course as any choices this one also has its pros and cons.

The huge pros of this decision is that we can design it just to fit the complexity of the MSC, another one is that we are not limited to any platform, currently in the builds we use steam networking for the low-level network communication, part of the overhaul will let you decide what driver to use potentially opening doors to implement dedicated server support.

Of course there are also cons as we mentioned before, as we decided to write own networking layer it will take a lot of time to develop it the way we want it to be but we feel that it’s worth the effort.

Thank you for your continuous support!

MSCMP Development Team and Contributors!

No comments:

Post a Comment