quote: Original post by bishop_pass
Something needs to come along which allows for speedier development. Not just premade engines. Something more exciting - a different paradigm.

Any thoughts?

2 words: open source

I think sites content sharing sites like www.gamebeavers.com will play a large part in the future of indy games.

And just a random stupid thought:

How about developing a set of generic inerfaces around which you could build any type of game engine (obviously there will be some limitation here). Then you could write generic code for a model and plug it in to any game engine.

quote: Original post by Raloth
Any thoughts?

2 words: open source Three words: Not a panacea.

quote: Original post by Erkki
The whole industry needs to change and mature and likely the changes should start from the publishers.

Yes, I just happen to disagree strongly with some people''s idea of ''mature''. Different industries require different cultures and trying to make everything into yet another middle-management-swamped office job is not going to solve any key problems.


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

Now for my actual response to the thread in general.

I tend to agree with Xai and some of the other comments made here.

In particular, I believe that we need more component-based design. In other words, parts of the system need to be more isolated from each other and should be interchangeable. And I don''t just mean the typical high-level designations of graphics/sound/input/networking. I mean a level beyond that too, such as using separate libraries for things such as:
- heightmap generation
- sound propagation
- GUIs
- filesystems
- dynamic music generation
- influence mapping
- cluster identification
and so on. Some will be open source, some will be commercial. All will work out of the box and be easy to integrate within a day. I think this fits into bishop_pass''s "useful specialization" comment.

There is a big disadvantage to this though; many people simply do not want to work on game software components. Games are fun. People often work in games rather than in normal programming because they enjoy the product and the design aspect. Moving the workforce towards components pretty much kills all that. Yet that is sadly how the industry may have to go. Most consumer electronics are constructed by 1 company by combining the components created by other companies. The same probably applies to most manufacturing. Perhaps software development has been slow to embrace this philosophy because the average programmer has all the tools in front of them that they need to create every component they will require, which isn''t true for television or car manufacturers. But I think people are beginning to realise that they don''t have the time to do this.

That leads me into the content issues mentioned by Bishop_pass. Content creation is very time-consuming, but would be alleviated by a more component-based approach to the code. For example, if a well-documented animation library emerged that provided you with ready-made human models and the methods to manipulate them, your artists could get down to the business of skinning them instead of having to build them in the first place. People already accept seeing the same graphical engine in different games. It''s not a big leap to assume that they will accept seeing the same model in different games providing the skin is appropriate.

There are 2 more aspects that I think are important, but which rely on the above paradigm for full benefit:

- procedural generation of content. One good algorithm could suit many games. Traditionally we think of terrain here and especially heightmaps, but there''s also the entire galaxies created in Elite etc, NPC name-generation, combinatorial composition of music, Diablo''s random treasure generation, etc. The possibilities are almost endless.

- more efficient language choice for core game development. As long as we have to keep reinventing wheels in each project, we''re stuck with using C or C++ to ensure that the wheels are efficient. However, if we can move the time-critical code into separate components, these components can be glued together with a language that is much better suited to speedy development, prototyping, and testing. My personal choice here is Python, but I can see Ruby, Lisp, Lua, or even Basic as being good choices.

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

On the other hand Kylotan, there''s a very real point to be made by people like Robert Glass (whom I have heard of only because of JoelOnSoftware), who notes that reuse in the small (functions, data structs) is a well-solved problem, but even the best software engineers have trouble creating meaningful component reuse scenarios. As a senior programmer, I''ve found that very problem to be a huge barrier to even simple component scenarios. There are many things that we can do to simplify the path of technical development, but there is a price attached to each.

ld

quote: Original post by liquiddark
On the other hand Kylotan, there''s a very real point to be made by people like Robert Glass (whom I have heard of only because of JoelOnSoftware), who notes that reuse in the small (functions, data structs) is a well-solved problem, but even the best software engineers have trouble creating meaningful component reuse scenarios.

Could you give an example of this? I''d say the masses of Delphi controls, graphics and networking libraries, COM objects, browser plugins, and other things in that vein prove that point wrong. If anything, it''s a lack of awareness of what is out there that leads a lot of people to rewrite the wheel.

It''s true that building a reusable component is a lot harder than building a specific one for a given situation but I would assert that (a) it''s not impossible, therefore not worth giving up on, and (b) it''s probably easier/more likely than writing a commercially successful game.

