Defining Awesome — Bad code & release dates
  • Status Updates

  • Bad code & release dates

    Written by . Posted at 4:22 pm on July 2nd, 2011

    Some requested a definition of good/bad code in the thread below.
    Archont is right with “good code” : works as expected. But I have a slightly different view.
    Suppose you want something expected to work on a release date (can be a major release in 6 months or just a patch in 3 days).

    Good Code:
    Any code that moves you closer to the release date.

    Bad Code:
    Any code that moves you further away from the release date.

    With this we see that if you don’t set a release date you cannot measure how good or bad is your code. So your development time increases infinitely because you might spend time rewriting and “perfecting” code that already works. Of course there are some companies that say it’s done “when it’s done” (like Valve, Id, 3D Realms RIP). I believe they just don’t announce a release date. I’m sure someone disciplined like Carmack sets release dates that are kept even for himself (like setting milestones). There is a paragraph in “Master’s of Doom” where it’s noted that Carmack after releasing Quake locked himself for a week in a hotel room to experiment with some technology. Doing that sets a deadline of 7 days. After that you expect to have something awesome working. It doesn’t matter what is inside the source code or how it looks.

    My favorite release date approach is a deadline of 1 day. When I start work on that day I say to myself: today I will make a physics engine or today I will make a particle engine. I work only on that during that day and usually at the end I have something working. Code made this way is usually the best code I make. If I tweak it or add stuff later it usually makes the code worse and less elegant. Doing a big chunk of code in 24 hours makes you remember the whole thing in your head. So you work the whole code in your head. The next day you will forget most parts of the code. If you return in a couple weeks there is nothing left of your understanding of the code. In 1 day it is possible to understand every bit of the code.

    Try it, instead of working on every piece of the game from time to time. Just take one segment of the game and try to code it in 1 day. If you fail, erases it, and try again.

    Be Sociable, Share!


    1. got to link this to the soldat dev team maybe..

    2. I have to disagree. This type of code is only good if you never have to touch it again, which I believe most of the times ends up not to be truth, we always make little tweaks, specially in this kind of stuff like physics engine. You might make it faster, but when you have to maintain it, the time you’ll spend on it will be much bigger than if you had good structured maintainable code. This might sum up and end up being more time than writing maintainable code since the first place. You never know for how long you’ll have to edit a code, it should be as easy to understand as possible. Take a look at Soldat, how old is it now? And people still want to play the game and even develop it. With maintainable code the game could have evolved to something more incredible and who knows, maybe you’d still be excited to update it.

      Making “good code” by your definition may be just your way to get things done, but I’m sure your programming style is now way better than when you did Soldat. It’s not all about just getting it to work.

    3. I have to agree with Random. Plus you have to remember that programming is 90% problem solving. Making nice clean code makes problem solving easier. I haven’t programmed as long as you have, I’m still green, but in the last few years I learned a lot that made it so that I could return to my code even after months and pick up where I left off. My first iOS game that I’m coding I started with the Corona SDK since I’m still a ways away from tackling pure Obj-C. In Corona you use Lua. The problem with Lua was that it isn’t object oriented. So here I was having to figure out how to make a game OO style with a scripting language. I ended up using arrays for objects and functions. I also used event listeners that followed a certain order. To get my movement and syncing right took a lot of trial and error but finally, the game is about 85% complete. All that’s left is some weapon firing, menus and adding sound, music.

      I ended up doing the code piece by piece rather than build the whole thing in one day and then try and make it work. What I was left with was modular code which I can plug anything into and I can time any event with another. Once I had the main engine done, expanding it and improving it was a complete breeze. I was even able to easily find memory leaks (which I’ve never had to deal with in code before, so no experience in how to look for them or even conceive what could cause a memory leak).

      Rather than building the whole game engine which is stupidly simple in one day or even a week, it took me weeks as I built the code block by block, always keeping future functions/events in mind.

      Mind you, before I started the game, I didn’t know Lua, never used it before. Plus, I had to figure out tricks to make it behave like object oriented code.

      The code is still not perfect and amateurish in the way I use the event listeners. But for a beginner at Lua and Corona it works, is bug free, no memory leaks and a good stepping stone to gaining experience and learning how to code a Corona game more properly (which is really about order).

    4. Clawbug

      Not really to the topic, but every single programmer should read Code Complete by S. McConnell and The Pragmatic Programmer by A. Hunt and D. Thomas. Really, they are probably two the most valuable software develoment & design books a person can ever read.

      When it comes to programming, understanding the fine details of the language is the hardest part. This is because way too often people (especially newbies) fall to the trap of trying to master a language without understanding what to DO with the language. Having went through this myself, I can only advice people to take the top-down approach and instead of focusing on fine details, focus on the big picture. Learn to THINK, learn what it means to be ABSTRACT, learn how to express the IDEA.

      Good code is well-written. It’s self-explanatory, obvious and well maintainable. Bad code NEEDS comments in order to understand it. Sometimes it’s nearly impossible to write good code, though it depends on the language and how powerful it is to express the thoughts of the programmer.

      Perhaps MM could make a blog post about the programming literacy which has proven to be helpful over the years?

    5. Snow, Random: you have not shipped any software yet, that is why you do not agree. Shipping is a whole different game than coding.

      There’s still a lot to learn. I can tell you that it’s faster to learn by scrapping the whole code and writing something new.

      Of course Soldat would be better if it had nice, modular code, but my point is it wouldn’t even exist if I tried doing that. It would not have been ever shipped, I would be stuck at 85%.

      ClawBug: I agree. My goal was always to make a concrete game. Never to master a specific language. I learnt a lot of programming languages but never mastered any language that I didn’t make a game upon.

      I don’t really read programming books. They bore the hell out of me to be honest. But I cannot say it wasn’t helpful whatever I read.

    6. MM, point taken. I’m not working with a deadline and haven’t shipped a game before. So no experience yet.

      Just the thing l’d be afraid of is if l wrote a program 1 day and thought of shortcuts, possible functions that could improve efficiency, etc, doesn’t it suck if you have to go through all that again the next day, when you rewrite from scratch? You night still forget some things you thought of the day before.

      Clawing, comments don’t always mean code is badly written. It’s definitely a valuable tool for beginners. I know ( and have yet to read ) the first book but didn’t know about the second.

    7. Uh, why did you assume I never shipped software? Are you that certain that it’s only possible to release something if you hurry to it?

      But yeah, I work with software (I’m a computer science student btw) so at work I’ve worked, developed and shipped products in teams and alone. As of side projects, I don’t know how big Soldat or KAG is, but the biggest piece of code I have shipped has 10k lines. I guess that’s not much and it’s not a game either. As of games my experience limits to browser based games, which I had a problem with the database queries so big that the hosting was threatening to close my account because of jeopardizing the network. I then decided to drop the game, at the time I didn’t even use OO, which wasn’t even that widespread or even very used with PHP4 (2005). So I was just rocking a bunch of files filled with functions.

      Since then I’ve always improved my style and always learning how to make my code cleaner, so that even after long periods of time I can still go back to it and not take much time until I figure out what’s happening. It doesn’t hurt me or delay me to deliver good maintainable code anymore, quite the contrary, I end up saving time because I barely have to rewrite code. I simply have to plan a little more before I start.

    8. Mr.Freeman

      you dont want to loose your auditory
      and need to write something
      but this thing make you not free to do what you should really do because you have feeling of limited time.
      thats what depressed you.

      “a lot of time and true-project”
      “little amount of time and trash-project”.

      P.S: but I dont know how to help you realize this 😉
      maybe you should write posts not about your project until its done. maybe some mini (twitter style) lifehack posts.
      P.S2: dont listen to me. drop this to trashbin. burn this to ashes. i understand nothing in this world. Hello.

    9. Mr.Freeman

      dont be y – be x
      wha ha ha!!
      i am insane!!!
      (blowing himself into pieces with grenade)

    10. Michal, brother!
      I wish you be in good mood.
      I wish you to find your fuel.
      I support you, in spite of everything.
      Best wishes, brother!

    11. Uh, why did you assume I never shipped software? Are you that certain that it’s only possible to release something if you hurry to it?

      I know this from nearly 20 years (?!) of coding experience. Of course, you must take into account that I am probably not the most intelligent person and don’t have the necessary genetic make-up / talent to ever be a super coder. Super coders that write super code and deliver it probably exist somewhere on the planet. Do you honestly think you are one of them?

      I will refer once again to John Carmack, no doubt you think of him as a super coder. However if you listened to the presentation I posted in the last blog you’ll learn how Carmack programmed Doom -> fast.

    12. If u do not even try to make things in a right way, you are already lost. all your speaking here is just about finding bunch of excuses to explain why did you fucked up. i am professional .net coder, i’m spending all fuckin day with code and what you saying here has a value of dog shit. Isnt it just to make you feel better?. Coding can be done good, because it is predictable if you focus intense enought. Link dead could be good game, if it wouldnt be limited to fight and kill only. there should be different localizations on the planet, owned by different clans.Destroyable environtment is mandatory to provide joy to the players. There should be demilitarized stations/cities, where weapon use is prohibited. there should be a trade/business aspect ( years ago i played Frontier – very limited game, but buying and selling was enought to keep me for hours next to the fuckin A500 monior ). Well, you fucked up, but you should’nt give up with this game.

    13. Hello,

      I am from Belo Horizonte, Minas Gerais, Brazil, and I study games in the unnivertsity PUC-MINAS, and I am in the course that focus in creating games. I want a work that make me “grow-up” in games, I love games since I was a child and know that games is a big thing in the word nowadays, and I want to work with this, please give me a chance, I can use the software Blender to make 3D-models and I can programming in UNIY3D, a engine. I programming in C++ and Open GL



      What I have?:

    14. Hey Michal,

      I’ve made a blog post on how to make a smooth networking game. I hope you check it out. :)

    15. truth: you code all day and?… what have you produced?

      Dalmar: Hello! I’ll check!

      shurcooL: gonna read that now.

    16. ZeroG001

      2D sidescroll shooter coming to xbla this august…

      Take Arms

    17. Reactorcore

      @Illu: lol nice one

      While it is true that well thought-out code is ultimately superior to rushed iterative code, in this day and age its very rare for a human to have enough time to perform this. Time and life is limited and only a released product has any validity to be sold, where as an idea or a design cannot.

      In our current world where you gotta pay bills and worry about a thousand other things besides the design of a project, its extremely hard to make a good code or design without running the risk of leaving yourself in a position where you have no money to pay bills as ideas cannot be sold.

      Apart from that, it is heavily advised that one should only pursue making good code/design if his vision of the project is clear enough.

      In MM’s case, he didn’t know clearly enough what he wanted to do (or what he could do). Thus “fast code” approach allowed him to prototype concepts and figure out the full vision, to the extent that he’s cleared to re-write the engine quite freely, because now he knows what works and how to set it up.

      In short, if vision of a project is unclear or unknown, MM’s developing method is an excellent choice for the matter. Otherwise, a traditional development method is adviced.

    Post a comment.