Wreed,
(I hope this doesn't come across as patronizing, it seems like you could use some help in the basics. If anyone else sees problems with what I've got, please chime in. Providing wrong advice is worse than providing no advice at all).
The biggest issue I see with this code is that you are mixing all sorts of things like input, drawing, updating together, and a good part of that reason is you aren't making good use of classes. A significant part of programming in Java involves determining what classes you need, what they look like, and how they interact. Until you understand that better, everything you try to do is going to be that much harder. I am going to walk through a way to think through your problem in hopes that you can better understand how to work with classes. I am not claiming it is the best or only way but I think it is a reasonable one.
Objects are all about behavior. What can you tell them to do(commands)? What questions can you ask of them (queries)? What kinds of things do they need to be notified about? The answers to these questions help define what behavior (and thus what methods) are needed.
So a reasonable way to go is:
1. Decide on what kinds of objects (classes) you might need
2. For each, decide what types of commands/queries they will need to be able to handle (behavior).
3. For the behavior, think about what facts it will need to know in order to carry out the behavior.
The most important thing is to understand that it's an iterative process. You create a few objects, then realize you need a new one. You may add some methods, then realize you don't need them and get rid of them.
A simple way to decide what objects you need is to think of all of the "things" in your game. In your case Resource, Player, and Level come to mind and it makes sense to make a class for each.
As an example, let's take your "resource". A Resource is a "thing" in your game so it is a good candidate for being a class.
So what is a Resource? From your description and code I see the following:
"A Resource sits in the world, unmoving. If the player is close enough and consumes it for 5 seconds, then it disappears and the player gets stone added to their inventory. If the player stops consuming it before the 5 seconds, it goes back to normal. It shrinks as it gets consumed."
So how does this translate into behavior? It actually helps to think of the Resource as a person. Imagine what kinds of questions would you ask it? What kind of things would you tell it to do? What would you need to let him know is going on?
"Is the player close enough to you, that he could consume you?"
"I want you to draw yourself"
Player: "I am consuming you!"
We can turn each of those into a method.
1
2
3
4
5
6
7
8
9
10
11
| class Resource {
public boolean isCloseEnoughToConsume(int playerX, int playerY) { }
public draw(SpriteBatch batch) { }
public void consumedByPlayer() { }
} |
This is just a start. The important thing is that you don't have to figure it out all up front. You can write what you need then make changes as needed. So what does a Resource need to know to be able to do what we are asking of it so far?
* To know if the player is close enough, it needs to know its own position and it needs to know how close is "close enough".
* To draw itself, it needs to know its position, its width and height, and the image being used to draw it
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
| class Resource {
public int x, y;
public int minimumDistance;
public int height, width;
public Image sprite;
public boolean isCloseEnoughToConsume(int playerX, int playerY) {
return (playerX - x)*(playerX - x) + (playerY - y) * (playerY - y) < closeEnough * closeEnough;
}
public void draw(SpriteBatch batch) {
batch.draw(sprite,x,y,width,height);
}
} |
We are getting somewhere now but let's look at consuming more carefully. If the player is close enough and holds the button down for 5 seconds, the resource is consumed and the player gets stone added to their inventory. If the player releases the B button before the 5 seconds are up, the resource gets reset. So what other queries/commands/notifications might there be?
Player: "I've started consuming you"
Player: "I've stopped consuming you"
"Is there anything left or are you all consumed?"
What does the resource need to know to carry these out? It needs to know whether or not its currently being consumed, and if so, how long it is being consumed for. So we can add the following to the class:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| private float timeConsumed;
private boolean isBeingConsumed;
public void startConsuming() {
timeConsumed = 0;
isBeingConsumed = true;
}
public void stopConsuming() {
isBeingConsumed = false;
}
public boolean isConsumed() {
timeConsumed > 5;
}
public void update(float delta) {
if (isBeingConsumed) {
timeConsumed += delta;
}
} |
So putting all of that together, you have a reasonably complete object that represents a Resource. We've pulled out some of the functionality from your original, sprawling method, and have put it where it belongs.
