Pages: [1]
  Print  
Author Topic: Programming principles from Id Software's early days  (Read 10225 times)
Neon_Knight
In the year 3000
***

Cakes 49
Posts: 3775


Trickster God.


« on: August 17, 2016, 10:54:21 AM »

    Quote
    When it comes to game developers, id co-founder John Romero is among the most influential. At GDC Europe in Cologne, Germany today, Romero ran down some of the key programming principles that the Doom studio adhered to in the 1990s.

    But be warned: Romero said some of these principles sound insane by today’s standards. These guidelines are products of their time, but in the 90s, they worked for id. The studio was able to crank out 28 games in five-and-a-half years with less than 10 developers, producing such seminal titles as Commander Keen, Doom, Quake, and others.

    No prototypes – always maintain constantly shippable code. Polish as you go.

    Today, the common advice is to prototype, prototype, prototype. Get something playable, and find the fun. But for id, Romero said the company had no time to prototype. The games the studio made were small in scope and easy to visualize in the team’s minds, so they went from idea straight to product. “Nowadays with any big project, you’re going to need prototyping,” he said.

    A game called Quake: The Fight for Justice was the only game that the team threw out, Romero said. They worked on it for two weeks (it was an RPG) before deciding to toss it out and move on. They wouldn’t return to the Quake universe until four years later.

    It’s incredibly important that your game can always be run by your team. Bulletproof your engine by providing defaults upon load failure.

    Romero repeatedly stressed the importance of finding ways to increase efficiency, including making sure the game can be run by your team.

    Keep your code absolutely simple. Keep looking at your functions and figure out how you can simplify further.

    Again, simplification is important. Not just in code but in game design and production processes.

    Great tools help make great games. Spend as much time on tools as possible.

    “We are our own best testing team, and we should never allow anyone else to experience bugs or see the game crash,” Romero said. “Don’t waste others’ time. Test thoroughly before checking in your code.”

    He added, “As soon as you see a bug, you fix it. Do not continue on. If you don’t fix your bugs your new code will be built on a buggy codebase and ensure an unstable foundation.”

    Use a superior development system than your target to develop your game.

    Though Doom’s target was MS-DOS, Romero said Doom was developed under the more advanced NextStep operating system, which was the predecessor to OS X.

    Write your code for this game only, not for a future game. You’re going to be writing new code later because you’ll be smarter.

    Reusing code from game to game didn’t make sense for a team that was all about optimization for the situation at hand. (And of course there was no Unity or Unreal Engine to license.)

    Encapsulate functionality to ensure design consistency. This minimizes mistakes and saves design time.

    When you do this, you’ll have more efficient code and more flexibility with design choices and changes.

    Try to code transparently. Tell your lead and peers exactly how you are going to solve your current task.

    In id’s early days it was just four guys – Romero, John Carmack, Tom Hall, and Adrian Carmack – in one room coding and listening to heavy metal. Everyone knew what the other was doing, and that benefited id back then.

    Programming is a creative art form based in logic. Every programmer is different.

    Self-explanatory! (And still applicable for today.) During a Q&A session, a budding game developer asked if Romero ever got burned out due to the furious pace of game development. Romero explained the kind of programmer he is -- he just loves programming so much that he never got burnt out. And another thing to keep in mind: There was a lot of work that came before id's most famous game, Doom. Wolfenstein was his 87th game; Doom was around his 90th, he said.

    http://www.gamasutra.com/view/news/279357/Programming_principles_from_the_early_days_of_id_Software.php

    Quote
    In a GDC Europe talk recounting id Software’s early days, co-founder John Romero revealed ten core principles that led to the studio’s success creating Doom, Quake, Wolfenstein and more than 25 other games in five years with fewer than ten staff.

    “Some of this will sound insane, but we were in our twenties and there were no limits,” Romero began, recalling the start-up developer’s experience making a Super Mario 3 demo for Nintendo, licensing the Commander Keen engine – a move Romero described as the beginning of the modern engine licensing business – and implementing smooth scrolling pixel-by-pixel in Dangerous Dave in Copyright Infringement – a discovery said led to “Id Software being born that moment”.

    Revealing stories behind the iconic studio’s formative months and years – including wading through a river filled with snakes to make it to the office in order to code and creating Doom in homage to Dungeons & Dragons, Aliens and Evil Dead – Romero outlined ten key commandments developers should abide by in order to produce the best game they can:

    • “No prototypes. Just make the game. Polish as you go. Don’t depend on polish happening later. Always maintain constantly shippable code. We just quantified what needed to be done and went about working on it.”
    • “It’s incredibly important that you game can always be run by your team. Bulletproof your engine by providing defaults upon load failure.”
    • “Keep your code absolutely simple. Keep looking at your functions and figure out how you can simply further. We made everything up to Quake in plain C, not C++.”
    • “Great tools help make great games. Spend as much time on tools as possible. I wrote a tile editor in 1991 called TEd, for ‘Tile Editor’. It was used for 33 retail games.”
    • “We are our own best testing team and should ever allow anyone else to experience bugs or see the game crash. Don’t waste others’ time. Test thoroughly.”
    • “As soon as you see a bug, you fix it. Do not continue on if you don’t fix your bugs, as your new code will be built on a buggy codebase and ensure an unstable foundation.”
    • “Use a superior development platform than your target. Doom was developed on NeXTSTEP workstations, which was superior to DOS.”
    • “Write your code for this game only – not for some future game. You’ll be writing new code later because you’re smarter, and you won’t be limiting yourself by using old code. Try new things.”
    • “Encapsulate functionality to ensure design consistently. This minimises mistakes and saves design time.”
    • “Try to code transparently. Tell your lead and peers exactly how you’re going to solve your current task and get feedback and advice. Do not treat code like a black box.”

    http://www.develop-online.net/news/10-development-commandments-that-led-doom-dev-id-software-to-change-the-games-industry/0223203[/list]
    « Last Edit: August 17, 2016, 11:04:40 AM by Neon_Knight » Logged


    "Detailed" is nice, but if it gets in the way of clarity, it ceases being a nice addition and becomes a problem. - TVT
    Want to contribute? Read this.
    Pages: [1]
      Print  
     
    Jump to: