• (cs) in reply to Simon Bradley
    Simon Bradley:
    Yikes! What's going on? How could I have accidentally posted multiple times before I'd even typed "onomatopoeia"? :D
    <beat target="deadhorse">The real WTF is the forum software.</beat>
  • Krakhan (unregistered) in reply to akatherder
    akatherder:
    Do all of these video game programmers have some sort of reading disability? Alex's qualifying statement was:

    "Short of the occasional patch, once the product is shipped, it's done"

    Most games (especially console) don't have patches and updates. Most games don't have an engine worth re-using. And any code you can re-use (memory management, wall wireframes, etc) was probably already re-used from a previous game. Once the product is working and ships, it doesn't matter what the code looks like.

    I used to think gaming coders were smart but they're just as easily offended, nitpicky, and whiny as the rest of us.

    Sure, but that doesn't mean the code during the development cycle doesn't need to be readable, or be subject to code-review by your peers.

  • facetious (unregistered)

    Just to clear up something here for all you "reusable game code needs to be maintainable"..

    Reusable code in video games is typically engine code. Engine code is typically created by a third party. So if your company brings in an engine that will be supported and maintained by a third party, do they care about it? No.

    So where's the reusable code? Yeah .. the code that isn't yours. The code that you don't care about. Any code in the game you're creating is most likely not going to be reused. Ever.

    Unless you're making Half-Life .. then you're reusing Alien code. And of course .. if you're making Halo, you're reusing Half-Life code. Gears of War: same deal.

    And if you're making any other game with a stupid annoying little crab-face-hugger-short-jump-up-and-hit-you enemy, STOP IT RIGHT NOW. Cause they're really irritating. I think we've all seen enough of them.

  • anon (unregistered) in reply to akatherder
    akatherder:
    Do all of these video game programmers have some sort of reading disability? Alex's qualifying statement was:

    "Short of the occasional patch, once the product is shipped, it's done"

    Most games (especially console) don't have patches and updates. Most games don't have an engine worth re-using. And any code you can re-use (memory management, wall wireframes, etc) was probably already re-used from a previous game. Once the product is working and ships, it doesn't matter what the code looks like.

    I used to think gaming coders were smart but they're just as easily offended, nitpicky, and whiny as the rest of us.

    Once the product is shipped, the engine and all the code is still there for reuse. Most games don't have an engine worth re-using because it was poorly coded to begin with. Maybe with some higher quality code, it would be worth reusing...?

    The reusable code still needs to be maintainable, even if it came from somewhere else.

    I'm not trying to be nitpicky or troll, I think it was a legitimate criticism of the statement that code quality is not "as important" in the video game industry. There's really not a whole lot of things you can qualify that with to make it true.

    Pointing out games that ship with horrible code does not make your statement true either, it just gives an example of a badly managed game development process. The fact is, companies that have high quality code can ship more products for less money, time, and effort. If that isn't important, I don't know what is...

  • Sam F. (unregistered)

    Uh, if it MUST be set to 1, why is it set to 3?

    WTF?!?

  • ElQuberto (unregistered) in reply to A frustrated 3DRealms fan

    Isn't that 2 words?

  • ElQuberto (unregistered) in reply to A frustrated 3DRealms fan
    A frustrated 3DRealms fan:
    there's no ten-year lifespan to worry about.

    Three words:

    Duke. Nukem. Forever.

    Doh. isn't that 2 words?

    / captcha: burned indeed

  • (cs) in reply to andrey plakhov
    andrey plakhov:
    I don't believe that code quality is as important in that industry. Short of the occasional patch, once the product is shipped, it's done

    Man, this is absolutely wrong; contemporary videogame (especially one for PS2 or XBox) is much more hard and interesting to develop than typical business app. First, on PS2 you have 32M memory and no swap file. So, you must manage huge resources like textures very smart and carefully. Second, you typically have no HDD, so every graphics or sound resource you use comes from such a slow-access device like DVD. But your players don't want to watch a "Please wait loading" screen, so you must foresee what resources to pre-load, and how to fit all of them in those 32M. There are tales of esoteric algorithms to perform such a task, and in fact you must really be a guru to use their power. Third, games are realtime apps. Less that 40FPS? Your project not gonna ship. Sometimes a little lag because your AI is a bit too smart and thinks a bit too much? Your project not gonna ship. Last, only one crash bug - and platform holder (M$ or Sony) simply won't allow your game to ship. Hey, how many "serious" apps that never crash do you know?

    Dude, that kind of stuff was true when the Nintendo Seal of Quality still existed, today unless the platform holder is the publisher (aka you're first or second party) they don't give a fuck, and many games show it: there are games with bugs (including crash bugs) being released, there are games that freeze being released (Castlevania: Portrait of Ruins has freezed my DS Lite at least 5 times...), and while 30FPS is considered the minimum (definitely not 40) and 60FPS the target, many games go occasionally get under 30FPS, something only seen on PCs until recently.

  • (cs) in reply to anon
    anon:
    Once the product is shipped, the engine and all the code is still there for reuse. Most games don't have an engine worth re-using because it was poorly coded to begin with. Maybe with some higher quality code, it would be worth reusing...?

    The reusable code still needs to be maintainable, even if it came from somewhere else.

    I'm not trying to be nitpicky or troll, I think it was a legitimate criticism of the statement that code quality is not "as important" in the video game industry. There's really not a whole lot of things you can qualify that with to make it true.

    Pointing out games that ship with horrible code does not make your statement true either, it just gives an example of a badly managed game development process. The fact is, companies that have high quality code can ship more products for less money, time, and effort. If that isn't important, I don't know what is...

    I do agree with you. My goal is to point out that Alex's original statement was misinterpreted. Some people read it as "Game coders are talentless hacks who don't give a crap about their code". I assume he meant something like "You can't update most game code once it has been released, so if you sacrifice readability and maintainability to speed up development, you aren't an evil programmer."

  • (cs)

    // TODO: Remember to setup business rules inside your code that you might have to reset, recompile, etc. that nobody knows or remembers to check...

  • Mr.<undefined> (unregistered) in reply to ElQuberto
    ElQuberto:
    A frustrated 3DRealms fan:
    there's no ten-year lifespan to worry about.

    Three words:

    Duke. Nukem. Forever.

    Doh. isn't that 2 words?

    / captcha: burned indeed

    Duke (1) Nukem (2) Forever (3)

    Yay, I can count to 11!

  • Anonymous Coward (unregistered) in reply to chris

    Actually, both Andrey and Chris are right.

    At the beginning of a project, the code is usually (although not always) well-thought-out, carefully documented, etc., like Andrey would expect.

    Then crunchtime sets in. Features get cut (or, in some pathological cases, ADDED), but the art (and sometimes alternate paths through the code) are still present on the disc, comments get out of sync, a guru is brought in to wring that last little bit of extra loading time or framerate out of the game, often having to make the code a bit more cryptic to do so, and whoever's doing the level scripting usually starts making half-hearted, piecemeal (and horribly, horribly uncommented fixes to prevent QA players from jumping through solid geometry, getting too much money too fast, etc. And there is always at least one last crash that's the result of a fix someone made eight builds ago, but "it's too late to fix this" and "Sony will never find this. We have to ship it right now!", meaning the end result comes out more like what Chris' described.

    Quality may be one of the aims at the beginning, but frequently, in the end, it's all about meeting the all-important deadline, and quality (along with fun factor and polish, sometimes, too) gets pushed to the back burner.

    (I know all too well, having been a QA peon at a certain house in Redwood City, California and a J2ME peon at a house in Foster City, California in past lives)

    captcha: tesla (as portrayed by David Bowie)

  • webrunner (unregistered) in reply to ElQuberto

    They had two words done a few years ago but had to start over when switching engines.

  • webrunner (unregistered) in reply to webrunner
    webrunner:
    They had two words done a few years ago but had to start over when switching engines.

    That was meant to quote the 'two words' thing about DNF.

    CAPTCHA: Waffles. http://heroeswiki.com/Theories#Waffles

  • Duston (unregistered) in reply to Glenn Lasher

    Obviously 0x01 & 0x02 = 0x03 == "File Not Found"

  • WTF (unregistered)

    Code quality is usually more important in the gaming industry, and the best programmers I have known worked in the game industry.

    Ever played a game with bad underlying code? It's not fun.

  • James Schend (unregistered)

    Unless you're making Half-Life .. then you're reusing Alien code. And of course .. if you're making Halo, you're reusing Half-Life code. Gears of War: same deal.

    To be pedantic...

    Half-Life was made from a modified Quake 1 engine (with a lot of Quake 2 enhancements added in.) Half-Life 2 is an original engine.

    Halo (as far as I know) is an original engine.

    Gears of War is the Unreal 3.0 engine. Epic is one of those previously-mentioned gaming companies that basically makes most of their income from selling the game engine and make their actual games (like Unreal Tournament) just to show off the engine. Id is another of those, and Croteam is yet another. (If Croteam is still around.)

    And of course the captcha is "quake"

  • facetious (unregistered) in reply to James Schend
    James Schend:
    > Unless you're making Half-Life .. then you're reusing Alien > code. And of course .. if you're making Halo, you're reusing > Half-Life code. Gears of War: same deal.

    To be pedantic...

    Half-Life was made from a modified Quake 1 engine (with a lot of Quake 2 enhancements added in.) Half-Life 2 is an original engine.

    Halo (as far as I know) is an original engine.

    Gears of War is the Unreal 3.0 engine. Epic is one of those previously-mentioned gaming companies that basically makes most of their income from selling the game engine and make their actual games (like Unreal Tournament) just to show off the engine. Id is another of those, and Croteam is yet another. (If Croteam is still around.)

    And of course the captcha is "quake"

    ...dude. I wasn't talking about the engines. I was talking about the face crabs/face crabs/locust/wretches. Geebus.

  • Abscissa (unregistered) in reply to facetious
    facetious:
    Just to clear up something here for all you "reusable game code needs to be maintainable"..

    Reusable code in video games is typically engine code. Engine code is typically created by a third party. So if your company brings in an engine that will be supported and maintained by a third party, do they care about it? No.

    So where's the reusable code? Yeah .. the code that isn't yours. The code that you don't care about. Any code in the game you're creating is most likely not going to be reused. Ever.

    Unless you're making Half-Life .. then you're reusing Alien code. And of course .. if you're making Halo, you're reusing Half-Life code. Gears of War: same deal.

    And if you're making any other game with a stupid annoying little crab-face-hugger-short-jump-up-and-hit-you enemy, STOP IT RIGHT NOW. Cause they're really irritating. I think we've all seen enough of them.

    Video Game Engine code is still Video Game code. It may not be "gameplay" or "game-specific" code, but it's still code for a video game that needs to be reusable/maintainable.

  • Abscissa (unregistered) in reply to andrey plakhov
    andrey plakhov:
    I don't believe that code quality is as important in that industry. Short of the occasional patch, once the product is shipped, it's done

    Man, this is absolutely wrong; contemporary videogame (especially one for PS2 or XBox) is much more hard and interesting to develop than typical business app. First, on PS2 you have 32M memory and no swap file. So, you must manage huge resources like textures very smart and carefully. Second, you typically have no HDD, so every graphics or sound resource you use comes from such a slow-access device like DVD. But your players don't want to watch a "Please wait loading" screen, so you must foresee what resources to pre-load, and how to fit all of them in those 32M. There are tales of esoteric algorithms to perform such a task, and in fact you must really be a guru to use their power. Third, games are realtime apps. Less that 40FPS? Your project not gonna ship. Sometimes a little lag because your AI is a bit too smart and thinks a bit too much? Your project not gonna ship. Last, only one crash bug - and platform holder (M$ or Sony) simply won't allow your game to ship. Hey, how many "serious" apps that never crash do you know?

    I completely agree with the spirit of this, but there's a couple details I disagree with:

    1. "Less that 40FPS? Your project not gonna ship." It shouldn't be able to ship if the framerate is that low, but it DOES happen. Example: Shadow of the Colossus.

    2. "Last, only one crash bug - and platform holder (M$ or Sony) simply won't allow your game to ship." Should never be allowed to happen, but it does happen all the time. Well-known example: The first "The Matrix" game.

  • facetious (unregistered) in reply to Abscissa
    Abscissa:
    Video Game Engine code is still Video Game code. It may not be "gameplay" or "game-specific" code, but it's still code for a video game that needs to be reusable/maintainable.

    I agree. But now you're talking about a different company than the one that creates the game. The company that creates the game doesn't need to care about code maintainability of an engine that they don't maintain. And if the engine is the only code reuse tha the company ever wishes to do (because their catalog of games is so diverse that there is never a chance for overlap), maintainability is pointless after release.

  • (cs)

    Well, I'm no regular game developer, but I have worked on them before. I worked on a title which originally shipped in 2002 for Windows. I was working on the Mac port in 2003. In this code, the developers (whose company also wrote the OS it originally ran on) decided that it was just fine to save their C++ objects directly to disk, vtable, pointers, and all. When it was time to save the game state, they just wrote the bits of each object to a file. Upon reading them back in, they corrected all the pointers, and the vtable magically lined up, too, so they didn't need to do anything there. Of course, when we attempted to read their crap into the Mac version, it made no sense at all. Boy that was a fun problem to figure out. I've never seen anything that egregious in regular application development. I think that's the type of thing Alex is talking about when he says that game development doesn't need to maintain the same standards as regular development. (And this was a game that they knew would be re-released in another 2 years as "<Title> 2004!")

  • Zylon (unregistered) in reply to Glenn Lasher
    Glenn Lasher:
    Part of this depends on what you are playing on, of course. If you are playing on a PC, fine. If you are playing on a console, however, PAL televisions display 25FPS; NTSC 30FPS (actually 29.97 -- don't ask). Only when you get into EDTV and HDTV models can you get to 60
    Not entirely true. The 30 frames per second of NTSC is assembled from a 60 fields per second signal, alternating between odd and even lines. Game consoles from the 8-bit/16-bit eras couldn't create interlaced displays, so they just generated a single-field display, yielding nice silky-smooth 60FPS animation (at the cost of the distinctive scanlines early videogames are known for).
  • Imperceptus (unregistered) in reply to David Dunham
    David Dunham:
    I consider code quality in the game industry MORE important, since we don't have the opportunity to patch! You server guys can just fix a file at any time. We have no practical way to deploy fixes, so it's got to work out the door.

    yeah like the PS3, that one worked awesome out the door. Right into the trash can.

  • (cs)

    I am the only one who sees no actual code WTF, but simply ignored comments on how a parameter "should" be set?

    but in general, the majority of video games are stuck in whatever state they were released.

    If a new version of a game is ever released, it's released as a new title with new features and most likely a new storyline/game dynamic/something else different.

    Completely inacurate, as early as NES titles, games have been updated when bugs are discovered, and all future "prints" of that game (under the same title, and without the consumers knowing) is the newer version.

    A modern example is Mech Assault (XBOX) -- the original release version allowed you to load bad savegame files and allowed code execution from the data file (thanks M$ for the only soft-moddable platform on the market) -- but if you just go out and buy a Mech Assault disc that doesn't mean you have the vulerable version, because after the bug was discovered, a new version released.

    Also, see your NES Game Genie guide that says that depending on the version of the game you're using, Game Genie codes for a particular title might not work as you might have a different version than the one they tested with.

    On top of that, code for games is not of low quality, it's just horribly complex, because with any console game you effectively, as a game developer, have to fit a full size tanker into a glass bottle.

  • mnature (unregistered) in reply to Jim
    Jim:
    I generally don't publish code from the videogames because I don't believe that code quality is as important in that industry. Short of the occasional patch, once the product is shipped, it's done; there's no ten-year lifespan to worry about.

    I think there's a few programmers of online games in general and MMOs in particular who'd argue your point there!

    SONY does a good job of ignoring code quality . . . or perhaps you never played Star Wars Galaxies.

    CAPTCHA: darwin (appropriate when speaking about SONY games)

  • (cs) in reply to fennec
    fennec:
    <beat target="deadhorse">The real WTF is the forum software.</beat>

    Target: Attribute deprecated.

  • frenzied-cavy (unregistered)

    so... how many XP do you need to get your parental skill to level 3?

  • PeriSoft (unregistered) in reply to frenzied-cavy

    A lot of XP, but you only need one Vista.

    Anyone care to mix the metaphor a little more?

  • (cs) in reply to Anonymous Coward
    Anonymous Coward:
    ...At the beginning of a project, the code is usually (although not always) well-thought-out, carefully documented, etc., like Andrey would expect....

    Then crunchtime sets in...

    The easiest way to find bugs in game is to play the highest (final) level there is in the game. That level is usually the least tested one since it was added to the game at the last minute.

  • (cs) in reply to PeriSoft
    PeriSoft:
    A lot of XP, but you only need one Vista.

    Anyone care to mix the metaphor a little more?

    no...but i dont see any real WTF beyond parental level being set way too low

  • Lacryse (unregistered) in reply to Jim

    Lack of quality standards may be a problem in games, but the ones to blame are not the developers but the publishers who insist on shoving the game out the door before {the Christmas rush; the release of a competing game; a new generation of graphics; the death of the console they are programming for}.

    A six month delay can spell the commercial death of a game, but bugs in a prematurely released game can kill it as well. In many cases, the devs ARE trapped between a rock and a hard place.

    The very fact that a game (by any company except Blizzard, strangely) disappears off the shelves after about 1-3 months must suck for game devs as well. Eventually the developers say to hell with it and become just another cog in the machine.

  • Wugga Woo (unregistered) in reply to triso
    triso:
    Anonymous Coward:
    ...At the beginning of a project, the code is usually (although not always) well-thought-out, carefully documented, etc., like Andrey would expect....

    Then crunchtime sets in...

    The easiest way to find bugs in game is to play the highest (final) level there is in the game. That level is usually the least tested one since it was added to the game at the last minute.

    Of course, and all movie scenes are always shot in the exact same order they appear on the film as well. And novel authors always write the first word in the novel first and the last last.

    Along my career in games industry, the absolute worst, sloppiest, inefficient, bloated code was generally from the former 'application programmers'. Either that or interns, only you can usually tutor interns.

    Anyway, how many database queries your web application can complete, from the user clicking a button to the results showing on screen, for in 0.01666 seconds? Assuming you have an extremely fast user...

  • gamedev (unregistered) in reply to Lacryse

    "The very fact that a game (by any company except Blizzard, strangely) disappears off the shelves after about 1-3 months"

    This is because games usually stop selling after 1-3 months (except for blizzard games lol) and shelf space is incredibly scarce, especially for PC games now a days.

  • Guy (unregistered) in reply to chris
    chris:
    Are you serious? I've seen plenty of games get shipped that are below 40FPS (30FPS is considered a minimum, usually) and drop below 30 at some points. Seen plenty that lag for whatever reason. Seen plenty that completely crash the game, destroy memory cards, or some other strange crash. The bottom line is to get the game out the door and sell some copies. That's generally all a publisher cares about.

    The last game I bought that did this - I called the game company, demanded my money back, and have never ever EVER bought anything by that company again. No matter how many spam emails they send me...and I still have no desire to buy their products.

  • MaineCoon (unregistered) in reply to dcardani
    dcardani:
    Well, I'm no regular game developer, but I have worked on them before. I worked on a title which originally shipped in 2002 for Windows. I was working on the Mac port in 2003. In this code, the developers (whose company also wrote the OS it originally ran on) decided that it was just fine to save their C++ objects directly to disk, vtable, pointers, and all. When it was time to save the game state, they just wrote the bits of each object to a file. Upon reading them back in, they corrected all the pointers, and the vtable magically lined up, too, so they didn't need to do anything there. Of course, when we attempted to read their crap into the Mac version, it made no sense at all. Boy that was a fun problem to figure out. I've never seen anything that egregious in regular application development. I think that's the type of thing Alex is talking about when he says that game development doesn't need to maintain the same standards as regular development. (And this was a game that they knew would be re-released in another 2 years as "<Title> 2004!")

    That's nothing new. Carmack was doing that years ago. Quake 2's game logic was done via DLLs, and entities stored pointers to functions to determine what logic to run in case of events, updates, etc. When saving to disk, this was all written to disk verbatim.

    I no longer do Mac work, I have moved on to hardware meant for gaming (consoles). Working at a large developer, we do have code review policies in place, and they get stricter the closer we get to finishing the project.

    I've seen plenty of game engines get reused for several iterations of a title or series, even if this engine is strictly internal. It undergoes heavy revision, and after a few games only some fundamental concepts remain in place. Usually the next project starts by taking the existing game, and replacing things piece by piece.

  • PHP coder (unregistered)
    I generally don't publish code from the videogames because I don't believe that code quality is as important in that industry. Short of the occasional patch, once the product is shipped, it's done; there's no ten-year lifespan to worry about.

    I know its already been said, but that statement is the WTF here!

    In the past game companies have dismissed code quality, but now (good) game development are at the bleeding edge of SW QA procedures. Why? Not because they felt like it, but because it is necessary to survive these days. The amount of code, and the complexity of the code that goes into the average video game is 10 orders of magnitude higher than any "real programming", such as business enterprise backends or whatever...

    BTW, what about console games, or single player PC games? You cant always expect your end users to be able to download patches you know. In gaming, you're supposed to get it right on the first release.

  • PHP coder (unregistered) in reply to Lacryse
    Lacryse:
    Lack of quality standards may be a problem in games, but the ones to blame are not the developers but the publishers who insist on shoving the game out the door before {the Christmas rush; the release of a competing game; a new generation of graphics; the death of the console they are programming for.

    Yes publishers set unrealistic deadlines that cause developers to rush, but what the dev's need to realise is that writing code along with unit tests shortens the development period, as well as increasing quality, its a win-win methodology. However, most dev's only think of this half way thru production when bugs start popping up, and if you try to implement unit tests at that point you're screwed.

  • game coder (unregistered) in reply to facetious
    facetious:
    Just to clear up something here for all you "reusable game code needs to be maintainable"..

    Reusable code in video games is typically engine code. Engine code is typically created by a third party. So if your company brings in an engine that will be supported and maintained by a third party, do they care about it? No.

    For your viewing pleasure, here is some C++ code from the engine used by Oblivion:

    typedef unsigned char Bool; #define BOOL_IS_TRUE(b) ((b) != 0)

    Yes, the dev's care about the quality of engine code.

  • (cs)

    You are mistaken. There is indeed code in the video game industry with long life support. The unreal engine is a perfect example.

    The days of writing video games over from scratch every time are LONG long gone. The pretty layer on top might be changed every time, but the guts are starting to be very long lived, shared and licenced entities with cross platform impact.

  • (cs) in reply to Saladin
    Saladin:
    I see what he did.

    // MUST be set to 1!

    So, 1.

    But, at the same time:

    // QA now insist this is set to 2.

    How do you assign it to 1 and 2 simultaneously? Thusly:

    Params->ParentalLevel = (1 + 2); Params->ParentalLevel = 3;

    Brillant!

    Maybe they are looking at the bits later in the code. The dev wants bit #0 set and QA wants bit #1 ... hmmm ... but that would a (brillant) WTF in itself.

  • Joel (unregistered) in reply to Sarkie

    No, that would be if they insisted on '1' and "2", respectively.

  • (cs) in reply to facetious
    facetious:
    Abscissa:
    Video Game Engine code is still Video Game code. It may not be "gameplay" or "game-specific" code, but it's still code for a video game that needs to be reusable/maintainable.

    I agree. But now you're talking about a different company than the one that creates the game. The company that creates the game doesn't need to care about code maintainability of an engine that they don't maintain. And if the engine is the only code reuse tha the company ever wishes to do (because their catalog of games is so diverse that there is never a chance for overlap), maintainability is pointless after release.

    The final consequence of what you are stating is that the moment the game is shipped then all game sour code except for a few masters for the game DVD can be safely deleted. Because if they cannot maintain the code then it would be pointless to even waste storage space for the code.

    This strikes me as odd.

  • Anon (unregistered)

    This is not a WTF... Although I've only worked on PS2 titles (maybe PC projects are different), when you're at the end of crunch time and still have 75 A bugs assigned to you, you do whatever's necessary to make it work and ship on time. If that means changing values without pondering how to update the comments, you do it. The product has to ship so you get your shipping bonus. Nothing else matters.

  • Sch3lp (unregistered) in reply to Jim
    Jim:
    I generally don't publish code from the videogames because I don't believe that code quality is as important in that industry. Short of the occasional patch, once the product is shipped, it's done; there's no ten-year lifespan to worry about.

    I think there's a few programmers of online games in general and MMOs in particular who'd argue your point there!

    I agree with that point, and believe you can add "programmers working for EA" to that list :) (those poor fellas)

  • (cs) in reply to PHP coder
    PHP coder:
    The amount of code, and the complexity of the code that goes into the average video game is 10 orders of magnitude higher than any "real programming", such as business enterprise backends or whatever...

    Whiny gamer defending his holy cow: funny.

    Someone calling himself "PHP coder" making bizarre blanket statements about "real programming": hilarious.

    Not knowing what "order of magnitude" means: priceless.

  • anon (unregistered) in reply to Abscissa
    Abscissa:
    "I generally don't publish code from the videogames because I don't believe that code quality is as important in that industry."

    Wrong! Try working on a project of that scope and THEN try to claim code quality matters less. The code quality typically matters MORE just because the scope is so much larger than the vast majority of IT software.

    Okay, I just had to reply to this. What's wrong with game developers? Seriously, why do you keep pretending that programming games is so much (more important | harder | cooler | whatever) than other development?

    Scope is much larger? How is the scope larger than, say, an app for processing CC or bank transactions from all over the world? Or a system that integrates all the (thousands of) information systems of a large enterprise or government agency? If you ask me I'd say screw ups in banking software would be a lot more serious than in a game.

    And stop giving the BS about how hard it is to program games. I can also say that I have a "small" amount of memory and CPU power for processing thousands of simultaneous transactions. It's just a different scale. Also games usually don't have all the concurrency or security issues (save perhaps MMO games).

    And games are NOT real time apps. You're not controlling a nuclear power plant or an aircraft navigation system and nobody in the real world is going to die if you miss an input event or two.

    Sorry for if I sounded harsh but the "my work is more important than yours" attitude angers me. Yes, the comments about code quality may not be fair. But programming games is just like any other programming, with its own domain-specific problems and solutions. You're not special.

  • anonymous (unregistered) in reply to James Schend
    James Schend:
    > Unless you're making Half-Life .. then you're reusing Alien > code. And of course .. if you're making Halo, you're reusing > Half-Life code. Gears of War: same deal.

    To be pedantic...

    Half-Life was made from a modified Quake 1 engine (with a lot of Quake 2 enhancements added in.) Half-Life 2 is an original engine.

    WRONG!

    Half-Life 2 ('Source') is based on Half-Life 1.

    Check here my map about the Quake engines family tree: http://en.wikipedia.org/wiki/Image:Familytree11.png

    The great Valve guys have show how you can make a extra-amazing-cool games, and how hot make a good engine better, and how to make a engine that old machines like.

    People can play "Dark Messiah Of Might And Magic" on old computers, that is another game that use Source engine, that is based on Half-Life1 that is based on a Quake 1 engine.

    A bug on Quake1 can slip on Dark Messiah, even after 4 half rewrites. (Example: a buffer overflow on quotes parsing for console commands)

    --Tei

  • anon (unregistered) in reply to PHP coder
    PHP coder:
    The amount of code, and the complexity of the code that goes into the average video game is 10 orders of magnitude higher than any "real programming", such as business enterprise backends or whatever...
    Stop giving that crap! It's only 10 orders of magnitude more complex if the programmers like to re-invent the wheel. Three words for you: 3-rd party libraries!
  • Anonymous (unregistered) in reply to anon
    anon:
    Stop giving that crap! It's only 10 orders of magnitude more complex if the programmers like to re-invent the wheel. Three words for you: 3-rd party libraries!

    Seems that games are alredy adding more and more 3-rd stuff:

    • Bink for videos
    • Gamespy crap for gamebrowsing
    • Punkbuster for cheat audit
    • Miles for sound
    • xerces for xml? msxml for xml?
    • Python for scripting
    • Lua for scripting
    • SOE Updater for SOE games updating ( Vanguard, Planetfield,..)
    • Valve for Valve distribution & DRM
    • Quake engines, for Quake-style games
    • Unreal engines for Quake-style games
    • Havok for phisics
    • FastTree for rendering Trees
    • Maya, 3DStudio and Blender for 3D modeling

    Maybe game programming on consoles can be different. Because If theres no bink for PS3, you are "forced" to re-invent Bink.

Leave a comment on “Gaming Ground”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article