Archived

This topic is now archived and is closed to further replies.

Are We Trying To Over-Engineer Games?

This topic is 5356 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I''ve been reading the Manager in a Strange Land series of articles by Jamie Fristrom over on GamaSutra, culled from Game Developer as usual. Have any of you read them? In Manager in a Strange Land: Benchmarking, Part 2 he interviews Neversoft''s Mick West. Here''s an excerpt:
quote:
Jamie: Neversoft has consistently turned out top-rated games, on time, every time, for years. There are very few companies in the industry with that kind of track record. What''s your secret? That is, of all the things you do, what do you think is the most important thing for making a great game on time? Mick: I''d call it "game-driven development". It''s easy to lose sight of what your final goal actually is. Neversoft went through some very hard times in our early years, where we were less focused. The key is to ensure that everything you do is focused on shipping a quality game on time. The quality of the code is a secondary consideration. The quality of the next game is a secondary consideration. The only thing that really matters is the game.
And another:
quote:
I read a LOT of books on software development methodologies. My favorite is Rapid Development by Steve McConnell (Author of Code Complete). It''s a big, old fat book with a simple message: do what is appropriate. There is no silver bullet, you have to use a rich mixture of techniques that suit the problems at hand. And more importantly, that suit the people at hand. UML is fine, but practically nobody at Neversoft has even heard of it, let alone could be comfortable using it. UML does NOT communicate if you don''t know UML. In fact, the vast majority of current software development methodologies might as well be non-existent to most programmers. Even your best programmers don''t have the time to keep up on the latest "thinking" in this area, so you are just not going to find people who are familiar with concepts such as eXtreme Programming or Design Patterns. So fundamentally, we don''t explicitly do ANY software engineering practice. Like our game design process, our coding practices are a collection of useful habits we''ve picked up along the way, refined and tempered by the fires of hell (using them on shipped projects).
In Joel Spolsky''s review of Robert L. Glass'' Facts and Fallacies of Software Engineering he says:
quote:
If you have even the slightest bit of common sense, you should ask: “Where''s the data? If I''m going to switch to Intense Programming I want to see proof that the extra money spent on dog kennels and bird cages is going to pay for itself in increased programmer self-esteem. Show me hard data!” And, of course, we have none. One set of people will tell you you gotta have private offices with walls and a door that closes. Another set of extremos will tell you everyone has to be in a room together, shoulder-to-shoulder. Neither of them have any hard data whatsoever, where by “hard data” I mean “data that wouldn''t be laughed out of a sixth-grade science classroom.” The truth is, you can''t honestly compare the productivity of two software teams unless they are trying to build exactly the same thing under exactly the same circumstances with the exact same human individuals, who have been somehow cloned so they don''t learn anything the first time through the experiment.
Are we trying to over-engineer games? While systems and techniques and methods are important and useful, can we develop any formal doctrine other than the collective wisdom amassed over the years? Many then-young film directors have cited "the talk" they received while working for Roger Corman as having been more important than everything they were taught in film school. Corman is known for his guerilla style of filmmaking, but he''s also known for having produced more on-time and on- or under-budget flicks than any other Hollywood producer. I guess my question boils down to this: how applicable is today''s software engineering to today''s game development? Should, perhaps, SE continue as an academic and business software (where markets are not so seasonal or transient) discipline until larger, more complex problems like true component reuse are solved?

Share on other sites
quote:
Original post by Oluseyi
Are we trying to over-engineer games?

I know I always tend to :S

One of the best things IMHO about the Quake and Unreal engines is that they have simplicity where appropriate, and complexity as appropriate. Basically an application of XP''s Simplest possible that actually works. On a superficial level, the end user doesn''t care whether you''ve got a full neural net powering the AI or a messy series of  .. elseif ..  statements.

Share on other sites
>> The key is to ensure that everything you do is focused
>> on shipping a quality game on time. The quality of the code
>> is a secondary consideration.

>
> how applicable is today's software engineering to
> today's game development?

