Sign in to follow this  
Spencer Burd

Very Basic Question about classes

Recommended Posts

I just need to know what classes i need for a 2D platformer other than these:

 

main

 

gravity

 

physics

 

player

 

entity

 

collision

 

Also, how do i set the dimensions for the game window on the desktop?

 

If you could include basic code for ones being added, that'd be great.

 

Share this post


Link to post
Share on other sites

I think you need some fundamentals down about how GUI in Java work since you are asking about how 

to set up a game window.

 

if statements to test collision between objects

 

timer class for animation

 

image class to add image to instance of a class called Player and Monster

 

canvas class can serve as a buffer to draw objects on screen

 

bufferstrategy class is useful for double buffering to achieve smooth animation in your game

 

MouseListeners and KeyListeners class are useful for objects to be able to listen to what events they should listen for to interact with other objects in your game

 

just to name a few.

Edited by warnexus

Share this post


Link to post
Share on other sites

You are going about the design of your game (and its classes) wrong.

To illustrate this point, I know what gravity is, but tell me what a “gravity” class is.

Gravity is just a number, and it is plugged into a few equations.  The way multiplication, division, addition, and subtraction work on that number are not different from what is specified by the language standard.

This is not the use of a class.  This is the use of a variable.

 

 

When you design a system, you get a general idea of all the components you will need, pick one as a good starting point, and then go into detail on just that one component.

That is when you decide on class names and class hierarchies.  You don’t just decide on every class in the entire game up-front.  It will never work.

 

 

You know you will need a window to see anything at all so that would be a good place to start.  Think about that system first.

And no I don’t know how to get the desktop resolution from Java.  You don’t need it. Just use 800×600 or 1024×768 and move on.

 

Next you won’t be able to see anything until you have graphics, so then, and only then, consider what kind of class structure you want for your sprites.

 

Next you will want a character and a ground on which he can stand.

Think about the character class next.

 

While only going into detail on one specific task at a time, it is always a good idea to remember the vague overview of the entire system that you originally made.

Because this would be a good time to realize that your player might share features of other things in your game such as blocks and enemies.

When you realize the potential to share things between what might have originally seemed unrelated, then you can think about a few system at once, but only for the purpose of what they share and with the main goal of getting your current task done better.

 

As you gain experience this becomes much easier.

Pick a starting point and go.

 

 

L. Spiro

Edited by L. Spiro

Share this post


Link to post
Share on other sites

I am currently working on a similar project. Rather than having a special gravity class, implement it into the physics class and use this as a full motion system, e.g. with acceleration (the gravity, also includes things like friction, air resistance, etc.), velocity, and position. The way I'm implementing it is with vector math (which isn't a bad way to go, I think). 

 

Also, if you are unfamiliar with sub- and superclasses, you may be able to make a hierarchy for your entities, mobs, static objects, walls, etc. - because in truth, all of these things should have at least a few variables in common (x,y,sprite,motionsystem), and you can save yourself quite a bit of coding.

 

Have fun,

 

Selenaut

Share this post


Link to post
Share on other sites

Also, if you are unfamiliar with sub- and superclasses, you may be able to make a hierarchy for your entities, mobs, static objects, walls, etc. - because in truth, all of these things should have at least a few variables in common (x,y,sprite,motionsystem), and you can save yourself quite a bit of coding.

You can, but I'd like to rant for a moment about inheritance. It is one of the more abused features out there. Deep inheritance hierarchies lead to brittle design. I honestly feel the is-a/has-a test may mislead a lot of people. Look to favor composition over inheritance.

Share this post


Link to post
Share on other sites

I am going to go through your list in terms of concepts, not just classes. "Main"... okay, not worth mentioning much... hopefully you're already familiar with update loops and I guess that you are. "Physics", "Gravity", and "Collision" can be merged. Gravity and collision are just components of Physics. For a basic platformer, the entire game will follow one set of physics rules.

 

That leaves "Player" and "Entity". A Player could be considered a type of Entity, which are usually described to have a location, graphic to represent it (optional) and dimensions (also optional). You can derive other things from Entity, like enemies, other moving objects and walkable tiles.

 

Physics will act on most or all of these things. Player is an Entity that receives Input, which would be a different concept altogether. I actually think it's okay to inherit Entity here, because this can all be designed with just one level of inheritance.

Edited by CC Ricers

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this