Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Server runtime: feedback and questions

Discussion in 'Multiplayer' started by BHouse, Sep 13, 2018.

  1. BHouse

    BHouse

    Joined:
    Jan 10, 2018
    Posts:
    76
    [Edit: removing old sticky posts as new Solutions Architect team begins to manage this forum]

    In a September ‘18 blog post, we shared more details about the long-term vision for Unity as a Server runtime, as well as some details about our first steps forward that will be available in alpha soon.

    This sticky post will stay up-to-date with blog posts and talks that are relevant specifically to the the future of Server runtime support. Here’s the list that exists today:

    Talks
    Blog posts
    If you have feedback and questions specifically about Unity as a server runtime, please post here to ensure the support team and developers dedicated to this topic see and respond.
     
    Last edited: Dec 3, 2020
  2. Zante

    Zante

    Joined:
    Mar 29, 2008
    Posts:
    429
    My suggestion is that you make it clear who you are aiming these questions at. I'm a self taught developer who has dabbled in everything from JS and C# to UNET authentication systems working via tokens and web APIs.

    There's much I'd like to feedback and discuss but I don't know what a server runtime is. I will after I post this because I will educate myself. The level of assumed prior knowledge you're dealing with might not match the existing baseline/literacy. Many game developers are known for their ability to improvise and aren't necessarily going about things in a manner you might see as standard or typical.
     
    BHouse likes this.
  3. VToon

    VToon

    Joined:
    Sep 17, 2018
    Posts:
    6
    Suggestion: A Customizable, Minimal, Headless Server Build

    Hello,

    First of all, I'd like to express my admiration for Unity's commitment to democratizing video game development, especially connected games. I'm excited about the evolving networking features of the Unity engine, in particular the new dedicated server/cloud based networking model.

    As you all know, cost is still the biggest obstacle for indie developers when it comes to server-authoritative connected games. Bare metal or cloud, most indie developers can't afford to successfully launch a server-authoritative massively multiplayer game!

    One of the helpful solutions that I've been thinking about is having a partially authoritative server model instead of a fully authoritative one. So that the server will only run a simulation of the critical physics objects and actions that need to be synchronized between all players.

    What I'm suggesting is a Trimmed Headless Simulation; not just Headless (without graphics), but also Trimmed (without non-critical objects/actions in the scene).

    So the game world will be divided into two categories:
    1. Critical objects and actions: These will be included in the trimmed headless build, and will be handled server-side based on input received from the clients.
    2. Non-critical objects and actions: These will be processed by the clients and won't even exist in the simulated world on the server. The server will only pass commands for these non-critical objects/actions and let each client process them locally.
    For example, objects/meshes outside or inside the playable area that have no effect on gameplay do not need to exist in the server-simulated world.

    Now, which objects and actions are critical and which are not will largely vary from one project to another, so the headless build should be customizable to allow each developer to create their own customized minimal headless server build.

    Maybe this can be achieved by adding a "TRIM_HEADLESS" tag or flag to scripts or game objects and components in the inspector, which excludes those items from the headless build. These still need to be accounted for in the server runtime (for passing commands to clients), but they don't need to be simulated on the server.

    For example, suppose you have a bunch of houses in a remote non-playable area with some lights on them that turn on/off based on certain in-game actions. These houses do not need to be part of the server-simulated world, but there should be "ghost references" to them within the server runtime to keep track of the lights' state.

    This is just a rough idea -- I hope it makes sense!
     
    Last edited: Sep 17, 2018
    BHouse likes this.
  4. VToon

    VToon

    Joined:
    Sep 17, 2018
    Posts:
    6
    @Zante - The server runtime is the headless build of the game that runs on the server, or more accurately, while it is running on the server.
     
  5. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,884
    It's really quite simple.

    Quit with making nothing but cloud based networking solutions.
    They are nothing but cash grabs with nice features until you get the 'bill' for them features
    whether your game sells enough copies to sustain it or not.

    Make actual dedicated server instances. I don't understand how this cloud based non-sense has gained so much traction when it's one of the worst design decisions to ever be designed.

    I can't speak for every developer. But I'm not a fan of being limited to how many players a game can host because of a CCU or message limit. It's stupid.

    Make unity be able to be a self-sustaining dedicated server, with no relay systems to the outside world.

    I know this thread was about the server-runtime stuff. But my point was. Make it a server-runtime without all that extra junk that isn't needed - such as relay services. In my whole time ever hosting dedicated server for anything, I've never even ran into anyone who needed to NAT Punchthrough, etc. to host a server.

    The minority of people in this case should just get with the program and get the proper network devices if they want to avoid them issues.

    Sorry I don't mean to sound so harsh in this. It's just been a really long road for me and one of my games.
    Finally just made the jump and purchased TNet3, does exactly what I mentioned above, and better than that, it even has a built in ready to go Console Server. Perhaps you guys should buy it from the developer and use that as the network solution. It works, works great and is VERY easy to get up and running.
     
  6. VToon

    VToon

    Joined:
    Sep 17, 2018
    Posts:
    6
    Why do you think many multiplayer games are using or have switched to cloud-based solutions instead of bare-metal servers?

    With bare-metal dedicated servers you'll have a hard cap on the total number of players your game can accommodate, which doesn't grow when suddenly needed. That is not unless you buy more servers and get them running, but new players won't wait for you to get more servers and will just leave and probably never come back. Maybe you would be happy with a fixed upper limit for your player count and you wouldn't mind losing those extra potential players, but that's not what Unity have in mind for Connected Games, as far as I can tell. And that's just one of the advantages of cloud hosting.

    I agree that a cloud-only solution is not financially wise, so to get the best of both worlds a hybrid solution would be the best way to go. You use bare-metal servers as a primary solution to host the expected everyday traffic, and a secondary cloud-based solution which you can burst into in times of sudden surges of players.

    Going back to the server runtime, I think this still is the main source of financial hindrance to a dedicated server architecture, regardless if you use a bare-metal or cloud solution. How many game instances (full server-side world simulation) you think you can run per bare-metal server? That's the main problem! Forget about bandwidth/CCU, it's the computing resources needed to run the Unity (headless) engine on the server that's going to be break the bank.

    Any way you look at it, unless you are a AAA studio, making an online multiplayer game with total server-side game world simulation is out of reach. Hence my suggestion above for a partially authoritative server with partial server-side game world simulation. A custom headless build where each developer can choose what exactly they want to simulate on the server and what will be left for local processing by each client, which can then be reported back to the server and checked against some custom server-side logic.

    Obviously, this won't be a one-size-fits-all solution, but the idea is to make the headless build readily customizable so that each developer can easily exclude objects/actions from the world and add custom server-side logic, resulting in a much lighter server runtime process than a complete simulation of the whole game world. This will still be costly, but it can make a significant difference, which will vary per project.
     
    Last edited: Sep 22, 2018
  7. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,884
    @VToon I'm not talking about Master Servers. I'm talking about dedicated servers..

    Player buys game. Player hosts a server.
    Client 1 buys game. Client 1 types IP/Hostname, and directly connects to that server, no master relay services that points you where to go.

    No middle man, no server-to-server communications. most games do not need multiple servers.
    For example. Starbound, Ark, Empyrion, Terraria, etc. All of which have dedicated servers that players can host on their own machines, or rent. But truthfully speaking, it costs the developers absolutely nothing to go this route, literally nothing, which allows them to focus on their game, rather than worry about extra stuff that isn't needed.

    I mean yeah,some games could use the cloud based systems, but if they are a big-time game, such as Battlefield, it's literally impossible to use any cloud network system, only because of the imposed limits.

    Now the developers could always just have an actual physical server somewhere that server-owners could send their hostname/ip and name of server so others can find it easily. But that's like hardly any cost involved there.
    Nor is it really required.

    That's my only point is the above^^^.

    Cost of Investment is slim to nothing at all, depending which route you'd like to take.
    People who host the servers manage it them-selves.

    So for the entire lifespan of your game, no matter how much it sells, or doesn't sell, the game could theoretically still be online in 3000 years if people still want to host the server for it (I know unlikely that far in the future), but my point was, the game can be online forever, and even if your company goes bust and crashes, people can still enjoy the game.
     
    UndeadButterKnife likes this.
  8. Raystorm

    Raystorm

    Joined:
    Mar 28, 2016
    Posts:
    9
    @N1warhead I think that is closer to what unity is aiming for, they do provide the hybrid dedicated server + cloud solution if anyone needs it, they did this because of the growing market for multiplayer games with developer controlled dedicated server.
    But, unity also stated that u can host the server runtime on your own solution (like, if you prefer to manage your own server, or like you stated, let the player rent or run the server on their own).

    so if what you're aiming is for player hosted server, it's possible, unity is not stopping you (event right now, with current UNet it's possible).

    as for player hosted servers, some games actually have a NAT punchthrough solution to make sure players can connect, other's don't. this could be a problem for those machine behind a router, as people need to know their public IP & port of the server to connect. usually, those running the server (who are behind the router) can configure their router to allow port forwarding, this will fix the problem with connection, but not all users might know how to do this and this is where the problem is.

    example is killing floor 2, where you have to configure for port forwarding if you are behind a router, even then, they have their own server to pass on the public IP of the host for anyone trying to connect.

    this is why other networking solution like Forge Networking provides a Nat Punchthrough solution for this.
    With Tnet they use UPNP for automatic port forwarding (so the users don't have to do this) & this is not perfect as not all router can support this (or if they do support it, some might be disabled by default, so you may have to instruct users to enable these).

    i am currently developing a multiplayer game where player can host on their own, and this is the biggest problem i have encountered so far. my options are, creating my own NAT punchthrough solution, give instructions to players on how to port forward (but this just reduce the overall User Experience, as it creates extra steps for players), or implement UPNP (like Tnet). at least steam provides a nat punchthrough solutrion, so im using steam for now to help with this.

    so saying that there is no worry for the developer, is not entirely correct. because for me, creating the best user experience is a top priority.

    conclusion, yes you can have player hosted server, but if you don't have a good dedicated community that helps each other on hosting, this might reduce the overall User Experience(there are user's that just want to play the game & not go through the hassle of problems that might arise on player hosted servers, these user's may get a bad experience).

    the service unity provide is to make it easier for indie devs who makes a more competitive type (where an authoritive server is a must).

    i do hope unity implements a nat punchthrough & UPNP solution, to make it easier for devs.

    note: killing floor 2 uses multiplay (this is service unity is currently implementing) with hybrid bare metal & cloud, but they also allow users to host their own servers on their machine in case their servers are all full. (i think this is the server runtime unity is aiming for)
     
  9. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,884
    Not that I don't agree that user experience is top priority. However, I thought it was common knowledge to port forward when hosting games? I haven't ever hosted a game where it just magically worked for me. I always had to port forward, no matter what I tried; also isn't very technical and hard either. I was doing it when I was 8 years old, nobody to tell me how to do it other than trusty google.

    I'm sorry that I have to disagree with everything else though.
    1. Long Term Sustainability: the game being playable 30 years from now.
    2. Is better than: Quick easy setup, that costs the company thousands if not over millions in 30 years.
    3. Unless: you already have (millions) of users who love your products, and buy your products.
    4. Otherwise: you're offering a service, that if nobody buys your game, is a waste of money, time, effort.
    30 years is just an arbitrary number in terms of the games life.
    Dedicated servers, for as long as we have Internet, will forever work and can always have a community,
    whether the company is shut down, no longer supporting the game, etc. So in the long term, is a much more
    engaging and affordable way to deal with games lasting beyond the intended range of time you think it will survive.

    So what if you have to give support to help people get up and running, that comes with the territory.
    Or, you know, make excellent documentation that very clearly explains what to do, what to avoid,
    and potential differences between things.

    Don't take me wrong, some games really just don't need a dedicated server, and that's okay.
    But any game, outside of casual, just literally has no place to be used with cloud based network packages that cost money.

    problems with cloud based network packages or even hybrids.
    1. No server-side authoritation, hackers will be everywhere.
    2. CCU Limits
    3. Only so many players allowed per room
    4. Only so many players allowed in general to connect.
    5. No server source code
    6. General use net code that is generic, not tailored to anything specific.
    7. Most people don't truly understand what's going on with what it does and how to optimize it.
    8. Pricing
    9. You have to have a self-sustaining business that can support the fees associated with this.
    10. Possible early shutdown of network services, thus upsetting customers. (really bad user-experience).

    The key part to pay attention to in that list is #9. Unless you already have a sustainable business, then it makes no sense to use cloud networking, unless you are without a doubt sure it will make sense to use said network.
    Otherwise, a good old fashioned Dedicated server is the most economic and sustainable way for your game to prosper in the years to come, whether it sells 10 copies or millions.

    Ultimately, which is just my opinion, that long-term-sustainability is more important than quick easy to setup for players, that not only drain your companies funds, but also have to deal with said third parties when something goes wrong, and there's nothing you can do to stop the issues other than telling players that a fix is 'potentially' on the way soon, if you can get in touch with the proper people soon enough.

    And the problem with UNet?
    Yeah LLAPI could do dedi servers, but just like Unreal, they push you to use the blueprints over C++. Same with Unet, they push very hard for you to use the HLAPI and leave the LLAPI docs with dread, brief descriptions, and some things not even documented, thus practically forcing you to use the HLAPI that practically forces you to use their cloud based solutions. Yeah you can make a dedi with HLAPI, but in a limited scope of what you can and can't do.
     
    UndeadButterKnife likes this.
  10. N1warhead

    N1warhead

    Joined:
    Mar 12, 2014
    Posts:
    3,884
    Sorry, I really do hate to sound mean about all that and such. It's just a topic that really messes with me big time.

    I know there's a place for cloud networking packages. I just don't understand why dedicated server seem to be a thing of the past, when they really are the most affordable option for the creator of the game. Everything today just appears to be a cash grab. So it really bothers me.

    But yeah, just wanted to point out that I really don't have 'problems' with cloud networking packages.
    I just wished dedicated servers were still a 'priority' rather than a quick and simple easy solution that in the long run, costs the company a lot of money.
     
    UndeadButterKnife likes this.
  11. VToon

    VToon

    Joined:
    Sep 17, 2018
    Posts:
    6
    Dedicated servers aren't a thing of the past. Peer-to-Peer and player-owned dedicated servers are becoming obsolete. The good old days of gaming when people mostly played with close (in all meanings of the word) friends are dying. That's not what new and upcoming generations of gamers are interested in.

    In fact I find it rather easily boring and sometimes uninteresting to play with the same "friends"! I want to play with different people everyday from all over the world! The kind of players I wouldn't trust not to cheat, so I wouldn't want any of them to have the privilege of being the host of the game, whether on their local device or a server they own.

    Worldwide connected games are the future! Free-to-play (freemium) games are the future! Instantly and largely scalable games are the future! And for those to work best, you need a dedicated server architecture, whether bare-metal (cost-effective), cloud (flexible and scalable), or a hybrid (best of both worlds). Not the kind of player-owned dedicated servers you are talking about, but rather developer-owned dedicated servers.

    I am not necessarily a proponent of these trends in the gaming world, but like it or not, things change and move forward. P2P and player-owned dedicated servers are looking backwards!

    And yes, it's all about money...well, maybe not all, but that's the primary driving force! You may be in it for the love of the game, but sadly, that's not what's gonna keep Unity alive and evolving!
     
    BHouse likes this.
  12. Raystorm

    Raystorm

    Joined:
    Mar 28, 2016
    Posts:
    9
    i think there is a misunderstanding here, after reading your post, it seems that what you want is dedicated server for unity games right?

    well, isn't that what unity is offering with their new Connected games?
    the example i talked about was killing floor 2, where the devs provide a dedicated server which they host, and also provide the tool for the players to host themselves. they use multiplay which is a service that manage said dedicated server.

    now the cloud solution unity is talking about, is a cloud VPS where those dedicated server instance could run (AWS, GCP, Azure) these cloud's are not for messaging relay, they are a dedicated server instance, the cloud VPS is used to increase the limit of the dedicated servers in the case of sudden influx, they use cloud because it can be easily scaled up and down, so if for example the dev predicted an x amount of players are gonna play on release, then they prepare x amount of dedicated server, but the game end up being more popular than what the devs expected, this is where the elastic cloud comes in to temporary increase the amount of dedicated server.

    unity's service is that same service, they bought multiplay. their service is that they manage these dedicated servers for you, but all of it is optional, if you want to manage your own dedicated server or give the tool to players, you can (& unity has stated that you don't have to use their service, you can host the server build anywhere).

    so point 1-7 is the things unity want to fix with their new connected games, 8-10 is up to the developers (whether you want to be fully authoritive, meaning all server's are hosted by you, which can be very expensive, or give players the tools to host their own, which is throwing the cost to the community, but if you really want to remove cheaters, you gotta have your own hosted server).

    i'm not here disagreeing with you about dedicated server, because i also want dedicated server.
    i hope this post clarify any misunderstanding you have with my previous post and with the service unity is offering.

    i reccomend reading into this blog post : https://blogs.unity3d.com/2018/09/12/multiplayer-connected-games-first-steps-forward/
    the post explains that unity is going for the dedicated hosting route.

    and this thread is for the server runtime build, the runtime build is the dedicated server instance, unity made this thread for feedback so we can have the most optimized build, therefore a lighter, less performance hogging dedicated server runtime, which in turn less cost for the devs.

    dedicated server isn't a thing of the past, it is the future, that's why unity is abandoning the old UNet for this new dedicated hosting aproach.

    edit: i was a bit confused when you said dedicated server are inexpensive, because in my head dedicated server is the server which the dev host (this is for security, so that all server instances are controlled), while you were talking about community ran server (People may mod the build, good for co-op or less competitive games, as they can still cheat), both are dedicated server.
     
    Last edited: Sep 26, 2018
  13. BHouse

    BHouse

    Joined:
    Jan 10, 2018
    Posts:
    76
    This is really great feedback and reminder that it's on us at Unity to provide resources for developers to teach themselves aspects of a new tech stack that are accurate and well-paced. This post literally lead to me re-writing the talk I'm doing at Unite LA to focus on a real-time multiplayer tech primer, so hopefully the subsequent expert-level talks in the track will hopefully make more sense to a broader audience.
     
    Deleted User and hwaet like this.
  14. BHouse

    BHouse

    Joined:
    Jan 10, 2018
    Posts:
    76
    This is excellent and definitely in-line with some topics we've been discussing internally. With packages, we want it to be possible to not only disable rendering and eventually completely separate "simulation" from "presentation", but we also know that certain games will care about authority of different aspects of the game more than others. For example, a really precise shooter may want a very detailed physics simulation AND animations, such that character arms/limbs/etc are represented on the server in their actual position and geo rather than hit-box style approximations. Wheres a more casual mario kart style game may be open to a simplified server authoritative physics package that treats every car as a box.

    The current plan is to leverage packages as the method for modularity; i.e. include only the packages necessary for your game, such that it could literally have just a very tiny Unity player and 1 or 2 packages on the server. That will take time, but we expect significant progress in 2019.
     
    Deleted User likes this.
  15. BHouse

    BHouse

    Joined:
    Jan 10, 2018
    Posts:
    76
    Been following this discussion, and pretty much everything VToon mentions here is true. Player demands and expectations have shifted drastically in the last decade or 2, and Unity devs need access to dedicated servers in cloud and hybrid hosting scenarios for fully scalable and cost-effective games.

    However, I can honestly say that, at least of the people I work with, it's definitely *not* all about the money (most of us are here for the mission). And even if it were, it would never be a viable business strategy to bleed money from devs who cannot reach profitability themselves; somehow we all have to find paths to success. Unity has to make enough money to be able to keep making exciting new tech, but IMO, that will only happen if our devs also succeed.
     
    Deleted User likes this.
  16. ksakins

    ksakins

    Joined:
    Aug 29, 2015
    Posts:
    16
    @BHouse I just want to say thanks for being engaging and professional on these forums, and not shrugging off some of the expressed concerns like I've seen from moderators (who I assume to be Unity staff) on other posts. For a hobbyist developer like me, who is freely benefitting from the hard work of a lot of other folks, it's stuff like that which keeps me engaged and more willing to want to help Unity grow its product. Thanks again.
     
    BHouse likes this.
  17. BHouse

    BHouse

    Joined:
    Jan 10, 2018
    Posts:
    76
    Thank YOU @ksakins - for many of us, the game dev community is why we are here, and messages like this really brighten our day. :)
     
    Deleted User likes this.
  18. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    Not sure if this is the place to post on the new multiplayer repo I saw today.

    Overall it looks pretty good. There are things there I would have done differently, but I really like that it's entirely open source and fairly modular. So if I wanted to replace/modify parts of it I can.

    So to picking on a few things.

    A pipeline approach for everything above the core networking is really difficult to beat as a larger design. It matches most networking flows very well, it makes the system easy to modify/extend at most any point, and solves the problem of passing state information from one layer to another in an elegant fashion. It's been adopted as almost a defacto standard for how to do this.

    Documentation for higher level protocols you make up would be nice. Especially for those integrating with non Unity servers.

    On my dream list would be Unity releasing a stand alone dll for native containers. I can imagine this opens up a whole can of worms, but for those of us who work with Unity but use non Unity servers in the mix, it would be completely awesome.
     
  19. timjohansson

    timjohansson

    Unity Technologies

    Joined:
    Jul 13, 2016
    Posts:
    473
    We are planning to do something like a pipeline for extending the transport without making source modifications. It is one of the highest things on our priority list and we will share it as soon as we have something implemented.

    We are planning to document all the protocols we use, we don't have all the detailed low-level details documented yet as we are expecting them to change while we are still in preview. If you really want to get a head start you would currently have to look at the source.

    A completely standalone dll for native containers would be a bit tricky to do since it relies on a few Unity API methods to work. The obvious ones is the UnsafeUtility class used to work with unmanaged allocations, which is tricky to emulate in pure c# due to moving gc. Another tricky one would be the integration points with the JobSystem, the concurrent collections rely on having thread index injected by the JobSystem. I don't think it is impossible to do, but it is not something we are actively working on.
     
  20. tiggus

    tiggus

    Joined:
    Sep 2, 2010
    Posts:
    1,240
    What would debugging look like for the server runtime? Would you still be able to run it in a Unity editor and for instance be able to see the lower detail collision meshes, etc.?

    I just read the blog post on the server runtime and it definitely seems on point to me, all of the points listed are very relevant to online games.
     
    BHouse likes this.
  21. yian-dev

    yian-dev

    Joined:
    Jun 26, 2017
    Posts:
    20
    Hey UT, first of all let me say that before you ask us feedback you have to tell us where are you willing to "make compromises" on your part, what i mean by that is are you actually serious about democratizing multiplayer game making you must allow us to have our own dedicated server's solutions, and build a workflow(very important) + framework for the engine that allows fast iteration of network building in two separate projects client should be developed inside Unity Editor and the server should be separate project without the editor. This is the basis of fast iteration and proper separation of tasks for a programmer team.
    Dont lock us in some silly CCU payment with google cloud, its fine if you want to offer your own solution with your own custom services, but if you really want to make money AND take Unity to the next level and make it the defacto game engine for online multiplayer games you must set it free, and let devlopers take control, the mmo market is starving for a an easier access to good GameEngine+ networking for big servers, sharding etc... currently UE4 is being used a lot but is SO difficult, their entire networking and C++ API is extrremely buggy and difficult to use, mere mortals and indies and non-C++ wizards cant make their smaller ORPG, OARPG and so on come to life its just not achievable.

    With the old UNET you have to build the networking inside unity editor using HLAPI clunky components and everytime i make a change for the server only i have to rebuild for client aswell very bad workflow, in larger projects this becomes extremely slow and bad.

    There needs to be high quality modern UDP Authoritative dedicated server capabilities with highly flexible API, maybe build in low level C++ with C# high level exposed API, its fine if its closed source but you need to make it flexible.
    E.g in UNET you derrive your scripts from NetworkBehaviour and it syncs automatically, takes care of the script data, but what exactly does it do? does it sync every since function and variable in the script? thats highly inneficcient, we need some way of declaring what needs to be synced in a script and what not, for safety,efficiency, flexibility etc.

    I think a good high quality authoritative API is the core of everything networking, it doesnt matter what type of game you have P2P card passive, moba LAN, shooter LAN, or battleroyale/MMORPG large maps, maybe even changing landscape maps that the server takes care of, you need dedicated server to have control over it.

    Another point id like to touch is that, can you please not leave free edition users locked out of your network hosting services? maybe its time for a new license type. If im developing a networked game and want to use your hosting+google cloud etc i cant even begin developing if im not Pro user and paying a lot in advance. How about a new model where as small team or indie developers you get acess to cloud infrastructure maybe something like 50-200 connections max for developing purposes, but you dont have to pay unless you release your game, that ofcourse if you dont already make >100k$ / year. And even after you release the game you should only pay for network services/cloud hosting according to how much traffic you have, and prices scale up according to number players.

    So at the end you have 2 networking options, 1 develop your own custom server infrastructure according to needs unrestriced, no payment needed for networking services and 2 you can use unity's network services without having to invest loads of cash in advance for a game that might die before release or have too few players, and affordable payments that scale with the increased hosting requirements.

    The 2nd option also will incentivize developers to use unity services since there is no entry bar you can go right ahead and start developing networked games for free up to a limit of connections and or developers and if you have higher needs during development you can pay for such services.

    Think about it this way, e.g. a new indie team of 12 developers is making a new networked mobile game, they never made over 100k$/year so they are using the free version with free unity cloud services for developing purposes license free, they develop their game and reach alpha/beta stage where they need to go alpha testing or closed beta and allow a high number of players to register and try their game out for bughunting, feature testing etc, but that doesnt mean they should subscribe for many months they can just subscibe for e.g 2000 players hosting service for 1 month or 2 so they can get testing done and then no payment usually a few more months of developing before release or next beta phase, and once their game reaches release date then they can fully subscribe for large scale cloud hosting and pay a monthly fee, all without the need of pro version. Once their game revenue exceeds 100k$ for the year they also have to subscribe to the pro version of unity along side hosting costs.

    In short make network hosting service separated from pro licensing, otherwise smaller indie teams will have no choice but to develop their own servers which slows them down and also doesnt bring unity any profits, but the option should still be there for anyone who wants to use their own custom servers, for gameplay innovation or other specific reasons.
     
  22. BHouse

    BHouse

    Joined:
    Jan 10, 2018
    Posts:
    76
    Thanks for the feedback; there is a lot here that we are already thinking about based on feedback from others as well. A few key points worth noting:
    * We will not force anyone to use our server hosting solution; we are providing an option that we hope will be the best balance of scale, performance, and ease-of-use for our developers, but we won't be offended if you find a different solution for your game.
    * Server/client runtime separation (and iteration time) is a good point, and definitely a problem we have in the 2019 line-up to at least start to solve.
    * All new networking packages will offer full source and be modular; i.e. you only use and pay the performance cost of the features you need. We also plan to leverage multi-threading with the new Job System, and some simulation code will take advantage of ECS structured data (in "high-performance C#") to ensure efficient compute across large sets of networked objects and users.
    * A Dedicated "authoritative" server model topology is our highest priority - we agree that the most-successful games today leverage this model for many reasons (cheat prevention, consistent connection speed/quality, larger scale, etc)
    * Pricing isn't announced yet, but you can expect a similar pay-as-you go / consumption model as other cloud compute providers, and free-license Unity users will not be blocked from getting started. In these models you pay based on the amount of compute you use (typically time and bandwidth), which scales based on the number of users. In the ideal case, if you have 0 users playing networked games, you should not pay much (if anything) to support the game.
     
  23. BHouse

    BHouse

    Joined:
    Jan 10, 2018
    Posts:
    76
    Hi All - just a note that some of the Unite LA talks went up on youtube yesterday. I updated the initial sticky post here; the most relevant talk for "server runtime" considerations is this one:
    "Connected Games: Real-time Multiplayer"
    As ever, feedback welcome!
     
  24. MrG

    MrG

    Joined:
    Oct 6, 2012
    Posts:
    363
    +1000 for completely separated server / client projects. Every time I write if (isServer) I want to scream.

    In watching this video, the glaring omissions are Database Server in the stack and Perpetual World Games in the list of game types.

    In all this spinning up and down of cloud servers, where does the data live? If each instance has a database, how will they stay in sync? How is Registration and Authentication to be handled (don't even say, "Oh, players will need a Google account to play your game so we can monetize off your players").

    Perpetual Worlds run 24/7/365 and they change constantly. Players drop stuff. Server cleans up after them. Staff will add things to the world that the server must retain. Players (and maybe even NPC's) evolve through game play over hours, days, weeks, or more. All of this must be retained and synchronized across all game servers.

    When Brandi talks about server runtimes, she barely scratches the surface with regard to what's different about a headless build, what might be stripped. She mentions compiler defines and disabling audio. Oh please stop. That might be acceptable in tiny projects, but doesn't scale worth a darn. A separate project for each entity eliminates all that mess. Further, the server's view of the world is far different than an NPC Client, a GameMaster Client, and a Player Client. Game Server may have a stripped terrain for collision, primitive colliders for objects, trigger volumes for firing events on server when players enter certain areas, and generally deal with player inputs authoritatively. NPC Client will not have a terrain, but will have a Nav Mesh instead, along with its own set of primitives like the Game Server, but its sole function is to drive all the NPC's authoritatively based on all sorts of information the Game Server shares with it, including player states and inputs. GameMaster Client might have a textured but otherwise bare terrain, and a whole different UI / UX because they can jump around the world, inspect details about objects and players, track multiple targets in split screen, change all kinds of data on any thing in the game world, control the weather, and kick-ban the trolls. Finally the Player Client has the rich environment, highly sophisticated controls for input, unique UI screens and scenes that load additively when the server detects they're needed (e.g. "load interior of building 12674" is sent from server to client that entered a trigger volume). Note that clients don't have trigger volumes like the server has. Player Client needs to handle Asset Bundles that none of the others do. Server may additively load dozens or hundreds of sub scenes and keep them indefinitley when it first starts up. NPC Client may as well, but they're different versions. GameMaster and Player probably only load them by proximity. In all of the above, only the player may have animated people and creatures. Game Server and NPC Client would only have primitive colliders. Game Master may have simplified versions like color-coded capsules with labels.

    In all of the above, there is virtually nothing in common from a code standpoint, other than perhaps the movement prediction on the Player Client being similar to that of the Game Server, and of course the low-level networking. Even the messages exchanged with the Game Server are different in each of the described Clients because their roles are different.

    Please think about how all this needs to fit together.
     
    Last edited: Nov 23, 2018
    aatithya and theanhchu like this.
  25. JTovey

    JTovey

    Unity Technologies

    Joined:
    Oct 30, 2018
    Posts:
    35
    Hi there,

    I am sorry for the time it took to get back to you! I will do my best to break down the first 2 questions, and I will see what I can do with regards to your other concerns/points.

    1) The spinning up and down of cloud servers is more for use in match-based FPS games, where CCU will change per region over the course of a day, and because persistence is not an issue, these can be spun up and down over time as required. That said, if you wanted to make a perpetual world game, then you would likely need to host a separate DB server in bare metal with which to track the changes that are occurring on a regular basis. Then, when there is an NPC interaction, for something like a shop in-game, the server makes a short DB request for the required information, and when the interaction is completed, the server sends an update to the DB. This is a complicated subject and unfortunately, there is no easy answer, as it comes down to how you are planning to operate the game, in a way similar to something like Rust, with lots of separate game servers, or something like Eve Online, with one persistent world, but certain areas broken up across your instances. If you mean something more akin to the latter, then you need to decide how all of your various systems are going to interact, and then progress from there.

    2) For registration and authentication, this depends on what platform(s) you are planning to release on. If you are releasing through steam, then they have a system which allows you to use the steam account UUID(s) for this. If you are releasing on Android or iPhone, then using their Google account/apple account would likely be the simplest method to take, though you would need to investigate how to interact with these.

    3) This again, like point 1, requires some more definition on your part as to whether you are thinking more akin to the likes of Rust or the likes of Eve online. For things like Rust, then one option would be something like having a primary server which is queried by a new instance on startup, which is then assigned an ID, based on something like the servers IP and Port, or how many are online at the current time, which is then used to track the changes to the game world, such as NPC interactions and behaviours, dropped items, so that when the instance is shut down again due to not being required, you can store this data for later use. If, however, you want something with one large world across all servers, then this is more tricky, and I cannot give you a model answer on how to utilise the system for that, given the complexity of the various systems that you need to determine the design for.

    Regarding your other issues, I will raise this with the rest of the team and see if we can get you an update, though this might not be immediate, the team and I will try to keep you updated on the status of your questions.
     
    NoDumbQuestion likes this.
  26. zhuchun

    zhuchun

    Joined:
    Aug 11, 2012
    Posts:
    433
    Greetings, is there any ETA of the minimal headless server?
     
  27. BHouse

    BHouse

    Joined:
    Jan 10, 2018
    Posts:
    76
    >> cross-posting in several sticky threads; please pardon the repeated message<<

    We understand many of you would like to create multiplayer games / multi-user projects and are challenged by Unity's current state of netcode. We also acknowledge the netcode and workflow requirements can vary based on the projects you're building.

    So, to help us understand how to best to support you, please share your thoughts in the survey below. The survey only takes about 10 minutes, and your feedback will help inform future product decisions. Click here to take the survey by June 8.