quote:

---

Original post by joelmartinez
Tomorrow''s games huh? well, aside from better technology (graphics, ai, etc.) I don''t see how it will be much different unless you totally break out into a new medium.

---

That''s perfect then. Develop better more detailed models. They''ll actually be useful for tomorrow''s games as well as today''s. That''s a start towards reducing the workload for development tomorrow.

And don''t just think in terms of polygonal count.

well, to that end, I saw a post floating around here about someone who's working on a hardware raytracer (don't remember who or where though). I guess that's enough of a paradigm shift (boy do I hate the word paradigm ... it was so overkilled when .net came out) to warrant what you're looking for.

I was reading a few of the threads around that and it would basically mean redefining much of what is currently known about graphics programming since many of the current algorithms are based on polygonal geometry. Of course, the end result (once said result is reached) would be much better graphics (in theory of course).

So I guess that would get my vote for "The next thing" ...

--Edit: here's the thread
http://www.gamedev.net/community/forums/topic.asp?topic_id=197516

Joel Martinez
http://www.codecube.net/

[edited by - joelmartinez on December 31, 2003 9:58:46 PM]

Here's an observation: 90% of today's development time (and likely tomorrow's) is comprised of developing 3d models, their movement, and their rendering.

To reduce that 90% (let's call it five man years) to one man month, perhaps what you want is to approach the problem as a director would - which means that the models already exist and can confrom to how you want them to look per your direction, and then act, or behave how you want them to behave per your direction.

[edited by - bishop_pass on December 31, 2003 10:09:37 PM]

well, I guess (just to play devils advocate) I could argue that this already exists. There''s free and commercial models available here and there.

You could just go to a talent agency and find the actor. From there you can modify his or her look in the studio (ie. 3d studio max) and direct his or her behavior in the game engine.

Joel Martinez
http://www.codecube.net/

when you speak of film, it appears that you are forgeting that for each actor it usualy takes about 18 manyears to create the "Model" you get where im going here. Directors get to use Models that have had a long time to be created and in many cases said actors also put as much of the movie in the movie as the director. Looking to the Movie industry wont solve our problems, Acepting the Video Game industry''s Place in the world will. Improved Graphics is not a radical concept. Adding more objects to your RPG isnt a radical Concept. The only thing we can change is how things interact, not how things are represented or how many things there are. I really hope this isnt total Giberish. PS I am one programmer/Designer that is going to stick to the "old ways" ie. come up with an idea, write it down, Build the basic components and then put them togeather.

quote:

---

Original post by joelmartinez
well, I guess (just to play devils advocate) I could argue that this already exists. There''s free and commercial models available here and there.

---

No - not really of very high quality - and they don''t conform to your needs. You might want to look closely at what I said, and instead of finding something remotely similar already out there, look at exactly what I said. There''s a world of difference.

quote:

---

Original post by joelmartinez
You could just go to a talent agency and find the actor. From there you can modify his or her look in the studio (ie. 3d studio max) and direct his or her behavior in the game engine.

---

*sigh*

I just said that methodology takes a huge amount of time - that''s what I said needs to be streamlined.

I think we need compilers which understand a natural language. Then you can just say, "Make a program which can do anything" or "Make the best game of all time" and there you are. That would rapidly speed up development time. And its very easy to make such a compiler, all you have to do is tell a compiler similar to it, "Make a compiler which understands English". Somehow, though, I think it would still manage to find syntax errors.

The official zorx website

Suggesting current software and data and "the way we do it today" as being solutions is against the theme of this thread.

Likewise, suggesting fairy tale compilers is also non constructive.

[edited by - bishop_pass on December 31, 2003 11:21:10 PM]

quote:

---

Original post by PlayGGY
If it is a different style of programming you are looking for, just don''t program in an object oriented style, and "design as you go". Again, you will lose out on a lot, but save tons of time.

---

Though I''m not yet willing to say you''ll lose out on much as you seem so say without any further explanation, what about what you''ll gain?

Bishop,
In terms of your model proposal, how would you go about setting up such a tool? Drawing from certain trends in your other threads, do you envision a system similar to that in the Using Lisp to Generate Fictional Characters and the corresponding A Program to Facilitate... threads?

Actually, many of my ideas for speeding development time have actually been discussed in various threads in various forums here. One very interesting thread was about constructing the architecture of an entire city algorithmically. I tend to think of it not as reducing the development time, but making it easier to develop a quality independent game.

On the development side, a very heavily over-engineered object oriented game component library (though not in any conventional sense) could perhaps work. Many games have very similar features: virtually all games today have (with or without using the engine) cutscenes at various points, they all require a menu at the beginning, they probably have some interface to create and modify keybindings. Furthermore, game entities require and provide certain things. An entity has or may have a model. The entity''s model may need to perform an animation or other procedure (we wouldn''t want to limit ourselves to animations, when IKS is a possibility) in response to a keypress (PC) or the action of another entity (NPC). An entity may need to be subjected to the laws of physics every frame. I''m convinced that standard object-oriented techniques are not up to this task; I would turn instead to a new phenomenon called prototype-based inheritance, typified by a Smalltalk-like language called Self. I think further explanation would go beyond the scope of this thread.

On the textures/skins side, I think a standard skin texture (procedural?) for human models that can be colorized for various complexions would be useful, if it does not exist. I think it''s counterproductive, at least at first, to bundle clothing with the model (and therfore the skin), although this would probably be one of the (biggest) optimizations made when reducing polycount of a model.

On the 3d models side, I pondered whether a decent-looking animal could be generated from modelling its skeleton (which is more easily decomposed into "parts") than each part of the body. After that is done, the bones are connected with ligaments, muscles are attached to tendons, and skin is layered on top of muscle. I have no idea how this would look (you can consider, for this purpose, that cartiledge is a part of the skeleton).

Another opportunity for modelling comes from advancements in computer vision, specifically in object recognition, and the proliferation of digital cameras on such things as cell-phones. Theoretically, one could model an object by taking pictures in an approximate orbit around the object. (plus hints or more photos for the top and bottom, not shown by any of the photos)

As for level-building, it''s been a long time since I''ve used level-building tools, but they were rather hard to use at the time. I hope by now they allow some sort of floorplan design, at least for the conventional parts of buildings. To build an octagonal room, you''d draw an octagon with point-to-point, and it would ask you how thick the walls are, and how tall the walls are, and it would make 8 walls and a floor. Then you''d draw tick marks where you want the door, and it would ask you how tall the door is, whether it was double-doored, and which way the doors turned, and it would make the door from tick mark to tick mark, and indicate it on the diagram. With a whole slew of partial solutions, designing any building with a somewhat conventional architecture should be a piece of cake. For any of the harder stuff, the standard tools would be available. Another benefit of this is that quality level maps could be generated automatically (as opposed to the original Jedi Knight level maps). Call me old fashioned, but I really liked this feature of Doom, System Shock 2, and lots of RPGs.

For anything larger than a single building, see the thread about generated cities.

On the music side, there''s a bunch of stuff under the heading "algorithmic composition". The idea is to construct a musical piece by describing an algorithm to generate and manipulate high level musical concepts such as movements, themes, and phrases. Evidently, it works extremely well for techno (which is dominated more by rhythm than pitch).