One of my biggest mistakes when it comes to video game development is spending too much...I mean way too much...time on the details. I have this problem. From the start I spend more hours tweaking things like graphics and sound way before there is anything resembling a game. And when I do have something resembling a game, such as a simple one-level demo, I spend even more time messing around with minute details than on moving the game forward.
Everything has to be perfect before I can move forward. The problem with this is if I want to change something down the road; hours of work gets thrown away with more hours of work required for the changes. An example may be redrawing an entire tile set because I decided to go with a jungle level instead of a desert one. Another example would be continually redesigning levels as the game evolves. These all take time and lots of it.
The most effective way to save time is to layout your entire game in advance, and then fill in the details after the core functionality is completed. This pattern not only applies to video games, but to other creative practices as well. Take drawing for example; many great artists will sketch out an outline of their drawing first, then draw the shapes, and finally -- when everything is how they want -- fill in the details. The same logic applies: if I being a drawing by working out the details of every square inch, and if I want to change something halfway through, it's going to take a lot of eraser and time to fix (not to mention the time wasted by all the work that was just erased). This approach just isn't effective anywhere.
So if you're still the perfectionist, then be perfect with the planning and design. Don't move forward with the details until you are happy with your design. Then don't move forward with the details until you have built a robust framework that can support your design. Then once that is all done, don't yet focus on the details until you've built most of the game; use temporary or placeholder graphics and music (they aren't important at this stage; what's important is finishing the game). Then finally, when all there is to do is fill in the details and to polish your game, you can have at it and be rewarded with an actual game when you are done (and not a game still in the making).
These are just guidelines though. "Easier said than done," you might think. I agree. For me, it's a goal and not an actual practice -- a skill to improve upon. What's fun about game development is, well, developing a game and not having to worry about the less-entertaining work of documentation and low-level coding. Though, sometimes documentation and low-level coding can be fun for geeks like myself. But seeing your game in action as you craft it is an addiction.
No code is clean code
Think about it. The less code you can write the better. And I don't mean by cramming lines of code together or shortening variable names; I mean things like consolidating repetitive code into functions, separating game logic and presentation code from the rest of the program into data files (like XML), and being clever with your code like being clever with words on Twitter (keeping it short, simple and to the point).
Cap your time
Here's an idea. Break your project into phases. The first phase is something playable with a couple levels; the second phase adds a bit more and has all the levels, story, bosses, and music implemented; and the third phase is for polishing your game and filling in the gaps.
Now break each phase down into hourly estimates of categories. For instance: planning and design, programming, artwork, level design, music and sound. Here's an example for a small game:
Phase I
Planning and design: 2 hours
Programming: 15 hours
Artwork: 10 hours
Level Design: 10 hours
Music and sound: 10 hours
Phase II
Planning and design: 3 hours
Programming: 30 hours
Artwork: 20 hours
Level Design: 30 hours
Music and sound: 15 hours
Phase III
Planning and design: n/a
Programming/bug-fixes: 10 hours
Artwork touch-up: 5 hours
Level Design fixes/changes: 10 hours
Music and sound touch-up: 5 hours
175 hours! Initially I was thinking it'd end up around 50 hours, but breaking it up into phases showed me that I greatly underestimated that. And when I estimate my hours I like to overestimate, because things aren't going to go as smooth as you think they will half the time. Breaking your game up into phases does 2 things: first, you focus on reaching the end of the phase and not the end of the game's development (so you're less likely to be caught up with feature creep and the like), second your hours are better estimated because you are estimating hours with more concrete markers than just "finishing the game."
Here's the second part of my idea: DO NOT GO OVER YOUR HOURS!!!
Why? Because if you go over the when will it end? Ideas and the quest for perfection always get me spending more time on little details than I should. Also, you if keep to your word, when the time gets close and you're not quite there you will have to finish up with what you have, even if that means putting in plain (placeholder) graphics and just the raw bones of your code. The goal is to reach the end of the phase, not to complete the game. And once you reach the end of the phase, you can assess where you are at and where you want to go and plan your next phase. This type of planning/execution/planning pattern is used in commercial software companies in one form or another; some examples are Scrum and Agile development. There's power in this strategy as it keeps you focused on more realistic (and closer) goals. It also allows for changes to be made if needed (re-planning a phase, for example).
Now break each phase down into hourly estimates of categories. For instance: planning and design, programming, artwork, level design, music and sound. Here's an example for a small game:
Phase I
Planning and design: 2 hours
Programming: 15 hours
Artwork: 10 hours
Level Design: 10 hours
Music and sound: 10 hours
Phase II
Planning and design: 3 hours
Programming: 30 hours
Artwork: 20 hours
Level Design: 30 hours
Music and sound: 15 hours
Phase III
Planning and design: n/a
Programming/bug-fixes: 10 hours
Artwork touch-up: 5 hours
Level Design fixes/changes: 10 hours
Music and sound touch-up: 5 hours
175 hours! Initially I was thinking it'd end up around 50 hours, but breaking it up into phases showed me that I greatly underestimated that. And when I estimate my hours I like to overestimate, because things aren't going to go as smooth as you think they will half the time. Breaking your game up into phases does 2 things: first, you focus on reaching the end of the phase and not the end of the game's development (so you're less likely to be caught up with feature creep and the like), second your hours are better estimated because you are estimating hours with more concrete markers than just "finishing the game."
Here's the second part of my idea: DO NOT GO OVER YOUR HOURS!!!
Why? Because if you go over the when will it end? Ideas and the quest for perfection always get me spending more time on little details than I should. Also, you if keep to your word, when the time gets close and you're not quite there you will have to finish up with what you have, even if that means putting in plain (placeholder) graphics and just the raw bones of your code. The goal is to reach the end of the phase, not to complete the game. And once you reach the end of the phase, you can assess where you are at and where you want to go and plan your next phase. This type of planning/execution/planning pattern is used in commercial software companies in one form or another; some examples are Scrum and Agile development. There's power in this strategy as it keeps you focused on more realistic (and closer) goals. It also allows for changes to be made if needed (re-planning a phase, for example).
A programming language is not a game development framework
I think many people fall into this trap. You have an idea for a game, so you start coding. Everything goes well at first and by next week you have an awesome demo to showcase your upcoming game: your player can do some awesome moves, the graphics are slick, and it all looks promising. But then...months go by and progress has sharply declined. Sometimes there is nothing more to show. What happened?
From the programming side of things, the game starts to collapse under its own weight -- the code structure that supported the demo cannot handle the complexity of a complete game; and building upon such a flaky framework leads to mounds of spaghetti and buggy code.
There are many assumptions, but I believe the core issue is that the programmer relies too much on features of the programming language rather than a well thought-out and planned framework to support the game. What does this mean? I'll explain.
The idea of a game framework (sometimes referred to as a game engine) is to have you only writing code that deals with the game logic, fun stuff like: weapon properties, special moves, power-ups, level dynamics, etc. That's all you need to define your game anyway, and you send that game data to the framework (or game engine). The framework is the inner-workings of the game. It consists of helpful methods (subroutines or functions) that load levels, organize and render graphics, calculate objects on the map, churn the physics for each frame, and so on. It's important to keep the framework separate from the game logic by providing an interface. The interface is a set of methods that you use to send the data the framework needs to run a game and nothing more. One example is a method that accepts a file name of a map to load for the current level. Another example is a method that accepts properties for an object and then creates and adds that object to the map (like for a demon that throws fire you'd pass its strength, speed, skill, etc.); the framework would then be responsible for rendering and moving the demon under the rules you provided (through another method). The idea is that the game logic is separate from the lower-level logic that the game is running on top of; and you communicate with the framework via its interface. When people try to code these two parts together...well...it gets messy.
A suitable framework for your game should be developed first or in phases as the game progresses. If you are not sure how to go about it then you can look at some examples. Old-school games like Quake have their source code available. Use of frameworks apply to web design as well, so if you understand web development check out the source code for frameworks like Wordpress or Magento. If you want to save yourself the time of writing your own framework, and you want to jump right into game development, then a quick search of Google for "game development frameworks" will give you more than plenty to chew on.
From the programming side of things, the game starts to collapse under its own weight -- the code structure that supported the demo cannot handle the complexity of a complete game; and building upon such a flaky framework leads to mounds of spaghetti and buggy code.
There are many assumptions, but I believe the core issue is that the programmer relies too much on features of the programming language rather than a well thought-out and planned framework to support the game. What does this mean? I'll explain.
The idea of a game framework (sometimes referred to as a game engine) is to have you only writing code that deals with the game logic, fun stuff like: weapon properties, special moves, power-ups, level dynamics, etc. That's all you need to define your game anyway, and you send that game data to the framework (or game engine). The framework is the inner-workings of the game. It consists of helpful methods (subroutines or functions) that load levels, organize and render graphics, calculate objects on the map, churn the physics for each frame, and so on. It's important to keep the framework separate from the game logic by providing an interface. The interface is a set of methods that you use to send the data the framework needs to run a game and nothing more. One example is a method that accepts a file name of a map to load for the current level. Another example is a method that accepts properties for an object and then creates and adds that object to the map (like for a demon that throws fire you'd pass its strength, speed, skill, etc.); the framework would then be responsible for rendering and moving the demon under the rules you provided (through another method). The idea is that the game logic is separate from the lower-level logic that the game is running on top of; and you communicate with the framework via its interface. When people try to code these two parts together...well...it gets messy.
A suitable framework for your game should be developed first or in phases as the game progresses. If you are not sure how to go about it then you can look at some examples. Old-school games like Quake have their source code available. Use of frameworks apply to web design as well, so if you understand web development check out the source code for frameworks like Wordpress or Magento. If you want to save yourself the time of writing your own framework, and you want to jump right into game development, then a quick search of Google for "game development frameworks" will give you more than plenty to chew on.
Back from hiatus
A good amount of time has passed; life happens...you know. Even so, I could have kept up on this blog. There is nothing new gaming wise. There are a lot of days where I am irked by the fact that I haven't release anything...not even a simple game...since 2007. What's the big deal? Why is it so hard to finish something today? Blah blah blah, whatever.
Anyway, I'm back and am going to give this blog another shot. Weekly postings about...I don't know...stuff. Good strategies for game development may be the focus for a while. I'm not writing another line of code until I have my next game on paper! Seriously, like a solid plan that'll get something done, and soon.
Anyway, I'm back and am going to give this blog another shot. Weekly postings about...I don't know...stuff. Good strategies for game development may be the focus for a while. I'm not writing another line of code until I have my next game on paper! Seriously, like a solid plan that'll get something done, and soon.
Subscribe to:
Posts (Atom)