Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Like
9Likes
Dislike

Pre-Visualization Is Important!

By superman3275 | Published Oct 28 2014 09:43 PM in General Programming
Peer Reviewed by (Gaiiden, incertia, jbadams)

program organization design visualization planning beginner

Hello everyone. This post should be pretty long (and heavy). I feel that this mistake is being caused largely by the more seasoned developers on here using the wrong words to describe how to pre-visualize. This led to me making a large amount of mistakes in software development and has made me scrap so much code. So, without further ado, I present to you: The Importance Of Pre-Visualization

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:

I have a really iterative design


I don't really pre-visualize, I try to sort out more details at implementation


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 :)!



License


GDOL (Gamedev.net Open License)




Comments

Thank you for this, I have also seen responses like you mentioned, seasoned professionals saying that they figure it all out in their head as they go along. This is the approach I have been taking and for me 50% of the time it results in spaghetti code and I get really confused and frustrated about the overall design.

My own students jump headfirst right into code because they want to get done.  Skipping the design process (no matter which program design paradigm you use) can be a recipe for disaster on all levels.. for beginners because you don't yet know what you are doing, and for larger projects because eventually you will end up having to do a major refactor just to get your codebase to not suck.

You began by bashing the gamedev community.... not even going to go further. Gotta love a teacher that says, everyone (people who arent me) suck so do what I tell you to cause I'm the $!!!

"I feel that this mistake is being caused largely by the more seasoned developers on here (Also known as, not me)"

 

You may want to reformulate this just for clarity, when I read it the first time it came off as "seasoned developers spread these mistakes - but not me" which I guess is the exact opposite of what you wanted to express.

I would like to see more work on this article. I am not a native English speaker, so excuse me if I am wrong, but for me some sentences do not sound right.

 

A bit of nitpicking:

- I suggest avoiding explanations in parentheses whenever possible. You don't need to add "." at the end if the sentence in parentheses. I think it is not even a separate sentence, so you don't need to start with capital letter either.

- More separation between paragraphs to emphasize the problem, solution, conclusion would be nice.

- You are changing conversation style a lot. Sometimes it is neutral "this article", sometimes it is reader "you", sometimes "you all", and then back to writer "I do this...".

 

And the way it "should be done" is the way "you do it". I suggest to keep explanation and the story of your learning process separate.

"I feel that this mistake is being caused largely by the more seasoned developers on here (Also known as, not me)"

 

You may want to reformulate this just for clarity, when I read it the first time it came off as "seasoned developers spread these mistakes - but not me" which I guess is the exact opposite of what you wanted to express.

 

Agreed.  I think it's okay to have some humility when discussing your level even if you are a beginner.   The author just needs to find better ways of saying it.

I meant to say that I'm not a senior developer :). Guess it had the opposite effect.

You got a point with that article, but while reading I was for a large part wondering when the justifying ends and the content starts on showing how people could do it.

I would like to see more work on this article. I am not a native English speaker, so excuse me if I am wrong, but for me some sentences do not sound right.

 

A bit of nitpicking:

- I suggest avoiding explanations in parentheses whenever possible. You don't need to add "." at the end if the sentence in parentheses. I think it is not even a separate sentence, so you don't need to start with capital letter either.

- More separation between paragraphs to emphasize the problem, solution, conclusion would be nice.

- You are changing conversation style a lot. Sometimes it is neutral "this article", sometimes it is reader "you", sometimes "you all", and then back to writer "I do this...".

 

And the way it "should be done" is the way "you do it". I suggest to keep explanation and the story of your learning process separate.

I agree.

 

You've got some useful information in the article, but it takes a lot of work on the part of the reader to find it.

Just to be clear, since I can interpret this article a couple ways: are you using "class" to mean literal, individual C++/Java class definitions, or are you meaning it in the context of broader modules or systems? I hope it's the latter.

I usually "jump in" and do it, which results in me needing to rewrite the code two or three times to make it work.

 

The reason why I don't pre-plan it is because of two problems.

 

