I always thought that game architectures were more complex than most other types of systems. Then I read some of the posts on SO and it makes me think that maybe it isn't a complex as others. It might be that I don't know enough about the domain of these other systems and that makes it seem more complex. What do you think? Do you think game systems are more complex than others?
views:
139answers:
6It all depends on the games you're talking about (as well as what other systems you're talking about).
There are some game architectures out there that are fairly simple...and the same can be said about business systems. On the flip side, both games and business systems can become extremely complex and intractate.
On average though, I'd say that a complex game system is on equal footing with a complex business system in terms of architecture complexity.
The goal when creating a systems architecture is to have it as simple as possible while still accomplishing the what the system is supposed to do.
The complexity of a business system should be in the business rules, rather than the systems architecture. Consider a tax or insurance system.
The architecture of a business system that develops over time, with many generations of - and different types of techology can become complex.
The architecture of a game can be reasonably complex, especially for a multi-user game.
On balance I would say the the most complex architectures (not systems) are in business systems.
The system boundaries of a game are pretty dell defined - it's basically what is on the DVD. The boundaries of a business system are typically ill-defined. Consider the trading system for an investment bank - this will typically consists of dozens of commercial packages, doozens of in-house applications, all liknked together using middleware and talking to dozens of different electronic exchange and market data suppliers. So in this case the business app is at least an order of magnituted more complex than any current game.
It's also interesting to consider that many games are minimally a rich windows client. I'll go out on a limb and claim that most business applications are N-tiered systems involving disparate physicals systems and software components that together form the whole.
On the other hand, these days MMOs seem to exhibit a very similar architecture of clients at 'terminal's connecting to a black box server which is a stack of load balanced tiers of some sort.
My feeling (as an experienced game developer with little experience outside of games) is that a modern big budget game will have more inherent complexity relative to many other systems but perhaps less accidental complexity deriving from years of ongoing maintenance, changing requirements, mixed languages and environments and other sources of complexity that accrete around many long lived systems. While there is quite a lot of code reuse in games and most companies will have code that has been through two or more console generations, there is generally more freedom in games to re-architect when the needs of new hardware or changing requirements demand.
Another thing worth mentioning that is I think often under-appreciated outside of games is that the complexity of the software that ships on a game disk is only the tip of the iceberg of the software complexity involved in game production. Game studios will often have many more lines of code in the supporting tools and production pipelines that are used to generate the assets in the game than are in the shipping game itself. Level editors, particle editors, animation tools and other custom software that most games require are very complex pieces of software in themselves and are only occasionally seen outside of the studios that produce them (the Unreal Editor is a publicly available example of the kinds of tools that most studios use internally).
Geometry and texture processing tools, asset databases, distributed clusters for lightmap rendering and asset processing, custom debuggers for scripting languages, profiling tools for analyzing performance and memory usage, localization databases dealing with GBs of audio files, tools for creating and managing sound effects... The amount of custom software used internally by most games studios is quite large. Even where game specific middleware or third party tools like 3d studio max or Maya are in use there will still be significant amounts of custom 'glue' code holding the game production pipeline together.
For MMOs there is a whole additional level of complexity dealing with server clusters and all the infrastructure required to support a persistent game world accessed by hundreds of thousands or millions of users.
The individual subsystems of modern games are also inherently complex and generally require specialized skills to develop and maintain. Physics systems, animation systems, AI code, low level rendering, network code... each generally requires one or more programmers specializing in those areas.
A range of languages are also required when working with all the various components of the systems. I personally use C++, C#, SQL, Python, max script, lua, Unrealscript, HLSL and a bit of Perl on a reasonably frequent basis. A working knowledge of x86 assembly, PowerPC assembly, SPU assembly and low level hardware details of the RSX (PS3 graphics chip), Xenos (Xbox 360 graphics chip) and the major PC graphics cards are also important.
I've no doubt there are systems outside of games of greater complexity than a typical game but I think a modern AAA cross platform title or MMO count as some of the most complex systems an average programmer is likely to encounter today.
I've worked on web development, then telecoms testing software, and most recently game development. The most complex code I came across in the non-games world was about a tenth the size of the game development code.
For back-end logic games and business software are much the same - you take input, store data, alter it a bit, and spit it back out when needed. The main difference is that games have much more complex input (bespoke networking protocols, keyboard/mouse/gamepad/tablet handling, physics, AI) and output (real time graphics, audio, tactile controllers, more networking). Obviously business systems have most of these as well, but you generally get the benefit of using off the shelf standard components (eg. web server/HTTP/HTML, XML, Windows Forms or MFC, RDBMS packages) that games typically cannot take advantage of to the same degree. Both types of app have a round trip between the user using an input device somewhere and pixels on a screen somewhere else, but the business app developer rarely has to spend much time on those end points relative to the business logic itself.
So if you count the 'architecture' as all the software and protocols between them that one company needs to create, set up, and maintain in order to put a working product into effect, I'd say that a typical professional big budget game is significantly more complex than all but the biggest of business systems.