• (cs) 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.
    Not even then. NO program ever written is 10 orders of magnitudes more complex than even the simplest "Hello World". 10 orders of magnitue would mean 10^10 or 10,000,000,000 times.
  • Nis L. Simonsen (unregistered)

    The difficulties in programming business apps and video games are often of completely different natures, however, having done business apps for close to a decade and a very small (< 2 years off working-hours) of video game programming (primarily AI) I certainly consider game programming way harder than business programming. Possibly because AI-programming requires you to think about your code in an entirely different way from what you'd normally spend your time on when working on standard business code (domain models, abstraction layers, etc.)

  • (cs)

    Ok Ok, it seems as if this discussion was shifting away from a fact-based debate to a bit of a mud-wrestling

    Therefore i made a little comparison of both categories of software (the way I think about it)

    Games (I'm talking real games, pc games, that is, here. I'm also talking good games, which try to maintain a certain level of quality. Sadly many of theese day's games don't fall into this category. However, most of theese DO become one-day wonders)

    • Generally more Complex operations (No matter what you say, NO business application/web interface/whatever has to do as many calculations in the same ammount of time (i work at europe's top business software developing company).
    • Generally runs on lower specifications-hardware
    • Developers need to read original code to develop patches
    • Short to Medium support time span
    • Games are installed by choice, i.e. users will usually readily install additional components (DirectX etc) and patches, but the game should run on older hardware
    • Too many bugs do annoy most players, leading most certainly to a game's rapid demise. Minor annoyances have a very negative effect (because when playing a game one wants to just play without having to deal with theese)

    Business Software

    • 'Simpler' operations, but often covers different topics (different business aspects etc)
    • Usually runs on high-end corporate servers
    • Developers need to read original code to develop patches as well
    • Long support time span
    • Require high backward compatibility (people still running Word 1.0...)
    • Errors may destroy entire companies, but usually don't. They will, however lead to the comanies switching products. Minor annoyances have a lesser effect, because business software is bought primarily with its functionality in mind, ease to use as a secondary priorits and 'pleasure' to use would come at thrid rank only.
  • (cs) 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.

    Doesn't the bolded part suggest code quality is important given you may re-use code in future games? Just imagine all those "wall wireframe" codes you can reuse from quake.

  • grumpy (unregistered) in reply to brazzy

    Of course there are applications more complex than games. But game still shouldn't be underestimated. We're still talking about something that takes maybe a dozen programmers 3 years (or more) to develop. It may not quite rival some other big projects, but games definitely tend to be a lot more complex and difficult to make than most business applications I see. (These can often be done with a rudimentary knowledge of Java + a 10-minute tutorial in SQL.)

    I won't say it's "harder" than other programming fields (because some fields are insanely difficult), but it's still not exactly "Paula Bean-friendly" territory. And compared to most business apps, games are quite hard to make.

    Unfortunately it seems most of the comments here are either from people who have never looked into games programming, and think "it can't be as hard as what I do", or people who want to become games programmers (and idolize them), but aren't.

    Getting back to the point though, while one single game may not have a lifespan of 10 years, a lot of the code from the game can easily be reused for that long. Which means code quality starts to matter after all.. (Especially because you're not even being paid for maintaining your code. It's just that if you don't do it, you're going to have to start from scratch and rewrite everything for your next project. So the easier it is to maintain, the better)

    To be honest, I've seen some horrible code in games (Anyone who owns Half-Life 2 ought to download the SDK and browse some of the code... Or maybe not. This WTF reminds me a bit of a line I saw in that SDK though. Something along the lines of: if (language == LANG_GERMAN){ m_bloodcolor = GREEN; } At least that cheered me up a bit :)

    But it seems no worse than what I see in the non-games apps I work on, or the third-party libs we use, for that matter. Code in games may be messier, and contains lots of premature optimization, but fewer tri-bools and "Paula Bean"-lines of code. Less downright incompetence in games, but the code quality is still rubbish. (Even though code quality certainly matters. That's just not as widely accepted yet, partly because until a few years ago, games were significantly smaller in scope, and computers were so much slower that there were no space left for that kind of considerations)

  • SleepyNinja (unregistered) in reply to Krakhan
    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. [bold]Most games don't have an engine worth re-using[/bold]. 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.

    Mate, I hate to be a nitpicky game coder, but your just not listening to us either ;)

    Most companies do have engines that lasts multiple years, we keep them from project to project to save time and effort of reinventing the wheel again and again.

    Look at EA, their sports games use the same engine 3 or 4 games in a row. Or Rockstar, their GTA series used the same engine with more and more updates each game over something like 5 years! Add to this that the complexity goes well beyond anything a standard database or website code has and your code standards have to be very strict or you'll be in a quagmire.

    I've personally never worked at any Games company (for long) that didn't consider code maintainability to be important. I consider good readable code an aid to my sainity if nothing else.

    Now I'm not saying that there aren't companies out there that consider game code to be 'fire and forget', but to lump all games coders in with them would be like saying 'All SQL/database/M$ coders aren't that concerned with Maintainability because I saw a few lines of dodgy code on The Daily WTF'.

    I love this site, and I read it every day, so please don't drag it down by being offensive games coders (atleast not the ones who think that magic numbers are bad). ;)

  • Anon (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.

    LifeSPAN, not "Indefinite development time"

    Lifespan of Duke Nukem Forever:0d 0h 0m 0s so far.

  • anon (unregistered) in reply to Nis L. Simonsen
    Nis L. Simonsen:
    The difficulties in programming business apps and video games are often of completely different natures, however, having done business apps for close to a decade and a very small (< 2 years off working-hours) of video game programming (primarily AI) I certainly consider game programming way harder than business programming. Possibly because AI-programming requires you to think about your code in an entirely different way from what you'd normally spend your time on when working on standard business code (domain models, abstraction layers, etc.)
    So, you don't have abstraction layers in game code? Then I think the comments about code quality may be justified.

    About domain models. Games have their own models too. The kind of AI algorithms used in games have been well understood for decades. Computer graphics algorithms as well. I maintain the comment about re-inventing the wheel. Business apps can be complex too if programmers try to implement their own synchronization or cryptography logic. But most business apps don't do that. So why do games have to?

  • grumpy (unregistered) in reply to anon
    anon:
    So, you don't have abstraction layers in game code? Then I think the comments about code quality may be justified.
    Of course there are abstraction layers. But there's also a limit to how much abstraction you can afford. In the end, you want a product that looks and runs *at least* as good as other games. In many business apps, it's no problem to hide everything behind a dozen abstraction layers. It doesn't matter than performance goes down by 50%, because it's already fast enough. Games don't often have that luxury.
    The kind of AI algorithms used in games have been well understood for decades.
    Have they? Which algorithms are these? Who has known them for decades? The problem with games AI is that it's not really AI. Short of the occasional pathfinding algorithms, there's no big unifying algorithms. There's no *general* code you can just use and reuse regardless of the game. It's just an endless series of hacks and tricks that seem to make sense, and usually make the characters in the game behave in a reasonable way. As far as I know, there's no known algorithm for this. (Partly because "behave in a reasonable way" is a quite broad concept that depends both on the character in question, and on the situation he or she is in. And as always, performance constraints peek their ugly heads in. Even if you found the magic algorithm that could simulate any character in any game, try making it keep track of thousands of characters simultaneously. While also leaving CPU time for the rest of the game.
    Computer graphics algorithms as well.
    Have been known for decades, yes. But that's not the same as "haven't needed to be (re)written for decades". For one thing, programmable graphics cards mean a major change in how graphics are rendered, and how the entire game engine works. Changes in CPU performance and capabilities are a major factor too. Some years ago, people had to make do with integer math for a lot of things, because fp was either nonexistent, or too slow. And now we have SIMD instructions to take advantage of. If we can. The problem isn't the algorithms (which mostly stay the same), but that wrapping it all in one big general-purpose library and reusing that forever and ever is simply not an option. Code that worked great for a game 10 years ago, and is based on the same algorithms that people still use, is simply not good enough for todays games.

    And of course, all the time new things are added. Recent games want full-blown physics as well. And yes, even Newton knew how to compute that stuff, but he didn't know how to do it efficiently on today's home PC's. And even if he had known that, he still wouldn't know how to do it efficiently on the PS3. Or on any other platform.

  • (cs)

    uhm, ... , WTF?

  • Baggy McBagster (unregistered)

    I think the real problem with these here game programmers is that they keep spoiling good games, like Far Cry and Half Life, by ALWAYS ALWAYS including the 'runs along really fast jumps on you and bites you' enemy.

    Presumably the meeting goes something like this:

    "Yeah, we've done the game. Trouble is, it's too thoughtful, requires too much skill, and it's too immersive and believable." "Hey, I know, why don't we include something that jumps out suddenly? That way the player's only reaction is to back and reload." "Cool idea." "And also, make it move really fast straight toward the player? Then we won't need any AI, or much of anything really." "Good one!" "And finally, why not make it take a huge chunk of damage off the player by biting. It'll be kind of weird that guns and grenades do less damage than an single bite, but probably nobody will notice as they'll be too busy running away from these things anyway." "Yeah, ok, consider it done."

    Seriously, guys, just STOP including the enemy that runs toward you really fast and bites you! Include something else instead! Even an enemy that runs toward you really fast and asks you trivia questions would be a welcome change.

  • (cs) in reply to Baggy McBagster

    Actually, I'd like a character that asks me trivial questions... but this'll lead us away from the topic.

    Anyway, viewing source codes of games often reveals wtf's, as does reading game files. There you can see how much effort was put into a game to convert it from where the engine was first used. For example, in the data files of Jedi Academy (undoubtedly one of the worst games ever done) is a line for every npc in game which specifies if it beams in with "starfleet beam effect", "romulan beam effect", "idryll beam effect"... go figure.

  • anonymous (unregistered) in reply to Infinity
    Infinity:
    For example, in the data files of Jedi Academy (undoubtedly one of the worst games ever done) is a line for every npc in game which specifies if it beams in with "starfleet beam effect", "romulan beam effect", "idryll beam effect"... go figure.

    If that is internal. Then is a cosmetic change no one will see, and may cause bugs. What if the Jedi Academy engine is reused to make a startrek game? then these beam effects name are right again... or you will need to change from your jedi styled ones. If you change this, for no reason. You will have more differences, so merging back enhancements will be harder. Is a bad idea. And resources on a game that the player sould see need to be external, because you want to support english german, french, italian, etc so your game sells everywhere.

  • (cs) in reply to anonymous

    In that case its external data (in a .pak file, i believe). Jedi Academy is based on the engine of some star trek game (which is based on the quake 3 engine), so they just altered an already modified engine and its data files and left hundreds of such rudiments, which are sometimes commented out or not loaded, but others are 'required' for the game (i.e. loaded but not used). For that specific game i'd have to agree with Alex: That code really is a mess.

  • matt s (unregistered) in reply to Sarkie

    12 is equal to 3. For the appropriate base, of course.

    ;-)

    And the captcha agrees, smile.

  • f@ (unregistered) in reply to Veinor
    Veinor:
    Actually, 1 & 2 = 0. You're either thinking of 1 ^ 2 or 1 | 2.
    I remember the days when 1 ^ 2 meant one to-the-power-of two, so 1 ^ 2 = 1 * 1 = 1, rather than these Java days when it's XOR and 1 ^ 2 = 3.

    Watch for that one on the SCJP exam, kids.

    CAPTCHA:
    bling
  • (cs) in reply to Anonymous

    I've seen a few XBox360 games that use BINK, so even console games are not exempt here.

    And for those that suggest that their piddle little 10,000 seat bank app is in the same class as video games that sell hundreds of thousands or even millions of copies to unsupported high diverse platforms is kidding themselves.

    Even assuming you have a fixed target like the 360, I don't imagine many of us hit 3 million units shipped like GOW did.

    I don't know about you, but I know that my apps don't have to face that kind of scrutiny. 1% of customers experiencing would you would describe as "an annoying glitch you can work around" might only be 10 or 100 people for you, but when that 1% starts to approach the population of small towns, even the minor glitches matter more and more.

  • (cs) in reply to matt s
    matt s:
    12 is equal to 3. For the appropriate base, of course.

    ;-)

    And the captcha agrees, smile.

    For which base then?

  • Lurker273 (unregistered) in reply to Baggy McBagster

    I think you might be thinking of the game designer, designers and programmers haven't been the same person at most companies for over a decade now.

  • Lurker273 (unregistered) in reply to Baggy McBagster
    Baggy McBagster:
    I think the real problem with these here game programmers is that they keep spoiling good games, like Far Cry and Half Life, by ALWAYS ALWAYS including the 'runs along really fast jumps on you and bites you' enemy.

    Presumably the meeting goes something like this:

    "Yeah, we've done the game. Trouble is, it's too thoughtful, requires too much skill, and it's too immersive and believable." "Hey, I know, why don't we include something that jumps out suddenly? That way the player's only reaction is to back and reload." "Cool idea." "And also, make it move really fast straight toward the player? Then we won't need any AI, or much of anything really." "Good one!" "And finally, why not make it take a huge chunk of damage off the player by biting. It'll be kind of weird that guns and grenades do less damage than an single bite, but probably nobody will notice as they'll be too busy running away from these things anyway." "Yeah, ok, consider it done."

    Seriously, guys, just STOP including the enemy that runs toward you really fast and bites you! Include something else instead! Even an enemy that runs toward you really fast and asks you trivia questions would be a welcome change.

    I can tell you from experience that programmers very rarely make any of these kinds of design decisions, sure we have input into the process but these decisions are ultimately up to the designers(see my above comment).

  • smetzger (unregistered) in reply to Lurker273

    I don't know about you but the gaming programmers have convinced me that their code is good enough for WTF articles. :)

  • doesn't matter anymore (unregistered) in reply to brazzy
    brazzy:
    anon:
    Stop giving that crap! It's only 10 orders of magnitude more complex if the programmers like to re-invent the wheel.
    Not even then. NO program ever written is 10 orders of magnitudes more complex than even the simplest "Hello World". 10 orders of magnitude would mean 10^10 or 10,000,000,000 times.
    Protip: Hyperbole is not pronounced Hyper-bowl. In some locations, hyperbole is filed under humorous. End of line.
  • Abscissa (unregistered) in reply to anon

    [quote user="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.[/quote]

    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? ... And stop giving the BS about how hard it is to program games. … Also games usually don't have all the concurrency or security issues (save perhaps MMO games). [/quote] Try it, and you'll get your answers to why we "pretend" it's harder. I get so tired of seeing people who have never ventured outside of their IT world (and yes, I have worked in IT myself) pretending they know exactly what it takes to make a game. So if you think it's so easy: put up or shut up.

    [quote user="anon"]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. [/quote] Except that for most (note, I didn’t say all) IT software, the higher-ups tend to just throw bigger and faster servers at any performance issue. So, sure you could say you have severely limited memory and CPU, but more often than not it wouldn’t be true. And certainly not to the extent that it often is in games.

    [quote user="anon"]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. [/quote] First of all, what in the world does the seriousness of a failure have to do with project scope? It’s an important issue, sure, but entirely unrelated to scope.

    Number of transactions does not constitute scope of the code, either. A bank app is still a glorified calculator hooked up to a database, no matter how many transactions there are, no matter how serious the consequences of failure. If it were moderately complex, then relying on twenty-year-old COBOL code as they do just wouldn't cut it.

    Now, take that bank app, add in things like 30-60 frame-per-second 3D graphics with convincing lighting and shadows, multi-channel audio decoding and mixing, convincing AI behavior, rigid-body and soft-body physics models, etc., and you'll start to understand what “scope” really means.

    A bank app involves the disciplines of coding, business logic and accounting, algebra, security, some standard networking, and maybe a handful of things needing internationalization. Game code involves all of those disciplines plus various branches of physics (light, audio, kinetics), calculus, basic EE (because the consoles ARE embedded systems, so ultra low-level code is needed), AI, usability engineering, economics (for MMO's), more complex networking (including dead reckoning, among other things), data compression, and up to a small novel's worth of internationalization.

    Enough code from enough fields that a full recompile can take hours (which in turn requires processes to be made to minimize the need for and impact of full recompiles). Enough code from enough fields that a single game is the result of the work of dozens of coders (among other positions) at both the game company and at each of numerous game-specific middleware providers (in addition the same baseline tools and libraries non-game programmers use). THAT is scope.

    I'm not claiming this makes game programming "cooler" or "better" or whatever than most other apps. Just more complex, and yes, “harder”.

    [quote user="anon"]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. [/quote] "Real time" just means something needs to get done within a maximum time frame. Yes, it's often associated with mission-critical and life-or-death systems, but those are not part of the definition.

    Also, for the record, nobody here ever said game code was "more important" than any other code. Code for power plants, aircrafts, pacemakers, etc. are all obviously more important. Nobody said otherwise, so chill.

    [quote user="anon"]Sorry for if I sounded harsh but the "my work is more important than yours" attitude angers me...You're not special. [/quote] Again, nobody ever said it was more important. But what angers both me and many other game developers is the constant barrage of flack we get from people with no game-related background who think that A. they can do our job better just because they've written a few PHP scripts, B. our jobs are easy because, "hey, they're just games, they couldn't be hard to make!", or C. any amount of other such uninformed nonsense (not to mention the barrage from much of the public who still insist our medium is nothing but "kids toys" and/or "evil serial-killer trainers" that don't deserve to be considered a legitimate medium).

    If we ever come across as sounding "holier than thou" it's not because we think we are, it's just a side-effect of all the defenses we’ve had to put up over a lifetime of having to defend our hobby/career/field to completely uninformed (and yes, often “holier than thou”) parents, relatives, politicians and forum posters like yourself.

  • (cs) in reply to anon

    (Damn, that's the last time I try to make a long post without logging in to make it editable... Mods can delete the previous mess if they wish.)

    anon:
    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? ... And stop giving the BS about how hard it is to program games. … Also games usually don't have all the concurrency or security issues (save perhaps MMO games).

    Try it, and you'll get your answers to why we "pretend" it's harder. I get so tired of seeing people who have never ventured outside of their IT world (and yes, I have worked in IT myself) pretending they know exactly what it takes to make a game. So if you think it's so easy: put up or shut up.
    anon:
    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.
    Except that for most (note, I didn’t say all) IT software, the higher-ups tend to just throw bigger and faster servers at any performance issue. So, sure you could say you have severely limited memory and CPU, but more often than not it wouldn’t be true. And certainly not to the extent that it often is in games.
    anon:
    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.
    First of all, what in the world does the seriousness of a failure have to do with project scope? It’s an important issue, sure, but entirely unrelated to scope.

    Number of transactions does not constitute scope of the code, either. A bank app is still a glorified calculator hooked up to a database, no matter how many transactions there are, no matter how serious the consequences of failure. If it were moderately complex, then relying on twenty-year-old COBOL code as they do just wouldn't cut it.

    Now, take that bank app, add in things like 30-60 frame-per-second 3D graphics with convincing lighting and shadows, multi-channel audio decoding and mixing, convincing AI behavior, rigid-body and soft-body physics models, etc., and you'll start to understand what “scope” really means.

    A bank app involves the disciplines of coding, business logic and accounting, algebra, security, some standard networking, and maybe a handful of things needing internationalization. Game code involves all of those disciplines plus various branches of physics (light, audio, kinetics), calculus, basic EE (because the consoles ARE embedded systems, so ultra low-level code is needed), AI, usability engineering, economics (for MMO's), more complex networking (including dead reckoning, among other things), data compression, and up to a small novel's worth of internationalization.

    Enough code from enough fields that a full recompile can take hours (which in turn requires processes to be made to minimize the need for and impact of full recompiles). Enough code from enough fields that a single game is the result of the work of dozens of coders (among other positions) at both the game company and at each of numerous game-specific middleware providers (in addition the same baseline tools and libraries non-game programmers use). THAT is scope.

    I'm not claiming this makes game programming "cooler" or "better" or whatever than most other apps. Just more complex, and yes, “harder”.

    anon:
    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.
    "Real time" just means something needs to get done within a maximum time frame. Yes, it's often *associated* with mission-critical and life-or-death systems, but those are not part of the definition.

    Also, for the record, nobody here ever said game code was "more important" than any other code. Code for power plants, aircrafts, pacemakers, etc. are all obviously more important. Nobody said otherwise, so chill.

    anon:
    Sorry for if I sounded harsh but the "my work is more important than yours" attitude angers me...You're not special.
    Again, nobody ever said it was more important. But what angers both me and many other game developers is the constant barrage of flack we get from people with no game-related background who think that A. they can do our job better just because they've written a few PHP scripts, B. our jobs are easy because, "hey, they're just games, they couldn't be hard to make!", or C. any amount of other such uninformed nonsense (not to mention the barrage from much of the public who still insist our medium is nothing but "kids toys" and/or "evil serial-killer trainers" that don't deserve to be considered a legitimate medium).

    If we ever come across as sounding "holier than thou" it's not because we think we are, it's just a side-effect of all the defenses we’ve had to put up over a lifetime of having to defend our hobby/career/field to completely uninformed (and yes, often “holier than thou”) parents, relatives, politicians and forum posters like yourself.

  • PHP coder (unregistered) in reply to brazzy
    brazzy:
    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.

    I used to program in C++ and Unreal Script, but then my company went bankrupt, so I got a cushy "integration" job at a big corporation. They use PHP to make their command line tools (for some strange reason), which is where I took the handle "PHP coder". Now I'm working on an engine based on Gamebryo, so I guess the handle isnt relevant anymore (although I still do PHP coding in my spare time). Sorry for the confusion.

    I was (obviously) using the phrase "10 orders of magnitude" colloquially, not literally, but you can take it to mean literally "10000000000 times" if it makes you happy.

    Some internet nerd being belligerent: lame, but at least he's not arguing about spelling.

  • Game coder (unregistered)

    Coding games is cooler than coding business software (seriously, who doesn't agree?)

    (AAA) Games have larger scopes than banking software*. Banking software is more important than any game.

    Games are real-time applications (performance critical)*. Games are not mission-critical applications.

    Games sometimes cannot be patched, unlike most software*.

    Most re-usable game code comes from 3rd parties. Most 3rd party code is supplied to game developers with source, and often requires modification (e.g. The unreal engine is always extensively modified by the developer)*.

    Games have very short schedules, and good QA procedures shorten development time*.

    Games have very short schedules, and bad QA procedures and "quick hack" style programming shortens development time.

    Programmers are arrogant because its a (relatively) small industry, confined to intellectuals.

    Game programmers are even more arrogant because their industry is even smaller and is confined to experienced programmers.

    Business software often contains WTFs. Game software often contains WTFs.

    (* = reasons why good QA is required for games)

  • Game coder (unregistered) in reply to brazzy

    [quote user="brazzy"][quote user="anon"]10 orders of magnitue would mean 10^10 or 10,000,000,000 times.[/quote]

    Only in base 10 :P

    it could also mean 1024 to a programmer ;)

  • (cs) in reply to Baggy McBagster

    [quote user="Baggy McBagster Seriously, guys, just STOP including the enemy that runs toward you really fast and bites you! Include something else instead! Even an enemy that runs toward you really fast and asks you trivia questions would be a welcome change. [/quote]

    Fallout 2 - Bridgekeeper special event. Based on Monty Python & the Holy Grail.

    It's already been done (sort of).

  • richard (unregistered) in reply to mr_smee
    mr_smee:
    But this one goes to 11.

    Why don't you just make 10 louder?

  • anon (unregistered) in reply to akatherder
    akatherder:
    The people who are complaining that gaming code needs to be of much higher quality don't understand what Alex meant. He was saying that once the product ships, no one can go back and change the code. If you ship it out the door and it works perfectly, it doesn't matter what kind of mess your code is.

    As mentioned, this doesn't apply to the few game engines that are re-used or the games that are patchable. But who cares if your code is a mess once it's released. No one can update it anyways.

    I'm not taking sides but that's how I understood the commentary.

    "the few game engines that are re-used" -- Actually most modern games are based on engines that are reused many many times. Modern game engines are so large and complex that attempting to write a new one from scratch is far too expensive (both in terms of money and in time). A well written and reusable game engine becomes a very valuable piece of technology for a game development company.

    Pick a random current-gen game, or the vast majority or previous-gen games and it was probably built on the same low level engine as numerous others.

  • CindyPsych (unregistered) in reply to Imperceptus
    Imperceptus:
    yeah like the PS3, that one worked awesome out the door. Right into the trash can.

    What are you talking about? First of all, the PS3 is a console, not a game. Patches were available the first second you logged onto the internet with your PS3. The only thing wrong with the PS3 was Sony's decision to launch it when they didn't have their manufacturing processes up to full speed and didn't have enough games available at launch. Very similar to the XBox 360 launch, in fact, but the XBox 360 didn't have the Wii breathing up it's keister.

  • totallymeat (unregistered) in reply to snqow

    I recognize that crap, I used to work for that company that generated that code. They probably licensed their "game" engine out Stellar Stone for way too much, because it looks exactly like all of the other vehicle-based "game" demos they produced. I saw them sit on their asses and make "game" demos like this for years, all with the promise of next generation interaction and excitement. Yeah, nice job, guys.

    We should have stuck with the bionic jackrabbits on speed. At least them it would have made sense if the characters could speed up indefinitely in reverse and clip through the entire playing field.

  • NeoMojo (unregistered) in reply to brazzy
    brazzy:
    anon:
    Stop giving that crap! It's only 10 orders of magnitude more complex if the programmers like to re-invent the wheel.
    Not even then. NO program ever written is 10 orders of magnitudes more complex than even the simplest "Hello World". 10 orders of magnitue would mean 10^10 or 10,000,000,000 times.

    Why would it mean that?

    What have you defined "order of magnitude" to mean?

    Order of magnitude means the size of something. 1 is an order of magnitude (of something). 54 is an order of magnitude (of something). The word magnitude does not imply 10 in any way.

    If someone say to me "2 orders of magnitude bigger" then I assume it's twice the size, because that what that phrase means.

  • (nodebb)

    cool

    Addendum 2022-12-01 20:57: I'm only able to describe my current playing style to you. Nowadays, in the era of online casinos, no one visits traditional casinos purely for financial gain. Typically https://www.canadianroofmasters.ca/best-gambling/blackjack/ people just go out to enjoy themselves, drink, and have fun. And people do make money at internet casinos. I've only been able to uncover one outstanding thus far. I started making money as a result after finding a typical casino. I now make several times more than I did at my previous position. Everyone can easily locate the same online casino and play now, in my opinion, because it's really respectable. Everything is currently available online =)

  • Rouwdy (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to Eric Cartman

    I m very glad to find this post.

    Addendum 2024-03-26 16:58: Hello Eric! If you are interested in online casinos and are just starting to play, you should use the Casiqo casino no deposit bonus https://casinosanalyzer.com/casino-bonuses/casiqo.com There you will get acquainted with the game, follow the instructions on their website, and learn the basic tricks to get the bonus, you will get it immediately. Thanks to reading carefully, here you can start playing safely and without losing money.

Leave a comment on “Gaming Ground”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article