I just took a look at the April 5th kickstarter blog thing. He made a mini game using Unity3d to show off networking and was excited about it? I did that in my truck, with my crap laptop, tethered to my cellphone while at work. Go to the unity3d website, check out the asset store and anyone with a hint of knowledge can do the same in a weekend. I'm not saying it's vaporware, but it's vaporware.
I have to say that what andrew meggs found as cool, making his own graphics engine, I think its solving a problem that doesn't exist and is an unnecessary risk.
There are entire companies that devote their whole existance to making videogame engines and fine tuning them. If you use their engines, you get to upgrade your videogame to the next big improvements they make with future hardware. Nvidia/Ati might invent some new great technologies and those engine developing companies will jump on the ball and take advantage of them.
Whereas when andrew meggs "finishes" his little engine experiment will he continue to fine tune it? To keep it updated with the times? Easy to work with so that content designers and artists can easily and joyfully work with it?
And in years down the road when the creme hardware is now considered old, will CSE be the ones to constantly be tuning and updating this custom engine?
And remind me again why one of the rocksolid engines aren't good enough? Because they don't handles thousands of players on the screen at the same time? This isn't eve online is it? The game will have servers with character limits will it not? People will expect a degraded experience when hundreds of characters are on the screen at the same time. This happens in PS2 at a much lower threshold than what we saw on megg's screen during his demo. Players are ok with it. It is expected.
Most of all for why I don't like this idea is, I see it as wasting valuable resources on a problem that doesn't exist, compromising on engine quality/support for a problem that doesn't exist, and where an established and fine-tuned liscensed engine is relatively future-proof and forward thinking, making your own engine is not.
With a proposed budget of $5mil, why the fuck is a tiny assed game studio making it's own graphics engine?
Basically yes it is necessary, even 50-80 people fighting in close quarters bring most of the "modern" engines to a laggy crawl. Reason is that they are made to make instanced world games with all the graphical bells and whistles. 200-400 man relic raid and you will have most of the cleints doing 1fps while crashing half the machines outright
That matches my recollection of DAoC, and yes it's a game breaker.
There are really only three good reasons to license a game engine rather than building your own.
1) You want to make a fairly generic clone game, so existing game engines will have nearly all of the capabilities that you need.
2) You don't have anyone on staff capable of making a game engine.
3) You need to have an early pre-alpha build that you can show quickly, to make it look like you're making progress.
Of course, #1 is a good reason to cancel the project outright rather than licensing the game engine, and #2 will greatly restrict what you can do with your game.
Every game engine is built to do particular things that the engine designers think that a lot of games will need. If you want to go off the beaten path and do something unique, then no game engine will have the capabilities that you need built in. At that point, you basically have three options.
1) Abandon most of the cool things that you wanted to do with your game and settle for what off-the-shelf game engines can do.
2) Write your own game engine.
3) License a game engine, buy access to the full source code, and heavily modify it to do what you want.
I hope you're not advocating #1. Because you should never advocate #1 as a gamer hoping someone will make cool games for you to play. #1 is really only acceptable as a first project for an aspiring game designer to get his feet wet before moving on to something more ambitious.
That leaves us with making your own game engine or heavily modifying an existing one. The latter option is expensive, however, and can easily cost more than making your own.
Remember that if you make your own game engine, then you just happen to have someone on staff who understands exactly how everything in it works: the person who wrote the game engine in the first place. If you license an existing game engine, you have to put so much work into figuring out exactly what it's doing so that you can optimize it for your particular game and change it to do what you need that it's far from clear that this will be less work than just making your own game engine. Licensing a game engine certainly lets you get started faster, but it will slow you down later when you create bugs by modifying one part of a game engine while misunderstanding how it interacted with another.
-----
Making your own game engine isn't that expensive. I read somewhere that Hero Engine has 60 shaders built in. I haven't seen those 60 shaders, but a typical shader may be about 20 lines of code. Of those 20 lines, maybe half will amount to declaring variables. (More technically, declaring which uniforms the shader needs access to, which inputs it will read in from vertex data or a previous stage, and which outputs it will pass on to the next stage.) So you've only got maybe 10 or so real functional lines of code. Multiply that by 60 shaders and you have, well, not really all that much code.
And that's intrinsic to the way shaders are done. You have to execute shaders hundreds of millions of times per second. Now, that could be 10 million shader invocations per second for this shader, 50 million for that one, 100k for this other, and so forth. But in total, you're easily looking at hundreds of millions of shader invocations per second. If your shaders are 200 lines long, you have a problem. You can have some longer shaders that don't get run that many times, so there isn't some fixed cap. But most of your shaders are going to need to be short.
Now, that's not to say that writing shaders is easy. While you might have 10 or so functional lines where the real computations are done, they're very dense lines. For some purposes, you might have more comments than code. And figuring out how to do the code is very mathematically intensive. An excellent understanding of linear algebra and multivariable calculus is basically the entry level, you can't do anything without this for 3D graphics. That's not "passed a class in it once". That's "would have a good chance of acing a final that would be unreasonably difficult to give to normal students" worth of excellent understanding. Well, you don't actually need everything from linear algebra and multivariable calculus, but you do need a good chunk of each. And quite a bit of higher mathematics is useful to know, too.
Here, let me give you a quick example with the comments removed:
If you can parse that, then good for you. And if you can't, well, I probably wouldn't, either, if I hadn't written it. Video cards have no clue what a shader is trying to do at a high level. They just run the desired instructions as quickly as possible and let the programmer worry about whether it's what he wants.
Shaders are also very performance sensitive, so it's critical that you heavily optimize them to do exactly what you need and nothing more, and to do it as efficiently as possible. Some chunks of code will only run once in a while, or even once per frame. If those run a little slower than they could, oh well. But when you need something to run many millions of times per second, taking a microsecond longer than necessary is a problem.
Now, you might say, why am I focusing on "shaders"? What about the rest of the game engine? You know what the technical name for the portion of a game engine that runs on the video card is? Shaders. Everything else runs on the CPU.
Now, there is a good chunk of work in setting up data on the CPU to pass to shaders, and in the rendering thread that directly passes that data to the video card. For the latter, think thousands of lines of source code--as opposed to tens of thousands. Most of what the rendering thread has to do isn't nearly as dense as shaders, though, and there is a lot of copy and paste. Much of it is just passing through data set up by other threads.
So while writing a graphics engine isn't necessarily easy, neither do you need 10 employees working on it. All you need is one good one. For that matter, if you try having 10 people work on the DirectX/OpenGL and HLSL/GLSL portions of the game engine at once, they'll probably trip over each other so much that you just get a huge mess. It's easy to have a bunch of people working in parallel on creating art assets. The graphics engine part of a game, not so much.
There is the problem that artists can't really do much until a good chunk of the game engine is already done. But that's easy enough to handle: if you're going to make your own game engine for a game, you don't hire 50 artists the day you start work on the game. That's as wasteful as hiring a bunch of customer service representatives a year before the beta starts. You get the game engine in place with a handful of employees, and then you hire the artists later. If you only have 3 or 5 employees for the first year, that's not outlandishly expensive, even on a $5 million budget with a game that will have dozens of employees by launch day.
-----
You might think, but wouldn't licensing a game engine get you a better quality engine, because you can license one from the people who are the very best at it, not just who you have on your staff? But it's often the other way around. The engine that they create for Camelot Unchained won't be nearly as good as, say, the Unity Engine, for the games that Unity is used for. Other games will need lots of things in a game engine that your particular game doesn't. If you're making an engine for one particular game, you include the features that your game needs, and not the features that you don't. That lets you completely skip tons of stuff--and thereby avoid a bunch of unnecessary bloat. Making an engine for a particular game is vastly less work than trying to make a general-purpose game engine.
Furthermore, there's a general principle that a given amount of effort to create a tool to do one particular thing will often get you something much better at that one particular thing than putting the same amount of effort into a general-purpose tool and using it for that one purpose. If you compare some random tool to a Swiss Army Knife, the latter can do a bunch of things that the former can't. But the Swiss Army Knife won't be as good of a screwdriver as a dedicated screwdriver that can't do anything else besides turn screws. It won't be as good of a pair of scissors as a dedicated pair of scissors that can't do anything else besides cut flat surfaces between its blades. It won't be as good at any particular purpose as a single-purpose tool built for that particular purpose.
Or to take another example, a CPU is a general purpose tool, and a GPU is more special purpose to handle specific types of computations. A CPU can do all of the computations that a GPU can do. You can write a software renderer that is fully OpenGL 4.3 compliant without even having the video card do any work other than pass through the completed image. But you don't because it will kill your performance. Even if you've got an extremely high end, $1000 CPU and a $70 budget gaming card, offloading work to the GPU properly might increase your frame rates by an order of magnitude.
In order for a game engine that you make from scratch to be better for your particular game than a game engine you could license, you don't need to have someone in-house who is just as good as the people who make off-the-shelf game engines. You only need someone in-house who isn't really all that much worse than they are. You'll get a ton of mileage out of being able to optimize for your particular game, rather than trying to create a bunch of general-purpose capabilities without knowing how games can use them.
Originally posted by Kuppa And to all the folks talking about the gw2 culling issue, it wasn't a graphical problem it was netcode.
GW2 is exactly what I don't want to see, regardless of the culling. All of your enemies are clones of one another. You're not actually seeing the other player's avatar. Totally ridiculous and a huge step backwards.
Originally posted by Kuppa And to all the folks talking about the gw2 culling issue, it wasn't a graphical problem it was netcode.
Guild Wars 2 still has a variety of culling bugs, most or all of which are graphical problems. They just fixed one particular culling bug that was network-related.
Culling shouldn't be a dirty word in game engines. Any respectable game engine will cull things in a bunch of different places for a bunch of different reasons. Your performance will be absolutely terrible if you don't. The basic principle is that if you can figure out that continuing to process some data won't affect the final image that appears on the screen, then you cull it--that is, you stop processing that data. You do that CPU-side for several different reasons, and then GPU-side at several different places in the graphics pipeline.
Culling only becomes a bug if you do it improperly, and cull something that should have appeared on the screen.
Originally posted by Kuppa And to all the folks talking about the gw2 culling issue, it wasn't a graphical problem it was netcode.
Guild Wars 2 still has a variety of culling bugs, most or all of which are graphical problems. They just fixed one particular culling bug that was network-related.
Culling shouldn't be a dirty word in game engines. Any respectable game engine will cull things in a bunch of different places for a bunch of different reasons. Your performance will be absolutely terrible if you don't. The basic principle is that if you can figure out that continuing to process some data won't affect the final image that appears on the screen, then you cull it--that is, you stop processing that data. You do that CPU-side for several different reasons, and then GPU-side at several different places in the graphics pipeline.
Culling only becomes a bug if you do it improperly, and cull something that should have appeared on the screen.
Culling is a tool. Like all tools if you use it incorrectly you're not going to get a good result.
Also, I'm not a game dev (I do Enterprise ERPs and DW/BI), but the gfx engine is only one part of the client. If they choose to go custom, they are taking on Networking/Comms, data management, UI's, asset formats and related tools, debug/profiling tool development, distribution/patching and packaging, version control, Customer Service interfaces, logging, web interfaces, 3dMax/Maya plug-ins, scripting engines, etc etc etc. You're in the industry, is that not accurate? Seems to me that is a LOT of re-inventing the wheel for a small team on a small budget.
OP didn't think about anything before he posted apparently. Almost every new mmo has had engine issues when they attempt to put a large amount of players in the same area.
Originally posted by Kuppa And to all the folks talking about the gw2 culling issue, it wasn't a graphical problem it was netcode.
Guild Wars 2 still has a variety of culling bugs, most or all of which are graphical problems. They just fixed one particular culling bug that was network-related.
Culling shouldn't be a dirty word in game engines. Any respectable game engine will cull things in a bunch of different places for a bunch of different reasons. Your performance will be absolutely terrible if you don't. The basic principle is that if you can figure out that continuing to process some data won't affect the final image that appears on the screen, then you cull it--that is, you stop processing that data. You do that CPU-side for several different reasons, and then GPU-side at several different places in the graphics pipeline.
Culling only becomes a bug if you do it improperly, and cull something that should have appeared on the screen.
Culling is a tool. Like all tools if you use it incorrectly you're not going to get a good result.
Also, I'm not a game dev (I do Enterprise ERPs and DW/BI), but the gfx engine is only one part of the client. If they choose to go custom, they are taking on Networking/Comms, data management, UI's, asset formats and related tools, debug/profiling tool development, distribution/patching and packaging, version control, Customer Service interfaces, logging, web interfaces, 3dMax/Maya plug-ins, scripting engines, etc etc etc. You're in the industry, is that not accurate? Seems to me that is a LOT of re-inventing the wheel for a small team on a small budget.
There are plenty of asset management systems, and if we're talking source control there's git/svn etc.
Anyway, considering the team will get much larger if it funds, I don't think it's that big a problem. And they are already planning to use other people's stuff wherever applicable. (Blink/webkit, whatever physics system they are using, etc)
You can write an import/export plugin for 3dsmax in no time, to be honest. It's a really clean API. Or used to be. You could easily get an intern to do that. Not going to be an issue.
Originally posted by Kuppa And to all the folks talking about the gw2 culling issue, it wasn't a graphical problem it was netcode.
Guild Wars 2 still has a variety of culling bugs, most or all of which are graphical problems. They just fixed one particular culling bug that was network-related.
Culling shouldn't be a dirty word in game engines. Any respectable game engine will cull things in a bunch of different places for a bunch of different reasons. Your performance will be absolutely terrible if you don't. The basic principle is that if you can figure out that continuing to process some data won't affect the final image that appears on the screen, then you cull it--that is, you stop processing that data. You do that CPU-side for several different reasons, and then GPU-side at several different places in the graphics pipeline.
Culling only becomes a bug if you do it improperly, and cull something that should have appeared on the screen.
Culling is a tool. Like all tools if you use it incorrectly you're not going to get a good result.
Also, I'm not a game dev (I do Enterprise ERPs and DW/BI), but the gfx engine is only one part of the client. If they choose to go custom, they are taking on Networking/Comms, data management, UI's, asset formats and related tools, debug/profiling tool development, distribution/patching and packaging, version control, Customer Service interfaces, logging, web interfaces, 3dMax/Maya plug-ins, scripting engines, etc etc etc. You're in the industry, is that not accurate? Seems to me that is a LOT of re-inventing the wheel for a small team on a small budget.
They don't have to re-invent the wheels for many of the things you mentioned, you can just get external lib's for each if you need to, and with experienced people its generally just a case of setup and go. Writing a custom GFX engine doesn't take as long as some people make out (for experienced people), but writing a engine with verbose tools such as ones found in Cry Engine / UE / Unity is generally a long task, this is generally why you see many developers use them, the tools are amazing.
The issue is the MTU limit, this is what holds backALL MMO GAMES from rendering masses of individual characters on screen (notice how gw2 change to basic models, hmm why ?) it's a hardware technology limitation, that's all there is to it. Some games can get away with more or less characters depending on their display/update system time requirements, but when you hit the limit, that's it.
Originally posted by Kuppa And to all the folks talking about the gw2 culling issue, it wasn't a graphical problem it was netcode.
Guild Wars 2 still has a variety of culling bugs, most or all of which are graphical problems. They just fixed one particular culling bug that was network-related.
Culling shouldn't be a dirty word in game engines. Any respectable game engine will cull things in a bunch of different places for a bunch of different reasons. Your performance will be absolutely terrible if you don't. The basic principle is that if you can figure out that continuing to process some data won't affect the final image that appears on the screen, then you cull it--that is, you stop processing that data. You do that CPU-side for several different reasons, and then GPU-side at several different places in the graphics pipeline.
Culling only becomes a bug if you do it improperly, and cull something that should have appeared on the screen.
Culling is a tool. Like all tools if you use it incorrectly you're not going to get a good result.
Also, I'm not a game dev (I do Enterprise ERPs and DW/BI), but the gfx engine is only one part of the client. If they choose to go custom, they are taking on Networking/Comms, data management, UI's, asset formats and related tools, debug/profiling tool development, distribution/patching and packaging, version control, Customer Service interfaces, logging, web interfaces, 3dMax/Maya plug-ins, scripting engines, etc etc etc. You're in the industry, is that not accurate? Seems to me that is a LOT of re-inventing the wheel for a small team on a small budget.
There are plenty of asset management systems, and if we're talking source control there's git/svn etc.
Anyway, considering the team will get much larger if it funds, I don't think it's that big a problem. And they are already planning to use other people's stuff wherever applicable. (Blink/webkit, whatever physics system they are using, etc)
You can write an import/export plugin for 3dsmax in no time, to be honest. It's a really clean API. Or used to be. You could easily get an intern to do that. Not going to be an issue.
I think no one knows more what is needed for CU than the guys who's working on it, and i assume they already checked out the biggests engine outthere, and were not satisfied enough with what they offered.
So if Andrew has the knowledge to make his own, or modify one for best performances needed to have thousands of people at same time, then i guess its the right call.
not many mmos out there need to that kind of performance, as everything is instanced now.
Bowbow (kob hunter) Infecto (kob cave shammy) and Thurka (troll warrior) on Merlin/Midgard DAoC Thurka on WAR
BTW there is a another reason to build one.. lets say CU is moderately succesful well now you have somethign you can license to people, it will be special purpose but since nobody else has it you can charge decent amount for it
I have to say that what andrew meggs found as cool, making his own graphics engine, I think its solving a problem that doesn't exist and is an unnecessary risk.
There are entire companies that devote their whole existance to making videogame engines and fine tuning them. If you use their engines, you get to upgrade your videogame to the next big improvements they make with future hardware. Nvidia/Ati might invent some new great technologies and those engine developing companies will jump on the ball and take advantage of them.
Whereas when andrew meggs "finishes" his little engine experiment will he continue to fine tune it? To keep it updated with the times? Easy to work with so that content designers and artists can easily and joyfully work with it?
And in years down the road when the creme hardware is now considered old, will CSE be the ones to constantly be tuning and updating this custom engine?
And remind me again why one of the rocksolid engines aren't good enough? Because they don't handles thousands of players on the screen at the same time? This isn't eve online is it? The game will have servers with character limits will it not? People will expect a degraded experience when hundreds of characters are on the screen at the same time. This happens in PS2 at a much lower threshold than what we saw on megg's screen during his demo. Players are ok with it. It is expected.
Most of all for why I don't like this idea is, I see it as wasting valuable resources on a problem that doesn't exist, compromising on engine quality/support for a problem that doesn't exist, and where an established and fine-tuned liscensed engine is relatively future-proof and forward thinking, making your own engine is not.
With a proposed budget of $5mil, why the fuck is a tiny assed game studio making it's own graphics engine?
Have you played an RvR game before that gave you staggering lag or major culling issues when massive amounts of people were onscreen at once? Not trolling, I am genuinely curious.
I have to say that what andrew meggs found as cool, making his own graphics engine, I think its solving a problem that doesn't exist and is an unnecessary risk.
There are entire companies that devote their whole existance to making videogame engines and fine tuning them. If you use their engines, you get to upgrade your videogame to the next big improvements they make with future hardware. Nvidia/Ati might invent some new great technologies and those engine developing companies will jump on the ball and take advantage of them.
Whereas when andrew meggs "finishes" his little engine experiment will he continue to fine tune it? To keep it updated with the times? Easy to work with so that content designers and artists can easily and joyfully work with it?
And in years down the road when the creme hardware is now considered old, will CSE be the ones to constantly be tuning and updating this custom engine?
And remind me again why one of the rocksolid engines aren't good enough? Because they don't handles thousands of players on the screen at the same time? This isn't eve online is it? The game will have servers with character limits will it not? People will expect a degraded experience when hundreds of characters are on the screen at the same time. This happens in PS2 at a much lower threshold than what we saw on megg's screen during his demo. Players are ok with it. It is expected.
Most of all for why I don't like this idea is, I see it as wasting valuable resources on a problem that doesn't exist, compromising on engine quality/support for a problem that doesn't exist, and where an established and fine-tuned liscensed engine is relatively future-proof and forward thinking, making your own engine is not.
With a proposed budget of $5mil, why the fuck is a tiny assed game studio making it's own graphics engine?
I think you just answered your own question. Are not the licensing fees on using someone else's engine a large cost? You also seem to think Andrew is stupid.
Maybe look up Andrew's bio and realize this guy knows his stuff?
Don't put words in peoples mouths, the people on this forum are intellegent, this isn't fox news.
My doubt is whether andrew can:
1) dedicate enough of his time to maintain a custom engine over the years to come, doing his due dilligence to keep the game up to date with technology and..
2) Create the quality, powerful tools with which to work on the game for the various content systems. As well and efficient as the tools for other engines and..
3) Guarantee to stay with CSE over the next several years in order to maintain his engine.
I have to say that what andrew meggs found as cool, making his own graphics engine, I think its solving a problem that doesn't exist and is an unnecessary risk.
There are entire companies that devote their whole existance to making videogame engines and fine tuning them. If you use their engines, you get to upgrade your videogame to the next big improvements they make with future hardware. Nvidia/Ati might invent some new great technologies and those engine developing companies will jump on the ball and take advantage of them.
Whereas when andrew meggs "finishes" his little engine experiment will he continue to fine tune it? To keep it updated with the times? Easy to work with so that content designers and artists can easily and joyfully work with it?
And in years down the road when the creme hardware is now considered old, will CSE be the ones to constantly be tuning and updating this custom engine?
And remind me again why one of the rocksolid engines aren't good enough? Because they don't handles thousands of players on the screen at the same time? This isn't eve online is it? The game will have servers with character limits will it not? People will expect a degraded experience when hundreds of characters are on the screen at the same time. This happens in PS2 at a much lower threshold than what we saw on megg's screen during his demo. Players are ok with it. It is expected.
Most of all for why I don't like this idea is, I see it as wasting valuable resources on a problem that doesn't exist, compromising on engine quality/support for a problem that doesn't exist, and where an established and fine-tuned liscensed engine is relatively future-proof and forward thinking, making your own engine is not.
With a proposed budget of $5mil, why the fuck is a tiny assed game studio making it's own graphics engine?
I think you just answered your own question. Are not the licensing fees on using someone else's engine a large cost? You also seem to think Andrew is stupid.
Maybe look up Andrew's bio and realize this guy knows his stuff?
Don't put words in peoples mouths, the people on this forum are intellegent, this isn't fox news.
My doubt is whether andrew can:
1) dedicate enough of his time to maintain a custom engine over the years to come, doing his due dilligence to keep the game up to date with technology and..
2) Create the quality, powerful tools with which to work on the game for the various content systems. As well and efficient as the tools for other engines and..
3) Guarantee to stay with CSE over the next several years in order to maintain his engine.
Obviously Andrew is the only one that can give you answers to those specific questions, but as far as #3 he is co-founder of CSE, so I'd say he is very likely to be a part of the team for awhile.
Originally posted by Kuppa And to all the folks talking about the gw2 culling issue, it wasn't a graphical problem it was netcode.
Guild Wars 2 still has a variety of culling bugs, most or all of which are graphical problems. They just fixed one particular culling bug that was network-related.
Culling shouldn't be a dirty word in game engines. Any respectable game engine will cull things in a bunch of different places for a bunch of different reasons. Your performance will be absolutely terrible if you don't. The basic principle is that if you can figure out that continuing to process some data won't affect the final image that appears on the screen, then you cull it--that is, you stop processing that data. You do that CPU-side for several different reasons, and then GPU-side at several different places in the graphics pipeline.
Culling only becomes a bug if you do it improperly, and cull something that should have appeared on the screen.
Culling is a tool. Like all tools if you use it incorrectly you're not going to get a good result.
Also, I'm not a game dev (I do Enterprise ERPs and DW/BI), but the gfx engine is only one part of the client. If they choose to go custom, they are taking on Networking/Comms, data management, UI's, asset formats and related tools, debug/profiling tool development, distribution/patching and packaging, version control, Customer Service interfaces, logging, web interfaces, 3dMax/Maya plug-ins, scripting engines, etc etc etc. You're in the industry, is that not accurate? Seems to me that is a LOT of re-inventing the wheel for a small team on a small budget.
Some things are 10 lines of code here, 50 lines of code there, 300 lines of code for this, 150 lines of code for that, and not a big deal. Some things have code that isn't much harder to type out than paragraphs of a forum post. Even if you make a list of 50 things that you have to do, if none of them are very hard, then doing all 50 doesn't add up to something impractical, either. Other things are 10,000 lines of spaghetti code if you're good, and much, much worse if you're not. That's the sort of thing that makes you ask, "Do I really want to do this feature?" And sometimes it can be hard to tell what is what until you actually try to do it yourself.
And some things can easily be very simple or a complete mess depending on how efficient you are. I had one function in my game engine that was once about 1500 lines of code, on top of calling a number of other very messy functions to do various things. After a series of simplifications, it's now under 60 lines of code and the only external functions it calls are some very simple things that are only a few lines each.
Furthermore, some things that would be easy if you built the game around them become nearly impossible if you want to tack them on to some other game engine that isn't built for them. For example, if you want to be able to have 100 players moving around on your screen at a time and still make the game run smoothly on modern low-end hardware, it's easy to do if that's your top priority. The character models won't be very detailed (e.g., 2D sprites with a few frames of animation each can surely work; rudimentary 3D models with few vertices and few, low resolution textures probably can, too), and player movement won't be updated from the server very often, but if you build the game around it, you can make it work and it's fine. If you have a semi-turn based game where players can only move at most once every five seconds anyway, then keeping 100 players updated of what everyone else is doing becomes practical.
If, on the other hand, you take an existing game engine that is designed with very good looking models in mind and never meant to show more than 20 characters on a screen at a time and want to modify that to allow 100 players running around at once on lower end hardware, it's going to be a complete nightmare. You'll probably be better off scrapping large swaths of the code and redoing them from scratch than trying to modify code that isn't even trying to do what you're looking for.
-----
The basic principle is that, if you need to do exactly the same thing that lots of other games need to do, then you can probably find or license something to do it for you. If you want to do something different, even if it's kind of similar to what a lot of other games do, then you'll have to code it yourself.
Some things intrinsically have to be different from game to game, and you're going to have to do that on your own. Some things are sufficiently performance-sensitive that, even if you could license code to do it for you, it's a bad idea, as it won't be optimized for your particular game, so it will kill your performance. Some things are simple enough to do from scratch yourself that there's no real point in looking for an external solution. And some things make a ton of sense to either find some free code somewhere or license something to do what you want.
To answer your question directly, no, I don't work in the gaming industry. My real-life situation is complicated at the moment. I have written my own game engine basically from scratch, though. Well, at least the graphics part of it; there's a lot of stuff still missing. I was surprised that it was a lot easier than I expected. I do some really unorthodox things, though, such as making all artwork procedurally generated, rather than having art assets stored on the hard drive and loaded as needed.
-----
Reinventing the wheel is a bad idea if it's a lot of work and the wheel you'd create isn't any better for your particular purpose than some other wheel that you could get cheaply elsewhere. But if the tools that you could license can't do what you want, then maybe you shouldn't license them.
Don't put words in peoples mouths, the people on this forum are intellegent, this isn't fox news.
My doubt is whether andrew can:
1) dedicate enough of his time to maintain a custom engine over the years to come, doing his due dilligence to keep the game up to date with technology and..
2) Create the quality, powerful tools with which to work on the game for the various content systems. As well and efficient as the tools for other engines and..
3) Guarantee to stay with CSE over the next several years in order to maintain his engine.
1) Who says you have to keep your game up to date with technology? If the graphics API that you're using can do everything you want to do, then why do you need to change to a different API later? What will graphics APIs five years from now be able to do that DirectX 11.1 and OpenGL 4.3 can't do today? Probably order-independent transparency that isn't a complete nightmare to deal with, and a bunch of minor tinkering around the edges that gives you slightly more efficient ways to do old things. Anything else?
For that matter, they're still launching DirectX 9.0c games today. That's a lot more stifling today than DirectX 11 or OpenGL 4.3 is likely to be a decade from now. Or even worse, have you seen what browser-based games are stuck with using? Besides, OpenGL generally makes the new version a superset of the old, so if OpenGL 5 offers something new that you really want, you just write it in and it works. With DirectX, it's a little more complicated.
2) He doesn't need to create a bunch of general-purpose tools just as good for a bunch of other games that he's never heard of as game engines that one can license. He only needs to create tools at least as good for the particular things that Camelot Unchained wants to do as the tools created by people who hadn't heard of the game and had no clue what games mechanics it wanted when they were creating the tools. That's not a trivial thing to do, but neither is it outlandishly hard.
With a proposed budget of $5mil, why the fuck is a tiny assed game studio making it's own graphics engine?
Mr Kokibukisa, do you know how much money it costs to buy a AAA commercial graphics engine? I give you a figure range, it has 7 digits.
That would be possible cost depending on the studio and liscense but this simply isn't true for a small studio. Every engine I've seen have very reasonable liscenses. Most get paid through royalties on earnings. While looking at costs you need ot keep in mind the cost of building your own, which believe it or not almost always costs more.
Originally posted by Kuppa And to all the folks talking about the gw2 culling issue, it wasn't a graphical problem it was netcode.
Guild Wars 2 still has a variety of culling bugs, most or all of which are graphical problems. They just fixed one particular culling bug that was network-related.
Culling shouldn't be a dirty word in game engines. Any respectable game engine will cull things in a bunch of different places for a bunch of different reasons. Your performance will be absolutely terrible if you don't. The basic principle is that if you can figure out that continuing to process some data won't affect the final image that appears on the screen, then you cull it--that is, you stop processing that data. You do that CPU-side for several different reasons, and then GPU-side at several different places in the graphics pipeline.
Culling only becomes a bug if you do it improperly, and cull something that should have appeared on the screen.
Culling is a tool. Like all tools if you use it incorrectly you're not going to get a good result.
Also, I'm not a game dev (I do Enterprise ERPs and DW/BI), but the gfx engine is only one part of the client. If they choose to go custom, they are taking on Networking/Comms, data management, UI's, asset formats and related tools, debug/profiling tool development, distribution/patching and packaging, version control, Customer Service interfaces, logging, web interfaces, 3dMax/Maya plug-ins, scripting engines, etc etc etc. You're in the industry, is that not accurate? Seems to me that is a LOT of re-inventing the wheel for a small team on a small budget.
Some things are 10 lines of code here, 50 lines of code there, 300 lines of code for this, 150 lines of code for that, and not a big deal. Some things have code that isn't much harder to type out than paragraphs of a forum post. Even if you make a list of 50 things that you have to do, if none of them are very hard, then doing all 50 doesn't add up to something impractical, either. Other things are 10,000 lines of spaghetti code if you're good, and much, much worse if you're not. That's the sort of thing that makes you ask, "Do I really want to do this feature?" And sometimes it can be hard to tell what is what until you actually try to do it yourself.
And some things can easily be very simple or a complete mess depending on how efficient you are. I had one function in my game engine that was once about 1500 lines of code, on top of calling a number of other very messy functions to do various things. After a series of simplifications, it's now under 60 lines of code and the only external functions it calls are some very simple things that are only a few lines each.
Furthermore, some things that would be easy if you built the game around them become nearly impossible if you want to tack them on to some other game engine that isn't built for them. For example, if you want to be able to have 100 players moving around on your screen at a time and still make the game run smoothly on modern low-end hardware, it's easy to do if that's your top priority. The character models won't be very detailed (e.g., 2D sprites with a few frames of animation each can surely work; rudimentary 3D models with few vertices and few, low resolution textures probably can, too), and player movement won't be updated from the server very often, but if you build the game around it, you can make it work and it's fine. If you have a semi-turn based game where players can only move at most once every five seconds anyway, then keeping 100 players updated of what everyone else is doing becomes practical.
If, on the other hand, you take an existing game engine that is designed with very good looking models in mind and never meant to show more than 20 characters on a screen at a time and want to modify that to allow 100 players running around at once on lower end hardware, it's going to be a complete nightmare. You'll probably be better off scrapping large swaths of the code and redoing them from scratch than trying to modify code that isn't even trying to do what you're looking for.
-----
The basic principle is that, if you need to do exactly the same thing that lots of other games need to do, then you can probably find or license something to do it for you. If you want to do something different, even if it's kind of similar to what a lot of other games do, then you'll have to code it yourself.
Some things intrinsically have to be different from game to game, and you're going to have to do that on your own. Some things are sufficiently performance-sensitive that, even if you could license code to do it for you, it's a bad idea, as it won't be optimized for your particular game, so it will kill your performance. Some things are simple enough to do from scratch yourself that there's no real point in looking for an external solution. And some things make a ton of sense to either find some free code somewhere or license something to do what you want.
To answer your question directly, no, I don't work in the gaming industry. My real-life situation is complicated at the moment. I have written my own game engine basically from scratch, though. Well, at least the graphics part of it; there's a lot of stuff still missing. I was surprised that it was a lot easier than I expected. I do some really unorthodox things, though, such as making all artwork procedurally generated, rather than having art assets stored on the hard drive and loaded as needed.
-----
Reinventing the wheel is a bad idea if it's a lot of work and the wheel you'd create isn't any better for your particular purpose than some other wheel that you could get cheaply elsewhere. But if the tools that you could license can't do what you want, then maybe you shouldn't license them.
Thanks for the answer, and understand about the licencing. Guess we'll see how they fare when they start development.
There are really only three good reasons to license a game engine rather than building your own.
1) You want to make a fairly generic clone game, so existing game engines will have nearly all of the capabilities that you need.
2) You don't have anyone on staff capable of making a game engine.
3) You need to have an early pre-alpha build that you can show quickly, to make it look like you're making progress.
Of course, #1 is a good reason to cancel the project outright rather than licensing the game engine, and #2 will greatly restrict what you can do with your game.
Every game engine is built to do particular things that the engine designers think that a lot of games will need. If you want to go off the beaten path and do something unique, then no game engine will have the capabilities that you need built in. At that point, you basically have three options.
1) Abandon most of the cool things that you wanted to do with your game and settle for what off-the-shelf game engines can do.
2) Write your own game engine.
3) License a game engine, buy access to the full source code, and heavily modify it to do what you want.
I hope you're not advocating #1. Because you should never advocate #1 as a gamer hoping someone will make cool games for you to play. #1 is really only acceptable as a first project for an aspiring game designer to get his feet wet before moving on to something more ambitious.
That leaves us with making your own game engine or heavily modifying an existing one. The latter option is expensive, however, and can easily cost more than making your own.
Remember that if you make your own game engine, then you just happen to have someone on staff who understands exactly how everything in it works: the person who wrote the game engine in the first place. If you license an existing game engine, you have to put so much work into figuring out exactly what it's doing so that you can optimize it for your particular game and change it to do what you need that it's far from clear that this will be less work than just making your own game engine. Licensing a game engine certainly lets you get started faster, but it will slow you down later when you create bugs by modifying one part of a game engine while misunderstanding how it interacted with another.
-----
Making your own game engine isn't that expensive. I read somewhere that Hero Engine has 60 shaders built in. I haven't seen those 60 shaders, but a typical shader may be about 20 lines of code. Of those 20 lines, maybe half will amount to declaring variables. (More technically, declaring which uniforms the shader needs access to, which inputs it will read in from vertex data or a previous stage, and which outputs it will pass on to the next stage.) So you've only got maybe 10 or so real functional lines of code. Multiply that by 60 shaders and you have, well, not really all that much code.
And that's intrinsic to the way shaders are done. You have to execute shaders hundreds of millions of times per second. Now, that could be 10 million shader invocations per second for this shader, 50 million for that one, 100k for this other, and so forth. But in total, you're easily looking at hundreds of millions of shader invocations per second. If your shaders are 200 lines long, you have a problem. You can have some longer shaders that don't get run that many times, so there isn't some fixed cap. But most of your shaders are going to need to be short.
Now, that's not to say that writing shaders is easy. While you might have 10 or so functional lines where the real computations are done, they're very dense lines. For some purposes, you might have more comments than code. And figuring out how to do the code is very mathematically intensive. An excellent understanding of linear algebra and multivariable calculus is basically the entry level, you can't do anything without this for 3D graphics. That's not "passed a class in it once". That's "would have a good chance of acing a final that would be unreasonably difficult to give to normal students" worth of excellent understanding. Well, you don't actually need everything from linear algebra and multivariable calculus, but you do need a good chunk of each. And quite a bit of higher mathematics is useful to know, too.
Here, let me give you a quick example with the comments removed:
If you can parse that, then good for you. And if you can't, well, I probably wouldn't, either, if I hadn't written it. Video cards have no clue what a shader is trying to do at a high level. They just run the desired instructions as quickly as possible and let the programmer worry about whether it's what he wants.
Shaders are also very performance sensitive, so it's critical that you heavily optimize them to do exactly what you need and nothing more, and to do it as efficiently as possible. Some chunks of code will only run once in a while, or even once per frame. If those run a little slower than they could, oh well. But when you need something to run many millions of times per second, taking a microsecond longer than necessary is a problem.
Now, you might say, why am I focusing on "shaders"? What about the rest of the game engine? You know what the technical name for the portion of a game engine that runs on the video card is? Shaders. Everything else runs on the CPU.
Now, there is a good chunk of work in setting up data on the CPU to pass to shaders, and in the rendering thread that directly passes that data to the video card. For the latter, think thousands of lines of source code--as opposed to tens of thousands. Most of what the rendering thread has to do isn't nearly as dense as shaders, though, and there is a lot of copy and paste. Much of it is just passing through data set up by other threads.
So while writing a graphics engine isn't necessarily easy, neither do you need 10 employees working on it. All you need is one good one. For that matter, if you try having 10 people work on the DirectX/OpenGL and HLSL/GLSL portions of the game engine at once, they'll probably trip over each other so much that you just get a huge mess. It's easy to have a bunch of people working in parallel on creating art assets. The graphics engine part of a game, not so much.
There is the problem that artists can't really do much until a good chunk of the game engine is already done. But that's easy enough to handle: if you're going to make your own game engine for a game, you don't hire 50 artists the day you start work on the game. That's as wasteful as hiring a bunch of customer service representatives a year before the beta starts. You get the game engine in place with a handful of employees, and then you hire the artists later. If you only have 3 or 5 employees for the first year, that's not outlandishly expensive, even on a $5 million budget with a game that will have dozens of employees by launch day.
-----
You might think, but wouldn't licensing a game engine get you a better quality engine, because you can license one from the people who are the very best at it, not just who you have on your staff? But it's often the other way around. The engine that they create for Camelot Unchained won't be nearly as good as, say, the Unity Engine, for the games that Unity is used for. Other games will need lots of things in a game engine that your particular game doesn't. If you're making an engine for one particular game, you include the features that your game needs, and not the features that you don't. That lets you completely skip tons of stuff--and thereby avoid a bunch of unnecessary bloat. Making an engine for a particular game is vastly less work than trying to make a general-purpose game engine.
Furthermore, there's a general principle that a given amount of effort to create a tool to do one particular thing will often get you something much better at that one particular thing than putting the same amount of effort into a general-purpose tool and using it for that one purpose. If you compare some random tool to a Swiss Army Knife, the latter can do a bunch of things that the former can't. But the Swiss Army Knife won't be as good of a screwdriver as a dedicated screwdriver that can't do anything else besides turn screws. It won't be as good of a pair of scissors as a dedicated pair of scissors that can't do anything else besides cut flat surfaces between its blades. It won't be as good at any particular purpose as a single-purpose tool built for that particular purpose.
Or to take another example, a CPU is a general purpose tool, and a GPU is more special purpose to handle specific types of computations. A CPU can do all of the computations that a GPU can do. You can write a software renderer that is fully OpenGL 4.3 compliant without even having the video card do any work other than pass through the completed image. But you don't because it will kill your performance. Even if you've got an extremely high end, $1000 CPU and a $70 budget gaming card, offloading work to the GPU properly might increase your frame rates by an order of magnitude.
In order for a game engine that you make from scratch to be better for your particular game than a game engine you could license, you don't need to have someone in-house who is just as good as the people who make off-the-shelf game engines. You only need someone in-house who isn't really all that much worse than they are. You'll get a ton of mileage out of being able to optimize for your particular game, rather than trying to create a bunch of general-purpose capabilities without knowing how games can use them.
So here is what will happen tomorow morning at the Camelot Unchained office. Some poor sap will grab a cup of coffee, head over to the work station, pull up the mmorpg.com forum to see what is happening and read this thread. That person will spit coffee all over their monitor as they read this and call an "emergency" meeting. The jist of that meeting will be, "Why the hell would anyone want to make a game for these nerds! SERIOUSLY!! Your wall of text includes CODE!?!?!? Let's go back to making ipod games where the customers say things like 'Look! A shiny!'"
Last I checked Unity is a a free engine they are using (well they can pay $1800 for "expanded" version). What Andrew was saying is he is making his own tools for it, not actually making a whole new engine.
Could be wrong here, but that is what I got out of the videos.
Making game engines from scratch is very time/cost consuming.
There are really only three good reasons to license a game engine rather than building your own.
1) You want to make a fairly generic clone game, so existing game engines will have nearly all of the capabilities that you need.
2) You don't have anyone on staff capable of making a game engine.
3) You need to have an early pre-alpha build that you can show quickly, to make it look like you're making progress.
Of course, #1 is a good reason to cancel the project outright rather than licensing the game engine, and #2 will greatly restrict what you can do with your game.
Every game engine is built to do particular things that the engine designers think that a lot of games will need. If you want to go off the beaten path and do something unique, then no game engine will have the capabilities that you need built in. At that point, you basically have three options.
1) Abandon most of the cool things that you wanted to do with your game and settle for what off-the-shelf game engines can do.
2) Write your own game engine.
3) License a game engine, buy access to the full source code, and heavily modify it to do what you want.
I hope you're not advocating #1. Because you should never advocate #1 as a gamer hoping someone will make cool games for you to play. #1 is really only acceptable as a first project for an aspiring game designer to get his feet wet before moving on to something more ambitious.
That leaves us with making your own game engine or heavily modifying an existing one. The latter option is expensive, however, and can easily cost more than making your own.
Remember that if you make your own game engine, then you just happen to have someone on staff who understands exactly how everything in it works: the person who wrote the game engine in the first place. If you license an existing game engine, you have to put so much work into figuring out exactly what it's doing so that you can optimize it for your particular game and change it to do what you need that it's far from clear that this will be less work than just making your own game engine. Licensing a game engine certainly lets you get started faster, but it will slow you down later when you create bugs by modifying one part of a game engine while misunderstanding how it interacted with another.
-----
Making your own game engine isn't that expensive. I read somewhere that Hero Engine has 60 shaders built in. I haven't seen those 60 shaders, but a typical shader may be about 20 lines of code. Of those 20 lines, maybe half will amount to declaring variables. (More technically, declaring which uniforms the shader needs access to, which inputs it will read in from vertex data or a previous stage, and which outputs it will pass on to the next stage.) So you've only got maybe 10 or so real functional lines of code. Multiply that by 60 shaders and you have, well, not really all that much code.
And that's intrinsic to the way shaders are done. You have to execute shaders hundreds of millions of times per second. Now, that could be 10 million shader invocations per second for this shader, 50 million for that one, 100k for this other, and so forth. But in total, you're easily looking at hundreds of millions of shader invocations per second. If your shaders are 200 lines long, you have a problem. You can have some longer shaders that don't get run that many times, so there isn't some fixed cap. But most of your shaders are going to need to be short.
Now, that's not to say that writing shaders is easy. While you might have 10 or so functional lines where the real computations are done, they're very dense lines. For some purposes, you might have more comments than code. And figuring out how to do the code is very mathematically intensive. An excellent understanding of linear algebra and multivariable calculus is basically the entry level, you can't do anything without this for 3D graphics. That's not "passed a class in it once". That's "would have a good chance of acing a final that would be unreasonably difficult to give to normal students" worth of excellent understanding. Well, you don't actually need everything from linear algebra and multivariable calculus, but you do need a good chunk of each. And quite a bit of higher mathematics is useful to know, too.
Here, let me give you a quick example with the comments removed:
If you can parse that, then good for you. And if you can't, well, I probably wouldn't, either, if I hadn't written it. Video cards have no clue what a shader is trying to do at a high level. They just run the desired instructions as quickly as possible and let the programmer worry about whether it's what he wants.
Shaders are also very performance sensitive, so it's critical that you heavily optimize them to do exactly what you need and nothing more, and to do it as efficiently as possible. Some chunks of code will only run once in a while, or even once per frame. If those run a little slower than they could, oh well. But when you need something to run many millions of times per second, taking a microsecond longer than necessary is a problem.
Now, you might say, why am I focusing on "shaders"? What about the rest of the game engine? You know what the technical name for the portion of a game engine that runs on the video card is? Shaders. Everything else runs on the CPU.
Now, there is a good chunk of work in setting up data on the CPU to pass to shaders, and in the rendering thread that directly passes that data to the video card. For the latter, think thousands of lines of source code--as opposed to tens of thousands. Most of what the rendering thread has to do isn't nearly as dense as shaders, though, and there is a lot of copy and paste. Much of it is just passing through data set up by other threads.
So while writing a graphics engine isn't necessarily easy, neither do you need 10 employees working on it. All you need is one good one. For that matter, if you try having 10 people work on the DirectX/OpenGL and HLSL/GLSL portions of the game engine at once, they'll probably trip over each other so much that you just get a huge mess. It's easy to have a bunch of people working in parallel on creating art assets. The graphics engine part of a game, not so much.
There is the problem that artists can't really do much until a good chunk of the game engine is already done. But that's easy enough to handle: if you're going to make your own game engine for a game, you don't hire 50 artists the day you start work on the game. That's as wasteful as hiring a bunch of customer service representatives a year before the beta starts. You get the game engine in place with a handful of employees, and then you hire the artists later. If you only have 3 or 5 employees for the first year, that's not outlandishly expensive, even on a $5 million budget with a game that will have dozens of employees by launch day.
-----
You might think, but wouldn't licensing a game engine get you a better quality engine, because you can license one from the people who are the very best at it, not just who you have on your staff? But it's often the other way around. The engine that they create for Camelot Unchained won't be nearly as good as, say, the Unity Engine, for the games that Unity is used for. Other games will need lots of things in a game engine that your particular game doesn't. If you're making an engine for one particular game, you include the features that your game needs, and not the features that you don't. That lets you completely skip tons of stuff--and thereby avoid a bunch of unnecessary bloat. Making an engine for a particular game is vastly less work than trying to make a general-purpose game engine.
Furthermore, there's a general principle that a given amount of effort to create a tool to do one particular thing will often get you something much better at that one particular thing than putting the same amount of effort into a general-purpose tool and using it for that one purpose. If you compare some random tool to a Swiss Army Knife, the latter can do a bunch of things that the former can't. But the Swiss Army Knife won't be as good of a screwdriver as a dedicated screwdriver that can't do anything else besides turn screws. It won't be as good of a pair of scissors as a dedicated pair of scissors that can't do anything else besides cut flat surfaces between its blades. It won't be as good at any particular purpose as a single-purpose tool built for that particular purpose.
Or to take another example, a CPU is a general purpose tool, and a GPU is more special purpose to handle specific types of computations. A CPU can do all of the computations that a GPU can do. You can write a software renderer that is fully OpenGL 4.3 compliant without even having the video card do any work other than pass through the completed image. But you don't because it will kill your performance. Even if you've got an extremely high end, $1000 CPU and a $70 budget gaming card, offloading work to the GPU properly might increase your frame rates by an order of magnitude.
In order for a game engine that you make from scratch to be better for your particular game than a game engine you could license, you don't need to have someone in-house who is just as good as the people who make off-the-shelf game engines. You only need someone in-house who isn't really all that much worse than they are. You'll get a ton of mileage out of being able to optimize for your particular game, rather than trying to create a bunch of general-purpose capabilities without knowing how games can use them.
So here is what will happen tomorow morning at the Camelot Unchained office. Some poor sap will grab a cup of coffee, head over to the work station, pull up the mmorpg.com forum to see what is happening and read this thread. That person will spit coffee all over their monitor as they read this and call an "emergency" meeting. The jist of that meeting will be, "Why the hell would anyone want to make a game for these nerds! SERIOUSLY!! Your wall of text includes CODE!?!?!? Let's go back to making ipod games where the customers say things like 'Look! A shiny!'"
You know, I've often thought the same myself reading these forums. Half of the people on here think they know what makes a good mmo, the other half think they're wrong, and neither side can even agree on what the common ground is, e.g., What is a sandbox? LULZ
Yeah, I'd push out crappy, money-grabbing, make-a-quick-buck games too . . . less effort, more reward.
With a proposed budget of $5mil, why the fuck is a tiny assed game studio making it's own graphics engine?
Mr Kokibukisa, do you know how much money it costs to buy a AAA commercial graphics engine? I give you a figure range, it has 7 digits.
That would be possible cost depending on the studio and liscense but this simply isn't true for a small studio. Every engine I've seen have very reasonable liscenses. Most get paid through royalties on earnings. While looking at costs you need ot keep in mind the cost of building your own, which believe it or not almost always costs more.
Please list these engines, and provide all the costing details for licensing them in the context of what CU is trying to do. Tell us how each can provide the level of pvp numbers they are hoping for.
Kyleran: "Now there's the real trick, learning to accept and enjoy a game for what
it offers rather than pass on what might be a great playing experience
because it lacks a few features you prefer."
John Henry Newman: "A man would do nothing if he waited until he could do it so well that no one could find fault."
FreddyNoNose: "A good game needs no defense; a bad game has no defense." "Easily digested content is just as easily forgotten."
LacedOpium: "So the question that begs to be asked is, if you are not interested in
the game mechanics that define the MMORPG genre, then why are you
playing an MMORPG?"
Last I checked Unity is a a free engine they are using (well they can pay $1800 for "expanded" version). What Andrew was saying is he is making his own tools for it, not actually making a whole new engine.
Could be wrong here, but that is what I got out of the videos.
Making game engines from scratch is very time/cost consuming.
Game engines sometimes have what effectively amounts to a trial version, where you can use the engine for a small fee, but can't modify it yourself. That's fine for a dinky little project where you're not trying to do anything remotely innovative, but not a serious option if you're trying to make a real commercial game.
The idea is to let you get started cheaply, so that you're a ways into the project when you discover something that you need the game engine to do but it can't. At that point, vendor lock-in kicks in, and your choices are to pay what it costs to get access to the full source code or start over with a different game engine. The former is expensive, and if you try the latter, you'll soon hit the same problem with the other engine you try.
If you want to make a serious commerical game and you want to license a game engine for it, then you need full access to the source code so that you can modify it however you like. You need to plan on that right up front, and not assume that you can actually launch a game on a trial version of a game engine. Getting the full source code that tends to be expensive. I don't know what Unity charges for it, but it's presumably where they make their money.
Comments
That matches my recollection of DAoC, and yes it's a game breaker.
There are really only three good reasons to license a game engine rather than building your own.
1) You want to make a fairly generic clone game, so existing game engines will have nearly all of the capabilities that you need.
2) You don't have anyone on staff capable of making a game engine.
3) You need to have an early pre-alpha build that you can show quickly, to make it look like you're making progress.
Of course, #1 is a good reason to cancel the project outright rather than licensing the game engine, and #2 will greatly restrict what you can do with your game.
Every game engine is built to do particular things that the engine designers think that a lot of games will need. If you want to go off the beaten path and do something unique, then no game engine will have the capabilities that you need built in. At that point, you basically have three options.
1) Abandon most of the cool things that you wanted to do with your game and settle for what off-the-shelf game engines can do.
2) Write your own game engine.
3) License a game engine, buy access to the full source code, and heavily modify it to do what you want.
I hope you're not advocating #1. Because you should never advocate #1 as a gamer hoping someone will make cool games for you to play. #1 is really only acceptable as a first project for an aspiring game designer to get his feet wet before moving on to something more ambitious.
That leaves us with making your own game engine or heavily modifying an existing one. The latter option is expensive, however, and can easily cost more than making your own.
Remember that if you make your own game engine, then you just happen to have someone on staff who understands exactly how everything in it works: the person who wrote the game engine in the first place. If you license an existing game engine, you have to put so much work into figuring out exactly what it's doing so that you can optimize it for your particular game and change it to do what you need that it's far from clear that this will be less work than just making your own game engine. Licensing a game engine certainly lets you get started faster, but it will slow you down later when you create bugs by modifying one part of a game engine while misunderstanding how it interacted with another.
-----
Making your own game engine isn't that expensive. I read somewhere that Hero Engine has 60 shaders built in. I haven't seen those 60 shaders, but a typical shader may be about 20 lines of code. Of those 20 lines, maybe half will amount to declaring variables. (More technically, declaring which uniforms the shader needs access to, which inputs it will read in from vertex data or a previous stage, and which outputs it will pass on to the next stage.) So you've only got maybe 10 or so real functional lines of code. Multiply that by 60 shaders and you have, well, not really all that much code.
And that's intrinsic to the way shaders are done. You have to execute shaders hundreds of millions of times per second. Now, that could be 10 million shader invocations per second for this shader, 50 million for that one, 100k for this other, and so forth. But in total, you're easily looking at hundreds of millions of shader invocations per second. If your shaders are 200 lines long, you have a problem. You can have some longer shaders that don't get run that many times, so there isn't some fixed cap. But most of your shaders are going to need to be short.
Now, that's not to say that writing shaders is easy. While you might have 10 or so functional lines where the real computations are done, they're very dense lines. For some purposes, you might have more comments than code. And figuring out how to do the code is very mathematically intensive. An excellent understanding of linear algebra and multivariable calculus is basically the entry level, you can't do anything without this for 3D graphics. That's not "passed a class in it once". That's "would have a good chance of acing a final that would be unreasonably difficult to give to normal students" worth of excellent understanding. Well, you don't actually need everything from linear algebra and multivariable calculus, but you do need a good chunk of each. And quite a bit of higher mathematics is useful to know, too.
Here, let me give you a quick example with the comments removed:
#version 420
layout(triangles, equal_spacing, ccw) in;
uniform vec3 moveVector;
uniform mat3 camMatrix;
uniform mat3 objMatrix;
uniform mat2x4 axes;
uniform vec4 persVector;
in mat3 tePosition[];
out vec3 gPosition;
out vec3 gNormal;
out vec2 gTexCoord;
out bool gFront;
void main() {
vec4 faxes = axes[0];
vec4 maxes = axes[1];
vec3 pos = tePosition[0] * gl_TessCoord;
pos.xy = normalize(pos.xy);
gTexCoord = vec2(fma(pos.z, 0.5f, 0.5f), atan(-pos.x, pos.y) * 0.159154943f);
float curveX = fma(fma(fma(fma(fma(faxes.z, pos.z, faxes.w), pos.z, maxes.x), pos.z, maxes.y), pos.z, maxes.z), pos.z, maxes.w);
vec2 curveN = normalize(vec2(1.0f, -fma(fma(fma(fma(5.0f * faxes.z, pos.z, 4.0f * faxes.w), pos.z, 3.0f * maxes.x), pos.z, 2.0f maxes.y), pos.z, maxes.z) / faxes.x));
gNormal = camMatrix * (objMatrix * vec3(curveN.x * pos.x, pos.y, curveN.y * pos.x));
gPosition = camMatrix * (objMatrix * vec3(fma(faxes.y * pos.x, curveN.x, curveX), faxes.y * pos.y, fma(faxes.x, pos.z, curveN.y * faxes.y * pos.x)) + moveVector);
gl_Position = vec4(gPosition.xy * persVector.xy, fma(persVector.z, gPosition.z, persVector.w), -gPosition.z);
gFront = (dot(gPosition, gNormal) < 0.0f);
}
If you can parse that, then good for you. And if you can't, well, I probably wouldn't, either, if I hadn't written it. Video cards have no clue what a shader is trying to do at a high level. They just run the desired instructions as quickly as possible and let the programmer worry about whether it's what he wants.
Shaders are also very performance sensitive, so it's critical that you heavily optimize them to do exactly what you need and nothing more, and to do it as efficiently as possible. Some chunks of code will only run once in a while, or even once per frame. If those run a little slower than they could, oh well. But when you need something to run many millions of times per second, taking a microsecond longer than necessary is a problem.
Now, you might say, why am I focusing on "shaders"? What about the rest of the game engine? You know what the technical name for the portion of a game engine that runs on the video card is? Shaders. Everything else runs on the CPU.
Now, there is a good chunk of work in setting up data on the CPU to pass to shaders, and in the rendering thread that directly passes that data to the video card. For the latter, think thousands of lines of source code--as opposed to tens of thousands. Most of what the rendering thread has to do isn't nearly as dense as shaders, though, and there is a lot of copy and paste. Much of it is just passing through data set up by other threads.
So while writing a graphics engine isn't necessarily easy, neither do you need 10 employees working on it. All you need is one good one. For that matter, if you try having 10 people work on the DirectX/OpenGL and HLSL/GLSL portions of the game engine at once, they'll probably trip over each other so much that you just get a huge mess. It's easy to have a bunch of people working in parallel on creating art assets. The graphics engine part of a game, not so much.
There is the problem that artists can't really do much until a good chunk of the game engine is already done. But that's easy enough to handle: if you're going to make your own game engine for a game, you don't hire 50 artists the day you start work on the game. That's as wasteful as hiring a bunch of customer service representatives a year before the beta starts. You get the game engine in place with a handful of employees, and then you hire the artists later. If you only have 3 or 5 employees for the first year, that's not outlandishly expensive, even on a $5 million budget with a game that will have dozens of employees by launch day.
-----
You might think, but wouldn't licensing a game engine get you a better quality engine, because you can license one from the people who are the very best at it, not just who you have on your staff? But it's often the other way around. The engine that they create for Camelot Unchained won't be nearly as good as, say, the Unity Engine, for the games that Unity is used for. Other games will need lots of things in a game engine that your particular game doesn't. If you're making an engine for one particular game, you include the features that your game needs, and not the features that you don't. That lets you completely skip tons of stuff--and thereby avoid a bunch of unnecessary bloat. Making an engine for a particular game is vastly less work than trying to make a general-purpose game engine.
Furthermore, there's a general principle that a given amount of effort to create a tool to do one particular thing will often get you something much better at that one particular thing than putting the same amount of effort into a general-purpose tool and using it for that one purpose. If you compare some random tool to a Swiss Army Knife, the latter can do a bunch of things that the former can't. But the Swiss Army Knife won't be as good of a screwdriver as a dedicated screwdriver that can't do anything else besides turn screws. It won't be as good of a pair of scissors as a dedicated pair of scissors that can't do anything else besides cut flat surfaces between its blades. It won't be as good at any particular purpose as a single-purpose tool built for that particular purpose.
Or to take another example, a CPU is a general purpose tool, and a GPU is more special purpose to handle specific types of computations. A CPU can do all of the computations that a GPU can do. You can write a software renderer that is fully OpenGL 4.3 compliant without even having the video card do any work other than pass through the completed image. But you don't because it will kill your performance. Even if you've got an extremely high end, $1000 CPU and a $70 budget gaming card, offloading work to the GPU properly might increase your frame rates by an order of magnitude.
In order for a game engine that you make from scratch to be better for your particular game than a game engine you could license, you don't need to have someone in-house who is just as good as the people who make off-the-shelf game engines. You only need someone in-house who isn't really all that much worse than they are. You'll get a ton of mileage out of being able to optimize for your particular game, rather than trying to create a bunch of general-purpose capabilities without knowing how games can use them.
GW2 is exactly what I don't want to see, regardless of the culling. All of your enemies are clones of one another. You're not actually seeing the other player's avatar. Totally ridiculous and a huge step backwards.
Guild Wars 2 still has a variety of culling bugs, most or all of which are graphical problems. They just fixed one particular culling bug that was network-related.
Culling shouldn't be a dirty word in game engines. Any respectable game engine will cull things in a bunch of different places for a bunch of different reasons. Your performance will be absolutely terrible if you don't. The basic principle is that if you can figure out that continuing to process some data won't affect the final image that appears on the screen, then you cull it--that is, you stop processing that data. You do that CPU-side for several different reasons, and then GPU-side at several different places in the graphics pipeline.
Culling only becomes a bug if you do it improperly, and cull something that should have appeared on the screen.
Culling is a tool. Like all tools if you use it incorrectly you're not going to get a good result.
Also, I'm not a game dev (I do Enterprise ERPs and DW/BI), but the gfx engine is only one part of the client. If they choose to go custom, they are taking on Networking/Comms, data management, UI's, asset formats and related tools, debug/profiling tool development, distribution/patching and packaging, version control, Customer Service interfaces, logging, web interfaces, 3dMax/Maya plug-ins, scripting engines, etc etc etc. You're in the industry, is that not accurate? Seems to me that is a LOT of re-inventing the wheel for a small team on a small budget.
There are plenty of asset management systems, and if we're talking source control there's git/svn etc.
Anyway, considering the team will get much larger if it funds, I don't think it's that big a problem. And they are already planning to use other people's stuff wherever applicable. (Blink/webkit, whatever physics system they are using, etc)
You can write an import/export plugin for 3dsmax in no time, to be honest. It's a really clean API. Or used to be. You could easily get an intern to do that. Not going to be an issue.
They don't have to re-invent the wheels for many of the things you mentioned, you can just get external lib's for each if you need to, and with experienced people its generally just a case of setup and go. Writing a custom GFX engine doesn't take as long as some people make out (for experienced people), but writing a engine with verbose tools such as ones found in Cry Engine / UE / Unity is generally a long task, this is generally why you see many developers use them, the tools are amazing.
The issue is the MTU limit, this is what holds back ALL MMO GAMES from rendering masses of individual characters on screen (notice how gw2 change to basic models, hmm why ?) it's a hardware technology limitation, that's all there is to it. Some games can get away with more or less characters depending on their display/update system time requirements, but when you hit the limit, that's it.
i have a very simplist vision of this question.
I think no one knows more what is needed for CU than the guys who's working on it, and i assume they already checked out the biggests engine outthere, and were not satisfied enough with what they offered.
So if Andrew has the knowledge to make his own, or modify one for best performances needed to have thousands of people at same time, then i guess its the right call.
not many mmos out there need to that kind of performance, as everything is instanced now.
Bowbow (kob hunter) Infecto (kob cave shammy) and Thurka (troll warrior) on Merlin/Midgard DAoC
Thurka on WAR
Have you played an RvR game before that gave you staggering lag or major culling issues when massive amounts of people were onscreen at once? Not trolling, I am genuinely curious.
CLICK: »»» http://CamelotUnchained.net «««
Don't put words in peoples mouths, the people on this forum are intellegent, this isn't fox news.
My doubt is whether andrew can:
1) dedicate enough of his time to maintain a custom engine over the years to come, doing his due dilligence to keep the game up to date with technology and..
2) Create the quality, powerful tools with which to work on the game for the various content systems. As well and efficient as the tools for other engines and..
3) Guarantee to stay with CSE over the next several years in order to maintain his engine.
Obviously Andrew is the only one that can give you answers to those specific questions, but as far as #3 he is co-founder of CSE, so I'd say he is very likely to be a part of the team for awhile.
Mr Kokibukisa, do you know how much money it costs to buy a AAA commercial graphics engine? I give you a figure range, it has 7 digits.
SKYeXile
TRF - GM - GW2, PS2, WAR, AION, Rift, WoW, WOT....etc...
Future Crew - High Council. Planetside 1 & 2.
Some things are 10 lines of code here, 50 lines of code there, 300 lines of code for this, 150 lines of code for that, and not a big deal. Some things have code that isn't much harder to type out than paragraphs of a forum post. Even if you make a list of 50 things that you have to do, if none of them are very hard, then doing all 50 doesn't add up to something impractical, either. Other things are 10,000 lines of spaghetti code if you're good, and much, much worse if you're not. That's the sort of thing that makes you ask, "Do I really want to do this feature?" And sometimes it can be hard to tell what is what until you actually try to do it yourself.
And some things can easily be very simple or a complete mess depending on how efficient you are. I had one function in my game engine that was once about 1500 lines of code, on top of calling a number of other very messy functions to do various things. After a series of simplifications, it's now under 60 lines of code and the only external functions it calls are some very simple things that are only a few lines each.
Furthermore, some things that would be easy if you built the game around them become nearly impossible if you want to tack them on to some other game engine that isn't built for them. For example, if you want to be able to have 100 players moving around on your screen at a time and still make the game run smoothly on modern low-end hardware, it's easy to do if that's your top priority. The character models won't be very detailed (e.g., 2D sprites with a few frames of animation each can surely work; rudimentary 3D models with few vertices and few, low resolution textures probably can, too), and player movement won't be updated from the server very often, but if you build the game around it, you can make it work and it's fine. If you have a semi-turn based game where players can only move at most once every five seconds anyway, then keeping 100 players updated of what everyone else is doing becomes practical.
If, on the other hand, you take an existing game engine that is designed with very good looking models in mind and never meant to show more than 20 characters on a screen at a time and want to modify that to allow 100 players running around at once on lower end hardware, it's going to be a complete nightmare. You'll probably be better off scrapping large swaths of the code and redoing them from scratch than trying to modify code that isn't even trying to do what you're looking for.
-----
The basic principle is that, if you need to do exactly the same thing that lots of other games need to do, then you can probably find or license something to do it for you. If you want to do something different, even if it's kind of similar to what a lot of other games do, then you'll have to code it yourself.
Some things intrinsically have to be different from game to game, and you're going to have to do that on your own. Some things are sufficiently performance-sensitive that, even if you could license code to do it for you, it's a bad idea, as it won't be optimized for your particular game, so it will kill your performance. Some things are simple enough to do from scratch yourself that there's no real point in looking for an external solution. And some things make a ton of sense to either find some free code somewhere or license something to do what you want.
To answer your question directly, no, I don't work in the gaming industry. My real-life situation is complicated at the moment. I have written my own game engine basically from scratch, though. Well, at least the graphics part of it; there's a lot of stuff still missing. I was surprised that it was a lot easier than I expected. I do some really unorthodox things, though, such as making all artwork procedurally generated, rather than having art assets stored on the hard drive and loaded as needed.
-----
Reinventing the wheel is a bad idea if it's a lot of work and the wheel you'd create isn't any better for your particular purpose than some other wheel that you could get cheaply elsewhere. But if the tools that you could license can't do what you want, then maybe you shouldn't license them.
1) Who says you have to keep your game up to date with technology? If the graphics API that you're using can do everything you want to do, then why do you need to change to a different API later? What will graphics APIs five years from now be able to do that DirectX 11.1 and OpenGL 4.3 can't do today? Probably order-independent transparency that isn't a complete nightmare to deal with, and a bunch of minor tinkering around the edges that gives you slightly more efficient ways to do old things. Anything else?
For that matter, they're still launching DirectX 9.0c games today. That's a lot more stifling today than DirectX 11 or OpenGL 4.3 is likely to be a decade from now. Or even worse, have you seen what browser-based games are stuck with using? Besides, OpenGL generally makes the new version a superset of the old, so if OpenGL 5 offers something new that you really want, you just write it in and it works. With DirectX, it's a little more complicated.
2) He doesn't need to create a bunch of general-purpose tools just as good for a bunch of other games that he's never heard of as game engines that one can license. He only needs to create tools at least as good for the particular things that Camelot Unchained wants to do as the tools created by people who hadn't heard of the game and had no clue what games mechanics it wanted when they were creating the tools. That's not a trivial thing to do, but neither is it outlandishly hard.
That would be possible cost depending on the studio and liscense but this simply isn't true for a small studio. Every engine I've seen have very reasonable liscenses. Most get paid through royalties on earnings. While looking at costs you need ot keep in mind the cost of building your own, which believe it or not almost always costs more.
Thanks for the answer, and understand about the licencing. Guess we'll see how they fare when they start development.
So here is what will happen tomorow morning at the Camelot Unchained office. Some poor sap will grab a cup of coffee, head over to the work station, pull up the mmorpg.com forum to see what is happening and read this thread. That person will spit coffee all over their monitor as they read this and call an "emergency" meeting. The jist of that meeting will be, "Why the hell would anyone want to make a game for these nerds! SERIOUSLY!! Your wall of text includes CODE!?!?!? Let's go back to making ipod games where the customers say things like 'Look! A shiny!'"
Last I checked Unity is a a free engine they are using (well they can pay $1800 for "expanded" version). What Andrew was saying is he is making his own tools for it, not actually making a whole new engine.
Could be wrong here, but that is what I got out of the videos.
Making game engines from scratch is very time/cost consuming.
Heartspark: Animist rr12, bors, Lone Enforcer, Retired
Dranzerk: Berzerker (kay) retired
Dhei: Spiritmaster (Kay) retired
Goblinking : Hunter (Kay) retired
Moongoose: Shadowblade (Kay) retired
You know, I've often thought the same myself reading these forums. Half of the people on here think they know what makes a good mmo, the other half think they're wrong, and neither side can even agree on what the common ground is, e.g., What is a sandbox? LULZ
Yeah, I'd push out crappy, money-grabbing, make-a-quick-buck games too . . . less effort, more reward.
Man I love this site.
Please list these engines, and provide all the costing details for licensing them in the context of what CU is trying to do. Tell us how each can provide the level of pvp numbers they are hoping for.
Epic Music: https://www.youtube.com/watch?v=vAigCvelkhQ&list=PLo9FRw1AkDuQLEz7Gvvaz3ideB2NpFtT1
https://archive.org/details/softwarelibrary_msdos?&sort=-downloads&page=1
Kyleran: "Now there's the real trick, learning to accept and enjoy a game for what it offers rather than pass on what might be a great playing experience because it lacks a few features you prefer."
John Henry Newman: "A man would do nothing if he waited until he could do it so well that no one could find fault."
FreddyNoNose: "A good game needs no defense; a bad game has no defense." "Easily digested content is just as easily forgotten."
LacedOpium: "So the question that begs to be asked is, if you are not interested in the game mechanics that define the MMORPG genre, then why are you playing an MMORPG?"
Game engines sometimes have what effectively amounts to a trial version, where you can use the engine for a small fee, but can't modify it yourself. That's fine for a dinky little project where you're not trying to do anything remotely innovative, but not a serious option if you're trying to make a real commercial game.
The idea is to let you get started cheaply, so that you're a ways into the project when you discover something that you need the game engine to do but it can't. At that point, vendor lock-in kicks in, and your choices are to pay what it costs to get access to the full source code or start over with a different game engine. The former is expensive, and if you try the latter, you'll soon hit the same problem with the other engine you try.
If you want to make a serious commerical game and you want to license a game engine for it, then you need full access to the source code so that you can modify it however you like. You need to plan on that right up front, and not assume that you can actually launch a game on a trial version of a game engine. Getting the full source code that tends to be expensive. I don't know what Unity charges for it, but it's presumably where they make their money.