Jump to content

  • Log In with Google      Sign In   
  • Create Account


Properly planning a game and its structure


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
20 replies to this topic

#1 XNobodyX   Members   -  Reputation: 132

Like
0Likes
Like

Posted 06 January 2014 - 06:55 PM

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)



Sponsor:

#2 Genocode   Members   -  Reputation: 148

Like
1Likes
Like

Posted 06 January 2014 - 07:17 PM

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.



#3 Mnemotic   Members   -  Reputation: 340

Like
0Likes
Like

Posted 06 January 2014 - 10:13 PM


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!



#4 Nathan2222_old   Members   -  Reputation: -400

Like
0Likes
Like

Posted 06 January 2014 - 11:17 PM

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.

UNREAL ENGINE 4:
Total LOC: ~3M Lines
Total Languages: ~32
smile.png
--
GREAT QUOTES:
I can do ALL things through Christ - Jesus Christ
--
Logic will get you from A-Z, imagination gets you everywhere - Albert Einstein
--
The problems of the world cannot be solved by skeptics or cynics whose horizons are limited by the obvious realities. - John F. Kennedy


#5 L. Spiro   Crossbones+   -  Reputation: 13214

Like
15Likes
Like

Posted 06 January 2014 - 11:36 PM


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

Keep making games, keeping making mistakes, and learn from them.

 

 

 


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 you have a good idea about how to do it.  Getting a good handle on how to properly do that tends to be the product of learning from past mistakes.

 

 

 


If anyone has any good ways of organizing a game that you could point me to that would be awesome

General Game/Engine Structure

 

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

No matter what strategy you use, at the end of the day you will still need to be sitting down programming, and you will still be making mistakes.  Throwing away code, writing tightly coupled code, and wasting hours of coding time is how we all start.  It is a natural part of the learning process.

 

And I wouldn’t advise using any strategy that you yourself did not create specifically for yourself.  When you create your own strategy it is based off what works best for you.

If someone told me to draw it out and I followed that advice, it naturally goes against my grain and would only slow me down.  I have a mental image that has no naturalistic translation to an actual image; an image I see on paper does not translate into anything useful related to code for me, so trying to work that way is like trying to sew a shape into cloth just by looking at numbers representing angles and distances.

 

You can create any strategy you want.  The point is that it won’t naturally flow for you unless it comes from you.

 

 

L. Spiro


Edited by L. Spiro, 07 January 2014 - 08:51 AM.

It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#6 boogyman19946   Members   -  Reputation: 1051

Like
2Likes
Like

Posted 07 January 2014 - 12:56 AM

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 


"If highly skilled generalists are rare, though, then highly skilled innovators are priceless." - ApochPiQ

My personal links :)
- Khan Academy - For all your math needs
- Java API Documentation - For all your Java info needs :D
- C++ Standard Library Reference - For some of your C++ needs ^.^

#7 NightCreature83   Crossbones+   -  Reputation: 2735

Like
3Likes
Like

Posted 07 January 2014 - 03:51 AM

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.


Worked on titles: CMR:DiRT2, DiRT 3, DiRT: Showdown, GRID 2, Mad Max

#8 XNobodyX   Members   -  Reputation: 132

Like
0Likes
Like

Posted 07 January 2014 - 04:59 PM


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,



#9 XNobodyX   Members   -  Reputation: 132

Like
0Likes
Like

Posted 07 January 2014 - 05:02 PM

 

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?



#10 swiftcoder   Senior Moderators   -  Reputation: 9851

Like
0Likes
Like

Posted 07 January 2014 - 05:06 PM


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.


Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#11 XNobodyX   Members   -  Reputation: 132

Like
0Likes
Like

Posted 07 January 2014 - 05:16 PM


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, 07 January 2014 - 05:18 PM.


#12 Vortez   Crossbones+   -  Reputation: 2697

Like
1Likes
Like

Posted 07 January 2014 - 05:49 PM

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.



#13 bigindie   Members   -  Reputation: 100

Like
0Likes
Like

Posted 08 January 2014 - 01:21 AM

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.

 

 

 

 

 



#14 Katie   Members   -  Reputation: 1312

Like
0Likes
Like

Posted 08 January 2014 - 04:28 AM

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

 

How do you think you were coding into a corner?



#15 Dezachu   Members   -  Reputation: 375

Like
4Likes
Like

Posted 08 January 2014 - 08:05 AM

Modularity is the one word that springs to mind.

 

Rather than writing a load of spaghetti code and then throwing it all away, take something away from each project. A prime example - I started writing a clicker-style game the other week but I've had to scrap it now I've started work again (alongside studying for my final year it just wasn't really viable). That didn't mean the hours spent working on it have amounted to nothing - I took away a static Utilities class that did simple calculations (kind of a math library I guess), a FontManager class, a LayoutManager class (for calculating the required scaling of text/an image to fit in a certain area) and also a ButtonObject class that eventually grew to be quite large. No doubt I can use these elsewhere because they're MODULAR - any game that uses fonts can use the font manager. Any game that uses button sprites can use the ButtonObject class and any game I write (at least in 2D) can use the LayoutManager to be easily portable to multiple screen resolutions. Same for the Utilities class I guess! From my next project when I get some free time I'll probably add some extras like a resource manager, an audio manager etc..

 

As others have said, there's no shame in failing again and again, it's all practice and learning. Instead of beating yourself up over failing, why not look at what you took away from/learnt in the project? In reverse, why not start a project with the intention of learning? Anything that comes out of it can be seen as a bonus ;)

 

 

So the questions:

1) Modularity.
2) Hmm probably not. Your standard loop is, as you appear to know, GetInput, Process, Render (maybe you use diff. words, it doesn't matter). These steps will be different for every program, although what they do is generally the same (as their name suggests). You're touching on game engines by suggesting modularity of these components which is a whole 'nother ball park. 

 

 

Hope this helps :)


Studying BSc Computer Games Programming @ De Montfort University, Leicester.

Completed a placement as a Junior Programmer at Exient Ltd in Oxford/Valletta, Malta


#16 YellzBellzDotCome   Members   -  Reputation: 152

Like
0Likes
Like

Posted 08 January 2014 - 08:09 PM

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)



#17 studentTeacher   Members   -  Reputation: 820

Like
0Likes
Like

Posted 09 January 2014 - 11:19 AM

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



#18 Tutorial Doctor   Members   -  Reputation: 1555

Like
1Likes
Like

Posted 09 January 2014 - 04:58 PM

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:


They call me the Tutorial Doctor.


#19 JustColorado   Members   -  Reputation: 149

Like
0Likes
Like

Posted 10 January 2014 - 12:26 PM

Reading the Book "Clean Code" helped me understand how to avoid making a "big ball of mud", and creating "Technical Debt"

 

Big Ball of Mud - http://en.wikipedia.org/wiki/Big_ball_of_mud

 

Technical Debt - http://en.wikipedia.org/wiki/Technical_debt


Edited by JustColorado, 10 January 2014 - 12:30 PM.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"If we knew what we were doing, it wouldn't be called research. " - Einstein
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

#20 Genocode   Members   -  Reputation: 148

Like
0Likes
Like

Posted 10 January 2014 - 03:45 PM

"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.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS