Are We Trying To Over-Engineer Games?

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.

>> 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]

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.

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.

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).

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.

> What about the more academic aspects of software engineering?

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

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.

---

Commercial-grade quality in games is sadly lacking for the most part.

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]

I don''t know if you''ve seen it yet, but we just had a discussion over here that was tangentially related to this issue. I''m still at the repeating-smarter-people''s-words phase in a lot of ways, but I''ll submit this as a good summary of my feeling:

quote:

---

From Bill Caputo''s blog:
I don''t set out to do XP in order to make my projects work, I set out to make my projects work, and I just happen to find XP helpful in doing that. If I didn''t I wouldn''t do it.

---

I''d like to get to that point where I''m just doing things because they click , you know, just make make a difference in how fast things go, how easy things are to change, how comprehensible the code is to another programmer, how performant the critical sections are. I don''t really have the game dev attitude, because I work in another sector entirely, but software is still largely software. Game development still needs to acknowledge that the longer a bug lasts, the harder it''s going to be to fix, and that means that quality-oriented development is still critical to the development of any project, even a one-off.

As dev cycles lengthen, this fact is likely to become even more pronounced.

ld

quote:

---

Original post by liquiddark
I don''t know if you''ve seen it yet, but we just had a discussion over here that was tangentially related to this issue.

---

I''ve been following that thread, but being posted in Game Design it''s been flooded with tons of, frankly, underinformed opinions. A good discussion eventually emerged about new paradigms in software development (Superpig, Washu and I were actually discussing the same thing with a few other visitors in #gamedev a few days before that thread was started; I could see the influence of our discussion on his opinions), particularly the place of graphical development. I think that a useful tool that employs UML and flowcharting as the design process itself, dropping into text to implement individual program statements that can be realized no other way (again, see National Instruments'' LabView), could play a crucial role in making certain SE practices more central to development, and more familiar to a wide range of developers.

(I''ve been trying to get Washu to write it for me... )

quote:

---

From Bill Caputo''s blog:
I don''t set out to do XP in order to make my projects work, I set out to make my projects work, and I just happen to find XP helpful in doing that. If I didn''t I wouldn''t do it.

---

I think Mr. Caputo''s attitude is a correct one. Unfortunately, it''s also a relatively rare one - most proponents of a particular software engineering technique tout it as gospel, rather than as a practice which may or may not be useful to a particular configuration of individual developers/teams.

quote:

---

I don''t really have the game dev attitude, because I work in another sector entirely, but software is still largely software.

---

Yes and no. Yes because of the obvious shared attributes - code, reliability requirements, performance requirements, etc. No because of the divergent purposes: For the overwhelming majority of game software, maintainability is a very minimal requirement, quite unlike non-game software (exceptions being game engines to be licensed by other developers, MMO games and so forth). In most cases, once the game has been released and there are no critical bugs requiring addressing via a patch, it can be "discontinued" as a supported product and left on the shelves as a retail item. The developers move on to the next project.

Is that wasteful? It depends on perspective. Game development is very sales-driven, and it is important to deliver the title within a certain period of time or consumer anticipation falters (see Duke Nukem Forever); technology advances beyond the game, resulting in an anachronistic title; and critical buying seasons (Christmas) are missed. This places the pressure on code that works now as opposed to code that works and is elegant next year. Nevertheless, there are best practices that introduce a reasonable amount of elegance and minimize bugs; Jamie Fristrom''s Manager in a Strange Land series on GamaSutra suggests quite a few, while still recognizing that there is that need for flexibility in game development that may not be as necessary in other sectors.

Hopefully, though, as more reusable components are developed, the proportion of code that requires this kind of "code like hell" approach will dwindle and quality will rise.

quote:

---

Original post by Oluseyi
For the overwhelming majority of game software, maintainability is a very minimal requirement, quite unlike non-game software (exceptions being game engines to be licensed by other developers, MMO games and so forth). In most cases, once the game has been released and there are no critical bugs requiring addressing via a patch, it can be "discontinued" as a supported product and left on the shelves as a retail item. The developers move on to the next project.

---

Can''t speak to others'' experiences, but I have several problems with this line of reasoning, among them:

• In my experience, most of the product-critical maintenance of software takes place before it hits the shelves. That is to say, a well-factored design matters during the development process more than it does during maintenance


• Starcraft and The Sims, taken together with, for example, Steve Pavlina''s rants, point to the value in continuing to work on the same codebase for extended periods of time


• Patching is a way of life for game developers, no question about it. The better your factorization, the easier patching is going to be

All of the above require a great deal of discipline from the professionals engaged in the project at hand. That discipline gets expressed by coders as software engineering.

ld

quote:

---

Original post by liquiddark
...a well-factored design matters during the development process more than it does during maintenance

---

While there is plenty of merit to that position, I wonder how true it actually is. I''ll have to think on that one.

quote:

---

Starcraft and The Sims, taken together with, for example, Steve Pavlina''s rants, point to the value in continuing to work on the same codebase for extended periods of time

---

Yes, but exactly those sorts of games were the exceptions I cited:

quote:

---

From my previous post:
...(exceptions being game engines to be licensed by other developers, MMO games and so forth)

---

I suppose I should have been more specific: games which aim for extendability, long-term customization and provision of new content over the lifespan (admittedly a growing proportion, if not the majority, especially on the PC) require more of a formal approach than one-off titles.

quote:

---

Patching is a way of life for game developers, no question about it. The better your factorization, the easier patching is going to be.

---

Agreed, though that is itself a sad commentary on initial product quality...

Ok, so then what are the needs driving engineering quality in game dev? I''ll start:

• Point of sale confidence (balanced need for big-plan SE methods and modern agile processes)


• Customizability (more agile than designed - the usefulness of a toolset for the end user can be evolved more easily than it can be planned)


• MMO Security et al (probably more a big-plan SE item)


• Episodic Delivery (iterative approaches, agile and non-agile alike, are suited)


• Engine reuse (more heavily big-plan, especially given the time involved in marketing big-ticket engines)


• Dynamically generated content (seems like it could go either way; my preference would be for agile drivers)

I know the two-pole picture of the discipline is simplistic, but I just wanted to start off in a way that made sense to me.