Jump to content
  • Advertisement
  • entries
  • comments
  • views

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

Sign in to follow this  


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.
Sign in to follow this  


Recommended Comments

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]

Share this comment

Link to comment
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.

Share this comment

Link to comment
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."

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!