If you applied full SE principles to games development, you would have version 2.9.176 of SplinterCell. That is, it would be expected to have more than one release of a software title and thus long-term planning will be the foremost skill a games development company would need in order to survive. Maintenance, which according to many books, entails 80% of a product's life cycle is a non-issue in games (modulo some 'patches' for the PC platform). Games development is more akin to film making where a group of people band together to build a product and disbands once the product is done. There is rarely any expectation for a version 2 (as this is usually left to the producer's discretion), and far less about versions 3, 4, etc.

My point is that games are expected to be shipped on time and on budget where other types of software are expected to endure for years. You must, therefore, examine the underlying rationale behind a SE principle to see if it fits the 'shipped on time, on budget, one-shot deal' -types of scenarios.

-cb

[edited by - cbenoi1 on January 14, 2004 12:53:32 PM]

Share on other sites
quote:
Original post by Oluseyi
I guess my question boils down to this: how applicable is today''s software engineering to today''s game development?

First off, I''d like to express my appreciation and love of PostMortems. Buy this book.

Second, read that book. It''s sectioned into different categories, including Startups, Softmore outings, IP development and so on and so forth.

The most dominant idea is that experiance helps mold and streamline production. New design paradigms either: haven''t been tested extensively in the production field or haven''t been integrated into the production/design process.

As far as software engineering relevance, most engineering practices haven''t been around long enough to evolve. "Fads" come and go, but the test of time will yield proficient practices.

This month''s GameDeveloper has an article on Scripting: Diagonal vs. orthagonal tool sets. PERL is a very diagonal language set, one that the author originally scoffed at.

I consider game development as the forfront of some computer technologies.

Share on other sites
quote:
Original post by Oluseyi
I guess my question boils down to this: how applicable is today''s software engineering to today''s game development?

Should, perhaps, SE continue as an academic and business software (where markets are not so seasonal or transient) discipline until larger, more complex problems like true component reuse are solved?

Engineering means doing the best you can with the resources you have. It''s always applicable.
What''s ''true'' component reuse?

How applicable is today''s (civil) engineering to building a house? A dog-house? a sky-scraper? Some of it applies to each, and the planning should be proportional to the development.

It''s easy to over-engineer a simple project. As students, you do this intentionally as a learning exercise.

Share on other sites
quote:
Original post by Magmai Kai Holmlor
Engineering means doing the best you can with the resources you have. It''s always applicable.
Yes, it''s always applicable. The question was how much - to what extent? What about the more academic aspects of software engineering? The diagramming and documentation practices that are taught as gospel (and often promptly forgotten at the undergraduate level) in universities? What are the benefits? Does it actually help reduce cost, improve efficiency and maintain schedules?

Game straddle software and other forms of content. They''re not just applications, they''re entertainment, and that brings certain ethereal quantities with it - the designer''s need, sometimes, to sit alone and just think; the realization that the bar to be passed (fun) is subjective and the flexibility to deviate from the original plan and schedule, and so forth.

I don''t know, I''m just thinking "out loud".

quote:
What''s ''true'' component reuse?
Well, there''s a lot of hoopla about components and reuse, but I can''t purchase components from a vendor, plop it into my codebase and integrate it rapidly because there are different interfaces to components doing the same thing in virtually every industry. True component reuse is something like in automobile engineering, where an engine - be it rotary, 4-stroke, 2-stroke, reciprocating, V8, V12 or what have you - has the same inputs and outputs, which allows an integrator to take preexisting components are rapidly build a working vehicle. A few fitting widgets (input nozzle for system A doesn''t match output hose from system B, so we fashion a convert/adaptor/clamp) may need to be fabricated, but nothing severe.

In software engineering we don''t have that kind of taxonomy available, so a given component may take radically different inputs - or different formats - than another. Since these same inputs are likely to be used in many places, the cost of transforming them back and forth may rise to the point where it makes the entire project effectively worthless. In the same review of Facts and Fallacies of Software Engineering, two of the facts and fallacies are that:
• Reuse-in-the-small (libraries of subroutines) began nearly 50 years ago and is a well-solved problem; and

