   The Difficulties of  Designing Game Engines
  Hi. I'm an aspiring video game developer trying to gain a little more insight on the complexity levels of designing different game engines.I figured an easy and understandable way, to at least get a basic idea, would be to ask the programming community here to rate well known games, on a scale of 1-10, on how hard they think their engines would be to create. I understand that the experience of the different respondents will vary the results, but I figure I should be able to gather enough information for a general consensus.For example:World of Warcraft: 1-10Halo: 1-10Command and Conquer: 1-10Chromehounds: 1-10   (I know it's not very popular but it was my favorite) Keep in mind I'm only referring to the Game Engines, not the stories, modeling, or other elements of game design.Thank you,-Thomas   
Quote:Original post by GninjaGnomeKeep in mind I'm only referring to the Game Engines, not the stories, modeling, or other elements of game design.But engines exist for sole purpose of allowing creation of stories, models and other elements of design.Difficulty of engine design depends on many factors:- Which tools and methodologies are specialized team members most comfortable with- Ability of developers and software designers to cater to needs to these specialized needs- Number of readily available tools that integrate different parts of development pipeline- The overall budget and time constraints- Existing code base and in-house tools- How diverse is the target platform- Rigidity of development - the more rigid requirements are, the easier/cheaper it is to develop, but the more final product will fall into a niche- Corporate culture and general QA/development methodology- State of the market, short and long term goalsCoding an engine is not difficult, it's not hard, it's not complex. It's what engine programmers are hired to do, it's what they studied, and what they know. It's what earns them their salary.The difficulties will almost never come from technical issues anymore - they are almost completely and entirely tied to (mis-)understanding of development process and organizational issues.But engine design today is a management problem involving 50-500 people, going towards 7000+ in case of WoW (yes, customer support affects engine design as well, just look at in-game support features and account management). It may also require taking input from customers or users, the numbers of which may be in hundreds of thousands, and filtering that feedback, or just extracting bug reports or subtle issues is a science in itself.Engine/framework/library design is no longer a programming problem and hasn't been for quite some time now.   ;  Thank you Antheus, I didn't expect such an informative reply so quickly.I hope I wasn't offensive, I did not mean suggest that game engines were uncomplicated or easily categorized. I'm only trying to gain a better understanding of the technical side of game development.I've only ever worked in modeling, textures, and concept. None of these areas are particularly simple, but if asked I could rate the complexity of a given project on a scale on 1-10.  Perhaps I still don't understand the very basics of game engine development. I thought their complexity could be rated in the same sort of manner. I figured I'd get more feedback on my question if I made it easy to answer in a way that is understandable to someone who isn't familiar with the field. I think I underestimated the passion of the game programming community.-Thomas;  And part of the problem is based on the actual scenario. A well designed engine hides a lot of its complexity. A badly designed engine becomes very complex, very quickly. That tends to impact the complexity of an engine, and working with the code far more than the technical features.   ;Quote:Original post by GninjaGnomePerhaps I still don't understand the very basics of game engine development. I thought their complexity could be rated in the same sort of manner.I would hazard a guess that the complexity was about equal for all of those, and will be roughly equal for most commercial games.Why? Because a game that looks simple by today's standards may have been very complex back in 1995. I could probably write a Command and Conquer engine for a modern platform in a week on my own, but the guys who wrote the original probably had to write their own software renderer, write their own memory manager (and cope with the complexity of MS-DOS memory types), optimise slow code in assembly language, handle networking over IPX/SPX and the serial port, etc - tasks either not needed these days or available in convenient packages for easy use. But as technological advances and improvements in software components continue, expectations rise in parallel.If you're asking which games would be hardest to make now, then your answer is hinted at in the above: the oldest games are easiest because their demands are lower (as befitting the era they came from) and technology has moved on (meaning their functionality is often half-written for you).   ;  "Coding an engine is not difficult, it's not hard, it's not complex. It's what engine programmers are hired to do, it's what they studied, and what they know."I have to point out two problems with this statement. First off, engine coding IS difficult, hard and complex. You stick a bunch of CS graduates in a building for 2 years with the best, most experienced management you can find, and you’ll be lucky if you get anything better than the quake 1 engine. It takes years of experience to develop the skills needed to design an implement good next gen engine code.Secondly, there are very few game related CS courses, none of the engine programmers that I know studied engine programming. It took them years to develop their skills to an adequate level to do their job. There is no course, even game programming courses, which can prepare you for the world of game development.Even with 75 programmers in a game studio, only a fraction of them are good enough to do engine programming, the rest are game-play programmers. If you look in the "real world" of programming, this fraction drops even further. Finding a good engine programmer is rarer than hen’s teeth.   ;  All the engines you mentioned have about the same difficulty level top develop.Working as a programmer you get given a set of requirements and you create software that meets those requirements.  There is no hard tasks vs easy tasks.I'd also have to disagree with thefries statement that a bunch of CS students with experienced management would only be able to produce a quake1 engine.Most of the new technologies that appear in the latest cutting edge games come directly from academic research.   ;  I'm certainly not saying that academic research can’t produce really cool technology - it does! But there are two problems with it...The code that any of the graduate students I’ve worked with is terrible, absolutely unusable - it takes a lot of guidance to get them to produce useable code of a high quality. It may be some great technology, but in the state the code is in, it’s usually hopeless. I'm not saying that this is the case for all graduates, but in the cases where the graduate can produce really good code, they have probably done a LOT of personal training/coding in their own time, hundreds and hundreds of hours over and above the course requirements.The other problem is that you can’t just pick a bunch of really good technological ideas and make them all interact seamlessly as an engine. It takes experience to be able to design everything to work well together. Most of the people here who call themselves graphics programmers have probably done bump/parallax/whatever mapping for instance, but they wouldn't have a hope in hell of putting an engine together from scratch. And when they try, they end up re-writing the whole thing a few times before its at all usable.Doing really cool 3d lighting and designing a proper data driven material system for the artists to use are two completely different topics. Academic research usually covers the former, with no interest in the latter.;Quote:Original post by thefriesI'm certainly not saying that academic research can’t produce really cool technology - it does! But there are two problems with it...The code that any of the graduate students I’ve worked with is terrible, absolutely unusable - it takes a lot of guidance to get them to produce useable code of a high quality. It may be some great technology, but in the state the code is in, it’s usually hopeless. I'm not saying that this is the case for all graduates, but in the cases where the graduate can produce really good code, they have probably done a LOT of personal training/coding in their own time, hundreds and hundreds of hours over and above the course requirements.The other problem is that you can’t just pick a bunch of really good technological ideas and make them all interact seamlessly as an engine. It takes experience to be able to design everything to work well together. Most of the people here who call themselves graphics programmers have probably done bump/parallax/whatever mapping for instance, but they wouldn't have a hope in hell of putting an engine together from scratch. And when they try, they end up re-writing the whole thing a few times before its at all usable.Doing really cool 3d lighting and designing a proper data driven material system for the artists to use are two completely different topics. Academic research usually covers the former, with no interest in the latter.I agree with thefries.From my experience I have seen this to be true.   ;  I would rate Mario on N64 as 10. Followed by Virtua Fighter 2 as 10 on the Sega platform.Halo the whole series (shebang) about 7 to 8.Valve's Left4Dead, yeah that's a 10. AI is pretty good.Forgot to mention Wolfenstein, that's a ten too. First time seeing a gameworld in 3D.Oh wait, the first version of Pacman is definitely a 10, I couldn't believe how complex is that game when I first saw it.[Edited by - dlangdev on May 14, 2009 2:15:25 PM]