quote: Original post by Xai
NO MATTER how much training is required, NO MATTER how much code is reused ... the LIBRARIES, like OpenGL, and the game engines, like Unreal Tournament .. are HUGE advances in developer coding abilities IN THE LARGE ... and the proof is in the results ....

The comparison you are NOT making in the above is "in comparison to custom-developed software". "Standards" improve the ability to push the envelope without worry - OpenGL, shader languages, network protocols, etc. None of those are reuse at the level I was responding to. They may contribute to larger movements, but they are not themselves pluggable systems, nor do they constitute anything near a reasonable definition of "components".

Engines are indeed components, but as mentioned they have their own problems - the level of customization required for novel projects, in particular, is often so high that reuse becomes insignificant or even counterproductive. For stock content, of course, it's easy to reuse systems - that's as true in my slice of the software field as in the gaming slice. But stock content is also not competitive.

Components, so we are clear, do USEFUL WORK. A brain that, for example, gives units basic pathfinding and target evaluation abilities is a component. A shader that produces a specifically lifelike explosion, coupled with the textures which flavour the mix, constitute a lower-level component. A level editor such as UnrealEd constitutes a higher-level component, although at that level the definition starts to impinge on the lower strata of "systems", which are largely not the same thing.

quote: The current software developers understanding of programming 3D is now AT A HIGHER LEVEL than it was 15 years ago, do to open gl like libraries which provide an ABSTRACT MODEL which developers learn and master, which is HIGHER LEVEL than the previous model ... step by step we build bricks out of air ... on top of the previous bricks, slowing building our castles ...

I reject the classification of OpenGL as a component. OpenGL is the ultimate example of reuse at a low level. It doesn't do anything useful by itself. You have to make all the hard decisions; the only thing that OGL does is give you a place to send it to the gfx card. Much the same principle holds for most of the abstractions which have been most pervasive over the years - TCP/IP stacks are another excellent example. These are reuse, but they are not in and of themselves workers. They perform a useful function, but they don't automatically compress, decode, verify, or otherwise mangle your data so that you don't have to.

quote: and it IS component reuse, for all the components that you didn't have to cut in half ... just not for the ones you replaced.

I don't think we're coming at this from the same angle. Even if people reuse everything in an engine, if it's hurting them significantly to do so then the original point stands.

The subject of the thread is basically advancing the state of the art, in particular with respect to speed of development. One has to keep in mind, then, that the results of this faster development must compete with products developed in other paradigms. If a graphics engine isn't capable of delivering at a particular level, or a sound system doesn't blend things dynamically enough, or an AI uses too inflexible a conceptual model, or any of thousands of other small errors, the developer is going to be left at a disadvantage that costs them money. If it takes 2 years to develop the game instead of 1 and it sells 10 times as much, well, was that worth the extra time spent? My answer is that mostly, it is indeed worth the extra time. And you can be certain that in almost any situation, the percentage of reuse DROPS as that extra year drags by, because the number of needs which don't fit the original implementation is so very likely to grow. I'm sure that some shops beat that particular metric, but as a general rule as a system grows its special-casing grows faster.

That's where reuse constantly falls down - it doesn't, in the long term, provide value commensurate with the effort required to harness it, or does so only marginally. You can reuse an engine for at most two generations before its assumptions are outdated. Give it thirty years, when the computational limits have been hit, and those trends will slow dramatically. But while hardware is evolving, software has to evolve as well - do more, do it better, with new tools.

Plus, the discipline as a whole only just starting to tap mental models of engineering. If the composition of the wood a building architect had at their disposal changed every month and in addition the definition of a hammer changed to a newer, better one every couple of days (especially if he had no objective metric against which to measure its performance), he'd go nuts trying to find the patterns of architecture.

ld

[edited by - liquiddark on January 13, 2004 12:07:07 PM]

I wanted to express a couple more contrarian thoughts on some material that was posted on the thread. Always helps to have at least 2 points of view, or so I''m told.

quote: Original post by Kylotan
I won''t say anything on larger teams, but just post a link: The Mythical Man-Month: Essays on Software Engineering.

"Adding more to a late project makes it later." - Freddie P. Brooks, MMM