• Reuse-in-the-large (components) remains a mostly unsolved problem, even though everyone agrees it is important and desirable.

quote:
It''s easy to over-engineer a simple project. As students, you do this intentionally as a learning exercise.
But are games simple? A cursory glance at the titles currently available and those under development would say no. While they may not be as complex as industrial software, I wouldn''t call them simple either; I think the difference is the maintenance factor - or the relative absence thereof in game development. When making a game, you try not to simultaneously creating technology - unless you''re id Software and essentially are making the game as an advertisement for the technology (intentionally or not).

Share on other sites
Aye, I agree that Software Engineering is usable to some extent in Game development. In many aspects, SE is ALWAYS critical.

Gone are the days where a single coder could ''hack out'' a commercial quality product... well, it''s possible, but not reccommended for that one poor sap''s sanity. =) One person doing development on something can keep a good track of a project as long as they''re personally disciplined: after all, the whole thing is in their head.

But what happens when multiple people are working on a project, and only one person has that ''vision''? Or worse yet, what if the ''vision'' of the project takes parts of what everyone is thinking about it?

Software Engineering, to me, is a way to make it so that the people working on a given project will know exactly what the goal and process to get to the end of the project is. When the project is not entirely the work of one person, or others need to get in on it, there is something needed to substitute the focusing power of having a true knowledge of the goals. That something is documentation, design, analysis, implementation and testing - it is software engineering.

I, for one, have a romanticized view of the ''hacker'' group - a group that can get together and ''hack out'' a game without the need for such documentation. Such a thing though is very rare in reality, and it''s a miracle if the end product of it is commercial-grade quality.

Perhaps if a group is focused enough, or knows each other well enough, they can get by without it. But if they barely know each other (as is the case most of the time on projects), then they need this formalized process.

Share on other sites

You have to remember in which context those came into existence. In my college years, a ''typical'' system weighted hundreds of KLOC and involved tens of programmers over many years. Most of the samples from academic books were airport control systems or retail sales & billing systems; in essence, big mainframe application that only large organizations could afford. The Waterfall model was the perfect paradigm for government-sponsored projects where cost accounting was in sync with the achieved milestones; the blue copy of the design specs went to the archives and the pink slip for the specification requirements was forwarded to the project accountant...

With PC game development cycles around 24 months and cell-phone titles now running more around 3-6 months, it''s no wonder that many of those SE principles are no longer valid. You simply don''t have the time nor the bandwidth for handling unnessary administrative processes. As stated above by others, project planning and management is a skill you learn along the way.

> The diagramming and documentation practices ...

... are still in use today. Just look at any software patent. Also, ask people in the heavy industries where FORTRAN & COBOL used to be dominant: Boeing, Rockwell, NASA, Visa, ...

They are still the basic language two programmers with different backgrounds can use to exchange algorithms and data structures. I''m new to UML, but I can still read a flowchart anyday. Would I use flowcharts for my own game designs? Hell no!

> Game straddle software and other forms of content.

And entertainment is mostly a single-use, throw-away product. No wonder that the engineering behind it also follows the same paradigm; tools that make up games are more likely to follow stricter SE principles.

-cb

Share on other sites
it doesn''t matter that they''re entertainment. design is separate, or can be, from Software Engineering.

i think cellphone games take less than 3 - 6. more like 1 - 3. at least that''s the timeline my friend''s company works on. (and yes, they ship the games, yada yada)

Share on other sites
quote:
Original post by VThornheart
I, for one, have a romanticized view of the 'hacker' group - a group that can get together and 'hack out' a game without the need for such documentation. Such a thing though is very rare in reality, and it's a miracle if the end product of it is commercial-grade quality.

I'm fairly sure thats due to the shear complexity of modern games, and lack of time and money to develop them in.

[edited by - ggs on January 20, 2004 11:19:54 AM]

1. 1
2. 2
3. 3
Rutin
21
4. 4
frob
18
5. 5

• 33
• 13
• 10
• 10
• 12
• Forum Statistics

• Total Topics
632568
• Total Posts
3007119

×