Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
Unity 5
Kayyd
Member UncommonPosts: 129
The February video was a huge upgrade to the look, and I know the development team has been talking about the conversion to Unity 5. They said an update is coming, but In the mean time I was wondering, is there any information or examples to show what the improvements in Unity 5 might look like?
Comments
Right now the 3 games I am tracking are CU, Crowfall and Pantheon. If all actually develop as planned I likely would only play CU and Pantheon but the development projects of all 3 interest me.
2 of the games are being developed on Unity 5. This offers far faster development as one would expect but as mentioned here it also comes with problems inherent to mmos. I really am interested to see the fruits of their labors.
CU: Custom engine, custom net code designed entirely for their mass combat RvR needs. This is going to solve a hell of a lot of problems in the future for them and allow the game to scale to the size and performance they desire. Drawbacks? We have no idea how long the design and testing of this engine will impact development time and cost.
Crowfall: How big can this game scale? What net code is going to be used? How will this impact it's open pvp concept?
Pantheon: Similar to Crowfall but sue to being mostly pve driven, how big can the world become before we see Vanguard-like issues? If open world pvp flagging or servers exist how will performance keep up on it's demands?
2 of the games will have pre-made tools for fast development. CU is already tackling netcode and mass pvp tests long before the other games even allow more than a few online for basic testing but has nothing revealed or effectively developed yet for character and world assets. Very interesting development project parallels and differences and I await how each approach creates either different or similar games.
You stay sassy!
Whoa, whoa, whoa! That's a pretty lofty assumption (that a custom engine will be better). There are so many reasons that a custom engine is a bad idea. First and foremost, you make the assumption that you've got the best engine designer in the world!!! Oh, and you also assume that they know better than teams of a hundred people or more. Plus, with Unity and Unreal asset stores, you could probably get a whole networking framework for the same amount you would spend for one of your devs to sit in a meeting and give you their opinion on this networking framework.
Crazkanuk
----------------
Azarelos - 90 Hunter - Emerald
Durnzig - 90 Paladin - Emerald
Demonicron - 90 Death Knight - Emerald Dream - US
Tankinpain - 90 Monk - Azjol-Nerub - US
Brindell - 90 Warrior - Emerald Dream - US
----------------
I was going to post on this. I'll admit I am not a game developer but I have written network drivers and test code as well as web applications. I don't get it. For situations where you are communicating directly with other players I can see networking being a huge issue, but in a client/server situation there are many robust and highly efficient tools to quickly build whatever you want. I wouldn't see lack of network code as much of a barrier in the current development environment so full of code to use to build client/server communications.
If there are problems with multiple players on the screen, that sounds like more of a rendering problem to me, but again what do I know I'm not a game developer.
... or maybe Daniel Krenn (Sarudan) could inform us about that if he is available.
Its probably a lot more complicated as more players are involved, rendering is just a client issue after all, on the server side it probably includes load balancing, though i doubt its as simple as that. But if Unity 5 doesn't have it, and their struggling to implement it, i'd definitely wait it out and see if they sort it out themselves before buying into anything, its a fairly significant issue, all things considered.
I make no assumptions. You do however.
You do not know who programmed the engine or his resume (one of the best in the industry as touted by other lead programmers). You do not know the results of their tests and it's performance benchmarks. You are not aware that NO engine exists for lease or buy that offers even the minimum performance demands they have set out for this game.
The game is in tech alpha which mean engine and tech testing (is also runs Nvidia full server side PhysX, Turf Effects and Waterworks). They have had many tests with 1000+ players on screen using high poly models and effects which ran above 30fps with no server crashes on current to older client hardware.
And you think this does not allow better future scaling with content and design? You be crazy dude.
The issue isn't what this engine can do. It is simply how much time and money it will cost them to make it in the long run within the project scope. Money likely isn't the issue as they keep getting pledges at increasing rates with every major reveal. I suspect When beta and more actual world assets are shown this will increase more as legitimate hype is earned (engine and tech testing isn't for everyone as it doesn't reveal anything of the actual game itself). Time is the issue because time costs money once a project is under way and time in finite for many other reasons such as scheduling, contracts and distribution planning.
Nearly everything is being designed with performance in mind. This also goes for characters, clothing and armor design:
David Hancock (programmer):
"A high-level view of the actual process of building one of our characters involves taking a lot of mesh data (or binary soup) provided by the art team, choosing specific bits based on priorities, and then layering determined by a higher-level system. Examples include the visual bits a pair of pants defines, or the basic nude undermodel for your character. Then we produce a single optimized model and its LODs (Level Of Detail meshes, used for rendering at a distance) for our rendering pipeline. We also take the different pieces and their respective underlayers and atlas their materials into a single texture for the different channels needed to render them that we care about, such as diffuse (the primary color you see), normals (a directional vector off the surface model that determines a number of things, but is primarily used for lighting), and specular/opacity (How shiny or transparent it should be).
After all of that, we end up with a model we can display and animate to the player. The primary goal of all the combining, optimizing, and atlasing is to reduce the cost of rendering characters, which is critical to our goal of a system that can support not just a handful of characters, but hundreds in the same place at the same time."Any mmo built upon Unity 5 will start to look like a game very fast. It has all the developer tools already built in to launch a game quickly. What they have to do on top of this is build the net code to support their concept. Unity 5 has ZERO precedence thus far for this being done on a level Crowfall or Pantheon demands. That is their risk and it is in no way a lesser risk than the on CU is facing.
I've looked into the backgrounds of the developers of all 3 projects and nothing leads me to believe any of them lack the expertise to at least understand the fundamental challenges they will face based on their design decisions thus far. I've heard good things about Unity 5 but also clearly see the reason why CSE chose to go with a custom base engine fully under their own control from the ground up. I doubt either myself or you are technically experienced enough to truly debate these choices. I leave it to them to progress and am patient enough to see how it all plays out.
Seeing this is a Pantheon forum I should mention it specifically I suppose.
The devs appear to love the engine and I know the world won't be seamless but they seem confident an old school approach to world building is possible. Developers did it in the past with truly archaic tech so I am less concerned about Unity 5 than with Crowfall. What I can't grasp yet is the scale Crowfall is truly attempting, how many players on screen at once they really are planning and how well their time limited shards will emulate an RPG-like world. Their scale may not cause issues if small enough but then it may not meet my demands for what an RPG world should be like.
You stay sassy!
I see, I was differentiating server side code from networking code. The only thing the network code needs to do is pass data from client to server and server to client. There is robust mature technology to do that very efficiently. The server on the other hand has to track everyone in the zone and update the clients of all the players with the locations, facing, customization data, and actions of all the other players. The amount of data per player is relatively small, but updating N players with data from N other players is an N square problem and so would become exponentially more work as payers were added to the zone. However, it would seem to me to depend on how many players are in the zone, not how many are on any given players screen.
This makes sense to me. The challenge in having lots of players characters on the screen is primarily a rendering one. Each character has customizable appearance and equipment. All those 3D objects have to be positioned, scaled, oriented, layered, textured, and lit in real time. That is a massive task and it would make sense to try to do as much as possible to "bake" the character so you do as little as possible on a frame by frame basis.
The challenge with networking code is not the communication itself. The real fun starts when you need to adjust everything that can move based on the information recieved. This is done with various techniques, but basically the server has to run the true emulation and send that information to its clients so they can adjust.
So all clients run their own emulation in real time, based on the last known state from the server. Since there is always a delay between clients and server (ping time), clients need to depending on the case re-run the simulation from a state in the past or in other cases simply adjust objects to their new states.
Clients and server must run the same simulation engine, so that from any given state the outcome of both client and server will be the same after one second. You can then make server hold a history of states for everything, and then when it receives an action from a client it can roll back time and rerun the entire simulation with the new information added, then finally adjust the actual state and notify its clients of the change.
One way to to it is to say that clients run in the future and server in the present. Clients future is the is present+ping. This means what you see on the screen is the best future prediction you have, and the actions you do will most likely reach the server around its present time, as to have the least amount of re-simulation backwards in time.
So you shoot a fireball at a moving target.. The moving target is shown to you at its probable state/position, so unless server notifies you that it has changed (if it is a player or other less predictable object), and because you are running the same simulation as server just forward in time, things (simulation) will match up and server will acknowledge your hit.
But what to do if your fireball miss? You already started the animation and the fireball is in the air.. Do you wait for acknowledgement from server before showing the explosion?, do you make an explosion that can be interrupted? What about hit animations, sound feedback and so on. For every case you need to decide what look and feel most natural to a player and it is always a tradeof.
These things obviously gets harder and harder to control the faster the game objects can move and the amount of less predictable objects there are..players, physics, ai, etc. The solution to end it all is ofcourse zero ping (or something close, like < 20ms).
Anyways Unity.. From the limited knowledge I have, it seem like many dynamic changes to a simulation will be a challenge, since doesn't seem to expose very much of its internal engine to change things. I would imagine you needed to create an external simulation module and override some of Unitys own simulation, effectively making Unity a display engine..which possibly other engines or self developed ones does more effeciently. This purely guessing, and even if my guess is correct, maybe the other advantages Unity offers makes up for it. Also lets not forget what Vanguard was build on (a modyfied Unreal engine) and that caused them plenty trouble, so I got a feeling mr McQuaid has some reservations about going that route again.
"I am my connectome" https://m.youtube.com/watch?v=HA7GwKXfJB0
Makes sense. What you seem to be saying is that it is a synchronization problem with trying to sync up multiple clients with each other and the server, and because of network delays that requires a certain amount of predicting what is going to happen. It also explain EQ "physics" where if you got some network delay things would start warping from one location to another, as if the client was predicting what the server would do and after a few second the server said "well really that guy is over here." I haven't noticed that as much with more recent games, probably because network delays and computing power have increased so much.
My brain always tries to differentiate what has to be rendered from the process of rendering it. What you describe is the process by which you determine the location and facing of all PCs and NPCs as well as actions they may take. The process by which you decide what is in the scene and where. Perhaps because I am only familiar with Direct X, I took it for granted that aside from providing the ability to design the 3D graphics and store objects and textures, Unity just gave you the tools to construct and manage the scene and then render it, because so much of the rest of the engine would be specific to a given game. In other words, I would have assumed the emulation you speak of would be custom code. Again, I have no idea, but I could read the Unity manual and find out.
In any event it sounds like Daniel Krenn at VRI has a bit of experience, and really in the end, if he is the one doing that work then what he thinks can be done with Unity matters more than Mr McQuaid.