A lot of the concepts (where people are being serious here) have already been implemented to some degree of success.

Lisp - is being used. Jak and Daxter and it''s successor were written in a variant of the language. Apparently they judged it a qualified success. This is relevant to the discussion here though, as Lisp IS a different way of doing things, and one that hasn''t been widely considered, let alone adopted.

Graphics content from real world sampling - sure, happens every day now. Many racers are built from photographs taken of real sites. Uses range from just textures to full on photogrametry (the reconstruction of geometry from a set of photographs taken from multiple povs).

Muscular deformation - been used by the highend (non realtime) boys for several years now. The Mummy I believe was one of the earliest samples of driving a mesh using an underlying bone and muscle structure. VERY expensive to even approximate right, unlikely for realtime, imho, for a while.

I recon the next big shift for me personally will be when we can afford some overhead in the rendering pipeline. Right now, the worst problem I have is the fragmentation of the graphics pipeline. Bump mapped materials this way, skinned that way, prelit here, dynamically lit there, shadows another way. Having to write and optimise each case and every used combination is the killer. In some (not too distant future), I can imagine a unified approach without too much penalty, where the last optimisation is just scene management. Everything has a common material. Graphics engine setup will be reduced to the level of writing an audio engine. Load sample. Play sample. Load mesh, assign anim, render.

As far as core game code goes, there''s always evolution going on. I find my code is shrinking with every rewrite, as I repath inheritance and update chains down more logical routes, and encapsulate a lot of common stuff. My most favorite recent one was implementing a version of Steve Rabin''s state machines. That''s made everything look so tidy, thus making it much easier to follow!

There''s plenty yet to do, imho, at this evolutionary level to feed the advancement of our production efficiency for quite some time yet. I.e. perhaps the future isn''t one giant wobbly leap to something, but a series of very efficient small steps.

The programmer of the game ''Elite'' had the right idea, I think. There''s an article about it on gamasutra: http://www.gamasutra.com/features/19990917/infinite_01.htm

Applying similar ideas to FPS genres, etc. would rapidly speed up game development and you can axe half the creative team.

Back in college we used to use a piece of software (called LabView I think) that was some sort of lab kit. You'd place various mathmatical elements (basic math, boolean ops, frequency analysis) onto your work area, connect them in sequence, and in the end you'd have a graph of indicator or something. I thought it'd be handy to use in trying to quickly figure out systems within a game. Would be even more useful if someone did up something like that specificly for game systems.

[edited by - kseh on January 1, 2004 5:35:11 PM]

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?

Larger teams, more experienced individuals, higher accountability to the publisher. Improving professional practices within a currently immature business market will result in more efficient development cycles. Instead of one or two teams using the same in-house technology to leverage a game while reducing costs and lead-time, we'll see ten or even twenty teams all developing products in tandem while a group of 30 or so people develop all of the low-level tools and engine/modules required by the game-teams. 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. Electronic Arts and Ubi Soft are two companies that are moving this way.

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.

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. Companies also need to understand that as the current developer age-group rises (we're all getting older) some of us, while experienced and still loving our jobs, want to spend more time with our families. 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. I'd much rather get a bonus then a new nerf gun each Christmas. Companies need to be smart, and to grow up and realize the publisher is their employer, not the other way around, but at the same time make efforts to educate publishers on how games need to be changed to keep them attractive - Studios need to do research, market studies and focus tests - hire researches to help, get some co-op students in to help, anything. Everyone in the industry has to open their eyes and realize that we are moving further and further into a mature industry and are no longer making games in our basements.

Anyways, that's my rant for 2004.

- S



[edited by - Sphet on January 2, 2004 3:08:07 PM]

quote: Original post by pjcast
I read (popular science?)about inventions that were created by using a technique like this. They were re-inventions of other patented inventions. But they were unique and different enough to warrent their own patents.

I remember an article in Scientific American about that. They would make inventions that worked, but some of them it was not understood how they ended up working. Really interesting stuff.

Something like prolog.

computer

/computer beeps

place a NPC here.

/computer asks for parameters

have him be 2 meters tall, 3 sets of arms, and reptilian like

/computer places npc

bigger eyes, and place a BFG in his hands, and the intellegence level of a savage brute

/computer updates

perfect! Now I want to create a desart planet that this creature is from


is that what your talking about?

I think tool developers need to address and accept the fact that while pure and unlimited flexibility is good, it also hinders development.

All the permutations of code, art and 3d models possible (and which can be developed with tools such as C, C++, Maya, 3d Max and so on) is a superset of what people want to actually develop. The ratio of that superset to what people actually want to develop is close to infinite.

On the other hand, specific tools and plug-ins often constrain too much. Graphics engines limit expression, but often don't decomplexify development to a ratio equivalent to their constraining features. Moreover, artists and coders, working together, develop products which, while exhibiting quality workmanship, contain content which is obsolete for the next generation of hardware and incompatible with another genre.

We know that for the purpose of visual presentation, we in general need architecture for humans, props for living, and people. Tools which allow freedom of expression for the design of those objects with depth will go a long way. A product like Poser might be an example of something which explores that front - whether the Poser product in particular meets all of those needs is another matter, but its premise is on the right track.

The key is to develop tools which offer:

• Very little limitation with regard to their specialization.
  
• A useful specialization, whether it be weather dynamics, human expression, locomotion, architecture, etc.
  
• An explicit and comprehensive methodology for merging the tool's output into an environment.

[edited by - bishop_pass on January 2, 2004 4:58:29 PM]

quote: Original post by bishop_pass
I think tool developers need to address and accept the fact that while pure and unlimited flexibility is good, it also hinders development.

All the permutations of code, art and 3d models possible (and which can be developed with tools such as C, C++, Maya, 3d Max and so on) is a superset of what people want to actually develop. The ratio of that superset to what people actually want to develop is close to infinite.

On the other hand, specific tools and plug-ins often constrain too much. Graphics engines limit expression, but often don''t decomplexify development to a ratio equivalent to their constraining features. Moreover, artists and coders, working together, develop products which, while exhibiting quality workmanship, contain content which is obsolete for the next generation of hardware and incompatible with another genre.

We know that for the purpose of visual presentation, we in general need architecture for humans, props for living, and people. Tools which allow freedom of expression for the design of those objects with depth will go a long way. A product like Poser might be an example of something which explores that front - whether the Poser product in particular meets all of those needs is another matter, but its premise is on the right track.

The key is to develop tools which offer:

• Very little limitation with regard to their specialization.
  
• A useful specialization, whether it be weather dynamics, human expression, locomotion, architecture, etc.
  
• An explicit and comprehensive methodology for merging the tool''s output into an environment.

[edited by - bishop_pass on January 2, 2004 4:58:29 PM]

I don''t really understand what you are getting at here. Could you elaborate?

> A product like Poser might be an example of something which explores that front

Doesn''t that technology exist already? It is just an IDE-like integration that''s missing? Otherwise, I fail to understand your point.

http://www.reflex3d.com/
http://www.safework.com/
http://www.biographictech.com/

-cb