• 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
XNobodyX

Properly planning a game and its structure

20 posts in this topic

Preamble:

I have attempted to make 2 little indie games and each of them have failed for one reason, planning. For both of the projects I started off only planning to have a few parts to the game. As I started to code those parts I would realized  that each of these parts needed a lot more code and classes and such than I originally thought. The problem is I would have already coded the majority of the game before I realized this. Thus leaving me with two options, 1) Rewriting the whole game, and throwing out countless hours of time. 2) Giving up sad.png . After thinking about where I went wrong it would always come down to the fact that when I started writing the game I didn't fully understand what I needed and thus didn't design it properly. I figure that this might happen a lot in many games(Realizing that a major change needs to be done) and I imagine that they don't all restart or quit. Which leads me to the conclusion that my planning might not be sufficient but the main structure of my code might be the problem. When I looked over my first game I found that a lot of my code was very specific and could not be easily rewritten without affecting other parts.

 

The question:

1) How do you go about properly planning a game and allowing major changes to be made without a re-write?

2)To avoid problems with having to rewrite everything should I try and write everything as a module that can be used in a main game loop?

 

If anyone has any good ways of organizing a game that you could point me to that would be awesome(Currently I am using the Model, View, Screen system)

0

Share this post


Link to post
Share on other sites

This is a problem I am kind of facing as well =/. I've had to resign to starting over due to not knowing an efficient way to continue my code and seeing that I was headed towards coding myself into a corner.

 

Any insight on dealing with this or avoiding this in the future would be greatly appreciated.

1

Share this post


Link to post
Share on other sites


1) How do you go about properly planning a game and allowing major changes to be made without a re-write?

Paper and pencil is really the way to go.  Sketching things out is a great way to work out ideas. Use of formal tools, like UML, is entirely optional -- if you think that they help, go for it!

 


2)To avoid problems with having to rewrite everything should I try and write everything as a module that can be used in a main game loop?

Do it, if it makes sense. But avoid over-generalization -- YAGNE!

 

 

Happy hacking!

0

Share this post


Link to post
Share on other sites
Code wise, not sure. As for gameplay, keep wrting each idea on a book (books for me), when you've reached a point where you think it's alright, read through the whole thing and make sure it flows naturally, removing and adding ideas till you feel it's good. It could help you guess what the code will be like.
0

Share this post


Link to post
Share on other sites

L. Spiro has pretty much nailed it in the head. I would like to add a slight bit of advice though that I've read a long time ago and I can't remember where it's from: Always try to refactor your code before throwing it away. I find this is a better approach when it comes to learning because by fixing the code that you know is broken, it forces you to think about why it's broken and what the correct solution is. When you just start over and toss the other code aside, you're just making another shot in the dark. That's really just the way your memory works too. If you don't think about something extensively, you decrease your chances of remembering it.

 

Initially, this process will take a mighty long time, but the more you do it, the better code you'll write in the first place. As an example, I program my UI's by hand, and, at first, the UI code alone would give me so much trouble that I would rather do just about anything else than have to modify it, but once I started refactoring it, I find much better techniques for separating all the parts of it. Now I actually got myself a little library that handles building intricate menus :D 

2

Share this post


Link to post
Share on other sites


You are basically asking, “How do I learn from experience without going through the ‘experience‘ part?”.

 

I wouldn't exactly say that. I understand how valuable experience is and learning from my mistakes. Getting experience helped me learn another fieldset(Web dev. php, js, ruby, ect). Like writing an essay, there are certain structures that are generally accepted as at least a good outline on how to do it,

0

Share this post


Link to post
Share on other sites

 

Preamble:

I have attempted to make 2 little indie games and each of them have failed for one reason, planning. For both of the projects I started off only planning to have a few parts to the game. As I started to code those parts I would realized  that each of these parts needed a lot more code and classes and such than I originally thought. The problem is I would have already coded the majority of the game before I realized this. Thus leaving me with two options, 1) Rewriting the whole game, and throwing out countless hours of time. 2) Giving up sad.png . After thinking about where I went wrong it would always come down to the fact that when I started writing the game I didn't fully understand what I needed and thus didn't design it properly. I figure that this might happen a lot in many games(Realizing that a major change needs to be done) and I imagine that they don't all restart or quit. Which leads me to the conclusion that my planning might not be sufficient but the main structure of my code might be the problem. When I looked over my first game I found that a lot of my code was very specific and could not be easily rewritten without affecting other parts.

 

