i think one of the most strongest things is, to gain _real_ professional knowledge & experience; this means utilizing your language at the maximum level; most programmers are keeping stucked at a distinct level, i think - from then one growing more and more seems pretty hard; i see so many people which are writing in todays application code as bad as 10 years ago.


DJSnow
---
this post is manually created and therefore legally valid without a signature

[edited by - DJSnow on December 31, 2003 1:18:15 PM]

Monster Game ... I''ll elaborate later, gotta run (bookmarking this thread for later)!

quote:

---

Original post by 5010
How about metadata is to a database as metagame is to a game. In a database systems class we were taught how to create tables that define the metadata, so that the database is self-describing. Then you can use the same tools that operate on you application's table to operate on the metadata tables.

---

I think metadata could be a step in the right direction and I've been keeping that in mind as I design/code/redesign... my latest greatest project. Metadata can be of enormous use when it comes to designing tools.

As far as bishop_pass's question, as a programmer/developer I'm on the fence with respect to new paradigms. On one side of the fence I realize how long it takes to create (design, code, test, redesign, code...) a game - and this is what makes me valuable or should I just come out and say "It's what allows me to buy bread"? On the other side, as you may have guessed, I realize that this something new would allow folks that may not have the capacity to create a game now, to do so and that may impede my ability to buy bread.

Of course, any new technology that seems as though it may replace the work that is done by those with skill is always met with fear. I remember reading back in the mid 80’s about some orchestra members were afraid of MIDI. They were afraid that the skills that they had to offer would be of little us with the advent of this technology… 20 something years later and I would say that most metropolitan areas still have locally funded orchestras.

I know that I’ll be ridiculed by saying that .Net is also a step in the right direction. Two nice things about .Net (C#) is 1) We can wire our classes up to the property grid and manipulate those properties at design time and/or runtime, very nice for tool development and 2) We no longer need to create a scripting language. I’ve written an article and posted it to my site regarding some of the benefits of .Net.




Dave Dak Lozar Loeser

"Software Engineering is a race between the programmers, trying to make bigger and better fool-proof software, and the universe trying to make bigger fools. So far the Universe in winning."
--anonymous


-- EDIT: Darn tags

[edited by - Dak Lozar on December 31, 2003 1:32:19 PM]

Melting pot developement. Design a api standard for executable modules. Release it to the world. People write abitrarty modules and subimit it. You dont know what it does but you do know it takes inputs and outputs. Using a genetic algorithims which links these modules together in different ways, to produce a desirerd result. Over time only the best combo of modules survie. Viola, instant application. Modules can be reused by others for their projects too. So as time goes on, more and more moudles are developed. Eventually the most stable and best modules remain.

Good Luck

-ddn

This post got me thinking.. it seems like the natural answer is to be able to borrow from other projects so that you don''t have to rewrite (or re-create) certain things. However this raises the an issue that if a method like this was adopted accross the board, games would start to get very similar to each other.. the rules would all end up based on the same set of functions, procedures and objects..

But I''m sure there is a solution that would help the process.. I''m a programmer so I''m thinking in the programming side of development, but it might be easier to speed up the other sections of development..

Maybe something like how they are using those camera''s to study the motions of people in order to animate sports games.

This really isn''t a "different paradign" but I would say the current biggest trend towards faster game production is simply reusing engines, and this trend is getting larger and larger. Look how many new first person shooters are in the market these days now that people can just license already created engines and just concentrate on the game play? And you can see how this trend is evolving just by looking at the quake series. Quake 1, one licenses game (hl). Quake 2, 2-3 licensed games (Well, about that), quake 3, dozens of licensed games. I''m betting that at some point, perhaps with the d3/q4 and/or hl2 engine or perhaps the next generation theres going to be (at least in the fps world) an engine "plateau" in that it''s just not worth trying to design a better engine from scratch. I''ll also bet that this trend starts spreading to other genres, as soon as someone releases an easily moddable RTS engine.

I think that text-based programming has already advanced about as far as it''s going to. The real hope for the future of development, IMHO, is graphical paradigms. I think of the IDE of the future being very similar to a UML tool such as Rational Rose, but with more complex, comprehensive, and formalized semantics. It would also give good visual cues to the conceptual organization of an application. Textual programming would be limited to things like expressing complex equations and algorithms.

---

"Sneftel is correct, if rather vulgar." --Flarelocke

quote:

---

Original post by Sneftel
I think that text-based programming has already advanced about as far as it''s going to. The real hope for the future of development, IMHO, is graphical paradigms. I think of the IDE of the future being very similar to a UML tool such as Rational Rose, but with more complex, comprehensive, and formalized semantics. It would also give good visual cues to the conceptual organization of an application. Textual programming would be limited to things like expressing complex equations and algorithms.

---

No offense, but I think you''re on crack. Have you tried "model-driven engineering"? It''s fine for very small subsystems, but as the abstraction level rises, it becomes more and more difficult to assimilate information across systems, because you don''t have the common dialect that is described by textual code. There are areas where this is mostly untrue - GUI engineering, of course, is a very different thing from business logic. But by and large an alphabet forms up into a language, and it turns out that no matter how you represent your code, you need both of those. At the level of a typical production system, you still need to have the abstractive power and the granularity of a base language.

All IMO, of course.

ld

I think one needs to decide what will exist in tomorrow''s games, and then develop content for tomorrow''s games, with the ability to simplify that content for today''s games.

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.

to stick with my first analogy, look at the movie industry, aside from better tech, it's still the same old concept of a story conveyed through a moving picture screen.

I can see some of this maybe evolving with "games" such as geocaching where the game exists in the real world. Some real cool ideas could be brought to existence with a wireless pda/phone/GPS combo (massively multiplayer real-time gaming??).

--edit: disclaimer, I didn't mean to come off sounding like a joykill ... brainstorming sessions like this are absolutely nescessary or else we certainly will be stuck with the same old "paradigm" for a long time.

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

[edited by - joelmartinez on December 31, 2003 9:42:15 PM]