A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Introducing the new Universal Render Pipeline and High Definition Render Pipeline subforums!
Unity 2019.3 Beta is out now.
Discussion in 'Assets and Asset Store' started by vis2k, Dec 29, 2015.
Progress: doing more stress tests today and adjusting code where needed.
The Road to 1000 CCU - 500 CCU WORST CASE @ 8 CPUs, 32GB RAM
It's done. Finally, after 3 years of networking hell.
1000 CCU in a real MMO with players spread across a huge map should be no problem for the server now.
Big thanks to everyone who reported bugs, all the people helping out new members and all the loyal guys who believed in uMMORPG since day one, no matter what. It's been a long, difficult journey to get where we are from UNET's initial 20-50 CCU full of errors. Every small contribution, every bug fix and every discussion was needed to get us here.
I also apologize for the slow message replies lately, but I hope that it all makes sense now.
An open 1000 CCU community test will follow after a few more optimizations and Mirror bug fixes.
How to run a server in Windows？
Check the documentation. -nographics -batchmode is your friend.
V.155 pending review! Very important fixes and improvements that were uncovered during the recent stress tests.
Open uMMORPG with Unity 2018.2.2f20
Delete old Mirror folder, use the new one
Drag all networked prefabs (monsters, players, skill effects, etc.) into the scene. Select them all. Go to debug view in the Inspector (top right icon), reassign missing NetworkIdentity components.
Reassign missing NetworkProximityChecker components with new NetworkProximityGridChecker
Save each prefab, remove them all from the scene again.
Don't panic. If you have trouble upgrading then please let me know and I'll help. This is the last time we have to replace script components with Mirror.
Switch Scripting Runtime version in Edit->Player Setttings to .NET 4.x, restart Unity, delete System.Data.dll from sqlite folder.
Upgraded to Unity 2018.2.20f1 + .Net 4.x to fix a bug where a client build would freeze after 3-15 minutes on OSX when the client sends data over the network. Originally we wanted to wait for Unity 2018.4 LTS to upgrade, but this fix is too important to wait.
Mirror updated to latest version: source drop-in instead of DLLs and a lot of bug fixes and improvements.
Escape key now cancels movement locally instead of on the server. Avoids a forced reset to the server's slightly behind position on local player.
Fixed chmod for files from 755 to 644 (default)
Remove [SyncVar] GameObject workarounds because Mirror handles it now
NetworkManagerMMO headless detection removed and feature enabled in Mirror's new NetworkManager instead
Adjusted spawn points so people don't spawn floating in the air for one frame
Cleared all name/guild/stun/quest overlays by default, so that they aren't shown for one frame when spawning and when moving into proximity
Skeleton giant scale reset to 1, increased 3D model scale instead. Fixes issues with too big and too blurry name overlays.
Mount: MOVING animation checks owner.IsMoving instead of owner.state==MOVING so that the animation isn't delayed in high latency situations
NetworkProximityGridChecker: 30x performance increase when checking 1000 monsters and almost half GC
Less logging on server, to focus on the important messages instead
Entity.OnTriggerEnter/Exit made virtual so it can be overwritten by Player without 'new' keyword
Player.OnTriggerEnter checks if server before calling QuestsOnLocation to fix the warning messages that QuestsOnLocation was called on client
Dont' show rubberbanding message each time. This might happen a lot under heavy load when resetting other player's positions on the client
Added BuffsPanel under Buffs to properly hide them after disconnecting
Little question: So you went away from LTS release and supported 2018.2 now? Are you going back to LTS release when 2018 LTS is released? Just asking because I waited to get 2018 LTS released and now you already switched to 2018.2 "without" LTS.
Yes. I wanted to wait for 2018.4 LTS too, but there is a bug in the 2017 .NET version that pretty much forces us to upgrade to 2018 + Net 4.x. Otherwise a game client can sometimes freeze when being connected to the server.
Will definitely update to and stay at 2018.4 LTS when released.
Few quick questions:
1. I hear no sound on your uTube example. Do you handle sound. Master Audio Multi is supposed to work with unet. Have you tried it?
2. NAT punch through. Do you handle this?
3. How many dedicated lines do I need to run a development server?
Progress: working on instanced dungeons, to be released soon! uMMORPG will get a significant price increase after instanced dungeons, so make sure to buy now while it's still cheap.
There is support for skill cast sounds, which is probably the only thing you need to sync over the network when it comes to sounds. Everything else is regular Unity AudioSources etc.
NAT punchthrough isn't really needed for an MMO, since you would normally host it on a decent server on the internet somewhere. NAT punch through doesn't work in all (most?) cases anyway, which is not ideal for the user experience.
3. What do you mean with 'dedicated lines'? If you are wondering which server to rent during development: probably at least 2 core cpu, 2 GB ram. A VPS is fine during development too.
I don't think I understand your answer. The punch through isn't needed at the server end, It's needed at the client end to pass through customer's router, etc. I have used multiplayer before, and without punch through, a connection between client and server could not be established between two computers in the same room, through the buildings internet equipment. Without punch through users need to learn how to open ports through their routers, and I can't expect them to do this.
What is it that you are doing to establish the connection?
Awesome, finally! When can we expect more news about the system?
I have specific questions like:
- Is the dungeon size for every dungeon configurable? Like 5 / 10 and also raids with 25 or 50 for example? Being able to define a min and max size would be good for every dungeon.
- Are solo dungeons possible? So min and max size = 1?
- I hope and suppose a dungeon will be a separeted scene which will be loaded when entering or using the mesh like a door?
- Will it be possible to host a dungeon on a seperate server or server instance to loadbalance? Having one instance server which host all the dungeons and one normal one for world and all other stuff? This is done by all MMOs out there and would save lot of load on normal server whith too many instances of dungeons.
Can't wait for the update!
If you host the game server on a vps or dedicated server or in the cloud, then clients won't need punch through. Which is what you would do for an MMO. Or do you want people to be able to host their own MMO servers?
Right now the dungeons have a level requirement and a 'be in a party' requirement. Could potentially add party size limits later. Want to get the simple version released and stable first.
So solo dungeons aren't possible at the moment. You definitely need a party member and a partyId, so that the server knows which party this dungeon belongs to - and when to close it.
About separate scene / load balance: I will explain this in detail in the documentation. I don't believe it's necessary to run them on separate servers. Think about it: if you have 1000 people logged in, then you would balance off 100 people to a separate dungeon server for half an hour, then they all get back to the main world - so the main world server has to handle 1000 people either way.
Ok make sense for the start, but would be a good and important feature in the future. As you know they are different types of dungeons like solo, 5 man, 10 man, raids etc. I also would like to define that this dungeon needs 5 gamers and not less or more, simply because I will design the bosses / AI and dungeon itself for this amount of players. Its hard to design dungeons without knowing the minium or maximum party size or being able to define a limit. So really hope for this feature in the future.
Well I know it from different Pservers or offical MMO servers that they are on different server, or you simply have the option to do that if you want, which would be cool if you ask me. You are right with your comparision but raids for example take 2-4h (good old Vanilla WoW ones). In this time the world server has to handle less players.
Another thing is, what happens if the world server crashes. The "instanced server" will still run and hopefully not be affected (for a specific time). It will lost connection to the login server but the gamers should still be able to play the dungeon.
Anyway of course its up to you, but in my opinion just giving the developers / administrators the option to use another server for it if they want to, would be a good option in the future. At the start I would also host everything on one server.
Thanks a lot for the fast response!
I think I get it. Rather than opening a series of ports in the firewall/router you are sticking with a single port basic internet connection to your server/vps/cloud. In keeping with your philosophy of simplest solution, you are not bothering with a sophisticated multiport connection, and you are able to provide the performance shown in your testing, which is sufficient for our purposes.
It is actually amazing that you provide as many of the classic WOW features as you do, because many have tried and failed. Is there a demo game I can log on to?
@vis2k Have you had anyone host the game servers at their house? If so, what are potential issues if any at all?
There is a webgl demo on the asset store page.
Paul does that for cubica. No nat punch through though, he probably just opened the port in his router.
Personally I wouldn't recommend it unless you:
Have a very good network connection.
And a safe network.
The latter part is the biggest concern imho. If I host it at my home, then I'll probably never know if someone hacked me because there was an exploit in the router firmware, or the operating system, or in uMMORPG, Mirror, Telepathy, Unity or any other aspect of it. If I host it on google's servers, then the odds of them being hacked are virtually zero.
I hope you don't mind a debate here on this topic but I disagree with you here. I understand your thinking here that you have to support 1000 players in a zone no matter what so why go through the extra effort for seperate/scenes for seperate zones. Its all going to be on the same box unless we get really complicated with multi-server support.
The biggest issue I have with this is that 1000 in the same zone is the worst case. If you can distribute players more evenly you should. I know you support grid based proximity which is critical but it's not just about network load. It's also about each zone being able to run on a different thread, it's also about each zone being able to have a different set of assets and being able to completely unload assets for zones you are not in. It's also about completely distributing players so you don't even have to do the proximity check for 800 of the 1000 players on the server.
To me the threading one is the one that gets to me on this issue.Being able to run the entire unity stack in a completely threaded but still safe environment (ie not having to worry about race conditions and thread safety across the zones), is game development paradise. Completely seperate zones are such a gift in terms of simplifying complex problems I am surprised you wouldn't want to go this route. Now that unity can run headless pretty easily there really is no reason not to spin off 10 zones all running on different threads to handle the load. Better yet spin up a zone only when players are in them. We are only pilling on the cores on the CPUs so this route is only going to get more and more attractive as time goes on.
The reason why I decided against this (even after doing that with my NetworkZones addon for a year) is that it's very difficult to develop and to maintain:
Chat needs to work across zones.
Guild invites need to work across zones
Party invites need to work across zones
Guild/Party status (online, level, etc.) need to work across zones
We need to make sure that people don't log in in two zones at the same time
For instanced dungeons, a zone needs to remove itself if the party is gone
There needs to be some kind of handshake/secure key to authorize people to connect to another zone
It would never work in the Editor. So if someone purchased uMMORPG from the Asset Store, presses play and walks into a portal, nothing would happen because we can't fire up another Editor instance and then press Play there.
It requires specialized logging, because by default Unity will put all the logging into one player.log file.
Most of these issues can be solved with a master server. This would not be easy to use for people anymore though. If you purchase uMMORPG and the first setup step is 'please run this master server.exe on your computer' - then this would really suck. In fact, I doubt that I am allowed to even distribute that on the asset store.
For WoW and AAA title MMOs it makes sense, no doubt. For Indie MMOs, it seems to be more important to optimize for the probability of ever releasing your game.
The MMO that I played back in 2006 allowed 2000 CCU per server, and they used 3 zones for that. It's 13 years later now, and processing power has grown exponentially. We should be able to handle 2000 CCU with Unity and in one scene. Why overcomplicate it.
I anyway understood his example regarding running scenes on different servers and not having the dungeon in a seperate scene. I expect and really hope the dungeon itself will be a seperate scene which is loaded when you enter the dungeon. If I have a big Terrain with a dungeon entrance, the dungeon should be in a seperate scene and be loaded when entering.
I can't put a dungeon below or above a Terrain when using Lightning and weather effects. The dungeon needs to be occuled and the Lightning needs to be generated seperatly from the Terrain scene.
I disagree here. I Master Server would bring much more benefits to uMmorpg than disadvantages and would make this a really MMORPG asset. Playerhubs, dungeons, raids etc. would benefit from it and would be possible almost "out of the box".
Also arguing that the main issue of the Master Server would be the complexety or "more work" to get uMmorpg running doesn't make any sense at all. You need to understand server configs and SQL anyway if you want to run uMMorpg. All needs to bet set before starting and testing it. uMmorpg and all other MMORPG assets will never be a press play and start playing asset. You will always need to create configs, relational databases and stuff before. Creating a small master-sever.exe will not change anything with it and will not make it harder to understand. uMmorpg will still be the most easiest MMORPG asset on the store.
Your can create at least a uMMORPG pro asset for people who needs something like that or an paid addon. Through Discord I know some people who need something like a MasterServer concept and are not happy with just the NetworkZone Script.
But well I am gonna wait for the update which anyway will be a big step forward. I just hope that my created dungeons - which are and will be all in a seperate scene - wil be instanced and get a simple teleport to them. Thats the main technical idea of a MMORPG dungeon. And not a pseudo dungeon hidden in the same terrain scene under / above the terrain...
Not all games lend themselves to the one zone philosophy. Speaking for myself, I don't need many of the features you named above as reasons not to include multiple zones. I don't need
Chat across zones.
Guild invites across zone
Party invites across zones
Guild/Party status (online, level, etc.) across zones
My concept of an MMO is not a WOW feature list (though years back it probably was). What makes my design unique has nothing to do with guilds and parties. I just need lots of concurrent players.
On the other hand, I suppose I could try to fashion one humongous terrain and make pseudo zones physically separate on the terrain and teleport players around. This means I will encounter Unity scene limitations, which I would usually solve with Sectr Complete, but I do not believe Sectr is compatible with uMMORPG.
To me, handling a couple of Unity scenes is a basic feature, lending itself to a more flexible and wider variety of potential MMO designs.
Having said that, I bow to your decision. In the immortal words of Ricky Nelson, "You can't please everyone, so you've got to please yourself."
EDIT: If you made it a paid add on, I would gladly pay.
The whole problem is HLAPI, doesn't matter what modifications have been made to it. It's not designed for what it's being used for.
So in case you did not know, MMORPG KIT does exactly this. Its is based on the wonderful open source Master Server framework (https://github.com/alvyxaz/barebones-masterserver). It allows multiple zones and spins off multiple servers on the same machine when the game world has them, one per zone. I am not mentioning that as a hit against your product but only as a counter to your point that it would over complicate it. The whole thing worked right out of the box as expected.
I am sure if you asked your users which is a necessary feature for release, most would say that multiple zones is far more critical than an item mall. But perhaps not. I am still with the argument that multiple zones is a critical core feature. You really can't viably make it to market without more than one zone. One server yes, but only one zone no. And packing a full MMO into a single scene just isn't as viable as I think you make it out to be. As RonnyDance pointed out you can't just spawn different levels at -1000 y (etc), your going to make the whole thing 10 times more complicated fixing the issues that arise from this rather than just spawning a new zone in a new scene.
I understand you are on your path, but I am willing to bet your going to regret that decision later on.
In any case, I am not trying to bash your work here (just honestly trying to give you feedback). You've done a great job here keep it up.
There is still the old NetworkZones addon that does just that. If you don't need chat or guild across zones then feel free to use that addon. It's very simple too, shouldn't encounter too many suprises.
uMMORPG is now feature complete. This is what I will be working on most of the time this year. So far uMMORPG's CCU have doubled every year. Let's if we can do that again.
The MMORPG Kit developer has stolen uMMORPG code twice in the past, which is why his previous two MMO assets were both taken down from the asset store. I wouldn't put too much confidence in his work.
Why is it not viable to put everything into one scene? The server doesn't really care. It cares way more about how close players are to each other and how much it has to broadcast. The only real limitation are floating point inaccuracies. If I remember correctly, notch once talked about how this affects minecraft. You had to traverse a distance equal to at least one surrounding of earth's surface before glitches would happen. So.. very unlikely.
As for CCU: valid point. The 500 CCU worst case test was successful. This should translate to 1000 CCU real world - that's my guess anyway. Will proof this with a community test and a larger map soon.
How much more CCU will we need? 1000 are definitely enough to be swimming in cash if your game becomes that successful. If you release 2 years from now then that's two years of processor hardware and Unity software improvements, which should easily make up for an additional 10% CCU for free. A lot can be done with Mirror/Telepathy in two years as well. So far we doubled CCU every year. If we manage to pull this off once more, then we'll be at 2000 CCU.
I am definitely optimistic. Indie MMOs don't fail because of CCU. They fail because they become so complex that the developers can't finish them.
You can use World Streamer or Sector, but you would need to do some of the leg work, but also allow streaming to be client base, and have the server handle the entire terrain by having it loaded. the streaming, would be client base. So not to bad to do, and I don't find myself to be a networking Guru, but I know about the streaming aspect fairly well. but there are many ways to do and handle it. but you would need to write something for this. I also asked about his zone tool, which would be wise to have it working with streaming like Sector /World Streamer. it would make people more so wanting to buy it. I know AVATISM did this as well. This is the part many people are unsure of or afraid of , on how to handle as more people are wanting to do it.
UNREAL is pushing more in the Blue Print to handle massive amount of people with adding more of what Fortnite can do and making it a little easier for people who don't know networking as well.. Many know, programming, art, design etc, but networking , its happens to be a different animal and many don't know as well. I know many net coders who don't know art, design and game play, programming etc. So having more tools for networking, makes it that much better for everyone. This is the part that many struggle with and ask about, from what I see. even a lot ask about streaming for single players. anyways.. best of luck!
For me it seems that you are trying to achieve your idea of an MMO with your asset, which is pretty much not an MMO at all, or at least you don't see the issues in designing your game with only one scene / zone.
Your are adding so much WoW-Like stuff to it, but comparing it to Minecraft regarding level / scene design?
WoW, GW1,2, Tera, ESO, Ragnarok, FF14 are MMOs, all AAA but anyway. All have and need to use multiple scenes. Minecraft isn't a MMO. It would more fit to your uSurvival asset.
You can't design a MMO without having to use more zones / scenes. Floating point is one issue, but when using realtime weather and lightning effects for different scenes you can't put them into one scene. Did you ever put two terrains in one scene without streaming? Like one above the other using different Y coords? Design tools like GAIA, CTS, RTP will not work.
We are talking about Design / Asset perspective and Unity approach here and not about what the Server wants or makes the networking more easy. Normally you design your Zones / Terrain / Scenes and put the Network feature into it. It's impossible to merge them all into one scene because ummorpg tells you so or because it simply comes with some restrictions. I know that you designed the NetworkZone for this, but again it seems just to be a temporary workaround and not a multiple zone / scene solution for the future with all the MMO features you need. (Seeing Master Servcer Concept)
It also seems that you are not aware of the Unity 4GB Resource restriction of Unity per scene:
When creating a big scene - which you will have to do with your restriction - using more than 4GB of resources / assets will results in texture errors. You have to use more scenes or Asset Bundles. This issue is still not fixed from Unity side.
For my MMO the most important points are instances and CCU. Having playerhubs (the big main cities) where the maximum of CCU can come together (take your demo scene as example). When leaving the Playerhub all the zone should be instanced to a specific number or party size, like other terrains which you explore alone or with a party, or dungeons where you need 5, 10 or 25 gamers. All as separeted scenes with loading screens. Mostly like GW1 that time.
This it seems I can only achieve with your NetWorkZone scripts but living with the restrictions you described above, which is sad and a bummer.
I see uMMORPG as a very valuable asset for learning. It will help you build the prototype very fast. But in the end, you have to handle your own game. You may probably end up rewrite or extend some or many parts of uMMORPG to fit your need because each game has different feature set and detail. You will have to find solution to overcome the limitation of this asset if it doesn't support out of the box. This is why I encourage you all to join Mirror Discord. https://discord.gg/N9QVxbM (It's also in the link of vis2k signature). If you count the resource available for Mirror then this asset becomes a very powerful product
I think that the real strength of this asset is Mirror and its community. In my opinion, the most important feature especially in MMO is network framework. So, a stress test result is very important. You can have game features as many as you like but if your network framework is not stable and can't handle many CCU then your game will fail. The biggest different about Mirror and UNET is that the developers of Mirror actually use it to build their game. Unity use UNET only for their demo showcase. That's why they don't know (or don't care) how crappy their network framework is. Mirror has been improved on a daily basis. If they find some bottleneck or bug then they will try to fix it immediately. People who use it can help debugging because it's an open source. So, the bug fixed is very fast most of the time.
There are many good things in Mirror discord. It has a free open source add on for Mirror to create Master Server which is based on https://github.com/alvyxaz/barebones-masterserver It's still in an early development but you can talk directly with the developer in discord. He also plans to support basic Matchmaking. There are also other transports available such as udp, steam and webgl. I've read that some people can successfully use NAT punchthrough with udp inside Mirror. People in the discord are very helpful. There are experts who you can discuss with about network or other programming topic. I also suggest that if you don't mind about paid solution then you should consider a back end service like PlayFab, GameSpark or GameLift etc
Thanks mate, I forwarded your post to the Mirror developers channel. We are glad that you like it!
Completely concur with this Ronny, and I hope we can eventually see some progress made towards making uMMORPG more instance/zone friendly (either via vis' work, or from some addons).
Isn't the whole issue of having different zones on the same server just a matter of putting players in different lists?
The server has a list of all players, basically. This is what enables chat with anyone online, for example. It's the global list.
Then for each player zone you want to have, you create a new list. Anyone joining the zone is added to the zone list, and upon leaving is removed from the list. This would apply whether the zone is an instanced dungeon or city or open zone.
Any zone list should have a maximum, whatever number you want to pick, but something that gives enough players in the zone for fun interaction, but also is responsive enough (not under too high of a load). When a zone list gets to the max, the game should create a new list for a new instance of that same zone, and put the new players in it. Then you have City 1 and City 2, which are the same city, just different player lists, and if you've created a mechanism to do it, players can move from City 1 to City 2 and vice versa to play with friends. Players in City 1 see each other and interact with each other, and the same for those in City 2, but they can't see the players in the other city, except via the global player list.
Likewise, when zone lists (like City 1 and City 2) get closer to empty, an algorithm should try to combine the zone lists by sending all new players to the first zone (City 1).
Possibly this all falls under the customization for each individual game.
I like your idea, hopeful. Always thought the same.
Well you can use your idea for every game as a start with just a small customization, if you ask me. If you support Min / Max User parameters (List Size) for every zone you can define by yourself when and if zone should get instanced or not. When adding a max size of 1 million the zone should never get instanced. Gamers who want to have instanced player zones like max 200 gamers per zone (and then another instance is generated like in your idea) can define that by using max size 200. The whole point is having something like that for the start.You could have a simple ENUM class with the zone types like 5Dungeon = (1,5), STORMWIND=(1,500) etc. and then just add the type to your zone / scene. With this you would have reusable min, max player limitations for different zones.
Did the price for uMMORPG just jump from $80 to $200 or is that a typo ?
Yes, thats intended:
Thanks missed that earlier post....looking forward to the new instanced dungeons.Quite the jump and glad I bought earlier . Thanks vis2k for not deprecating and trying to charge existing customers a subscription fee.Been there..done that with another always being updated ie: WIP asset.....ate Ramen and PBJ for a couple days to offset the act of throwing a $50 bill out the window in lieu of accepting their contractually unacceptable scheme (for existing customers).
Is the instanced dungeons now implemented!?
Another question, since I know virtually nothing about this asset, how hard is it to put other asset characters into? There are certain ones that fit better than others?
according to the changelog they were implemented in version 1.157
Are there any videos on how the system works?
No but the documentation was extended for it:
So, the Summary right now: Z-Stacking Instances in the main zone.
I couldn't find information how to combine it with NetworkZoneScript or load a already created dungeon scene.
I'm not sure what I've described is all that different from what @vis2k is thinking of providing with instanced dungeons. We'll have to see what that looks like when it is implemented, but it sounds like players will still be in the global list, but in some way they will be in a sub list when in a dungeon.
So possibly to enable the scenario I outlined above, you don't have players appear in a global world, except virtually. (No world rendering, just UI, like a friends list and chat.) They would only enter a zone if it is what uMMORPG calls a dungeon.
Thus, City 1 and City 2, and all other zones, are just dungeons that the player switches around by whatever controls you supply.
CCUs should go up with players not in proximity to one another. So if you implement code to limit the number of players that can possibly fit into a dungeon, you should be able to keep higher CCUs.
Wellt it's implememted. See my post above. Right now the "first" version comes with Dungeons in the same one main zone as z-stacking spawned dungeon template.
How Limits will be designed we will probably see later
Ah, I see it in the notes now. I'll have to check on it, but I'm sure it will be a while (if ever), as I'm swamped.
Progress: working towards the 1000 CCU community test. I still believe the low level transport is where we need to optimize hard. Imho this is way more important than worrying about where to run the instanced dungeons.
Unity's Mono version has some serious limitations. We can't use anything 'async' for MMOs because it only scales up to around 50 CCU and results in 120 second lags afterwards.
Telepathy uses 2 threads per connection right now, which scales up to some point. But even with that approach, Unity's Mono version seems to have some internal limits at around 1200 threads and / or connections.
We are currently researching different transport approaches that don't use Unity's Mono backend. Here is a screenshot of my 'magic-transport', which scales significantly. I believe it can scale to 10k+ CCU easily, which means that Unity's Mirror/uMMORPG main thread is now the next bottleneck (which is good - it means that we are not transport limited anymore).
As you can see in the picture, the magic transport results in half the latency, which is very good. I believe the remaining 400ms latency are caused by Unity's main thread choking up on so much work.
I am still doing lots of tests with the magic transport, and can't make any promises yet. As mentioned above, it works around Unity's Mono backend - which means that there is quite a lot of magic happening. I am not yet sure if I will ship this with uMMORPG by default.
That was intentional. Trying a few different prices because it's feature complete now.
Depends on what you want to change.
Environment, 3D models, etc. should all work.
Things like player controllers / inventory need to work over the network and with Mirror - which is very difficult to get right.
Dungeons already have an instance limit. So you can set a hard limit like '10' per dungeon type to not prepare for the worst case.
Okay, I tried the demo scene, formed a party, and was able to use the portal for the dungeon instance. It did indeed teleport the character to z+500, using the z-shifting strategy.
I'm trying to think of a way around it now. Possibly there is some easy solution. I can't follow this example literally, as the visible areas of my zones are large, including high altitude views and movement in outer space, and I design around the idea of staying close to the origin so I get as little jitter as possible. Having a network design with core logic that pushes game scenes away from origin will force small zones, few instances, and close camera far planes, limited procedural generation, etc. It won't work for me. I have to find a sneaky way for each instance to operate from the origin, or not use this tool.
I don't know how uMMORPG organizes its server functions, deciding which request to process next. But if it is natural to process each instance's requests in a batch before moving on to the next, then it seems like instances could all reside at origin and be switched off and on as needed by the scheduler. The neighbor-detecting algorithm could be altered to recognize that only coordinate neighbors in the same instance are neighbors.
News: people said uMMORPG was too expensive. It is now available for $20 on the Asset Store! Enjoy.
Sorry but I don't fully understand which problem you are talking about. Can you explain further?
$20 seems a bit low, but my mommy taught me how to take yes as an answer.
Bought @ $20.00
$20 is to low for what you are getting. I think $120-$200 is a safe bet now that you have instances implemented.
SickaG is correct. $20 is too low.
I was thinking about how uG could be monetized. This may have been suggested before, but once you have all the basic systems in simple form, you could code some more advanced systems and sell them as add ons. Take a look at how Jason Booth monetized MicroSplat. MicroSplat is free, but has nine add ons at about $12 each. Then he sells MegaSplat which is sort of a high end MicroSplat.
You could price uM at a modest price, then make additional money by selling add ons. And, down the road, you could release a uMMORPG Pro, with all the addons integrated, at a higher Pro price. The indies who comprise your base could still get on board with the original uMMORPG package. Those who want more, can pick and choose from the add ons they want, and people like myself, well, I would probably buy uMMORPG Pro to start.
Just thinking out loud. I want you to be financially successful, so you and your assets will stay around for a long time.
sub fee? what assets charge sub fees? now if they charge upgrade fees that is common//./ we can't expect asset dev to not make a living... if that is what your talking about.... many assets drop off, because they are working for free after awhile...so they charge 10-20 dollars for a upgrade fee...if we bought it else where it would cost way more... so Unity users need to understand this, so we don't scare off, asset developers ...( just saying.... 10 -20 bucks for a yearly upgrade is nothing, and its not required. I see many people throwing a fit about this with bad reviews of some assets, but more need to understand it cost them money, they also need to pay them selves there team and cant give free updates for EVER...... you may have to eat p & J..so should they also so you can release your game? lets think about this more... and be fair to them, they are already selling for dirt cheap LUNCH money...updates..so I see why Viz jacked up the cost and don't blame him either.... it cost money to make this stuff as a developer since the 90's...this has keep me from selling stuff on the store. because people throw a fit over 10-20 dollars upgrade, I won't work for free, nor should anyone else.. so sorry to pick on you but this is for anyone, to see, so they understand the cost more... for making a game... have a good one . and I hope you understand the cost more.(
PS: I know you never gave a bad review, most of this is not pointed to the OP of this. just commenting, so i'm clear. just making sure others understand, why the upgrade costs.. never seen a sub cost before.. here.
not here , not uMMORPG......another well known unity asset I won't name here but have certainly named elsewhere...Updates are now $100 per year or subscribing via another venue for $25 a month... existing customer or new....cost me $50 on sale originally....threw it out the window rather than get stuck paying sub fees that I never agreed to under the contract in force at time of purchase.No biggie...a few days of eating Ramen and PBJ and I bought an attractive alternative that promised in writing via email to provide updates free of cost .I work alone and things take a long time.....if I thought there would be recurring fees I'd have to rethink ever buying an asset on speculation to support the devs.
have a great day
Sure, thanks for asking!
First, I want to say that the things I noted in earlier posts ought to still work (getting more CCUs by using instances and limiting the number of players per instance, and treating all play zones as dungeon instances), so this is not a problem with that.
And having zones with large surrounding vistas ... there's no problem with that, either, as these vistas would not be rendered by clients not in those instances, so there's no issue with overlapping vistas, so long as they are not traversable by networked objects.
The main problem I think I'm going to have is with the z-shifting of instances away from the origin, and how that affects floating point coordinates. My impression is that Unity has been built around the principle that all objects created will be close to the origin, otherwise you may get jittering that comes from floating point precision issues. This shows up in a variety of areas, one of them being animation.
Here's a thread where someone is noticing animation jitter happening just 1500m from origin. If we take that as a guide, getting out to z+1500 might be a little shaky at times, simply animating characters at that distance from origin. That's still a sizeable area (a radius of 1500m), but if you are running a few instances, it can get chopped up quick, I imagine, and that means small instance sizes.
If your game focuses on walking around, as in the demo, small instances are going to be reasonable for players. But if you are using vehicles, then you are going to want to use a larger play area.
When I first began considering networking options, I concluded that I'd need to keep every instance at origin. On the server side, the server doesn't need the client's meshes and shaders at all, but just a physics world, colliders, and a navmesh. The server could keep each of these rooted at origin, but in effect juggle them, using the proper physics world, colliders, and navmesh for each instance. It seems to me that so long as the contexts for the server objects aren't jumbled, you can have everything operating at origin.
(This post went through some editing ... if you were reading during the editing process and got confused, my apologies!)