The question:

1) How do you go about properly planning a game and allowing major changes to be made without a re-write?

2)To avoid problems with having to rewrite everything should I try and write everything as a module that can be used in a main game loop?

 

If anyone has any good ways of organizing a game that you could point me to that would be awesome(Currently I am using the Model, View, Screen system)

Start using a source code revision tool as it allows you to code a lot more fearlessly of  losing old work, make sure you checking in often. If something doesn't pan out just revert to the last working version and start afresh, if something pans out to work check it in so you have a backup.

I am pushing to a private git repo every night after I finish. Is this sufficient for version control?

0

Share this post


Link to post
Share on other sites


I am pushing to a private git repo every night after I finish. Is this sufficient for version control?

You really want to be making commits of each feature and/or refactor, so that you can step through the history change-by-change to analyse when bugs were introduced.

0

Share this post


Link to post
Share on other sites

You really want to be making commits of each feature and/or refactor, so that you can step through the history change-by-change to analyse when bugs were introduced.

 

Thats what I meant(I guess I was a little unclear) I commit nightly. Usually I am able to knock out at least one small feature a day(2-3 hours of work) so nighly committing is usually sufficient.

Edited by XNobodyX
0

Share this post


Link to post
Share on other sites

One thing i did when rewriting one of my application is to write a coupe of interfaces before actually starting coding it. I dunno exactly why but this helped tremendously.

 

Here's an example of one of them:

class IRemotePC {
public:
        virtual void Reset() = 0;
        virtual void ProcessRemotePCMessages(MsgHeaderStruct *pMsgHeader, BYTE *pMsgData){}
        
        virtual bool InitOpenGL(){return false;}
        virtual void ShutdownOpenGL(){}
        virtual void RenderTexture(){}
        virtual void ClearScreen(){}

        virtual void WaitForScreenShotThreadToFinish(){}
};

class IRemotePCServer : public IRemotePC {
public:
        virtual void SetLoginInfo(char *pUserName, char *pPassword) = 0;
        virtual void OnLoginRequest(LoginInfoStruct *pInfo) = 0;
        virtual void SendLoginResult(LoginResults Results) = 0;
        
        virtual void OnScreenshotRequest(ScrFormat *pFormat) = 0;
        virtual void SendScreenshot(CRawBuffer *pBuffer) = 0;

        virtual void OnMouseMsg(CMouseInputMsgStruct* pMsg) = 0;
        virtual void OnKeyboardMsg(CKeyboardInputMsgStruct* pMsg) = 0;
};

class IRemotePCClient : public IRemotePC {
public:
        virtual void SendLoginRequest(char *pUserName, char *pPassword) = 0;
        virtual void OnLoginResult(LoginResultStruct* pLoginResult) = 0;
        
        virtual void SendScreenshotRequest() = 0;
        virtual void OnScreenshotMsg(MsgHeaderStruct *pMsgHeader, BYTE *pMsgData) = 0;

        virtual void SendMouseMsg(CMouseInputMsgStruct *mm) = 0;
        virtual void SendKeyboardMsg(CKeyboardInputMsgStruct *km) = 0;
};

At first the functions arguments where empty, then got filled as i was adding more code. This helped me a lot to know where i was going.

1

Share this post


Link to post
Share on other sites

Hi,

 

Properly planning a game takes time to learn on your own. It can be one of those things that a programmer has to  experience to understand. Unless you have worked for a large company who would obviously have a structure in place on how a game is designed. For an Indie developer this can seem complicated once your game code starts to get over a few hundred lines of code. What I've learned from my game design attempts is that you have to try to separate each part of the game into sections. Try to keep different areas of your game code organized so that if you need to update one area you can do it easily. It's kind of like writing a book. You have to learn how to put it together so that it's organized and well written. Other programmers always say to make sure to put lots of notes in your code so that if someone else needs to update it later they can easily get an understanding how your game code works. This can also help yourself when you need to come back and make changes.

 

 

 

 

 

0

Share this post


Link to post
Share on other sites

"seeing that I was headed towards coding myself into a corner."

 

