Massive Info Dump on Halo History - My takeaway (Destiny)

by Blackt1g3r , Login is from an untrusted domain in MN, Thursday, June 01, 2017, 18:40 (2822 days ago) @ dogcow

A solid, stable and finalized game engine & content tools can do wonders for your content teams. Especially if it's done before the content teams are ready to build levels. (see ODST). The downside of this is you'll be over a year behind in technology.

Now for my soapbox (read this with the understanding I do not know what it's really like inside the walls of Bungie. For you software guys I'll just say, I think life at Bungie would be improved if they adopted a more agile development method regarding their engine & tools. As I said earlier, I don't know what it's really like inside Bungie and it sure is easy to be an arm-chair-director-of-development).

Smaller more frequent iterations on the game engine would be better for Bungie. The engine-in-development should often be in a "ready to go" state. The developers should be working on the engine and tools for the NEXT game while the content people are working with the last solid & stable (content-ready?) engine for the current game. You should be exploring ideas for your next game with a smaller team using the most-recently-stable-engine&tools. This will help keep it in a "ready to go" state. When the content team is ready to start on the next game the last "ready to go" build of the engine should become the "content-ready" version and only change for bug fixes or management-authorized features (which should be rare). The price you pay for this more-sane development style is that you'll be a little behind technologically, also you can't throw out the whole engine & toolset & do complete re-writes, which, IMHO, is a good thing really (says I as I'm doing a near complete rearchitecting of a major module @ work that's taking over a month ;-) ).

I think the main problem is that improvements to a game engine are generally very hard. Often that means to keep the main engine something people are able to use you have to fork the codebase for a significant amount of time. Anytime you do that to a codebase it becomes increasingly more difficult to pull in the changes when you are finally ready to do so which results in the possibility of introducing bugs.

Alternatively, you merge in those changes often while putting them behind a feature flag, but then you are increasing the complexity of the codebase. This makes it easier for developers to make mistakes and introduce bugs, but lets you quickly turn things on and off in the production systems if necessary. In a PC build though, you probably don't want that code easily accessible since people might be able to use it to exploit the game.

There are a lot of trade-offs in where you put your complexity no matter how you approach the problem.

(I realize you probably know all this, but others here don't. Also, I think Engine development is possibly one of the hardest problems in computer science when you are talking about AAA games.)