Jump to content

  • Log In with Google      Sign In   
  • Create Account





Day... ah, screw it, I have no idea what day it is

Posted by ApochPiQ, 12 February 2006 · 76 views

Well, my car is dead. There's a rod broken loose in the engine that's pretty much destroyed things, and the timing computer has tried to "compensate" by downtiming the engine so much that it barely runs. It currently sits, dejected and stripped of all my belongings, at a local garage.

They want to make me pay $25 to have it "impounded" and removed, which is total B.S., because there's a good $500 worth of salvageable parts and goodies left on that car, all of which are in perfect condition. Heck, there's four perfectly good door panels on the thing which I know from bad experience are worth a pretty penny. So I'm looking for a way to get some cash back out of it without having to actually do the work of dismantling the usable parts and selling them myself (which I have neither the time nor tools to do).

Incidentally, if anyone knows of any services that will pay for such cars, please let me know - especially any in the Atlanta metro area.




Random thought for the day: why hasn't anybody written a book on software engineering and production methods for games? Anyone with any real world experience knows that different types of software have very different constraints and requirements, and yet it seems like all the good engineering-practices books out there are aimed at business logic or shrinkwrap products. Seems like a prime opportunity for someone to come along and fill that void.




Quote:
why hasn't anybody written a book on software engineering and production methods for games?


Game Architecture and Design

That said, a man more cynical than I might suggest that there are no books on the subject because there is no software engineering or formal production methods in the games industry [wink]
I'll admit to not having read the book cover-to-cover, but from what I understand (and my flipping through the Old Edition in a bookstore a few years back) GA&D is all about design and not about production. There seems to be some stuff on project management in there but that's hardly useful in the real world; every house will have a different management style, and different teams work differently. I definitely recall from my skimmings that it came across as "this is The One True Methodology" which is just bad. The problem with things is over-generalization, and as far as I can tell GA&D is contributing to the problem, not solving it.

I guess what I'm really looking for is something like "The Pragmatic Game Developer" that has some generalized and open-ended advice, specifically aimed towards the realities of game development. Heck, maybe someone should just take The Pragmatic Programmer and edit up all the bits that are questionable from a game industry perspective, and rerelease it [wink]


There's plenty of formal SE in the industry. The problem is, it isn't the same calibre (or on the same scale) as in other fields, like business apps. I think the problem is a lot of people look at business-SE stuff, realize fast that it won't work in games, and chuck the baby out with the bathwater.
Quote:
why hasn't anybody written a book on software engineering and production methods for games?


Software Engineering for Game Developers

The Game Producer's Handbook

I don't know if they are exactly the kind of books you are looking for, but the truth is that there are not many resources on software engineering and production applied to games out there.
What I'm really looking for is something that doesn't specifically advocate a single methodology. Those two titles look great in their own right, but they still seem to focus too deeply on a single "One Right Way" - at least from what I can see by reviews and sample excerpts.

I guess what I'd like to see is some cold, hard, in-the-trenches stuff that compares various options, especially in light of team dynamics. Team dynamics seem to come into play in game development more than any other kind of software development - at least any kind that I've been involved in. I've read scores of articles and books about software engineering that just don't work if you break some fundamental assumptions about team dynamics; and I daresay most teams will do so.


I'd love to read something that takes the usual methodology advice, and looks at it in the light of adapting it to an existing team. Adopting a One True Methodology is all well and good for a startup team, but that kind of massive change simply isn't practical for long-established teams, where experience, convention, and library code do not lend themselves to massive philosophical overhaul.

Basically, when it comes down to it, what I'm after isn't so much of the standard "do all these things and your project will go well" but more along the lines of "here's some stuff you can adopt in your existing infrastructure to get some benefits."

October 2014 »

S M T W T F S
   1234
567891011
12131415161718
19202122232425
26272829 30 31 
PARTNERS