Hey, for the past two hours or so I've been attempting to add collision detection into my program but for some reason I just can't seem to figure out how to do it. I know that I'm supposed to use .intersects() and I've managed to get this working, somewhat, before in a different program but this one is a bit different so it's just thrown me off a bit.

The player's character is always centered on the screen, I've made sure of that. The screen moves around the player instead of the player moving around the screen. The map is loaded and then re-rendered depending on where the player moves. I can't figure out how to do .intersects() with the way that I've made the movement.

If anyone can figure out a way to get it working or has an idea of what I can try to get this working it'll help a lot.

Before you try to fiddle with collision detection, I highly recommend to take a step back and divide rendering from the rest, meaning character movement, collision detection and all other game logic.Then do not use magic constants, what is -16735512 ? Makes it unreadable, especially for outsiders.

Each character has its map location, collision detection will be based on that, as will be any movement stuff. After updating the internal game state/logic, everything gets into the rendering method.

Lethal Running - a RPG about a deadly game show held in a futuristic dysoptian society.

Guess I'll need to a bit of re-writing before I figure out collision detection then. I've fixed up the KeyListener with the keyCode.VK_key's, as for this method:

1 2 3 4

publicbooleangetInventory(){returninventory;}

It just gets a boolean saying whether the I key, used to open up the inventory, has been pressed. ATM this does nothing as I haven't done anything with the inventory yet.

As for the magic constants, whatever that means, they're used to figure out the RGB value of each pixel; I'm not sure of any other way to do it atm. I do agree that it's unreadable though.

Now about separating the state/logic and the rendering. I thought I wasn't supposed to do that since all I'd be doing is creating another class that stores a bunch of static variables as far as I can see. All my code is doing is getting resources and re-drawing them depending on where the player is. It doesn't seem as if there is much of anything to separate.

As for separating logic from rendering: perhaps that´s why you´re having problems with the collision detection? You want to update positions on everything that´s moving, check for collision and then, when everything is sorted out, render.

As for separating logic from rendering: perhaps that´s why you´re having problems with the collision detection? You want to update positions on everything that´s moving, check for collision and then, when everything is sorted out, render.

ps. Why would you make a new class with static variables..?

Ah, that makes sense. Well, the only thing I see that I could separate are a few variables that keep track of misc data so I'd just do something that I was told not to do and throw them all into a random variable class as static variables and just use them wherever and whenever I want without having to care about get/set methods and stuff like that. But, because I was not told to do that, I'm not going to do that.

I'll keep looking at the code and see if I can figure out what to separate I guess.

You have get used to start with a different mindset. All of those modifications and updates of the virtual game world are possible without actually showing them and tying them to specific graphics classes. The game logic should be runnable on a server without graphics sub system.And if you really want to learn how to set up and connect classes and objects, stay away from statics for quiet a while.

Lethal Running - a RPG about a deadly game show held in a futuristic dysoptian society.

So, what I think you're saying, is that I need to have, for example, a class that just deals with changing the numbers of where the player, sprites and map are and then do something like .getPlayerX(), .getPlayerY(), getSpriteX(), .getSpriteY(), etc... instead of changing the numbers in the same class that I'm doing graphics in?

So, what I think you're saying, is that I need to have, for example, a class that just deals with changing the numbers of where the player, sprites and map are and then do something like .getPlayerX(), .getPlayerY(), getSpriteX(), .getSpriteY(), etc... instead of changing the numbers in the same class that I'm doing graphics in?

Yes, for example:- world class where sprites live in- sprites with position, velocity, etc.- movement handler responding to user input and updating sprite properties- collisision detector called from the movement handler or being actually the same class- renderer taking the world and showing a snapshot during each game loop pass

Lethal Running - a RPG about a deadly game show held in a futuristic dysoptian society.

It just gets a boolean saying whether the I key, used to open up the inventory, has been pressed. ATM this does nothing as I haven't done anything with the inventory yet.

Should be the player's inventory, not the keyBoardListener. Listeners should be more of an inbetween than actual base classes. I would just have it with a getInventory() method in your player class and with your keyBoardListener calling that method upon the desired keypress.

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