He wasn''t saying "Don''t have a big team." He was saying "Don''t think that adding people halfway through the process because you screwed up the first part is going to get you anywhere." That is to say, get it right the first time, because there isn''t anywhere else in the process to get it right that''s going to help you make money/provide value.

quote: All the latest revolutions in software development such as extreme-programming and test driven development pass you by then? The days of the monolithic requirements spec are past, as people come to realise that they''re not worth the paper they''re printed on by the time the product is even half developed.

Remember that these methods have plenty of opposition as well as devotees. Even Fowler is starting to sound a little wary of the hardcore nuts, especially when it comes to large-scale systems. The monolithic spec, and I say this from a position of experience, is a thousand times better than no spec at all and not quite as good (say 20-80% as good) as an agile development process. The difference is far less marked than some folks would have you believe. These techniques, as with all others, have their benefits and their drawbacks, and only the organization itself can find the right balance of the two. This is the unfortunate part about software - design pervades every element of the industry, from an individual''s coding process to the final production of packaged goods.

ld

Does Flash count?

--
You''re Welcome,
Rick Wong
- sitting in his chair doing the most time-consuming thing..

quote: Original post by liquiddark
"Adding more to a late project makes it later ." - Freddie P. Brooks, MMM

He wasn''t saying "Don''t have a big team." He was saying "Don''t think that adding people halfway through the process because you screwed up the first part is going to get you anywhere."

I''m pretty sure he also made the point that larger teams require a higher communication:action ratio, meaning each subsequent person is less efficient. Sadly I don''t have the book handy any more so I can''t back this up with a quote.

On a more personal level, I don''t think big teams are a good idea for software development. The more people are on the code, the less of the entire code will be known by any one person, so you''ll get a less coherent construction. The traditional way to alleviate this sort of problem is to encapsulate the details and hide the complexity behind interfaces, which brings us right back to objects and components. At which point I argue that most of the components are probably better outsourced and the game making companies just need a small team to bring them together.

quote: Remember that these methods have plenty of opposition as well as devotees.

Of course. And a large number of those are from the "we''ve always done it this way, it works for us, so why change" camp.

quote: The monolithic spec, and I say this from a position of experience, is a thousand times better than no spec at all and not quite as good (say 20-80% as good) as an agile development process.

I just want to add a bit more on software development processes. Pretty much every software design methodology I''ve read about, excluding recent ones like RUP and XP, focused on developing bespoke software that was expected to run in a very specific environment and last for numerous years. If it took you 6 months to get all your requirements down and the specifications drawn up, that was ok as the software would be running for many years. This isn''t the case with developing computer games for retail.

Surely the best situation for such a fast-paced industry (which needs to get faster!) is a compromise of a lightweight spec that focuses on the essentials, and an agile process that can adapt to changing needs.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Kylotan:
Agreed, except the bit about the opponents of agile. A limited number of them are as you say, from the traditionalist camp. But from my readings, I would conjecture that most of the rest are from the "been burned once too many times" camp. Agile is still young enough to be a Next Big Thing, and while it''s a lovely process improvement it requires if anything MORE discipline than older methods to execute in a software development organization. Ane discipline, in my experience, is about as good as talent for a room - if you''ve got it, it really doesn''t matter how you go about things because they''ll likely turn out OK. The problem is, discipline fluctuates even more wildly than talent.

quote: Original post by Kylotan
I must take issue with this ''rant''...

quote: Original post by Sphet
Larger teams, more experienced individuals, higher accountability to the publisher.

I won''t say anything on larger teams, but just post a link: The Mythical Man-Month: Essays on Software Engineering.

As for ''more experienced individuals''... that''s pretty impossible because the game industry is difficult enough to get into as it is. You can''t have more experience and bigger teams. You have to recruit from somewhere .

quote: Amortizing costs of a tool-team across ten or twenty teams means that people of greater experience are hired for the tool-team, creating a better code base that is actually maintained, and used from project to project, unlike most professional game companies.

Problem: experienced programmers don''t want to work on tools, they want to work on products.

Re-use of tools and engines and the like is probably good though.

quote: I don''t think software development needs to change at the coding level, I think it needs to change at the level of professional practices, where software engineers understand how to communicate with one another, the artists, the designers and the producers, writing things like ''requirement documents'' and ''feasability studies'' before letting vanity projects get off the ground without clear forsight.

