Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (539)
Games in Android Showcase (133)
games submitted by our members
Games in WIP (603)
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  
  Question about Design  (Read 958 times)
0 Members and 1 Guest are viewing this topic.
Offline tyeeeee1
« Posted 2013-03-22 18:50:37 »

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...?
Offline opiop65

JGO Kernel


Medals: 161
Projects: 7
Exp: 4 years


JumpButton Studios


« Reply #1 - Posted 2013-03-22 18:57:18 »

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!

Online HeroesGraveDev

JGO Kernel


Medals: 312
Projects: 11
Exp: 3 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #2 - Posted 2013-03-22 19:10:17 »

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!
Legends of Yore - The Casual Retro Roguelike
Offline tyeeeee1
« Reply #3 - Posted 2013-03-22 19:18:06 »

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

Thanks for the replies.
Offline ctomni231

JGO Wizard


Medals: 99
Projects: 1
Exp: 7 years


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


« Reply #4 - Posted 2013-03-22 19:31:01 »

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.

Offline tyeeeee1
« Reply #5 - Posted 2013-03-22 21:40:33 »

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?
Online HeroesGraveDev

JGO Kernel


Medals: 312
Projects: 11
Exp: 3 years


┬─┬ノ(ಠ_ಠノ)(╯°□°)╯︵ ┻━┻


« Reply #6 - Posted 2013-03-22 21:49:14 »

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

Offline tyeeeee1
« Reply #7 - Posted 2013-03-22 22:12:23 »

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.
Offline Agro
« Reply #8 - Posted 2013-03-22 22:12:34 »

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.

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.

rwatson462 (38 views)
2014-12-15 09:26:44

Mr.CodeIt (31 views)
2014-12-14 19:50:38

BurntPizza (62 views)
2014-12-09 22:41:13

BurntPizza (99 views)
2014-12-08 04:46:31

JscottyBieshaar (60 views)
2014-12-05 12:39:02

SHC (74 views)
2014-12-03 16:27:13

CopyableCougar4 (77 views)
2014-11-29 21:32:03

toopeicgaming1999 (138 views)
2014-11-26 15:22:04

toopeicgaming1999 (127 views)
2014-11-26 15:20:36

toopeicgaming1999 (38 views)
2014-11-26 15:20:08
Resources for WIP games
by kpars
2014-12-18 10:26:14

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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