Tips for controlling large game code

Newbie & Debugging Questions
#1

Like in topic. What tips on handling large code can you give to someone who is developing his first large game in small (3 programmers) team?

Currently my system looks like this:

Initiation:

  • Create new core (display)
  • Initialize new game loop elements, one after another
  • Run core (open game window)

Game Loop:

  • Calculate delta
  • Keyboard and mouse input
  • Logic
  • Collisions
  • Graphics
  • Sounds
  • Sleep

Beyond the general question I have a few small questions:

  1. Where should I initiate and how should I call classes like particle makers and any other classes that have more than one task? (for example, both logic and graphics)
  2. How should be code organized - everything in one package or maybe another packages for every element of game loop?
  3. How should game loop elements contact with each other?
  4. If I want to make 2D game with player character ALWAYS in center of screen, what is better - move everything but not player or move player and camera?
#2

Just some general ideas for large projects:

  • Have classes with well-defined domains (don’t mix responsibilities in one class).

  • Have well-defined and lean interfaces between the classes (low number of public methods and fields).

  • Avoid cyclic dependencies between packages.

  • avoid magic, vodoo and super-clever code that no-one but the writer can understand. In a team, all must read the code, but only one wrote it. Write code not only for the machine, but also with the readers in mind.

  • Try to use as few as possible global objects.

  • Avoid singletons unless you are very sure it’s a good idea to use the pattern.

  • Keep classes and methods small. If they grow too much, most likely the domain was too big, and it has too many responsibilities.

  • Document class purposes, also document what is not purpose of a class.

  • Document the package structure (what goes where, and why).

#3

-create unit test
-write testable code
http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf
http://misko.hevery.com/code-reviewers-guide/

#4

Thank you for answer Varkas! You gave me lots of tips, now I have only few additional questions related to your tips to ask.
Also, I am checking your links OttoMeier. I see that there are lots of informations, so I certainly will use something. :wink:

So, this is better for example to divine particle generator into particle logic updater and particle displayer? If yes, how to “connect” them?

I think that I understand what do you mean, but could you explain me how to pass previous layers to next ones (like logic>graphics). By the way, should I handle physics as part of logic layer?

Everything inside one package, but documented - am I understanding this right?

#5

I think of three classes:

  • The particle data (position, shape, color, age etc …)
  • The display -> must have access to the particle data, and know how to display a particle
  • The logic -> must have access to the particle data, and know how to control particle movement.

ParticleDataCollection pdc = new ParticleDataCollection();

Display display = new Display();
display.setParticles(pdc);

ParticleController pc = new ParticleController();
pc.setParticles(pdc)

This way you have a clear separation of data, logic and display. Also logic and display can stay independant, and data is completely independant from all other components.

I meant to have multiple packages, with well-defined purposes and document what they are for. So that your teammates, if they make a new class, know where to put it, also know where to search for some specific code.

There are many ways to structure a project, so you’ll need to find something that fits your style and your project. Often I put UI classes in one package, game logic in one package, and the rest depends.

A small project of mine, maybe not the best example but it must do:
http://sourceforge.net/p/freemapper/code/26/tree/gardenlife/trunk/src/gardenlife/

UI package: Custom UI components.
Actions: Events which the player can trigger through the UI.
Resources: The games static data (some graphics).

The rest I put into the main package because it’s a small project and didn’t need this much of structure (yet).

#6

So, this should look like this:

  1. Particle data is private, initialized at game run with basic values or loaded from save file
  2. Particle logic is private, initialized at game run and bind with logic - it is reading particle data, updating and returning it
  3. Particle display is private, initialized at game run and bind with display - it is reading particle data and displaying it

Am I understanding everything right?

#7

[quote]What tips on handling large code can you give to someone who is developing his first large game in small (3 programmers) team?
[/quote]
Working in a group can be daunting, but Varkas has got the right idea. I have worked in a few small groups of 3 people, and there is a few hints I can give to help out.

  1. Document your code.
    Make sure you use full advantage of J-Unit tests and JavaDoc. They will make your code readable and help eliminate confusion on what you are planning to do.

  2. Have a plan.
    This is very important if your group needs to know the way forward. A plan is a great way to keep the group focused on completing tasks, and will make your project look a lot more organized too.

  3. Split the work
    It helps if you split the work into different major groups to avoid conflicts. Having people edit each others code is where battles can happen. Splitting work between coders will reduce conflicts, and allow you to get work done if each member believes they play a definite role in the game.

  4. Respect coding practices
    Every group needs a leader to make sure the code stays a certain quality. Make sure your rules for coding is set early and are executed. Also, you want to make sure no one is getting harassed for their coding practices. Every programmer has their own understanding of how code is to be written. Be respectful of their views and use examples to persuade them into a new way of thinking. Always listen to ideas given by each member, and respond to the best of your ability.

In response to your questions…

  1. You should try your best to keep particle makers confined into one specific class. These are tools and they should be put somewhere where it can be accessed easily.

  2. You want to make sure that you have different packages for each section (graphic, logic, networking, etc…) of your code. Organizing your java code into folders combined with documentation will help users find your information a lot faster.

  3. This is ultimately up to how you want to do it, but documentation of how you want the connections to be handled is crucial early on. There are a lot of factors, like networked or console… etc. That changes the decision making. Discuss it with your group, and make your decision from there.

However, if you want a straight answer.

I like to connect modules through the update(). I update 1 module at a time until I go through all the modules. I have one class that orders the modules for me in the order I think they are best updated. Therefore, even though all the parts are needed, none of them necessarily have to interact directly with each other.

  1. Again, difficult to say. It totally depends on the style of your game. Again, you should consult the members of your group and get their opinion on it before you do anything. Input from your group members keeps them interested in the final product.

The straight answer…

I prefer moving the screen and the player. It allows you to choose between the 2 styles interchangeably. You will be able to allow parallax scrolling and also allow the camera to move in a way that does not give the user motion sickness. Camera movement when done right can really improve the feel of your game, so having more options is always great.

I don’t want to overshadow you Varkas, you gave some really good advice. However, I want to give a little bit of a different angle and see how it goes. Good Luck with the group project and I hope you are successful with your huge project.

#8

Have tried entity/component based approach?

#9

Currently only in small projects.

#10

No problem. I’m coming with a business application development background, and games are different - e.g. the particle example was only good in theory to show how to structure components, but particles need a lot of optimization, and in games this often has preference to clean code.