Question about Design

[tyeeeee1]

Hey, I'm currently re-writing all of the code for my game once again in an attempt to start doing things correctly. I'd like to ask a question about how the framework of a game should be set up, I know this is pretty basic but I've messed up on this a few times.

Example Game Structure:
http://imgur.com/cORcu9x

Questions:

• Is the diagram that I linked to above correct, if not what should be changed?
• Should the game loop call a method in a different class that then gets all of the changes for every single thing and sends it off to all of the other classes that require variables or is there a better way to do it?
• Should I have separate classes for the player, sprites, map, etc...?

[Opiop]

I always have a interface that all my classes extends; it holds a update and render method. All my classes have the ability to render or update something. I then call the update and render methods in my main gameloop. Graphics are rendered and then I update the positions before doing it all over again. I would be against your 2nd bullet point, I think your code would get way to dependent on its self, and if you change one thing, you'll screw it all up. I would look into OOP, I think games really benefit from it. You are also correct on your 3rd point, you need to make separate classes for everything. You need a base sprite class for all of your sprites to have one common place to operate from. So, your Player class would extend Sprite, your Enemy class would extend Sprite, etc. If you try to throw everything into the same class, you will again clutter your classes up way to much, and I guarantee you you will have some very buggy code on your hands!

[HeroesGraveDev]

1. Updating is one action. Rendering is one action. Why are there four parts to your loop?
2. Objects should collect the variables themselves unless it is a non-field variable. I do not mean to make EVERYTHING a field. Work out whether to pass the variable or collect it AFTER you decide whether it's a field or not.
3. Java is OOP. The whole point is to have loads of classes (within reason) to make it easier to code.

Games published by our own members! Check 'em out!

[tyeeeee1]

1. Updating is one action. Rendering is one action. Why are there four parts to your loop?
2. Objects should collect the variables themselves unless it is a non-field variable. I do not mean to make EVERYTHING a field. Work out whether to pass the variable or collect it AFTER you decide whether it's a field or not.
3. Java is OOP. The whole point is to have loads of classes (within reason) to make it easier to code.

It's actually just updating/rendering, the two extra parts are just descriptive text but I guess they looked more like their own step. I'm somewhat bad at drawing diagrams. 

Thanks for the replies.

[ctomni231]

Just a quick suggestion.

I think that your diagram is spot on. When I build my code, I usually do all the updating first followed by the rendering. Splitting up everything into classes helps immensely in that regard. If you give all your objects and scenes an update function. It'll give you a lot of control on which order they are rendered, and what appears above and below certain details on the screen.

Remember, your code is supposed to help you design easier. So, always strive to do what you are comfortable with. (You'll probably learn good OOP eventually.) The basic rule is, the more that you split up your logic code from your graphic code, the easier it'll be to control things graphically within the code. Control is really all your after, so keep that in mind as you make your decisions.

[tyeeeee1]

I just thought up another question to ask after I did a few tests with inheritance which I've never used before. If I have a base Sprite class and all of the other Sprite classes inherit from it, what should I put in the base Sprite class?

[HeroesGraveDev]

I just thought up another question to ask after I did a few tests with inheritance which I've never used before. If I have a base Sprite class and all of the other Sprite classes inherit from it, what should I put in the base Sprite class?

Everything that applies to all sprites. (eg: position, tex coords, velocity, life, etc.)

[tyeeeee1]

Everything that applies to all sprites. (eg: position, tex coords, velocity, life, etc.)

I did a test to see if I could do this before I asked. I made two classes, one was Entity and the other was Player, and in the Entity class I created a variable 'public int testInt = 1;'; after that I had Player extend Sprite and then made a constructor method for each class, in both constructors was the statement 'System.out.println(tempInt);'. When I tested the classes by calling both of the constructors they both printed 1 to the console. Because of this I thought that it wouldn't be possible to use a Sprite class for something such as holding all of the variables.

The way that I thought it would work is if Player extended Entity then player would create it's own instances of all of the public variables in the Entity class without me having to specificly create them.

[Agro]

I do something similar to you guys: have an interface called Active that has basic things like update and render. Entity class implements that so all things can be updated and rendered.