quote:

---

Original post by cbenoi1
http://www.reflex3d.com/
http://www.safework.com/
http://www.biographictech.com/

---

Those are excellent examples of niches being filled, validating what I''m saying, not contradicting it. A suite of tools such as those which function and merge seamlessly together, and addressing all aspects of a game''s requirements would essentially serve as the foundation for the solution being sought in this thread.

Then send a mail to Gareth Morgan {gmorgan@softimage.com} with your deeds (and the links I've provided). He is someone who listens, has the power to make things change and is keen on getting industry feedback on such matters as this thread.

-cb

[edited by - cbenoi1 on January 2, 2004 5:30:36 PM]

Ok, what is MonsterGame ... it''s just a stupid word I use to clearly identify an age old Software Engineering idea for development ..

ENGINEERING for building bridges and architechture etc is well understood (mostly), and so a show (MonsterHouse anyone) can exist where they get 5 strangers together with different specialties needed to acomplish a building task ...

this is possible because of at least 2 things ... enough advancement in the engineering / building knowledge to allow people to have a good guess about what is possible and how hard it will problably be to acomplish ... and enough seperation between the duties to allow different people to take on "tasks" with only a basic understanding of the project as a whole and what the people around them are going to do ...

SO, in software ... we MUST come up with a common enough system that a SOUND engineer / programmer DOES NOT NEED TO KNOW how the graphics engine works to any large degree, nor the networking, nor nearly anything else in the game ... just the general goal and the specific needs for the sounds ...

he might choose to work with the other people, for a shared vision / artistic creation ... but as bishop_pass noticed, that''s not really the work of the indivuduals by necesity ... it''s usually the work of a "Director" whose job is to control the vision of the project and make use of the specialists to get the job done ...

My suggestion for current technolgy ideas to go down this path ... define the basic game functionality ... and then define the MESSAGES / EVENTS ... from this way of thinking, the sounds don''t need to know graphics ... or networking .. just the GAME EVENTS ... everyone then has a common language and place to hook into (the event queues and the event definitions) ...

If we develop some basic building blocks that describe, create, expose, provide these events IN A WAY that is largely platform agnostic, and not rapidly changing ... then this can be the platform on which the new world of development comes into being ... a world where different tool vendors and artists come together by interfacing to a common MINIMAL model ...

it''s like handing a "blueprint" to a sound guy and saying ... here''s the ABSOLUTELY REQUIRED game events that are going to happen ... and here''s some OPTIONAL game events that the game or game engine guy is hoping to support - can you make it sound cool ... kinda dark and ominous most of the time ... but with some audio rewards for acomplishments made ...

etc ... just one simple example ... the sound guy then goes into his TOOLBOX of sound libraries / engines / sounds, and other usefull tricks of his trade (like his UltraSoundScript language he uses to layer his sound effects via events / time / and progressive sound scape state ...) and starts making it happen ....

the game engine guy PROTOTYPES a fake game, by creating a sample file which fires events AS IF the game is being played ... and LOW AND BEHOLD ... a hush falls over the developers as the HEAR the monsters breathing, the dagger plunge and the music SOAR!!! ... all with no graphics, no networking, and no game ...

and in parallel to this ... the graphics guys busy at work ... TIED CLOSELY with the game engine guy (cause these two are impossible to seperate with current 3D technology levels ... the graphics engine and physics / game engine are still unfortunately tied closely at the moment) ... and they pull out their placeholder models "small character" "big character" "simple forrest" and "blade" ... which they began tying into triggering and recieving game logic events ... or something ... this is NOT my strong point area ...

and the networking guy gets his overview of the game and events and begins segregating server side and client side, secure and insecure messages ... looking for likely cheat areas .... and in HIS bag of tricks are, lobby code, encription, data transports, authinticationg, and latency simulators ... and he goes to work ... he takes the fake data file from the game logic guy and creates a second user or server file ... and begins modeling their communication and adding fake latency and disconnects to identify holy terror crash points ... he sniffs the packets to see glaring cheats - and then he provides a nice extinsible message passing library and all the messages clearly processed and sent to the correct places (local, specific client, all clients, server, etc) and with correct security (plain, encripted, etc) ... and publishes his expected latency or bandwidth requirements (can prob support 2 users on 33k, 8 on ISDN, etc ... or, cannot handle latency higher than 800ms) ...

that''s my vision ... a unified base for all, and a great big growing toolbox for each ... and then we become something more than we are today, because we can work together without months of training and terminology lessons, and specialists can come together without reinventing every wheel ... and games can be made in weeks or months, not months or years ...

SURE, NEW content for a thousand solar system space game will take a LONG time to create ... but the basic system will not ... and years later, there will be many objects, models, data, sounds, graphics, event sets, games modules, etc ... all there, using the semi-standard systems ... ready to be mixed and matched to create "new" games ... ready to be extended and enhanced ... or even limited to form new challenges ... just like the REAL world ...

we make a new sport out of EXISTING fields and equipment - we don''t INVENT a bat first, we find a stick ... then we improve it towards our needs.

I must take issue with this ''rant''...

quote:

---

Original post by Sphet
Larger teams, more experienced individuals, higher accountability to the publisher.

---

I won''t say anything on larger teams, but just post a link: The Mythical Man-Month: Essays on Software Engineering.

As for ''more experienced individuals''... that''s pretty impossible because the game industry is difficult enough to get into as it is. You can''t have more experience and bigger teams. You have to recruit from somewhere.

quote:

---

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.

---

Problem: experienced programmers don''t want to work on tools, they want to work on products.

Re-use of tools and engines and the like is probably good though.

quote:

---

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.

---

All the latest revolutions in software development such as extreme-programming and test driven development pass you by then? The days of the monolithic requirements spec are past, as people come to realise that they''re not worth the paper they''re printed on by the time the product is even half developed.

quote:

---

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.

---

This part I wholly agree with.

quote:

---

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.

---

And this part I don''t. Having a few distractions around the office doesn''t harm productivity. It relieves stress, builds team spirit, and helps to ensure that you have people who understand the idea of ''fun''. Far better to set reasonable targets and let people work to those, rather than removing all external stimuli in the hope that it''ll force them to work harder. If I spend half my waking hours at work, it had better be enjoyable. I''d much rather have a relaxed and fun environment than Christmas bonuses.

You''re also placing a lot of blame on developers when a significant part of it should fall on publishers. Publishers have been known for arbitrarily changing deadlines and shipping products that they knew were not ready, despite the development team making this quite clear to them a long time before the event. Unreasonable deadlines are part of the cause of ''crunch time'' and the foolish hours that some places end up having. The short-sightedness of publishers is another reason why research and the feasibility studies you desire are not practical. Publishers don''t pay unless you have a product. Need I mention the occasional obsession with branding and marketing over the quality of the product? Daikatana was allowed to slip and slip because the publishers thought the John Romero brand would sell it, despite the game being useless. On the other hand, Looking Glass studios were allowed by the same publisher to go bankrupt, despite that team showing beyond a doubt that they were producing consistently high-quality titles that sold well.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost
Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

I''m not part of the game industry, but based on what I''ve read all over the internet, I think Sphet''s rant made a whole lot of sense.
The developers won''t change how games are made alone by using new kinds of tools. The whole industry needs to change and mature and likely the changes should start from the publishers.

I also like what Xai said.

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.

---

Yes! This is what I was trying to say on IRC the other day. Bishop, it''s a pity you don''t visit, you might have enjoyed that discussion

Developers work at varying levels of abstraction. You might have a PS2 programmer who writes a graphics library at the very lowest level (i.e. in assembler). Then you''ve got C++ programmers who make use of that library, operating in a higher-level language which is faster than ASM but not suited to creating the finely-tuned graphics library. Above that you''ve got level editors who write scripts which manipulate objects and call functions written by the C++ coders.

But there''s still a large disparity between the abstractions available, and the abstractions that would be most productive for team members. I worked with a designer who told me he wanted a tool that would let him prototype and test gameplay without him needing to be a programmer; there are things like Klik ''n'' Play around, but they''re severely limited. That''s just for game design though.

Why are 3D artists still having to work with polygons so much of the time? They do have *some* abstraction; they manipulate the control points that compose NURBS surfaces, rather than playing with vertices themselves all the time, but still... why not use one tool to generate a humanoid character with given characteristics, and then drop down to polygon editing for specific details which the first tool does not provide? You end up with a whole suite of tools for generating specific types of model algorithmically; we already have tree generators, but how about human generators, cat generators, dog generators, horse generators?

Even better - with regards to ''tomorrow''s games'' - is that simplification can be applied *after* the tool has been used. You can generate a million-polygon human head. The fact that you then downsample it to a few hundred is just a reflection of the state of today''s technology; maybe next year you''ll be downsampling to a few thousand instead.

A game designer can''t just click on an enemy and press a button that says ''make harder;'' but that''s what he *wants* to be able to do. In exposing all the governing numbers for that agent''s AI, any changes will be in persuit of a wider goal: making the enemy harder, making him easier, letting him see further, letting him hear more/less clearly. How many times have I had to change all three ''near/mid/far visibility range'' values by the same amount, just to create a consistant net effect?

It applies to all areas of development; anyone saying that coding will never change really should look around a little more. I''ve already come across a number of ''state machine generators'' which allow you to design an entire state machine visually (and then generate code for it). The new Visual Studio (Whidbey) has built-in ''Refactoring'' commands, to make a sequence of changes in one motion. It''s a move away from the basic steps - typing out code - and towards the overall goal - achieving a specific behaviour from the program.

Richard "Superpig" Fine
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4 | Enginuity5
ry. .ibu cy. .y''ybu. .abu ry. dy. "sy. .ubu py. .ebu ry. py. .ibu gy." fy. .ibu ny. .ebu
"Don''t document your code; code your documentation." -me
"I''m not a complete idiot; parts of me are missing." -}}i{{

Among other things, I think it would be perfectly appropriate to develop custom languages for developing specific types of games.

For example, you''d have one type for adventure games (of course they already have SCUM which was used on Monkey Island games), for puzzle games, another, for RTS another, FPS another, etc. There really usually is a significant amount of commonality among games in the same genre (in my experience).

The languages should present the developer with no more detail than they want (kind-of like Java). In a sports game, the developer should get direct access to all kinds of physics commands/formulas/reactions WITHOUT having to code them themselves. Collision detection should be built in, etc. Rendering should be a part of the language itself. Now before people scream at me, they should also be modular and updatable. That is, if you don''t really like the default rendering scheme because you think you''ve figured out a great way to handle self-shadowing with displacement maps in your FPS, then you can override any appropriate language module definitions with your own lower-level code.

But honestly it feels kind of forced using generic development software on games, because how many times do you write that rendering loop? Collision code? You''re going to have a player-interface binding, game rules, reactions, graphical and audio responses. I know that there are engines now, but why do we even need to code in C, VB, C#, Java,...? Those languages weren''t made for games, they were made for systems/business development. We don''t need everything they have and they don''t have everything we need.

The time is now! Are you with me? (Sorry, got a bit melodramatic there). But seriously. Why not? I''m thinking of this breakdown:

- Platform Jumper
- RTS
- FPS
- Adventure
- Action
- MMORG
- Arcade
- Puzzle
- Physical Simulation
- Sports

quote:

---

Original post by bishop_pass
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]

---

Hmm, it is spent more creating the renderer than actually making the models (as that goes on during the rest of the dev process making it actually not take any more time), I think we should just have a more speciallized OpenGL/DX (wait that would just be a wrapper...)

---

It''s Maxd Gaming, put in an underscore and I will beat you with a rubber ducky!
{ Check out my Forum } { My First Space Art (Ever) }{ My Second Space Art (Ever) }{ A upcoming space RTS codenamed Gruntacktica . }{ . }

quote:

---

Original post by maxd gaming
Hmm, it is spent more creating the renderer than actually making the models

---

No.

Especially given that many games just buy in an external renderer (middleware). Or use one from a previous project by the same studio.

We''re talking about professional development here, not hobbyists.

Richard "Superpig" Fine
- saving pigs from untimely fates, and when he''s not doing that, runs The Binary Refinery.
Enginuity1 | Enginuity2 | Enginuity3 | Enginuity4 | Enginuity5
ry. .ibu cy. .y''ybu. .abu ry. dy. "sy. .ubu py. .ebu ry. py. .ibu gy." fy. .ibu ny. .ebu
"Don''t document your code; code your documentation." -me
"I''m not a complete idiot; parts of me are missing." -}}i{{

http://c2.com/cgi/wiki?ExtremeProgrammingForGames

Perhaps?