All the latest revolutions in software development such as extreme-programming and test driven development pass you by then? The days of the monolithic requirements spec are past, as people come to realise that they''re not worth the paper they''re printed on by the time the product is even half developed.

quote: Companies also need to change, understanding that employees who work eight hour days, five days a week instead of twelve hour days seven days a week are far more productive over a two year development cycle.

This part I wholly agree with.

quote: If these development houses become more mature and understand the nature of actually running a competitive business, they''ll use some forsight and create an environment where productivity increases. This includes getting rid of all the nerf guns and girly posters that still seem to be everywhere.

And this part I don''t. Having a few distractions around the office doesn''t harm productivity. It relieves stress, builds team spirit, and helps to ensure that you have people who understand the idea of ''fun''. Far better to set reasonable targets and let people work to those, rather than removing all external stimuli in the hope that it''ll force them to work harder. If I spend half my waking hours at work, it had better be enjoyable. I''d much rather have a relaxed and fun environment than Christmas bonuses.

You''re also placing a lot of blame on developers when a significant part of it should fall on publishers. Publishers have been known for arbitrarily changing deadlines and shipping products that they knew were not ready, despite the development team making this quite clear to them a long time before the event. Unreasonable deadlines are part of the cause of ''crunch time'' and the foolish hours that some places end up having. The short-sightedness of publishers is another reason why research and the feasibility studies you desire are not practical. Publishers don''t pay unless you have a product. Need I mention the occasional obsession with branding and marketing over the quality of the product? Daikatana was allowed to slip and slip because the publishers thought the John Romero brand would sell it, despite the game being useless. On the other hand, Looking Glass studios were allowed by the same publisher to go bankrupt, despite that team showing beyond a doubt that they were producing consistently high-quality titles that sold well.

Kylotan,

Your point about publishers is well taken. There''s nothing more frustrating with having publishers change requirements on you. I think what I was trying to get at was that developers need to push the publishers to understand there are real problems with these changes, and to set an example by dealing with these kinds of issues when they arise internally. It''s not just publishers who change requirements as they go.

With regard to experienced programmers not wanting to work on tools, wanting to work on products. While I think we need to find ways to show people that the tools are important to product development and thus worthy of their time, I do agree with your point. Perhaps a system whereby developers spend one cycle on tools, the next cycle using that tool on a project, and then back again? Maybe a problem with maintenance of the toolset. I''d be happy working on tools as long as I was given the time to spend on them and not get dragged back into production every three weeks.

About software development processes and such, yes there has been a case made for Extreem programming and other methods, I think that there are more important things to change. If a group of developers are successful at developing code, but there are scheduling problems, or dependency problems, changing to another coding mehtedology isn''t necessarily going to save them. Looking at the bigger picture of process engineering in a company wide or at least team-based level is more effective, IMHO.

Nonetheless, your points about enjoying your environment are valid, and I was on too strong a rant.

Thanks for your reply.

- S

Liquiddark & Kylotan, I just wanted to thank you for your posts; I found them to be a very good read. It''s interesting to hear the thoughts of people working within the industry. Its not often that we can talk about these issues with candor.

- S

and we come full circle back to "component" reuse ...

There are problems with large teams communicating (and I have the book right here, and since the communications grow combanitorially, they overwhelm the actual work very quickly) - both Brooks and Jim McCarthy put forth the idea of functional teams (usually sized between 4 and 8 people) which do not need to communicate accross boundries to get their job done ... any larger and the development work drops, not increases. Teams cannot be larger without clear seperation of tasks and their interactions. Of course microsoft proved them wrong when they built Windows NT ... they just threw over a hunder people at a problem for years ... brute force past the limitations ... and of course they did have it divided into more than 12 seperate units that even used their own source control trees.

Back to components .. since INTERNAL TEAM SIZE must be small, the only way to acomplish more is to SYNTHISIZE the products of multiple other teams ... this is where ALL ASPECTS of reuse come into play. Each member reusing a FileStream class is at least as usefull as someone having access to a "Brain" for doing AI ... cause it affects nearly every developer ... but as you said, this problem is already well solved, and so even though it IS critical, and the body of SMALL components is ever improving, it is not something NEW for significantly faster development ... it''s more of the same ...

