Jump to content
  • Advertisement

JM-KinematicSoup

Member
  • Content count

    20
  • Joined

  • Last visited

Community Reputation

6 Neutral

1 Follower

About JM-KinematicSoup

  • Rank
    Member

Social

  • Twitter
    @kinematicsoup
  • Github
    kinematicsoup

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi all, I'm on the team that is working on Scene Fusion for Unreal. I have a little showing off to do: Real-time collaboration in VR! We are starting our alpha next week. We have quite a few signups to get through but if you're interested we have a sign-up sheet here: https://www.kinematicsoup.com/scene-fusion/unreal-engine-signup
  2. JM-KinematicSoup

    Whatever happened to Havok?

    PhysX is in both Unreal and Unity. We use it too. However, if Havoc has deterministic features it might be worth licensing, especially if you are doing multiplayer networking. We use PhysX, and keeping the bandwidth down is hard: http://demo.kinematicsoup.com is an example.
  3. JM-KinematicSoup

    Whatever happened to Havok?

    I'm curious myself. I seem to remember that Havok did have a subset of functionality that could do deterministic physics, which was interesting at the time. TBH, it is probably hard to compete with the likes of PhysX and Bullet these days. I imagine even MS doesn't know what to do with it. I would hope that they would just open-source it rather than abandon it. Perhaps they are working on something big in secret that uses it.
  4. JM-KinematicSoup

    [UNREAL] WIP real-time collaboration plugin - Scene Fusion!

    Thanks a bunch! We released a version for Unity some time ago, which we are actively developing for. The Unreal version is something we have really wanted to do for quite some time, but didn't take the plunge until recently. We are very excited, and when it is released it will be very customizable so that teams can fine-tune it to suit their projects.
  5. Hi all, Some of you may already be familiar with Scene Fusion for Unity. Well, we kept getting asked when the Unreal version will be coming. After many months of hard work, we were able to produce our first teaser! We will be going into a closed alpha test in the coming weeks: In the meantime, check it out!
  6. JM-KinematicSoup

    Snapshot Interpolation

    Glenn's articles are a good place to start. Multiplayer is such a complicated topic that even in all his blog posts he only covers most of the basics. We are using snapshot encoding as well because we need to do dynamic physics, and it's easier and much more reliable to reconcile from a single authoritative source. We can add a deterministic lockstep method later, however we will still have an authoritative sim running somewhere. We also will need to be able to sync in at any point without rerunning the sim from the beginning.
  7. JM-KinematicSoup

    Snapshot Interpolation

    Yes. In our case we run network receives at a different rate than sends as well in order to process RPCs as fast as possible. In our case we use previous packet data to predict current state, just due to the number of objects we are describing. In that case we need to packets to always be in-order and guaranteed to arrive. If order does not matter, dropped packets also won't matter and you don't need RUDP, regular UDP will suffice. True. I should have qualified that better: It is possible to each user to experience exactly the same simulation, just not at the exact same time.
  8. JM-KinematicSoup

    Snapshot Interpolation

    These are excellent points. Latency is actually a lot more complicated than people realize. Not only do you have a server loop, but you'll have encoding time and other factors that can sneak a millisecond in here and there. The approach we took was to run two threads: A game loop thread, and an network thread. All the serialzation/encoding happens in the networking thread, so we have a pretty reliable loop latency. Typically we send data about 2-3ms after the logic loop has completed. When the encode runs longer, we track the extra ms and try to catch up in subsequent frames that finish earlier. This helps to smooth out the arrival of packets on the client-side. We do something a bit goofy, but works for us. The network library runs as independent Hz from the main loop, and further can receive at a different Hz than it sends. This means that if we set the main loop to 60 Hz, we can run the networking send loop at 20 Hz, so you get the precision of 60 Hz but the data reduction of fewer packets. The network receive can still happen at 60 Hz, which means you can receive RPCs fast enough to have them be meaningful in the game logic. http://kazap.io runs at 30 Hz but does feel quite responsive despite being a web game that uses websockets, and has a relatively low update rate (okay, I consider 30 Hz low...). Part of the reason it feels responsive is we use local input and extrapolation to mask the extra latency. Lag manifests differently when you use extrapolation. Instead of a delayed response, you get sluggishness, which is preferable in some cases. We use UDP and TCP. TCP has a lot of drawbacks but is otherwise fine for development, and when your frames encode to < minimum MTU it does behave a lot like an RUDP library. The key thing with making sure sends go out quickly using TCP is to turn off Nagle (set by using TCP_NODELAY). To address that last point, which I think is the most important: Synchronous multiplayer is an illusion - focus on the appearance of synchronization, not the accuracy of it. Most of the time you'll be close enough that it won't be an issue, anyway.
  9. Hi all, My team and I are working on a feature video to cover everything Scene Fusion is capable of. It covers almost all of the features in Scene Fusion to date. Other features are coming over the next 3-4 months. We will be introducing several new capabilities soon such as an revamped API so you can choose what gets synced an how, a raw C# and raw C++ API, and Scene Fusion for Unreal beta.
  10. JM-KinematicSoup

    ZLib compression from UE4 to Boost ?

    Oh BTW, have you tried using LibLZMA from the 7-zip project instead of the zlib library?
  11. JM-KinematicSoup

    Snapshot Interpolation

    We used a type of extrapolation for a game we created. It works well on slower games and masks latency effectively: http://www.kinematicsoup.com/news/2017/5/30/multiplayerprediction
  12. JM-KinematicSoup

    ZLib compression from UE4 to Boost ?

    More importantly, it is probably actually expanding the data.
  13. Hi all, We do these internal game jams from time to time. One of us created a multiplayer game that we had enough fun playing in the office that we thought we would just stick it in a browser for the world to enjoy, and just use ads to pay for it's running costs. The game is kazap.io. I thought I would share with you how we handled making the motion smooth and keeping a 'snappy' feel. Here is the video, and there is also a blog post with code!
  14. JM-KinematicSoup

    Multi-player level creation

    You are thinking about MaxPlay. I have quite a bit of background knowledge on them. They wanted to take on Unity and Epic, which was not a small task, and the funding did dry up for various reasons. We are looking at UE4 support right now. I estimate that it could take up to a year for us to get it to where it currently is with Unity (ie. we support all built-in components as well as custom components - properties all sync, and it works in tandem with source control for code/asset changes). However, we can at least get the basics in place in a matter of 6-10 weeks. Our biggest problem is just getting interest from developers. I would love to have 20 studios in the beta to help us focus on the pieces we need to focus on.
  15. JM-KinematicSoup

    Multi-player level creation

    Hi all, I have been working on a project that enables multi-player level creation (ie. multiple level designers work together in real-time). Right now we have it working for Unity. Here is a video of it in action: This isn't a new idea, and has been tried before. The idea is that you get lots of benefits from working this way: 1) No more scene merging/conflicts. 2) People can see and react to each other's work immediately, they can iterate on things instantly. 3) Much easier for the lead designer to be active in the work, supervise, and provide feedback - camera following is actually being used as a supervision tool. 4) It's actually much more fun to work this way, so people are more motivated and work faster. So here is a question: Has anyone worked with a system like this in the past? What did you think of it?
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!