Re: [Algorithms] Complexity of new hardware

[Nicholas \Indy\ R. <ar...@gm...>]

On 4/16/09, Jon Watte <jw...@gm...> wrote:
>  Dealing with complexity is really becoming quite a chore, and our tools
>  just aren't keeping up IMO.
>  What good ways are you seeing of lifting game design and implementation
>  up onto higher levels of abstraction? Is it just middleware, or will the
>  middleware guys in turn need newer, better ways of doing things?

I find that middleware while often built to be as general as possible,
it's still too specialized to be the end all of game design
abstraction. all middleware is designed for a specific purpose and a
subset of game types.

Since we have been topping out at progress we can make in the graphics
sense, that leaves us with much more progress to be made with core
design decisions, as evidenced by the wealth of new game mechanics
being constantly introduced by the indie game community.

Yet at the AAA end of the scale the scope of our games are so large,
and the amount of work involved is so much that we aren't yet able to
experiment so freely. As often such changes don't fit very well into
our existing pipelines/engines/middleware.

Additionally we are constantly developing tools for our artists and
designers and giving them more freedom. But here we are still
developing with the same old tools we have been using for 10+ years,
that were created with no thought to the specific challenges of game
development.

Thusly I feel that some large improvements need to be done in the
tools that help us develop our games, otherwise programming will begin
to be a larger and larger bottleneck, and we will fall into the
pattern of making the same old sort of games.

We need improvement in the languages we use, compilers, and
IDE/Editors; It's absurd that I am using tools/languages that have
been only incrementally improved in the last 10 or so years, and have
evolved naught with considerations from the problems we face in game
development.

Nicholas "Indy" Ray