   I need help breaking a bad pattern of behavior.
  Greetings. I have a problem, that I suppose I might share with you guys. The problem is that whenever I start with a project I'm always motivated and often has a pretty good idea what I want the end result to be etc. However, rather quickly, I get very demotivated by thoughts such as "oh this bad code, you shouldn't be doing this", "this is not modular enough", "too much coupling" or whatever. And the interesting thing is I probably have no idea wether the design etc is any good OR bad at all.Does anyone here have the same or a similar problem? What do you or can you do about it?I'm personally trying to tell me myself that I can't possible know if it's bad code yet, I've usually only started and it will probably take at least a couple of thousands of lines of code before I can really start to see the code smells etc.   
  I tend to do this sometimes.  One thing I found to help is just finish anyway.  Once I start recognizing that this may not be the best solution (but yet I have no idea what would be better or how to improve it) I try to make a note of it, pay attention to it, but force myself to continue with the program.  Then, once I finish*, in a type of postmortem process, I think about why that design failed and what would've made it better.  It usually helps me to evaluate it better once everything is done because I better understand how the full program was finally structured and how I could've better designed that entire structure.*Ok, so it's impossible to really finish a program.  But at least I try to reach some type of playable prototype.   ;  I've got that problem big time.  It's a commitment issue.There are a few things you can do to combat it.  First, when you get an idea, question yourself on what you think development of the game will be like in a few months.  Has it already become stagnant?  What implications does the project have and how will they get in the way?  Are the implications avoidable?Second, (this helped me the most), start writing the engine without knowing what game you're going to build from it.  There is tons of work you can do on an engine before ever really implementing game-specific code (basic rendering, input capturing, game states, etc...)You learn by your mistakes and if you stop before making any you won't be learning much at all.  Take a chance and write bad code.   ;Quote:Original post by programmermattcSecond, (this helped me the most), start writing the engine without knowing what game you're going to build from it.  There is tons of work you can do on an engine before ever really implementing game-specific code (basic rendering, input capturing, game states, etc...)I find the opposite (as do others).Making an engine in isolation has been argued here before many times. The main problems are that until you start writing your game, you don't really know what your engine should do. You might find that after X months making an engine, when you start writing the gameplay code that you have made some huge omission. You save time by focusing on writing a game.You can usually extract an "engine" from your game later, by simply stripping out the parts that are specific to the particular game. If this is easy to do then you already have a good chance at having a flexible engine, or parts thereof, that can be reused with ease.The main thing that helped me was writing lots and lots of programs. My usual routine for starting a new project now consists of copy/pasting my latest project, deleting code until when I run I am presented with a black screen and then proceeding to start changing and tinkering. In this way, I've built up a large amount of code that is pretty flexible for the kind of games I like to make, and is easy to reuse in different contexts etc.Practise makes perfect, so practise designing large systems by building lots of them.   ;  There's this thing some developers do, where they code defensively, in an aggressively bottom-up fashion. This is usually coupled with some really big ideas about engine architecture and data-flow and suchlike. Three months into the development of their Mario clone, their "game" will consist of an empty level with a mushroom bouncing across it. Under the hood, of course, it'll have ten thousand lines of physics integration and resource management and middleware paradigm management and event-integrative transformal framework response applets. (God only knows how Nintendo managed without those.) Meanwhile, because it's ten thousand lines long and has dozens and dozens of classes, the developer will have painted himself into at least five corners, and will additionally be getting absolutely sick of the thing.Does this describe you?   ;  Well Sneftel it describes me down to a T unfortunatly.   ;Quote:Original post by SneftelThere's this thing some developers do, where they code defensively, in an aggressively bottom-up fashion. This is usually coupled with some really big ideas about engine architecture and data-flow and suchlike. Three months into the development of their Mario clone, their "game" will consist of an empty level with a mushroom bouncing across it. Under the hood, of course, it'll have ten thousand lines of physics integration and resource management and middleware paradigm management and event-integrative transformal framework response applets. (God only knows how Nintendo managed without those.) Meanwhile, because it's ten thousand lines long and has dozens and dozens of classes, the developer will have painted himself into at least five corners, and will additionally be getting absolutely sick of the thing.Does this describe you?Well, actually, it almost does. Except that I never even get to the 10k lines of code stage because I've downplayed myself so much that I'm not capable of doing it (I suppose). And thanks rip-off (and you other responders aswell), Quote:Original post by rip-offPractise makes perfect, so practise designing large systems by building lots of them. is the simplest but also most profound ideas as of yet for solving this :). I mean, even if I create 10 crappy games, hopefully the tenth will be somewhat an improvement over the 1st one. Cheers!;  It's difficult to pinpoint why, exactly, people are driven to this. I've heard it suggested that programmers, left to their own devices, overcomplicate things in order to make them worthy of their intellect. So koopas get a neural network AI, genetically evolved to make them turn around when they hit a pipe. And I think this is a reasonable criticism, but only part of the problem; after all, games are demonstrably complex in essence. Another possible issue is that they're afraid to commit to the details of their game design (Does an enemy go ragdoll when he is shot, or is there a specific animation for it? What's the full set of character classes? Are there going to be area of effect spells?) so they make their program able to embrace all of these possibilities, hedging their bets against a finalized design that never evolves itself. Finally, I think that (ironically) people are afraid of painting themselves into a corner, so they feel pressured to design and underlying framework that can do absolutely everything they'd ever want to do.I think I have a fairly workable two-part solution. First, a full game design up front, in detail, with specific details that you are confident will go together well with each other. That's the easy part, though boring for a game developer who prefers programming to design and really thinks he has the whole concept together in his head [he doesn't].Next, a top-down development process that emphasizes visual, playable improvements on an incremental basis. Today Mario's on the screen (project now has fifty lines of code total). Tomorrow he can move around and jump (120 lines). Under some circumstances, this visible development slows down a bit, say to replace the ten places resources are being loaded with a unified resource loader, but the developer is forbidden to be proud of these or think of them as progress, because they aren't visible. I'm guessing that this will be a much more controversial suggestion, because a lot of that scaffolding stuff really is useful in a large game. I would argue, though, that until you have completed a game of almost a given size, you are not qualified to opine as to how much scaffolding is necessary for it. Do the simplest thing that could possibly work NOW, and then redesign it later if necessary. The wasted time will probably be much less than the time spent on underutilized scaffolding.   ;  Personally, I think your problem is you simply don't have a goal. You're thinking maybe you'll make a game, maybe you'll make an engine, maybe you'll make some nice module for something... but "maybe" doesn't really cut it. It doesn't count.If you don't have a goal, you'll never know if you're doing well or not. Hence the whole "shouldn't be doing this" mentality. Am I finished? Should I rewrite it? Does it need to be more modular? Why do you need to ask? What are you trying to do?When I started making games again last year I decided to complete a very simple game. I didn't care about whether the code was pretty. I didn't care about if it ran well. I didn't care if it would be easy to extend later on. I had an idea and I wanted to complete it and that was that.That game is written like complete crap. The engine infrastructure is completely inane and most of the code is downright stupid. I made terrible design choices, didn't iterate enough, and didn't polish. But none of that has anything to do with my goal. I wanted to make a game and I did. Now it's been played over 2 million times and still gets 7000+ plays a day. I took my experience from that and now run a profitable company.So if you want to make a game then just make the game and don't worry about how messy it is. Or if you want to make nice code then just make that your goal and don't worry about big game designs. Write some nice little module that does something neat and move on. No matter what, as long as you have a goal and finish it, you'll be more experienced than when you started. Doing it right "next time" is a wiser strategy than you might think because you can't get to the next time until you finish something first.   ;  I had the same problem. Two things really helped me:1) Have a clear vision, and an actual design for a game you want to make.2) Have a deadline to complete it!Especially the second one. Without deadlines, I think you'll have a tendency to always try and build the "perfect" system and not actually get anything done. Plan out the development of your project, do estimates to find out how long it'll take, create milestones, and try to follow that plan. Adjust the plan if necessary.With a fixed amount of time for development, I find that while you may not write the best code (some of it may be downright horrible), you actually get stuff done.   