dude that is the **game** source not the **engine** source.
It compiles to like game.dll. Not the actual Q3A engine...
Professional Source Code
Most commercial apps are driven by time-to-market and artificial deadlines like needing to release in time for Christmas. These sorts of pressures do not encourage high-quality code, especially in games where you have a relatively short shelf-life and little or no long-term maintenance requirement.
Quote:
Most commercial apps are driven by time-to-market and artificial deadlines like needing to release in time for Christmas. These sorts of pressures do not encourage high-quality code, especially in games where you have a relatively short shelf-life and little or no long-term maintenance requirement.
Perhaps, but that doesn't make it a good thing. I'm not convinced that deadline pressure is a good excuse for poor code -- it may very well come back and bite you later on (in the same project) and you'll lose more time in the long run than you would have if you wrote better code in the first place.
This is definately a trend I would like to see vanish from the industry, and I think that with the rising popularity of middleware and such, we may just see this happen.
I dont work in the games industry, but jpetrie, whilst I agree with you, when it comes down to your bonus on any IT project, and your PM or teamleader says you have 3 days, and you know you can do it in 3 days if its 'down and dirty', then 9.5 times out of 10 thats how it happens on any commercial project.
Producers, PM's and managers will push you to take the easy solution, and then if it doesnt work, will find a way of not taking the hit.
Thats just life, dont forget, depsite all the best intentions, these places are businesses, and as such will take commmercial risks that a project will be fine and on time, over a 10% chance that a rewrite will make it late
Its not right, it sucks, but its business, these game comapnies may say they are run by gamers, but the owners have multi million pound budgets and bankers to please before they can be aesthetic :-/
Bp
Producers, PM's and managers will push you to take the easy solution, and then if it doesnt work, will find a way of not taking the hit.
Thats just life, dont forget, depsite all the best intentions, these places are businesses, and as such will take commmercial risks that a project will be fine and on time, over a 10% chance that a rewrite will make it late
Its not right, it sucks, but its business, these game comapnies may say they are run by gamers, but the owners have multi million pound budgets and bankers to please before they can be aesthetic :-/
Bp
Game developers have to hack code originally written as a prototype of tech demo into a whole game. Because of deadlines, rewriting something properly from scratch when some functionality already exists will not be approved by the boss!
And since game code gets resued between games, a bodge required for one game will still be there when the next game is written, possibly requiring the bodge to be bodged!
I'd recommend looking at professional application software, where some software engineering and QC has ever taken place!
But the code used in games is no different to yours, just bigger!
And since game code gets resued between games, a bodge required for one game will still be there when the next game is written, possibly requiring the bodge to be bodged!
I'd recommend looking at professional application software, where some software engineering and QC has ever taken place!
But the code used in games is no different to yours, just bigger!
The thing about quake 2 is that it had legacy ties to Quake 1. So it was a pre-existing mess. But then think to yourself how massive is quake 2? Really really big. I know when things get its hard to keep track of it. 50 thousand lines are hard to keep up with especially when things need quick fixes.
As far as quakes go, the constant technology breakthrus negated the code design methodology. Since you didn't know where the next change was coming from you didn't bother to find it. People always harp on how game devs are coding in the wild west and are not adopting industry standards but I think things are much more dynamic in our field that it's hard to stabilize them. It's like a carpet that keeps moving under your feet and you're trying to keep pace with it or you're left behind.
Actually I find game devlopment to be lagging behind. When developing on the PS2 you ahv ethe same exact hardware for 5 years - you have way longer to write stable code between the hardware changing...
I guess you mean the rush to develop things ASAP - but that could apply just as well to application developers. It's just they get easier deadlines and have more to lose if bugs/crashes etc are found later...
I guess you mean the rush to develop things ASAP - but that could apply just as well to application developers. It's just they get easier deadlines and have more to lose if bugs/crashes etc are found later...
Quote:Original post by Promit
Unfortunately, seeing professional source code is usually not a major eye opening experience that shows you the beauty of perfect software engineering. It's generally pretty bad, and sometimes you wonder how such an incredibly awesome game can have code that is that bad.
LOL. Early in my career I remember embarking on an exercise like this as well, and figured "well, they know best - they're the experts".
Probably your best bet is to check out the Quake 1 and 2 source. There's also been source released for one of the Descent:Freespace games, Microsoft's Allegiance, and I believe some degree of Unreal source. You could also check out GarageGames Torque sdk, but that will cost you.
Thing is, while it may be an interesting exercise in and of itself, you may not find professional source to be the best learning tool and you will almost certainly be disappointed and disillusioned.
Having worked on a few commercial games myself, I'll tell you there's no real magic here... On a day-to-day basis, most of what we do is driven by the need to GET IT DONE. NOW. Which may not result in the nicest code or the best implementations. Corners are cut, kludges are inserted into previously good code. Whole pieces of the game are axed. You just have to understand that the demands of getting something to market in a reasonable amount of time take precedence... And no matter how good a team is or how well intentioned they are, code can only take so much of a publisher going "Sure, that's greaaaat, but it sure would be nice if it did THIS(thing we agreed months ago that it would never have to do)". You also run into issues with pieces of engines and tools that have been around for years, and just kind of patched up and kept on life support because nobody could ever justify the block expenditure of time to completely rewrite them (which is what really needs to happen).
Unless you had inside access to the absolute latest stuff from id or Epic, you'll be much better off learning techniques from the Game Programming Gems series and other good programming books, and online tutorials that keep things compartmentalized and manageable.
[Edited by - The_Incubator on June 14, 2006 2:16:12 PM]
Thing is, while it may be an interesting exercise in and of itself, you may not find professional source to be the best learning tool and you will almost certainly be disappointed and disillusioned.
Having worked on a few commercial games myself, I'll tell you there's no real magic here... On a day-to-day basis, most of what we do is driven by the need to GET IT DONE. NOW. Which may not result in the nicest code or the best implementations. Corners are cut, kludges are inserted into previously good code. Whole pieces of the game are axed. You just have to understand that the demands of getting something to market in a reasonable amount of time take precedence... And no matter how good a team is or how well intentioned they are, code can only take so much of a publisher going "Sure, that's greaaaat, but it sure would be nice if it did THIS(thing we agreed months ago that it would never have to do)". You also run into issues with pieces of engines and tools that have been around for years, and just kind of patched up and kept on life support because nobody could ever justify the block expenditure of time to completely rewrite them (which is what really needs to happen).
Unless you had inside access to the absolute latest stuff from id or Epic, you'll be much better off learning techniques from the Game Programming Gems series and other good programming books, and online tutorials that keep things compartmentalized and manageable.
[Edited by - The_Incubator on June 14, 2006 2:16:12 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement