Jump to content

  • Log In with Google      Sign In   
  • Create Account

Need some help with planning/organizing game 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
5 replies to this topic

#1 TGibson   Members   -  Reputation: 102

Like
0Likes
Like

Posted 14 March 2012 - 01:45 AM

Hi guys, first off sorry if this is in the wrong section. I'm new here and I consider myself a beginner, so I figured this would be the best spot. Posted Image

I've done a few simple games in XNA and recently finished a Tetris clone in SFML, and each time I get about half-way through a project, my code begins to look like a cat was dancing on my keyboard and somehow produced working code.

I'm looking for some tips on how to organize my games to help reduce the spaghetti factor. My problem is that every time I sit down to plan out a structure on paper, I just get overwhelmed. Even with something as simple as my Tetris clone, I end up just saying screw it halfway through and wing it without any planning, and wouldn't you know it, it ends up being a mess. Everything is tightly coupled, and the code is just a headache to look at. I mean, the game is working, and I'm just glad to have actually finished the game, but the code itself leaves a lot to be desired.

Do you guys have any pointers on how to break everything down and create a structure that's orderly, and where I'm able to add in a new feature without breaking too many things in the project?

Sponsor:

#2 6510   Members   -  Reputation: 151

Like
1Likes
Like

Posted 14 March 2012 - 01:55 AM

- identify your game entities
- think about responsibilities of each entity
- keep responsibility as narrow as possible
- do not introduce cyclic relations
- only communicate between entities through well defined interfaces
- only put required methods in the entity interfaces
- use interfaces to declare method parameters not specific implementations

- get several good books about software development and ... read them Posted Image

#3 TGibson   Members   -  Reputation: 102

Like
0Likes
Like

Posted 16 March 2012 - 01:25 AM

Thanks, just the stuff I'm looking for Posted Image. The first three points I try to keep in mind while coding, but the rest is new to me as I haven't really used interfaces or abstract classes much. I understand the basic concepts, but I've never actually applied them. Time to get my hands dirty!

- do not introduce cyclic relations


This is a totally new one for me, and my google-fu is failing me Posted Image. Could you elaborate a little?

- get several good books about software development and ... read them Posted Image


I've actually got 3 books sitting in my closet right now that I plan on getting to soon (Pragmatic Programmer, Game Architecture & Design, and Game Engine Architecture). I've actually read through Pragmatic Programmer late 2010 - early 2011, and I plan on going through it next week while on spring break. The other two I got from a friend a while back and, while very interesting, are very heavy with content. I plan on maybe getting through them this summer before classes start back up.

I plan on picking up something geared more towards C++ in general soon, are there any recommendations?

#4 DvDmanDT   Members   -  Reputation: 893

Like
0Likes
Like

Posted 16 March 2012 - 06:50 AM

My tips are
  • Avoid cyclic relations, especially cyclic references. If the map has a reference to a tree, then don't let the tree have a reference to the map. If the player has a reference to a weapon, then don't let the weapon store a reference to the player. If the weapons logic needs to access the player data, then pass the player as a parameter to that method.
  • Don't be afraid of rewriting and/or refactoring code when it becomes messy. Use some version control software like Subversion or Mercurial so that you can easily track changes and go back in case something goes wrong. For example, whenever you find yourself in a situation where you have code duplication, you should probably start refactoring.
  • Don't use static variables or globals.
  • I separate my engine subsystems in a stack-like structure, where each layer only knows about lower levels. At the bottom, I have my game logic, then my network logic and at the top, my presentation logic. In other words, the game logic knows nothing about graphics. The higher levels (ie the ui system) can register callbacks to the lower levels (game logic) for two-level communication though.

    There are some serious pros and cons with this particular structure, the main advantages being that it's easy to serialize (save/load) and synchronize over network.
  • Don't overuse inheritance/polymorphism. Lookup the Strategy pattern.
  • Keep coding and learn the hard way. Posted Image


#5 6510   Members   -  Reputation: 151

Like
0Likes
Like

Posted 16 March 2012 - 07:12 AM

DvDmanDt just elaborated about cycles. That's very important to keep your code from turning into a chaotic unmaintainable monolith.
All his other points I would sign as well.
#5 is especially important, people often think of OO as mainly creating class hierachies. But object - not class - relationships are much more important.

#6 Quasimojo   Members   -  Reputation: 243

Like
0Likes
Like

Posted 16 March 2012 - 08:20 AM

I've found the book, Head First Design Patterns, to be very helpful in becoming familiar with various patterns and how/why to use them. The book is written using Java, but the concepts translate easily to other languages.




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