Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

General Tips for Solo Developers @ GameDev.net

LoktofeitLoktofeit Stone Mountain, GAPosts: 14,247Member Rare

A neat article at GameDev.net offers some general tips for the solo developer. They offer a five-step process and take you through each one.

  1. Idea
  2. Prototype
  3. Iteration
  4. Playtest
  5. Finish

Link: http://www.gamedev.net/page/resources/_/business/production-and-management/general-tips-on-the-process-of-solo-game-development-r3281

 

 

 

There isn't a "right" or "wrong" way to play, if you want to use a screwdriver to put nails into wood, have at it, simply don't complain when the guy next to you with the hammer is doing it much better and easier. - Allein
"Graphics are often supplied by Engines that (some) MMORPG's are built in" - Spuffyre

Comments

  • RhinotonesRhinotones BenowaPosts: 241Member Uncommon
    Thank you for the link. Added it to my list of items to read in the morning.

    image
  • TheRedDreadTheRedDread Vancouver, BCPosts: 145Member Uncommon
    Good read. Thanks for the link.
  • QuizzicalQuizzical Posts: 16,611Member Epic

    Interesting stuff, but there are a few things I'd like to add:

    1)  Try hard things early on, especially things that you think that you may not be able to pull off.  You don't want to think that you're 90% done and then realize that a key feature on which the entire game depends simply can't be made to work at all.  This is part of why he talks about the importance of prototyping.

    2)  While saying that you shouldn't "prematurely" optimize is something of a tautology (if you should do it now, it's not premature), some optimization should be done early and often.  A game will have a tiny number of lines of code (e.g., hundreds of lines) that run an enormous number of times, and these need to be heavily optimized for speed.  Finding out early on that you can make your game run 20% faster may make it possible to implement more things without killing your performance.

    Additionally, in what he calls "life optimization", cleaning up code so that it is more comprehensible or can serve additional purposes can pay huge dividends, even if it doesn't improve game performance.

    3)  There are some performance optimizations that are simply a lot easier to do if you do them early on.  Most notably, making a game scale well to many CPU cores in CPU-limited situations is pretty easy to do if you plan for it before you write the first line of code that will go into the final game.  If you write your game to be single-threaded and want to go back and use more CPU cores when the game is nearly done, it's going to be a royal pain to do that, and you'll probably introduce a lot of new bugs if you try it.

    4)  If you find a bug, fix it.  It's much easier to fix a bug when you've just found it and can readily reproduce it.  Letting bugs stack up and figuring that you'll deal with it later is how you end up with a buggy mess of a game.

    5)  Make sure that the tools you're going to use can do what you need them to do before you get started.  You don't want to think you're 2/3 done and then realize that you have to scrap and redo a ton of stuff to use different tools because what you were using can't do what you need.  In particular, if at all possible, you want a compiled programming language as opposed to an interpreted scripting language, you want access to all of either OpenGL or Direct3D, and you want built-in sound and (if relevant) networking capabilities.

  • makutomakuto Rexburg, IDPosts: 1Member
    Originally posted by Quizzical
    Interesting stuff, but there are a few things I'd like to add: 1)  Try hard things early on, especially things that you think that you may not be able to pull off.  You don't want to think that you're 90% done and then realize that a key feature on which the entire game depends simply can't be made to work at all.  This is part of why he talks about the importance of prototyping. 2)  While saying that you shouldn't "prematurely" optimize is something of a tautology (if you should do it now, it's not premature), some optimization should be done early and often.  A game will have a tiny number of lines of code (e.g., hundreds of lines) that run an enormous number of times, and these need to be heavily optimized for speed.  Finding out early on that you can make your game run 20% faster may make it possible to implement more things without killing your performance. Additionally, in what he calls "life optimization", cleaning up code so that it is more comprehensible or can serve additional purposes can pay huge dividends, even if it doesn't improve game performance. 3)  There are some performance optimizations that are simply a lot easier to do if you do them early on.  Most notably, making a game scale well to many CPU cores in CPU-limited situations is pretty easy to do if you plan for it before you write the first line of code that will go into the final game.  If you write your game to be single-threaded and want to go back and use more CPU cores when the game is nearly done, it's going to be a royal pain to do that, and you'll probably introduce a lot of new bugs if you try it. 4)  If you find a bug, fix it.  It's much easier to fix a bug when you've just found it and can readily reproduce it.  Letting bugs stack up and figuring that you'll deal with it later is how you end up with a buggy mess of a game. 5)  Make sure that the tools you're going to use can do what you need them to do before you get started.  You don't want to think you're 2/3 done and then realize that you have to scrap and redo a ton of stuff to use different tools because what you were using can't do what you need.  In particular, if at all possible, you want a compiled programming language as opposed to an interpreted scripting language, you want access to all of either OpenGL or Direct3D, and you want built-in sound and (if relevant) networking capabilities.

    Hey, I'm Macoy (the author :) ). Interesting thoughts!

    #1- I totally agree with you. Most moves that reduce risks and don't take too much time are beneficial to the process.

    #2-  Optimization is largely by feel, so it usually takes quite a bit of experience before you take it on. I wanted to deter beginners from optimization because they would likely get discouraged, waste time optimizing the wrong lines, or fail (make the code worse). Once you become more experienced, definitely optimize the code you know will be the most significant bottleneck, but still be wary of spending too much time optimizing a small bit of code. Metrics are incredibly important. 

    And what you were saying on life optimization is also true, but focus on the code you KNOW you will be using a lot in the future! Don't clean up the code for a function you will be replacing quickly, but still use adequate documentation. I'd recommend everyone create their own game library for collecting useful classes/functions, documenting them well, and reusing them.

    #3- Yet another good point. I wrote the article with beginner-intermediate developers in mind, so you don't really expect them to revisit projects to make them multicore!

    #4- I must've forgotten to include that in the iteration stage! Definitely finish a module before moving to the next, or bugs will cause more and more bugs. I've started coming at new modules with an Extreme Programming-ish method where I test every single part/function thoroughly before moving on, and it's helped to kill a lot of bugs.

    #5- Agreed. Optimally, the prototypes will reveal as much as possible about the technical requirements early on. It is important to look ahead and clearly identify exactly what you plan on doing before beginning Iteration/implementation.

    You've made some very good points! Thanks for the feedback!

  • LoktofeitLoktofeit Stone Mountain, GAPosts: 14,247Member Rare
    Some nice additions, Quiz!

    There isn't a "right" or "wrong" way to play, if you want to use a screwdriver to put nails into wood, have at it, simply don't complain when the guy next to you with the hammer is doing it much better and easier. - Allein
    "Graphics are often supplied by Engines that (some) MMORPG's are built in" - Spuffyre

  • aspekxaspekx Brandon, FLPosts: 2,167Member Uncommon
    fyi: Quiz is a Jedi.

    "There are at least two kinds of games.
    One could be called finite, the other infinite.
    A finite game is played for the purpose of winning,
    an infinite game for the purpose of continuing play."
    Finite and Infinite Games, James Carse

  • WereLlamaWereLlama Lubbock, TXPosts: 244Member Uncommon

    Good list.

    With respect to optimization, if you are doing 3d optimization for mobile or other demanding tech, I  suggest finding out  as soon as possible what your 3d animated model gameplan is.

    Last years mobile devices are still demanding.   We had to re-build our main animated character models once we learned you can only put 30 on the screen at once the way we were originally doing it.

    Luckily, in 2 years, mobile devices will be amazing.. dynamic lighting on 100 animated objects, etc.

    -WL

Sign In or Register to comment.