Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (491)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Tips for controlling large game code  (Read 951 times)
0 Members and 1 Guest are viewing this topic.
Offline Mac70
« Posted 2012-11-12 20:30:29 »

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?

Check out my Devblog! Smiley
Offline Varkas
« Reply #1 - Posted 2012-11-12 21:19:13 »

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


if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline OttoMeier

Senior Member


Medals: 4
Projects: 1



« Reply #2 - Posted 2012-11-12 21:38:27 »

-create unit test
-write testable code
http://misko.hevery.com/attachments/Guide-Writing%20Testable%20Code.pdf
http://misko.hevery.com/code-reviewers-guide/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mac70
« Reply #3 - Posted 2012-11-12 21:50:56 »

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

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

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

- Try to use as few as possible global objects.

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?

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

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

Check out my Devblog! Smiley
Offline Varkas
« Reply #4 - Posted 2012-11-12 22:20:53 »

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

1  
2  
3  
4  
5  
6  
7  
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.

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

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

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

if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Offline Mac70
« Reply #5 - Posted 2012-11-12 23:10:42 »

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.
1  
2  
3  
4  
5  
6  
7  
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.

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?

Check out my Devblog! Smiley
Offline ctomni231

JGO Wizard


Medals: 99
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #6 - Posted 2012-11-13 06:20:32 »

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

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

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?

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.

4) 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.   

Offline ReBirth
« Reply #7 - Posted 2012-11-13 09:03:50 »

Have tried entity/component based approach?

Offline Mac70
« Reply #8 - Posted 2012-11-13 12:17:18 »

Have tried entity/component based approach?

Currently only in small projects.

Check out my Devblog! Smiley
Offline Varkas
« Reply #9 - Posted 2012-11-13 13:14:44 »

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.

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.


if (error) throw new Brick(); // Blog (german): http://gedankenweber.wordpress.com
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (15 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (29 views)
2014-08-22 19:31:30

atombrot (41 views)
2014-08-19 09:29:53

Tekkerue (39 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (25 views)
2014-08-16 06:20:21

Tekkerue (36 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!