Many a beginner on gamedev.net (including me) has trouble with their software in the beginning. I had no idea how to plan for projects or what was even included in projects. I would look for posts about how to plan out projects. Generally when these questions get ask the seasoned developers on here (Also known as people who have worked on many finished projects) answer with responses like:
[quote]
I have a really iterative design[/quote][quote]
I don't really pre-visualize, I try to sort out more details at implementation[/quote]
Now, that's not to say these developers are in the wrong at all. For a beginner however, these terms can be very daunting and confusing. For me, I thought I shouldn't really pre-visualize at all and that everything would sort itself out eventually (Boy how wrong was I
). In this article I plan to explain to you how I pre-visualize my projects, how much you should really be pre-visualizing, and why it's important. So let's jump right in with the third one: Why Pre-Visualizing Important?Pre-Visualizing allows you to plan how your classes interact. Imagine this: In many projects, your Collision and Physics interact, and almost all of your classes have to access a singular Map for the level you're on. How they will interact and how the map will be handled must be thought out so that the code you write at the beginning will be prepared for how the other classes use the Map. This must be sorted out in pre-visualization because you write certain code (classes) at different times, which means if you don't think about this you'll end up re-writing enormous amounts of code.
Pre-Visualization also defines project scope. Knowing what you plan to accomplish and what accomplishing that includes helps with development (For one thing, you will be able to gauge your progress and define what needs to be done next). When making a Side-Scroller, understanding the scope of the enemies A.I. is important so you'll know the work involved. If you make simple A.I., you can compensate with adding bows to a Side-Scroller that was originally only going to have swords. Now that I've made that analogy however, let us move on to another important topic involving why pre-visualizing is important: Understanding the Mechanics of your game.
This ties into project scope. The mechanics are part of project scope because the more complex the mechanics the more time it will take to implement them. Imagine this: Having a Bow involves a lot more coding (Handling projectiles shot, their collision, how fast they move, animation for them, etc.). So at project scope, you define if you'll have a bow or if you'll only have swords. This lets you only plan for swords. The first part of planning should always be defining your scope.
Now on to the second part: How much you should be pre-visualizing. My general rule is figuring out your hierarchy and how your classes will interact, however I leave out the actual coding details. I know how to code, and a large part of my actual software-design is figuring out how to solve problems or thinking about the best way to solve a problem. Figuring out what those problems are and how you'll solve them is pre-visualization. Actually planning out my code, what my functions will pass in, etc. shouldn't be defined in pre-visualization (Except for small, single-task programs like converting one form of a linear equation to another form.). Solving these problems before you start coding make sure that all the code you right already had that problem in mind (So when a problem turns up or when you are implementing something, you don't have to scrap existing code).
Some problems are bound to be encountered while coding, and trying to write down and fix every minute detail of your program is an example of bad pre-visualization. You can't anticipate everything, however anticipating what you can (AKA the bigger problems and ideas) will help exponentially.
Now, what you've all been waiting for: How do I pre-visualize? It's simple really. I get a notebook, write down the name of my project. I define the scope, the mechanics, and then take one or two pages in the notebook I label "Classes". I figure out the basic classes and write down their responsibility (Defining responsibility make sure you understand what all of your classes are actually supposed to be doing). Then, I take maybe a page for each class or important mechanic and think about it hard. I think about how it'll handle it's responsibilities and how it will interact with other classes. The key word here is interaction. Interaction is a huge part of software design (Especially video game software design.). This allows me to anticipate the basic structure of my code and the problems I'll run into. Then for a day or two I'll read over what I have and reflect. After I do this, I take my journal to the computer and start coding. This whole process is one to two weeks.
The main point of this article was to stress how important pre-visualization is to beginners. Now, it might just be tic-tac-toe, however still get in the habit of pre-visualizing. It'll pay off in the long run.
If you enjoyed this article, please post down below. If you have any recommendation about how you plan or any corrections, feel free to share them with everyone. Cheers
!
Once you have your framework of understanding, you're always adapting it and changing it as new situations come up. Hence the iteration. Last time, this thing you did worked out pretty well, while this other thing turned into a pig's breakfast and had to be scrapped. So the next time, you'll go with A and relegate B to the trash heap. Every so often, you'll read an article or a book that will completely redefine how you think about things, and you get to start the whole process over from scratch. But at least this time, you have more experience and the whole "getting comfortable with your framework" stage takes less time than it did before. Plus, you have the weight of experience to temper your new framework. "B didn't work very well in the last project, but I think it will work a whole lot better in this new way."
At the higher experience levels, your pre-visualization becomes less about "How do I structure it so that you can have a Sword, or a Bow, or whatever" and more about "How can I make gameplay using a Sword and gameplay using a Bow be tight, visceral, and as enjoyable as possible". Because you have your framework already in place, you see; and since the pre-visualization questions you must answer are less fundamental, so too are the iterations of your project. Rather than iterating on the basic object structure, you iterate on higher-level tweaks to that structure.
I think that as you become more and more experienced, it becomes harder and harder to express the fundamentals of your framework and process to somebody else without spending hours writing it out. So much of what you do on any given project or to solve any given problem builds on your years of experience, so how do you boil that down to a few sentences without simplifying to the point that, as you indicate happens, you mislead others about the process? Because the pre-visualization I do, after two decades of doing this, is going to be much different than the pre-visualization you do, who are just starting out, without the benefit of the years of experience that came before.
For myself, I went through a framework shift a couple years ago, when component/entity systems became "the hotness". I'd always understood on an academic level the idea of object composition, but I hadn't thought deeply about the principle, or tried to apply it to my own work. So I worked for years building a confusing framework of ever-more-complex object hierarchies, growing comfortable with the complexity but never really at ease. Until that "ah ha!" moment, when I really sat down to think about object composition, entity systems, and exactly how brittle and ultimately unsustainable large, complex inheritance hierarchies can be. Boom. Framework shift.
However, usually when I sit down to start a project, I don't think too much about structure beyond the "how can I improve things just a little bit over what I did last time?" stage. I've got a solid understanding of my framework as it stands, so I have a good grasp on how things are going to be structured. I am aware that my framework is very much less than perfect, though, so I am constantly combing the forums and the internet in general, looking for ideas I can incorporate into my understanding. Nevertheless, I build on the groundwork I already laid.
I start a new project, and right off the bat I already have a pretty good chunk of it written. As the months and years have passed, I've written and re-written a large number of portions of it, modified things, tweaked things, possibly made some things worse than before (it happens). But since I have iterated so much on it, I have solidified many large portions of it. I have an object composition framework, I am accustomed to thinking about objects in terms of what components comprise them, and how I can break their behavior and components down into discrete, manageable chunks. At this stage, the iteration is all about trying different composition break-downs, playing with how the pieces fit together. In the beginning, I did a lot of up-front design work with paper, but as my framework and understanding have matured, I do much, much less work on paper, and spend much more time rapidly prototyping out things in actual code to see how they work in actual operation. (It does help that most of my lower-level systems are already finished, and most of my iterating and prototyping can be done in Lua. So much faster to work in a language like Lua for quick prototype work.)
Building a game is much like building an elaborate house of cards. It's a juggling game of increasing complexity, and the further in you get the more things can come crashing down around your ears. If you don't have a strong foundation (framework) you will find that the house can't support itself as the weight grows and you have to knock it down and start over. You can read about how to build a house of cards all you want, but the only way you gain the strong, steady hands required to do the task is to build many, many houses, most of which will probably crumble before you finish, some soon and others late.