Jump to content
  • Advertisement
Sign in to follow this  
vibrunazo

Tips OOP architecture in Java?

This topic is 2780 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, long time lurker, first time poster here.

I started to make a game using Java to use with the Google Web Toolkit (compiles Java into javascript + html5). I have a reasonable experience with scripting on a few different game engines. But I'm a complete newbie to low level coding and I'm unexperienced in Java. So I'm stuck trying to decide how to organize the code to make it: efficient, easy to read, simple to maintain and scalable. I have a class called Game. From which will spawn several players, which will each perform several actions (run, attack, cast spell etc). I aim to have hundreds of players and hundreds of actions. So I'm worried about how to write a code that is scalable. So I can start with a few but easily add more. But I'm not sure which of these options would be a better design:

( a )
- The Game class should have a large number of methods with every possible player action. As well as all low level methods like drawing in the screen
- The players should have their own class, spawned from the Game class, this class will only have simple class variables like name, position, health etc. Simple geter and seter methods. But no methods with player actions.
- The Game class will handle all the actions, and will edit each Player object accordingly (ex.: change it's animation and position, if it should be running)

Pros: this seem the easiest thing to code for a newbie like me. This is the only option I actually know how to do :P
Cons: sounds like it would be way too unorganized and messy to maintain, since I will have this huge game class with way too many methods. I'm also worried about performance since not all actions would always be used, but it would all be loaded in memory on the Game class methods

( b )
- The Game class will not deal with actions at all, and would only deal with low level stuff
- the Player class would be just like in (a), simple self reference methods with no actions
- an Action class object would spawn from the Game class and hold all the actions and it's methods would edit player atributes
- The Action class would have methods that calls low level methods from the Game class, to draw the actions on the screen.

Pros: would be more organized and easier to maintain actions on a separate file from the low level Game class
Cons: I'm not sure how to execute (The map variable and the drawing methods are on the Game class, so how can the Action class use it's parent methods?). And I'm even more concerned about performance, since I would be creating extra Action objects

( c )
- The Game class will be same as (b), only low level methods.
- The Player class would not only hold basic self reference geters and seter methods. But would also deal with actions.
- The Player class object would spawn it's own Action class objects. Each action object for each action the player actually uses.
- Just like (b), the Action class draws on the screen

Pros: seems to be the most efficient, since only actions been used are loaded.
Cons: I think this would be the hardest for me to code, I would have to look up how to execute this properly

Which of these options would be a better route for me to follow? Or are all of them bad? Should I be doing something completely different? Any general design tips that would help guide me in the right direction?

I would love to hear a few tips from more experienced coders. Any small help can be huge for me. Thanks in advance :)

Share this post


Link to post
Share on other sites
Advertisement
You shouldn't worry about memory used for for game actions and other logic: it might be a lot of source code from your point of view, but it is compiled to a few kilobytes of class files at worst.
Objects themselves, unless you screw up with multiple copies of redundant data, are also small: 1000 bytes*1000 player instances =1 megabyte.

Option a) is what's derogatorily called a god object (in this case the Game): it will be messy because it has too little encapsulation, not because it is too large.
Options b) and c) seem unclear about the highest level of control: something is going to iterate through all entities to collect their actions, sort actions in the order in which they should happen, apply the effects of actions to data structures that are presumably in the Game class, and render new frames when they are ready.

Regarding your idea of "Actions", it is more usual to separate as much as possible updates to the state of your entities and rendering the new state, since it is a logical division and there will be cases in which the two functions aren't paired: rendering without events when the game is paused, updating at a fixed rate and rendering as many frames as possible (or as many as vsync dictates) in a separate thread, or updating the game but skipping a frame because the frame is already late, possibly advancing the game state without rendering (e.g. when fast-forwarding a replay).

Share this post


Link to post
Share on other sites
I think you should consider your objects in terms of their /data/ and not what they actually do (although this is probably harder in Java since I guess there are no global functions, although maybe not really THAT much of an issue).


If you take a data-first approach, even if you end up with a lot of functions for a single object, they're almost certainly going to be quite closely related, necessary, and filling a specific role. The issue with god objects is that a lot of their methods just sort of... sprawl. Lots of unrelated functionality, or functionality that's too distant from what it actually needs to work with.

Basically don't worry about what your Game /does/, at first, but worry about what it /is/ or what it /has/.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!