The first is: How are you supposed to pre-plan it? What does that look like? What tools are available? What is the proper way to leverage those tools? I think this article needs to go more into this.

 

And the second is that my designs aren't pre-thought out (another big issue), so the lack of a solid design document means I can't really pre-plan my architecture, because the features are changing as the design is changing (this topic is beyond the scope of this article).

The "pre-visualization" phase of a project is usually called the "design" phase within a software development life cycle. It comes before coding and after requirements definition. You should never start coding without having planned what you're going to code and how its all going to work together. I used to just jump right in and say, "eh, I'll figure it out as I get there." It doesn't work very well for long, and I learned that through my attempt at creating a chess game a decade ago. I spent a lot of time and effort building a chess board and putting the chess pieces on there and getting them to move legally. It was tough and took a month. Then, the next step was to build in an artificial intelligence which would play against me. I had an inkling of an idea on how that should work using min-max trees, but then I had realized that the sloppy code architecture I wrote would just not support that. So, I gave up and scrapped the project. I vowed to plan a little bit more for my next project so I wouldn't run into the same problem.

How do you go about planning your software design properly? There are lots of books written on the subject, each with their own ideas which come with strengths and weaknesses. Some people want to do 100% of the design up front before writing code (which is common to the waterfall model). This can work and has worked in the past and still works, but it does have limitations and weaknesses. The biggest strength is that 100% of the software has been planned in the design phase, so you don't have any guess work to do during the construction phase. All problems have been identified and resolved (in a perfect world). It's like constructing a building based off of a blueprint. It's quite straight forward and refreshing to work with. However, in practice your requirements will change or something just can't be anticipated in a design (such as play balance). So, you need a more flexible design methodology.

When it comes to making video games, what seems to work best is a lot of iterative testing. What I do is write up a game design document to be as complete as reasonably possible, with the purpose of the game design document being a way to nail down what exactly I'm trying to build and how everything should work together. This is a detailed description of the game as its envisioned in my head. It forces me to write out every mechanic and describe how it will work with other mechanics. Usually through the process of writing it all out, I can start to see some of the issues which will emerge and resolve them by spending more effort designing a solution. The wrong time to find out that something doesn't work is after you've implemented it and try to get it to work with something else (for example, chess + AI) only to find out that it's not workable in its current state.

I sincerely believe that the amount of development refactoring time is inversely proportionate to the amount of time spent planning and designing (but there's a diminishing value from excessive design). In my current project, I treat my game design document as a sort of "hand waving gesture" vision on all the things I'm trying to build and how they should work together. The document is about 60% accurate, with the remaining 40% being fuzzy things that get worked out through iterative play testing and development. This is good enough to let me know what I'm trying to build and where I'm trying to go with it and gets me to a point where I can iterate and improve something tangible.

Eventually, all of my game systems get too big to store in my head, so I have to start drawing diagrams of how all of my game objects interact and work together (and where it all lives in memory!). I tried maintaining an MS paint class diagram, but found it requires constant updates or else it quickly gets out of date and useless. Instead, I mostly resort to drawing my current problem diagram in MS paint to visualize the problem and how to resolve it. The diagrams I use are 100% whatever I want and have the meaning of whatever I want.

This is fine for a lone programmer who doesn't have to communicate with other programmers on the systems they're building, but if you do have more than one developer on the team, you'll have to come to an agreement on a standard for diagrams so that everyone is communicating in the same way (which is where more formalized data models come in handy).

At the end of the day though, all of the data models and designs are just chaff / overhead costs to act as scaffolding to build what needs to be built -- don't waste a lot of time making them look pretty because it doesn't matter. Its purpose is to help you write more architecturally solid code, which solves the problem you're trying to tackle, whatever that is. If you aren't or haven't been in the habit of carefully planning out what you're going to do, it's good to start sooner rather than later so that you get the experience and figure out what works for you and where you can improve. It's especially good to figure this out on projects which are more forgiving of mistakes (ie, smaller scope projects, hobby projects, school projects)


Note: Please offer only positive, constructive comments - we are looking to promote a positive atmosphere where collaboration is valued above all else.




PARTNERS