Ok, just to explain this all I use a distance formula to detect if the character is within range to pick it up, then as you hold b to pick it up the "resource" gets smaller. I know this code may need to be further organized possibly into some type of MVC, but I will use it for now. So here is my question; how can I call this method without requiring all these booleans / int's ? This is what it looks like calling this method

Does this code have to have all of these different objects? (I call them id's in the method). There seems like theres no way to make unlimted objects without defining more booleans / int's... I feel like there may be something silly that I am overlooking or possibly something lacking in my java education. Well I appreciate any suggestions here guys, thanks in advanced

Now you can use ArrayList<T> or another "growable array" to store an indefinite amount of entities. In LibGDX you are suggested to use their own list, Array<T>, which is more Android-friendly. Now, presumably, you would add your stones/items/whatever in some manner -- i.e. procedurally (like randomly within a certain range) or using predefined locations (like for a tiled map). The latter would need to be parsed somehow from a file. The former might look like this:

@wreed ArrayList is very simple to use, just think of it like it is, a list. first in first out, you can add and delete, adding without an index automatically adds to the end. In ArrayList<T>, T defines what type of object goes in the arraylist, and to access an index instead of

1

array[i]

it's arrayList.get(i), or you could use an iterator (I prefer get(), however). Advantage over Array is that the size changes depending on how many elements you have, and the disadvantage is that every time you remove/add something at an index that's not the last everything has to shift.

Thanks jimmt! Now with that in mind does davedes' example using an array list sort of create a new a instance of that entity class so that the x and y ints in the entity class can be used for sort of more an one thing?

(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 need2. 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.

1 2 3

classResource {

}

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

classResource {

// Are you close enough to the player, that the player could consume it?publicbooleanisCloseEnoughToConsume(intplayerX, intplayerY) { }

// I want you to draw yourselfpublicdraw(SpriteBatchbatch) { }

// Player: "I am consuming you!"publicvoidconsumedByPlayer() { }}

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

classResource {

// To draw itself and to see if the player is close enough, it needs to know its position.publicintx, y;

// To know if the player is close enough, it needs to know what close enough means.publicintminimumDistance;

// To draw itself, it needs to know its height and widthpublicintheight, width;

// To draw itself, it needs to know which image to use.publicImagesprite;

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:

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.

Thank you actual, I have never been one to really divide up my code well although what you have said really helped me understand why that makes sense to do. I will be sure to take advantage of your post, however I'm still confused about my original question...

Wreed, I think there´s a pretty good answer to what you´re asking in reply#1 by Actual. Turn all those arrays into one array of class "Resource" and you will have a lot less code, it will be easier to read and easier to find errors. It´s all win win.

Would you mind looking at my reply number 12, that is the only question I have left then it will be a true win win, and do you mean post number 2? as I dont see any of that in actual's post number 1...

Ok I think I have that part figured out (^) but my last question is involving actuals example, would you recomend creating a "master" method in that Resource class or would I remotely call each method individually?

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