When is it a good idea to write a tech doc?

Discussion in 'Indie Basics' started by NothingLikeit, Dec 1, 2007.

  1. NothingLikeit

    Original Member

    Joined:
    Aug 26, 2005
    Messages:
    343
    Likes Received:
    0
    Hey guys,

    I'm working on the prototype of my game. I have some of the stuff up and working. the player can pick up a gun and shoot the enemy. It's an arcade based 3D shooter by the way.

    But my question is this: The action of shooting with different weapons is the main functionality of the game. So should I write a technical document at this stage? And if so, what do I need to include in such a document?

    How do you even start writing one?

    P.S. I'm scripting this with 3D gamestudio, so the engine was done for me. Thanks for any insights you all can provide.
     
  2. Coyote

    Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    697
    Likes Received:
    0
    Why do you need a technical doc?

    Are you trying to assess risks and possible work-arounds? Are you trying to decide on what technology to use? Do you not know what platform you will be making your game? Do you have employees or contractors who will be building the technology for you and need specifications?

    If it's for you alone, make notes to yourself in whatever format you find most readable, make sure you can convert those notes into a "hit list" of tasks, and call it done. Anything else is wasting your time. Unless I'm really missing something here?

    A TDD (Technical Design Doc) is just a way to communicate with other people. And aside from using it to schedule tasks for employees, it's primary communication purpose is the equivalent of two sentences sent to a publisher: "Dear Publisher, we know what we're doing. Please keep sending money."
     
  3. NothingLikeit

    Original Member

    Joined:
    Aug 26, 2005
    Messages:
    343
    Likes Received:
    0
    yeah I guess you're right. For now it's just me. I was wondering if I really needed one. I've just been making notes to myself about this and that. But since this is my first real programming project, and I"m getting into game specific elements, what would you say are good notes to make to yourself?

    For example: I coded a generic entity that controls the enemy, but each enemy type has unique attributes (health, damage etc) So should I write notes like

    This enemy does this damage, the action for him is named...

    This enemy is named ... and is controled by these functions....


    What type of notes have helped you in the past.
     
  4. Reactor

    Moderator Original Member Indie Author

    Joined:
    Jul 27, 2004
    Messages:
    1,637
    Likes Received:
    0
    You should write down whatever you think is going to help you. Not anyone else- just you. If you're not sure it'll help, write it down and see if it helps. If it doesn't help, stop writing it down. Keep on developing the game, and you'll learn by experience what you should have written down (if you hadn't previously thought it might help), and remember that for next time.

    In other words, if you're clever enough to make a game, you should be clever enough to figure out what information assists you in development. If you find a complex code of pink and purple swirls in an Excel document help you, roll with that.
     
  5. PrefixEx

    Original Member

    Joined:
    Nov 25, 2005
    Messages:
    51
    Likes Received:
    0
    Sometimes its also a nice thing to have if you want port something or you eventually decide you want someone else to port your game (from platform X to platform Y).

    You are exactly right Coyote, most of the formal documents just for fun if your team is less than 3 people.

    If you do add someone to your project it is nice to have them instead of making them up on the fly.
     
  6. Nikos Beck

    Nikos Beck New Member

    Joined:
    Jun 14, 2007
    Messages:
    321
    Likes Received:
    0
    There should be a spot where you keep the stats on each eneny. Ideally it'd all be in the same place, maybe in Excel, so you can see all of the enemies at a glance and tweak the numbers. You could have the stats as a comment in the header file for each enemy. For that kind of data I usually have a text file that the game reads and sets stats accordingly. If it was in source you'd have to rebuild the game every time you make a change.

    Personally, I don't write tech documents. I write the code I need to use right now, look one step ahead to make sure the new feature won't break my current code, and move onto the next task on my list.
     
  7. dpadam450

    dpadam450 New Member

    Joined:
    Dec 11, 2006
    Messages:
    23
    Likes Received:
    0
    I will suggest though, if this is an "engine" framework that you might use again, then design your code. Never copy paste, always make functions. Tips:

    Mesh* ship= Load3DModel()
    Texture* shipTex =LoadTexture()

    DrawModel(ship, shipTex)

    Also, write tools, if your say trying to tweak the correct value for anything, add a debug where you can hit keys to adjust values or if its something more bigger, write a small tool for it.
     

Share This Page

  • About Indie Gamer

    When the original Dexterity Forums closed in 2004, Indie Gamer was born and a diverse community has grown out of a passion for creating great games. Here you will find over 10 years of in-depth discussion on game design, the business of game development, and marketing/sales. Indie Gamer also provides a friendly place to meet up with other Developers, Artists, Composers and Writers.
  • Buy us a beer!

    Indie Gamer is delicately held together by a single poor bastard who thankfully gets help from various community volunteers. If you frequent this site or have found value in something you've learned here, help keep the site running by donating a few dollars (for beer of course)!

    Sure, I'll Buy You a Beer