• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
superman3275

How Do You Plan?

13 posts in this topic

I was thinking. Right now I'm getting into some bigger projects (For me, at least :), and as I said in my other post, I felt that I wasn't structuring my code correct. But right now, I believe I need to have some kind of pre-visualization process. There can't be anymore "Just start programming and go with it" because I have to go between file 1 and file 2 all the time, and eventually it all becomes spaghetti code. So, how do you Plan, or pre-visualize your projects. Do you go through any steps, and if so, what are they? Are there certain things you include in the process because, from experience, they help? Please share how you manage to keep the "Big Picture", as I've heard it said ;)
0

Share this post


Link to post
Share on other sites
Assume I want to create a game for example 'MotherLoad': [url="http://www.miniclip.com/games/motherload/en/"]http://www.miniclip..../motherload/en/[/url]

[b]I write down everything I need[/b]. In this case:
- Tileable sprites for the dirt, copper, tin, etc
- sprite of a vehicle
- Bitmaps for buildings
- Bitmaps for menu's when your vehicle comes closes to a building
- Sounds
- Day/Night -> Bitmap of a sun that moves in a circle.

Ok I got kinda the basics. [b]After this I draw on a piece of paper what classes I'll need and link them[/b].
[CODE]
class main; // entry point of the application
class Window; class System; class Graphics; // will be created in the main.cpp
class Bitmap; class Sound; class Text; // stores handles to the images, fonts, etc
class Vehicle; // this will store an object of Bitmap for your vehicle.
class GameState; // will keep a state ( static int m_GameState = STATE_IN_GAME; // or STATE_MENU_MODE; such things.
class Game; // this will create all game objects, sounds, etc. Also checks collisions.
class Level; // contains information how the level looks like
class LevelProp; // props like dirt, copper, etc. Can be a virtual class and support sub-classes.
[/CODE]
[b]Linking I do with drawing arrows from class to class.[/b]

Still don't have any code.
Now I think [b]"What possible methods can the classes contain?"[/b]
I give 1 example:
[CODE]
class Bitmap
{
public:
Bitmap(string path); // Loads an image from a file
~Bitmap();

Bitmap* GetBitmap();

void SetAnimationRect(RECT bounds);
RECT GetAnimationRect();

void StartAnimation(int from = 0);
void StopAnimation();
void PauseAnimation();
void SetAnimationSpeed(int speed);
void IncreaseAnimationSpeed(int speedDelta);
void DecreaseAnimationSpeed(int speedDelta);

void Render(int posX, int posY); // The position can also be stored and called with a method: SetPosition(int posX, posY);

private:
HBITMAP m_hBitmap;
RECT m_Bounds;
int m_AnimationCounter, m_AnimationSpeed;
};
[/CODE]

Of course this class sucks. [img]http://public.gamedev.net//public/style_emoticons/default/laugh.png[/img] It was just an example so don't copy that one. [img]http://public.gamedev.net//public/style_emoticons/default/wink.png[/img]

And in case you are wondering, why not painting(Photoshop) and typing instead of drawing(on paper) and writing?
Answer: You only need to have a basic idea for your whole game. So don't waste time with with PS or Notebook.. Drawing & Writing goes allot faster.


~EngineProgrammer
1

Share this post


Link to post
Share on other sites
Software design a tricky process, mostly guided by experience (primarily meaning "avoid ways in which you have screwed up previous designs").

The first thing I try to do is identify what the core of the project is, and thinking about how to attack that. I try to put together a prototype of that part pretty quickly (so in some sense I start programming early on, but in a very focused way). For this first prototype, all non-core parts of the program are either dummy versions or missing completely. This exercise often will result in a much better idea on how to implement the core part of the project, without wasting too much effort in the wrong direction. The rest of the parts will often just fall into place.




If you have a particular project in mind, perhaps we can give you some pointers on how to divide it up in chunks, where we would start, etc. Edited by alvaro
2

Share this post


Link to post
Share on other sites
I get the idea I want in my head. This very often (for anything more than a day's work) requires not being at a computer, stuck doing some mundane task. Driving, shaving, waiting for the dogs to do their business, falling asleep... whatever. A whiteboard sometimes helps, but isn't required. A peer to bounce ideas off of can help and quicken the process, but isn't good right away (and isn't necessary).

