Speed for developing

Maybe Dark Basic-like software, but faster and more customizeble?

My game: Swift blocks

C#? :-P

but seriously ... though I don''t have any specific ideas, my only thought would be to look to established and slightly related industries to see how they do it. First thing that comes to mind is the movie industry.

They''ve got standard equipment and methodologies that (more or less) abstract the low level aspects of making a movie so they can concentrate on the artistic aspects of the project. For example, they''ve got the camera which abstracts the process of getting their content into viewable/editable format. wait, this is starting to sound like a game engine ... oh well, back to the drawing board.

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

Lisp is already here. Lisp is something that developers can already to choose to use, if they feel so inclined. The direction of this thread should be aimed at discussing that which is not here yet - some set of tools or paradigm not yet in existence that should be created for the facilitation of development.

Erasmotron?

ld

Sorry, didn''t notice your last post there.

Did you have anything in particular in mind, bp? I think at this point that it''s more likely that we have to find new ways to incorporate two-sided human intervention into games. Neverwinter Nights is a decent example, every MMORPG has more examples. But then, MMOGs are more useful as social augmentation than as implements of drama. Erasmotron might be the work that deals with that best.

There used to be threads here discussing the idea of a situation-driven vignette story engine. I think that''s a tool worth pursuing, except that the Erasmotron patent probably covers it.

ld

Some kind of genetic like game building blocks maybe? Or, maybe games that evolve... You enter a few values for the type of genre, and whatever other specifics you want... And then you let the computer evolve the game. It would first hatch all the pieces that would be in the game, then it would combine them in wierd - and mostly useless ways-, and in the end the strongest, most streamlined, best game that fits with your selections is created.

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.

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.

[edited by - PlayGGY on December 31, 2003 12:36:01 PM]

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.

So take that analogy to metagame. Is it possible to describe a metagame in terms of a game? Then developing is a matter of "playing" the metagame to build or enhance or change the resulting games, but all using the same set of tools.

Seems to me you could come up with a system that is actually slower than the classic development methods. It would be a challenge to come up with something speedier. On the other hand, a multiplayer metagame might be a great way to facilitate cooperative efforts.

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]

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]

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]