Howdy, Stranger!
It looks like you're new here. If you want to get involved, click one of these buttons!
Quick Links
CU's Game Engine Fast and Light -Andrew
gylnne
Member UncommonPosts: 322
It looks like you're new here. If you want to get involved, click one of these buttons!
gylnne
Member UncommonPosts: 322
Comments
Haha, you beat me to it by 5 secs. I'll delete my thread to keep it simple.
If you're an RvR fan, if this doesn't excite you, nothing will!!
Sorry glynn, can't figure out how to delete mine. I'll ask a mod to lock it.
No worries Edany, you are usually the fastest.:)
Honestly, I think 5K would be MORE than enough models. That would leave a lot of overhead for better effects and lighting. Plus, those are all using the exact same model - How many different variations of models are there going to be?
I mean, realistically, are they EVER going to have 10K people on the screen at any one given time? Possible? Maybe. Probabable? Not likely. The server can obviously handled much much more than 10K on the back end, but it's a different thing to say you'll get that many people in the same viewable space at any given time.
Regardless, it's good that they are taking these factors into consideration. I'm feeling much more assured now with my pledge knowing that he can write an engine to do even that in about a week.
Reminds me of the quote by Hannibal in the A-Team:
"Give me a minute, I'm good. Give me an hour, I'm great. Give me six months, I'm unbeatable."
From a technical glance, the model used is a low polygon (300-600) from March on Oz. So obviouslly the game can easily render between 30,000 to 60,000 polygons at any one time without a hitch. That's an impressive start. I'm willing to wager that the character models found in Camelot Unchained will be within the 600-1200 poly range and will exhibit incredibly smooth animation (you can see the animator working with the footing in the original video to provide a smooth walk animation).
It's this 3d modeler/animator's opinion that we'll be absolutely fine regarding smooth graphics. If you look at March on Oz's art direction, there's a strong presence of hand painted textures.. which further reduces the need for additional polygons to provide depth.
Awesome update.
EDIT: fixed typo
Plastic, not being a techie guy your input is always nice to see, thank you.:)
I love that update, too. Can't wait to see the first CU model animated on screen, the concept arts on the ks page and in the ks video are already really nice to look at.
Technically, this game will be worlds ahead of good ol' daoc
Btw: Please keep a dark style
MMO's played so far:
UO,EQ,DAOC,EQ2,GW,ROM,WOW,WAR,AOC,LOTRO,RIFT,TSW,GW2,POE
Looking forward to: Camelot Unchained, Star Citizen
http://www.mmorpg.com/blogs/PerfArt
I find these type of updates, and the conversations they spark, far more interesting than pre-release footage of the actual game. Not that some isn't warranted, but these days, you can find almost every zone, character model, animation etc. on YouTube months before the actual release.
Here's to hoping this trend continues. I don't want to see 99% of the game before release, but am interested in development decisions and the creative process.
My main concern isn't so much with the character models as it is for the structures. If you have player made structures. You take your castle. Crafters add things to do it. Banners. Spikes. Adjusted ramparts. Defenses. They carve out a moat, add roads. Spikes, traps.. the list goes on. Then they start adding towers, with the same stuff. Then expand, and expand again. It's gonna add up.
Wonderful Van, the revolution begins.:)
Good afternoon from Andrew! Today’s Kickstarter update is a demo of some graphics tech. And it’s pretty neat, but more importantly it’s necessary. I want to talk a little about why that is. There’s a lot of good engine tech out there, so why roll our own?
First, to make something clear: We’re not going doing everything completely from scratch from the ground up! That’s would be, to put it mildly, suicidal. We’re using someone else’s physics engine. We’re using huge chunks of some very familiar open source for our UI. We’re using some industry-standard networking that allow us to run some well-known programs as part of our stack. We’re still evaluating our audio middleware, but we’re definitely using middleware.
So what are the parts that we need to do ourselves? Basically, anything that involves scaling up to a whole lot of players at once. There are a lot of engines out there that can do a great job drawing around 100 characters at once, but then they start to lag. I’ve worked with a bunch of engines and/or middleware pieces, and there’s a common reason for that limit. They’re general-purpose tech. They have a lot of flexibility in what you can do with those 100 characters. The trouble is that every bit of flexibility has a tradeoff. In programming, especially optimized game engine programming, building in flexibility adds a cost in performance. There’s a cost to figuring out what you don’t want to do. There’s a cost to every polymorphic virtual function call just to figure out that “no, we don’t need this thing on this character at this time”. There’s a cost to generic data structures that can represent any custom possibility.
For games with 50-100 characters, that’s the right tradeoff. You can spend that time. Flexibility to do what you need, right out of the box, is worth a millisecond or two every frame. But what happens when you multiply that by 10? We’re not going for 50-100 characters in this game; we want to be EPIC. That was something we struggled with in Warhammer Online, where we inherited a renderering system and licensed someone else’s animation system and used a completely stock effects system. They all had great artist-friendly tools to bring whatever vision you had into the game, but by the time you got 200 characters going at once, the total overhead meant the game wasn’t running nearly as well as I would have liked. As I mentioned in the Foundational Principles, none of the shinies mean anything if the gameplay isn’t slick. We. Can. Do. Better.
What that means for us is that we need something purpose-built. We need tech defined not by all the things it can do, but by what we can leave out for this particular game. Think of it as tossing things overboard to lighten a ship, or taking the back seats out of a race car. We’re going to do one thing, but if that’s the only thing we need to do then we can do it really, really well. One of the other programmers here saw the “Electra 10000” demo and said, “I really want to see the code for that!”
The truth is, there’s almost no code to see. But the code that’s there is the right code. It’s a small, clean, straight line that does exactly what’s needed and absolutely no more. That’s part of why it’s feasible to do this ourselves. We don’t need to spend months writing hundreds of thousands of lines of flexible code. We have a clear vision of what we are and aren’t using for this game, and we just need a few smart people to write the little bit of code that we’ll actually use. I’ve spent enough years doing this, and learned enough about the right (and wrong!) ways to put those things together, that I believe we can do that.
But that’s a bold statement to make, so we also made a demo and a video to prove it. There’ll be more of these to come over the next month.
Good afternoon from Andrew! Today’s Kickstarter update is a demo of some graphics tech. And it’s pretty neat, but more importantly it’s necessary. I want to talk a little about why that is. There’s a lot of good engine tech out there, so why roll our own?
First, to make something clear: We’re not going doing everything completely from scratch from the ground up! That’s would be, to put it mildly, suicidal. We’re using someone else’s physics engine. We’re using huge chunks of some very familiar open source for our UI. We’re using some industry-standard networking that allow us to run some well-known programs as part of our stack. We’re still evaluating our audio middleware, but we’re definitely using middleware.
So what are the parts that we need to do ourselves? Basically, anything that involves scaling up to a whole lot of players at once. There are a lot of engines out there that can do a great job drawing around 100 characters at once, but then they start to lag. I’ve worked with a bunch of engines and/or middleware pieces, and there’s a common reason for that limit. They’re general-purpose tech. They have a lot of flexibility in what you can do with those 100 characters. The trouble is that every bit of flexibility has a tradeoff. In programming, especially optimized game engine programming, building in flexibility adds a cost in performance. There’s a cost to figuring out what you don’t want to do. There’s a cost to every polymorphic virtual function call just to figure out that “no, we don’t need this thing on this character at this time”. There’s a cost to generic data structures that can represent any custom possibility.
For games with 50-100 characters, that’s the right tradeoff. You can spend that time. Flexibility to do what you need, right out of the box, is worth a millisecond or two every frame. But what happens when you multiply that by 10? We’re not going for 50-100 characters in this game; we want to be EPIC. That was something we struggled with in Warhammer Online, where we inherited a renderering system and licensed someone else’s animation system and used a completely stock effects system. They all had great artist-friendly tools to bring whatever vision you had into the game, but by the time you got 200 characters going at once, the total overhead meant the game wasn’t running nearly as well as I would have liked. As I mentioned in the Foundational Principles, none of the shinies mean anything if the gameplay isn’t slick. We. Can. Do. Better.
What that means for us is that we need something purpose-built. We need tech defined not by all the things it can do, but by what we can leave out for this particular game. Think of it as tossing things overboard to lighten a ship, or taking the back seats out of a race car. We’re going to do one thing, but if that’s the only thing we need to do then we can do it really, really well. One of the other programmers here saw the “Electra 10000” demo and said, “I really want to see the code for that!”
The truth is, there’s almost no code to see. But the code that’s there is the right code. It’s a small, clean, straight line that does exactly what’s needed and absolutely no more. That’s part of why it’s feasible to do this ourselves. We don’t need to spend months writing hundreds of thousands of lines of flexible code. We have a clear vision of what we are and aren’t using for this game, and we just need a few smart people to write the little bit of code that we’ll actually use. I’ve spent enough years doing this, and learned enough about the right (and wrong!) ways to put those things together, that I believe we can do that.
But that’s a bold statement to make, so we also made a demo and a video to prove it. There’ll be more of these to come over the next month.
-Andrew
someone beat me to it
What happens when you log off your characters????.....
http://www.youtube.com/watch?v=GFQhfhnjYMk
Dark Age of Camelot
/em hug
http://www.mmorpg.com/blogs/PerfArt
Have faith Tayah:) Of course we won't have 10,000 players at one time but the point Andrew was making is they can do this.:)
I agree. CSE needs to take a page from the Unreal Engine 3 playbook and force optimization through only rending what's visible on an individual's screen - Which, in my opinion, would include lots of topography changes in terrain to ensure it happens.
+1 I love that Bender dude's input
When designing something like this, CSE will push their poly budget almost to max to ensure that it'll be "hard" to reach that level by most engagements. That being said, most fights (other than probably relic raids or the first month after release) won't be zomgwtfmassive zerg fights.
So, you can reduce the poly budget to include spell effects and such. Spell effects are just 1-polygon planes that have a texture applied. The easiest thing I can describe it as is a more complex .gif file.
I am not sure I am getting this.
Simply put: Guy (Andrew) shows a rendering animation, the characters that are rendered multiply and continue to do so. These characters have no outside influence, meaning the characters are not controled by someone else somewhere else.
How does this proof this supports hundreds or thousands of players simultaneously in the same area?
As said not sure I am getting this......
it shows the engine can display multiple thousands characters on screen.
Buddy in the video even said its a tradeoff....have a ton of people on screen but your enviroments are boring and sparse?
so wouldint you rather have an awsome looking enviroment with say 1000 players on screen...or a dull and sparse envirment with say 5000 on screen?