It's hard to describe. I get a mental model of the solution and run through scenarios in my head, changing the model where things fail. As different pieces pass more of the scenarios, they become firmer. Once there's a pretty solid mental model, then I can go to a computer and start coding; fleshing out the details and possibly stopping if I run into an unforeseen roadblock. Often times I will segment the problem into the one I want to tackle now and work on that small chunk of work.

As I've gotten more experience (read: made a lot of bad designs) I've realized how much [i]not being at the computer[/i] aids this. I've changed the model to use more pre-defined shapes (design patterns) than random blobs. The model is quicker to react to common scenarios (design patterns/previous good designs), and identify traits of those scenarios that guide the trait of the solution. And since the shapes are more pre-defined, I can work with much larger models now that I could as a beginner.

I've realized how much design documents and other formal design hinder [b]my [/b]ability to design code, since the audience for the model there is different than 'me, making code'. Once I translate the design into something others can grasp well (and shift into a writing/communicating state of mind), the images pollute my mental model of it and it takes some time to firm it back up.

The process though hasn't really changed in 20 years.
0

Share this post


Link to post
Share on other sites
[u]Superman3275[/u], you can see 3 different ways now to get started. This means everyone has [b]his [/b]special way of programming, and you need to find your way. Seek out what's the best for you. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
Downloading open source games / engines, exploring them has been a great help for me. So I suggest you to do the same.
Look how other people have done it. How they structure their classes, how they have written their lines of code, etc.
It's very hard to [b]tell [/b]you a structure / design. You need to explore / see it for your own.


[u]Telastyn[/u], I also try to work everything out in my head. But when a week has passed it's hard to remember where I was. [img]http://public.gamedev.net//public/style_emoticons/default/laugh.png[/img] That's why I'm writing/drawing it all. So if I look at my paper a year later I can still remember what I've done. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]


[u]Alvaro[/u], I used to work the same way as yours. But I disappreciate it.. Coding immediately caused me allot of messy code, which made me create new projects over and over again. And after that I got 10 files with sort of the same code and I need to look in all of them first to know what I was doing. My first year of programming I made Dragonball Z: supersonic warriors. I've count the number of versions I have: 17. With only 1 working completely. But the examination went pretty good with that file [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]. After the examination in school I asked the lecturer how he started when he had a game in mind. He said: [i]"I can't tell you that. Every programmer has his own way of thinking so I cannot tell you how to program like me. But I can give you a hint: Storage your information so you can return at it any time."[/i]. And so I came with a piece of paper and a pencil. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]


~EngineProgrammer
0

Share this post


Link to post
Share on other sites
EngineProgrammer: I don't think of my approach as "coding immediately". I first think of a rough division of the problem into parts (this is often not easy, and it takes time), I think of what the interfaces between these parts are going to look like. Then I identify the hardest part(s) and try to code a prototype focusing there. This is very different from the experience you describe with your Dragonball Z project. Of course, I've been programming for 30 years, so I have a much better chance at making a successful prototype on the first or second attempt than anyone in their first year of programming.
1

Share this post


Link to post
Share on other sites
Thank you for the fast response Alvaro. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
You are programming for 30 years now, that's nice! I have 2 years of experience now hehe.

