To those of you who have read ''Game Architecture and Design'' (Morris, Rollings) and/or are otherwise familiar with the ''software factory'' model of game development esposed in this book. - What are your general thoughts on this process? - Do you know of any companies which use this structural methodology for software development? - Do you know of any game companies, specifically, that have adopted the software factory model in whole or in part? I''m very interested in this model, and would like to query those who know more about it. If you don''t feel comfortable sharing your experiences in a forum, I invite you to email me directly at r_van_lierop@yahoo.com. Thanks for your time.

Rapid Prototype is only way to fly! Big company or small, game related or not.

Glen Martin
Dynamic Adventures Inc.
Zenfar

I want to comment on this...I just have to re-read that section of the book again so I use the terms correctly...

DavidRM
Samu Games

Glen, care to elaborate somewhat on that statement?

David, I look forward to your comments.

I can only assume the silence means one of the following:

- few people have read the book
- few people are working in the game industry (professionally)
- few people really give a damn

Sound out people!! I''m curious to hear your opinions...

I skimmed the chapter in the book again last night.

Overall, I think the "Software Factory Model" that is presented is sound. Since I come from industries outside of game development, though, it''s hardly revolutionary. Game development is hardly the birthplace for new and exciting development methodologies, though it could seriously benefit from the inclusion of such methodologies in place of the scribble-hack-ship process that still seems prevalent.

The fast pace of hardware evolution, especially in graphics hardware and their support libraries (e.g., DirectX) has made it difficult to create re-usable modules and components. At least for the "cutting edge" of game development.

For those of us, though, who actually like *not* being on the "bleeding edge" of the technology demos, it''s not so difficult. As technology moves away from the forefront of New & Different, it tends to stabilize and become easier to integrate with projects.

In fact, as independent developers, we can''t afford to be in the "arms race" anyway. We have limited time and resources and so must focus on using readily available tools and practices just to have a chance of completing a product.


DavidRM
Samu Games

Right...interesting. I know that this model of software development is nothing new outside of game development. What I''m looking for are concrete examples of how it''s being used in current development, and I''m not only talking about ''independent'' developers but large commercial projects as well.

I too come from a background outside the game industry, and have worked on the periphery of software (and hardware) development for many years. It seems to me that the games industry is plagued by a lot of problems associated with a poorly managed software development process, and the software factory model seems like it addresses some of these problems. In theory it looks good. Now I''m just curious about how it works in practice.

Thanks for the input.

R.

I read the first part of the chapter very quickly.

As I understand it the Factory model is just about re-using components?

Well of course that is a good idea. Don''t you think most game companies do that ? The graphics part may be the hardest to re-use because of the development but things such as resource files, soundcode, inputcode. Surely these things are re-used.

At my work we have an engine/wrapper which uses DX3. We have used that for 3 years only fixing bugs and adding minor features in this time. It has saved us lot''s of time. No doubt about it.

Of course the problem is that now we are stuck with it. I wonder if we will ever use a version higher than DX3.

It''s about more than reusing software components, it''s about maximizing the use of ''people'' components. In GAD, they lay out a workflow and hierarchy of teams (I won''t go into detail here because it''s rather lengthy, and if you''re interested I recommend picking up the book because there is some good stuff in there; although the design sections mostly relate to RTSs but I digress), to optimize the efficiency of the project. Teams are set up in a modular fashion, with a software architecture team at the hub of this greater ''team network''. If I use a (probably flawed) networking analogy, this software architecture group is a kind of router for data going from the other groups (design, artwork, tools, testing, etc.). This way you avoid things like a designer walking to a programmer and requesting changes that have a domino effect on other aspects of the project (even if only to disrupt the established schedule), or a programmer going to an artist and requesting some changes that impact the overall design, etc. It''s really a system for making sure that everyone is working towards the same goal, the development of a game. It sounds rather structured, and it is, which is why I suspect it''s not popular in the games industry which prides itself as being a group of people who ''shoot from the hip'', but it occurs to me that this is one of the huge problems with the industry at the moment, and if we can learn from other areas in software development and business and establish some ''best practices'', then there is a possibility of affecting some change for the better. At least, that''s how I see it.

Sorry for the lengthy post...

I''m happy to say that we don''t use that model at my work

At least not in my team but we are only 4 people, so it might be overkill to have a "router".
But I see the point.