Look here or here: examples of code re-use that a lot of academic and business software developers still probably don''t think is possible, because so many of them don''t think about games when they consider that reuse is hard. Now there we are talking about reuse of massive pieces of software, not individual functions or data structures! Surely therefore, if game developers are able to reuse large chunks of code in this way, and if Robert Glass and the like are correct about smaller pieces of code being easier to reuse, then game development would be massively accelerated by the availability of more smaller and specialised libraries?


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

quote: Original post by Kylotan
Could you give an example of this? I''d say the masses of Delphi controls, graphics and networking libraries, COM objects, browser plugins, and other things in that vein prove that point wrong.

I apologize, but I don''t have any specific examples which I could discuss without being in violation of my employment agreement. Yours is, however, to some extent, a valid argument. The problems with this type of reuse are still myriad, however. First, most graphics libraries et al are not what one would call "components". They''re libraries, which tend to be reuse-in-the-small-oriented. They are typically function-based at heart, and you can use them for a limited extension of their original purpose, but they don''t work in a general context. So much work is committed to learning and customizing the component that its value in reuse is partially or completely undermined.

We are, slowly, entering a more reuse-friendly world, especially as things like pixel shaders extend the power of our metaphors for subsystems. But the goal is far from achieved. And with games, the problem is exacerbated by the extreme performance requirements and specificity of the platforms being targeted, which then reduce the value of reuse overall.

quote: It''s true that building a reusable component is a lot harder than building a specific one for a given situation but I would assert that (a) it''s not impossible, therefore not worth giving up on, and (b) it''s probably easier/more likely than writing a commercially successful game.

It''s not just that problem that gives us headaches, however. Reuse has its own cost, because at its most powerful the concept means that the component in question will have been created by someone other than the people reusing it. That means they then have to learn the item and customize it to their needs. IF source and support are available, which is almost certain to be a more expensive option than buying the component without said advantages (and hence less easily justified to business-level concerns).

quote: Look here or here: examples of code re-use that a lot of academic and business software developers still probably don''t think is possible, because so many of them don''t think about games when they consider that reuse is hard. Now there we are talking about reuse of massive pieces of software, not individual functions or data structures!

I can''t comment on the precise usage of engines in game development, but I can comment specifically on Deus Ex. They are probably shining examples of offenders, but I know specifically that they bought the Unreal Engine. The first time out, they changed so much code they couldn''t put out a proper SDK or multiplayer mode without a sizeable expenditure of time and effort. The second time out they bought it not for the brilliant scripting language, nor the top-quality physics engine - both of these were essentially discarded - but rather because they liked the level editor. Ergo, reuse is indeed achieved, but they could likely have done as well or better building their own tool to begin with. This isn''t efficient reuse of components. If other companies have similar attitudes towards "reuse" targets, then the technique is worthless and perhaps even damaging to the industry.

That is not to say that such is the case everywhere. But if one of the most groundbreaking series in the industry needs to pretty much rewrite the technology to reuse it, then reuse isn''t working nearly as well as we''d hope.

ld

but liquid, you are still partially incorrect in your logic ... 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 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 ...

The current state of 3D First Person Shooter game development is WORLDS beyond what it used to be, partially do to hardware advancement, but also do to engine reuse ... think of how peculiar, limited, and buggy most 3D games we''re a few years ago ... or RIGHT NOW ... for people that do not reuse an engine ... the ENGINE gives them the IN THE LARGE paradigm reuses, that they then modify only as much as they must ... much like someone taking a Car, cutting it in half, and making a Limo ... 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.

quote: Original post by Kylotan
In particular, I believe that we need more component-based design . In other words, parts of the system need to be more isolated from each other and should be interchangeable. And I don''t just mean the typical high-level designations of graphics/sound/input/networking. I mean a level beyond that too, such as using separate libraries for things such as:
- heightmap generation
- sound propagation
- GUIs
- filesystems
- dynamic music generation
- influence mapping
- cluster identification
and so on. Some will be open source, some will be commercial. All will work out of the box and be easy to integrate within a day. I think this fits into bishop_pass''s "useful specialization" comment.

Have you read Game Architecture and Design, by Rollings and Morris? There''s a great section on the Software Factory concept, which sounds pretty much like what you''re talking about.