So back to the LARGE reuse ... which is COMPLETELY a relative term, because anything which is CUSTOM today, will be LARGE reuse for the next 3-10 years, and then SIMPLE/SMALL reuse of core framework functionality after than (just as you think File Systems, Graphics Libraries and Networking are SMALL . - YET There is a THREE BOOK SERIES on programming TCP/IP with over 2500 pages total ...

THIS DECADE''S large reuse will hopefully come in the form of what we currently call GAME ENGINES .. but with a better MODULAR design ... an engine that only ties in the pieces that have significant reason to go together. There is no need for networking to be build-in to your 3D game engine .. and it SLOWS DOWN our progress, because the 3D engine vendor is busy writing a CUSTOM network system, instead of reusing one written by a networking system vendor ... The types of things we need in a 3D engine include the modeling stuctures, the physics, effects, particles, etc .. things which relate directly to an objects existence in 3 dimensions

Then we would want to have a "game logic" library or system which deals with things like providing a scripting langauge to work in, and means to access / query objects in the game programatically and from AI ... or maybe even a higher level AI system ..

And of course a networking system, higher level than DirectPlay, even higher level than MUSCLE ...

Our interface system needs direct / complete hooks for scripting / programatic debugging.

If I wasn''t so sleepy, I''m sure I''d have more to add

quote: Original post by Xai
and we come full circle back to "component" reuse ...

I don't understand...That was the issue at which I am taking umbrage. I haven't argued the point of reuse of libraries, or at least I hope I haven't...

quote: both Brooks and Jim McCarthy put forth the idea of functional teams (usually sized between 4 and 8 people) which do not need to communicate accross boundries to get their job done

I'm only going to say it once: Not possible. Communication is vital to have components which mesh well. That's the whole problem with component reuse. Certainly, you can build best-of-breed components easily. They will do one thing well. They will also be useless garbage when you try to combine them with other systems. I don't have to conjecture about this. I've witnessed the principle in action more times than I care to admit.

quote: Each member reusing a FileStream class is at least as usefull as someone having access to a "Brain" for doing AI ...

No, no they're not. The Brain would do work that has a visible effect. The Filestream is a useful abstraction, but it is basically just an object oriented version of a function library, and moreover it's a far cry from a State Serializer, which would be the analagous component. I hope you see what I'm saying here - I could take a brain and plug it into my units, and they would automatically be able to consume map data and then find their way around it; I could take a State Serializer, input my level and game state as a set of serializable objects, and I'd instantly have a game save.

quote: (just as you think File Systems, Graphics Libraries and Networking are SMALL . - YET There is a THREE BOOK SERIES on programming TCP/IP with over 2500 pages total ...

You misunderstand me. I don't think these are small in complexity. The reason why they require 2500 page series is because knowledge of the APIs is next to useless without knowing how to apply it in depth. And that part of the equation, you see, is where components come into their own

quote: There is no need for networking to be build-in to your 3D game engine

Except that about 75% of the postmortems on Gama which mention networking as a problem have as the source of the problem late inclusion of the technology. You have to think about networking from ground zero, because it forces tradeoffs between data size, complexity, and compressability, not to mention the time take computationally to do things like arithmetic encoding.

quote: Then we would want to have a "game logic" library or system which deals with things like providing a scripting langauge to work in, and means to access / query objects in the game programatically and from AI ... or maybe even a higher level AI system ..

We have these already. No question they're useful. But they're not whole-component reuse. By themselves, very few of these do useful work. Typically, they force the overall quality of execution upwards, but leave something to be desired in terms of their flexibility and performance.

At this point I will back down somewhat. My original point was that there are many perspectives, and not all of them view components as a vector of reuse along which much progress has been made. That's it. I've elaborated on some of the reasons why, but the more I get into the discussion, the less I'm interested in it. Buying an engine has other advantages besides those inherent in raw reuse, so it's a good bet for any game dev team (an advantage not, i am afraid, shared by my professional sector).

ld

[edited by - liquiddark on January 15, 2004 7:16:57 AM]

quote: Original post by Sphet
Liquiddark & Kylotan, I just wanted to thank you for your posts; I found them to be a very good read. It''s interesting to hear the thoughts of people working within the industry.

You''re welcome, sir (or madam), although I''m afraid all of my professional experience is outside of games.

ld