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.
I think you may be confused about how classes are used. While it's good to plan ahead just arbitrary names for classes isn't what you're looking for. The first thing you'll probably want to do is get your player class up and running. Just set an arbitrary y value to be the 'ground' and get your player set up so that they can run back and forth and jump or whatever. After that you can make your collision mechanics and whatever classes you need for that. Replace your fake ground with a collider and get your collision physics working. Then you can make yourself a little area to run around in and start working on adding entities. Just make the classes you need as you move forward.
Once you see what all parts are needed for this then you can go back to the drawing board and start planning not what classes you need, but the best way for the classes to relate to one another. That's the tricky part.
Maybe you should get better at programming(a lot better) before start developing a game, which is a hard task.
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.
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
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
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.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.
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.