How do you think you were coding into a corner?

0

Share this post


Link to post
Share on other sites

lol, keep doing what your doing, in ten years, you'll be where I'm at. Hopefully a hell of a lot better though.

 

You'll find out eventually if you code because you love it or if your chasing a rabbit.

 

I got on a pathfinding kick once that lasted for 6 months. Tons of unusable code, unreadable notes. In the end I did produce something that I still implement in any game I make using path finding though, regardless of which language I use.

 

The moral of my little verbal toilet spackle? The majority of the stuff I have made in the past 10 years is useless, but when I look at the steps and problems I overcame getting past each point, each one is an invaluable lesson!

 

Keep going or get into paper mache' little doggies with 1 jelly bean inside. (<---- my backup plan)

0

Share this post


Link to post
Share on other sites

The things that has worked for me are twofold. Firstly, I make sure to write my code in a way that is modular and easy to change and refactor. By this I mean that, well, code is always changing. You'll have to rewrite classes, separate classes into multiple classes and interfaces, refactor code, etc. In the end, you need to get used to the code changing. When you get to that point, you're in business -- having to rewrite the interface of a class or refactor a single giant class into many modular pieces becomes easy (especially with copy and paste!). If the project actually is useless, take it as a learning experience. I tend to program in units, so I write crap code while I work out my idea, and then copy/paste/rewrite my production code in the actual engine. Keep the code for nostalgia/as notes, but you can move on from those little tests and know you learned a lot from it!

 

Secondly, I've also noticed that I can work a problem a few ways -- this is what works for me. I tend to start at the outermost layer and figure out the interface I want for the class. From there I'll then begin unit testing each method I write for the class, but making sure I meet the interface I want for the class so it all looks nice to the user/works to my software design/engineering needs. Again, things change, and I refactor code all the time, but with a little planning on the interactions and outside interface of the class, it works out nicely.

 

Modularity also helps, as well as experience over time. I've written the same engine in a couple different languages, multiple times in each language. Each time I get more tired of writing the same code, so I got used to changing classes and isolating dependencies and BAM, I got a nice way of furthering the engine of the game without having to keep starting over or scrapping my code. As people have said above, pencil/pen and paper always solves your problems. UML has helped me a bit laying out interactions between classes. Try different things, and with time you'll be well and better off :)

0

Share this post


Link to post
Share on other sites
You should use modular programming, that is the technical term, there are a couple of tutorials on it on YouTube. Also, write pseudocode.

I made something I call a customizable game script. It's a template for making a game that has all the essential parts of a game ready to go. I also made it flexible (all my functions use arguments that can be changes outside of the functions. I also name my variables and functions with non-specific names (can be changed to specific names per game.)
Here is one of them:

http://youtu.be/ZdhibG2QoCg
1

Share this post


Link to post
Share on other sites

"seeing that I was headed towards coding myself into a corner."

 

How do you think you were coding into a corner?

 It was because I felt overwhelmed by the code I was writing and it was indeed a big digital bowl of spaghetti code. Although I did have certain parts of the code in separate classes, there still wasn't much modularity. So when a bug pops up I spend all day swimming through the code in order to find it. It only became tougher the more code I wrote. I'll need to do a bit more modularity moving forward. But the previous comments are all very helpful. Coding does feel somewhat of an iterative learning process. It helps to know that I'm not just missing some big picture. Thank you all for the helpful input.

0

Share this post


Link to post
Share on other sites

"Practice" is definitely solid advice. As you do it more and more, you'll start realizing flaws in your design earlier and earlier. You might start out with some simpler games like pong or a tetris clone.

 

If the code is too hard to manage, spend some time thinking about why that is. If you had it to do over again, what would you do differently? Do you think you could salvage that with some refactoring or is it too far gone?

 

Spend some time reading about software design techniques or good programming principles. Yeah it's boring, but they have some solid ideas.

 

Spend some time thinking about the proper name of a variable/class/function before you start using it. 

 

And I recently replied to a thread that meandered through how I go about refining a design. You might find it useful?

http://www.gamedev.net/topic/652095-help-on-how-to-implement-stories-and-quests-on-an-rpg/#entry5122714

 

Anyway, I don't think there's some big picture you're missing. Keep at it.

 

- Eck

 

2

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