Thoughts on Current Video Games

With material from

EVL graduates who have done work for video game companies


Odie has worked for Midway games for several years

I've been doing AI in the past 3 years instead of graphics.

Basically the whole industry is moving towards using Graphics Libraries like Renderware (by Criterion). So it is like using OpenInventor.

-----

-----

oh, and scripting languages is very big now ... both in the art tools (like 3d studio and hash animation master) and the actual game engine.

networking for some reason is still not widely supported, maybe in a year or two.

------

graphics wise

-----

less we forget about memory management ...

still not enough memory!

-----

animation system


Ben has worked for LucasArts for a year

For starters scene-graph based graphics have not faired well in the console gaming world. Though I appreciate their architectural strengths, it often results in far too much overhead in both time and space. Recent games have found that after texture downloading the next biggest performance hit is scence graph overhead.

If all you want to do is cull the scene or perform intersection testing, it doesn't pay to traverse 100's of base class objects through many levels of indirections (going say from a game object, to a graphics object to it's poly sets). Rather what you want is a lean set that is much more specialized.

On consoles time and space is everything. Unlike PCs where you can code and forget about it, you're very much aware of every minute detail from structure sizes, to member offsets and byte alignment. Many of the consoles can't deal without very specific alignment requirements.

At my work programming groups run from about 4 or 5 to about 10-12. The average size is probably 5 or 6. For the most part game progammers are encouraged to specialize in one area. A successful programming team demands that it's members have an arsenal of experience and algorithms behind them. It's difficult to amass that kind of experience if you don't focus on one area.

The rest of the team which includes artists, art techs and production staff brings the count up to about 40 or 50.

The programming team tends to interface with eachother when there's cross over, but a good lead will keep the communicaton lines open and regular meetings keep everyone up to date. People don't generally work in a box, and in those rare cases where it does happen, it usually results in an unsuccessful project.

Building a game is not about building an accurate model, but building something that looks good and
plays well. May projects have been doomed because someone tried to build an uber physics engine. Also the keep it simple rule has never been more relevant. Large hierarchies with complex relationships do not fair well when it comes to code sharing and engine reuse. Successful code tends to be succicint and to the point. If it gets the job done and has simple hooks to expand it, it will probably go a lot further than a large convuluted framework that is no use to anyone once the author has moved on. Programmers tend to chose the path of least resistance and would tend to build it themselves rather than spend weeks pouring through someone else's work. If all you need is a dog house, build the dog house, don't plan on the sky scraper unless the problem demands it.



last revision 2/7/02