It would be awesome if you could help me out. You have more experience and you could help me allot now.
I know I'm not the OP but, I want to rewrite this game for another school project: [url="http://www.rocksolidarcade.com/games/robokill/"]http://www.rocksolid...games/robokill/[/url]
How would you handle it? Please play the first level and explore how you would create a game like that. I owe you one. [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

( [i]moderators this is not offtopic. I'm asking a plan to Alvaro.[/i] [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] )


~EngineProgrammer
0

Share this post


Link to post
Share on other sites
Two things really help me,

First: get several white boards and lots of different colored markers start drawing your system structure.

Second: UML diagrams, there are some really nice open source UML designers out there. Use them.

Also, when I code, I start by writing the basic classes that passed around as data like a Vector, Matrix, String, Actor, Node, ect... after I get those done then I cleared out most of the small details and can focus on the larger "Manager" kind of classes, which use these data classes that are mostly done.
0

Share this post


Link to post
Share on other sites
That looks like a very polished game, and it probably took the authors some serious effort to put together. Notice that this is not only a programming project. You'll need graphics, music, sound effects, level design...

I've never made a flash game before, so the first things I would do are getting familiar with the programming environment and testing that I can correctly process input, animate a character, play music, play sound effects... If any of these things is trickier than it seems, better to find out early.

For a prototype, I would focus on getting the gameplay working, even if I don't have a way to load a map, sound of fancy graphics. Programmer art works to begin with.

I haven't given it nearly enough thought, but one possible division of this in blocks would be:
* Description of the scene (as a data structure in memory).
* Scene update
* AI
* Rendering
* Input
* Sound

So you need to write a game loop and work primarily on my first two bullet points (how you describe the scene in memory and how it gets updated). Of course you'll need to render it and you'll need to process input, but input is probably simple and rendering can be kept crude (think triangles instead of robots) for the first stages.

Just make sure you keep things flexible enough that it won't be impossible to add cutscenes and menus in the future. I imagine in this case it would be easier to not use the game loop at all for those things, and simply implement cutscenes and menus separately, with the game loop only running for the game proper.

I don't know if this level of detail helps you at all or not. The next thing is getting dirty and trying to describe the scene in a data structure. A whiteboard and colored markers can be very helpful. Edited by alvaro
0

Share this post


Link to post
Share on other sites
I ask myself questions:

What are my primary goals?
What kind of system would best serve those goals?

Then I write the simplest possible version of that system, and build from there.

It's simple, but it works for me.
0

Share this post


Link to post
Share on other sites
The problem with planning ahead is that only experience can give enough information to plan a software design properly. So, in a domain where you have good experience (i.e. many completed programs), you might plan ahead and be mostly right.

Myself, I find that minimal planning and then [url="http://en.wikipedia.org/wiki/Code_refactoring"]refactoring[/url] as I progress gives me the best results. Refactoring is especially valuable in retrospective to crystallize the real meaning of your code; in contrast to the mess that code can be when you just got it running for the first time. ;) Edited by demonkoryu
1

Share this post


Link to post
Share on other sites
[quote name='demonkoryu' timestamp='1349353123' post='4986738']
The problem with planning ahead is that only experience can give enough information to plan a software design properly. So, in a domain where you have good experience (i.e. many completed programs), you might plan ahead and be mostly right.
[/quote]
Agree. When I'm not familiar with what I'm implementing, I tend to plan a bit too much and end up repeatedly going "wait, I need this too" and "hang on, this isn't actually what I want" or "oops, I overlooked such and such dependency and now need to redesign everything", which wastes a lot of time.

In my experience, you want to start small (don't start making plans for every little feature you add, or you'll get overwhelmed and will just give up). Plan the core, then add the rest later on when everything works. Make heavy use of stubs if that's your thing. Always try and keep your code as modular and self-contained as possible, so that adding another feature does not interact (and hence, cannot break) other features on the same level of abstraction. Most of your code should be reusable, ideally you should be able to plug in and out features, if that makes sense for your project.

For instance, your game might end up looking like a tree graph, with each node being either a "feature" (for leaves) or a "manager" (for nodes). The tree is strictly going down, so leaves do not interact with anything except utility functions, and nodes only interact with the leaves they use (like the graphics loading manager might use the PNG loader feature to be PNG-enabled or something - dumb example though). This is all very simplified of course, in the real world relationships are much more complicated... Edited by Bacterius
0

Share this post


Link to post
Share on other sites
[quote name='EngineProgrammer' timestamp='1349318468' post='4986636']
But when a week has passed it's hard to remember where I was.
[/quote]

If a class-level plan takes more than a week to do then your problem is too big. Break it down more and work on one piece at a time.
0

Share this post


Link to post
Share on other sites
I start with an idea that I like. I hack together what is basically a starting point, and then this process is triggered in my brain. I read it over and over and over. I tinker with it; I adjust it here and there. Out of that, I can simplify the code and cut away the chaff. I can refactor it. The writer in me can take the helm, and he doesn't like ugly hacks or special cases very much. I rewrite some parts. I combine some things, and remove others. What is left, then, can be more thoroughly documented and expanded to actually do what I want.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0