Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (109)
games submitted by our members
Games in WIP (536)
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  
  [Solved] Organizing Code  (Read 565 times)
0 Members and 1 Guest are viewing this topic.
Offline dissonance

Senior Newbie





« Posted 2013-02-26 08:55:08 »

I am currently working on a simple game, using Slick2D, as a means of practice and I was wondering if someone can give me some advice on how I've set up my code. This is how I have it thus far:

AssetLoader - This basically loads the sounds and sprites. It also has a set of getters for these assets.
SoundManager - This basically handles all the sound playing and music playing.
UserInterface - This handles all the userinterface nonsense.
Debug - This is a simple class of booleans with getters & setters that are used to check for when certain debug functions are enabled.

Now, in the GameState class, the SoundManager object is created and is updated in the update method. The SoundManager gets it's sounds from the AssetManager and handles when a sound is playing. The UserInterface object is also created and has a render and update method. The UserInterface gets all of it's Images from the AssetManager; it also checks the Debug if any of the options are enabled so it can draw them.

Now I have a debug option for displaying the current track. The UserInterface will check the Debug to see if this is turned on. If it is, it will then check the SoundManager for what song is playing and display it.

So, does this make sense? Am I going about it all wrong? Should I break it down more? Any advice will be appreciated! Smiley

Thanks!
Offline 65K
« Reply #1 - Posted 2013-02-26 09:37:46 »

If you have multiple screens, like game start, options, the running game itself, etc., you better also have dedicated screen handlers instead of one almighty UserInterface.
For debugging, you might as well use an existing logging library.

Offline dissonance

Senior Newbie





« Reply #2 - Posted 2013-02-26 17:03:37 »

If you have multiple screens, like game start, options, the running game itself, etc., you better also have dedicated screen handlers instead of one almighty UserInterface.
For debugging, you might as well use an existing logging library.

I didn't even think to check for a logging library. Thank you, for the information.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Damocles
« Reply #3 - Posted 2013-02-26 17:11:16 »

Tip: dont create complexity for the sake of it. (An unnecessarily complex Class-Hierarchy / including
huge Logging libraries if you just need a "Log" class that can print lines to a textfile)

Else you create lots of boilerplate code, and loos oversight of the important parts of the program.

Offline dissonance

Senior Newbie





« Reply #4 - Posted 2013-02-26 17:18:18 »

Tip: dont create complexity for the sake of it. (An unnecessarily complex Class-Hierarchy / including
huge Logging libraries if you just need a "Log" class that can print lines to a textfile)

Else you create lots of boilerplate code, and loos oversight of the important parts of the program.

As for how I've set up the AssetLoader and the SoundManager, this isn't over complicating it, is it?
Offline Mac70
« Reply #5 - Posted 2013-02-26 20:48:17 »

My code organization currently looks like this:

  • Core
    • Textures list (class full of public static Tex (class which store informations about textures) which can be used in rendering)
    • Shaders list (class full of shaders ID's)
    • Preloader (loads all texture and shaders data into Textures list and Shaders list)
    • Loop
    • Input
    • Logic (can read data only from input, almost every object and interface element is created there)
    • Collisions (if needed for the game, can read and save data in logic)
    • Graphics (can read data only from logic)
    • Audio (can read data only from logic)
  • Objects
    Everything what is displayed in your game (except interface) - background entities, player, enemies, bullets etc.
  • Interface
    Name speaks all. I am using interface classes for everything related to interface, with exception of mouse cursor (controlled directly by core).
  • Libraries
    Storage of all "high-level" functions which allows me to do things like rendering, loading assets etc. using only one function.

This system works well - I'm not very experienced, but at the moment I have about 100 classes in my project and everything is still prefectly clear.

I hope this helps. Wink

Check out my Devblog! Smiley
Offline dissonance

Senior Newbie





« Reply #6 - Posted 2013-02-27 02:28:48 »

Thanks for the insight. It's pretty useful to see how other people setup their code.
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.

CogWheelz (18 views)
2014-07-30 21:08:39

Riven (25 views)
2014-07-29 18:09:19

Riven (15 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (33 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (43 views)
2014-07-24 01:59:36

Riven (43 views)
2014-07-23 21:16:32

Riven (30 views)
2014-07-23 21:07:15

Riven (31 views)
2014-07-23 20:56:16
List of Learning Resources
by SilverTiger
2014-07-31 18:29:50

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

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

HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54
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!