Tech Director and lead programmer Andrew Meggs is spearheading the creation of our internal Unchained Engine. It’s sole purpose: to allow our players to fight epic RvR battles in a dynamic world, without the slideshows or limitations of many past games. Our objectives for this engine are:
- Maintain an absolute minimum of 30 FPS in battles of up to 500 people
- Efficiently prioritize network usage so there's minimal lag on the things that matter
- Allow extensive character customization so every player can have uniquely crafted items
- Enable dynamic, changeable, and creative player-built structures
Each update from Andrew has highlighted the continued expansion of the engine’s capabilities while maintaining an ultra-high rate of FPS, and we're still making improvements.
Engine Progression[]
April 13, 2013
CSE SmackHammer Livestream
CSE SmackHammer
April 13, 2013
https://s3.amazonaws.com/ksr/projects/486351/posts/453681/image-240284-full.jpg
April 11, 2013
April 10, 2013
April 05, 2013
First, we are currently using Unity and it's a great engine and we've really pushed it a lot. However, there are limitations with it and if we were making a PvE game, we probably would use it but based on the tests we've run on it, that wouldn't be our first choice for a live RvR game. Now, could we use it for prototyping? Yep, we are already doing that. Second, as to other engines there are both financial reasons preventing us from using some of them as well as technical concerns. On the financial side, some of the engines that are interesting want a nice chunk of the subscription fee. Since I intend to have a lower than average sub price, a large amount going to an engine maker is not a good decision. In terms of technical reasons, what it boils down to is that there are some awesome engines out there but most of them are geared to looking great even in a multiplayer game but we need them to be able to handle a MMO where RvR is everything. I'm not totally ruling out using an engine but when you've seen most of the MMOs created with the "usual suspects" they all tend to choke a bit under decent load. We need to do better than that. Is it a bit scary, yes but Andrew has built engines before so...
Source: KS Comments - April 03, 2013
As of now we are going to build the engine from scratch. We love some of the off the shelf engines out there but our focus has got to be on an engine that can handle the load of ton of players even if it means it isn't as pretty. Rendering speed trumps all in our case.
Source: KS Comments - April 02, 2013
Speaking as the guy who wrote it, it wasn't using instancing. There were 10,000 individual DrawIndexedPrimitve calls going on, plus an update to set up new bone positions for each one. Not fancy, just streamlined.
Phase two, which I'm working on RIGHT NOW, is to reduce that number of draw calls. The plan is to stream multiple meshes into a single vertex buffer, and then fire off one draw that covers 10-20 characters at a go. It's a generalization of the WAR character art system (which I wrote), in which all the models attached to a character (gloves, boots, helm, etc.) were merged into a single unique per-character mesh so it could be done in one draw. By extending that to work across characters rather than just within a single character, we'll go even further. Of course, the downside of that approach is that in order to get high performance I'll have to treat multiple copies of the same mesh as if they're unique meshes....you're saying that's the problem, but I'm saying it's the solution. :-)
Phase three is to move more of the character animation into a compute shader. I'm trying to keep as much of this off CPU as possible, because the prediction and encoding models needed to push this kind of world over the network takes a fair bit of CPU. As far as the "yes we can make this game" type of demos go, that's lower priority than some other things, so I probably won't get to do it unless the Kickstarter actually funds.
Source: Massively.com comment/Andrew
for technology purposes Camelot Unchained’s gameplay pitch is simple: a whole lot of player-controlled characters, interacting together in a world that they affect dynamically. Performance is the primary pillar supporting that — but rather than going for the highest frame rate, our benchmark is the number of players on-screen while running smoothly at our target frame rate. Gameplay and Performance are the two top-level goals of the engineering team, and if we achieve them, we’re good.
Source: Foundation Principal 12