I'm trying to write a simple ball game, and there's several turns (ie., ball lives). The ball "dies" when it passes the bottom border of the screen. What I have so far works, but doesn't seem to be the proper way to do things:
if (ball.getY() > bottomOfScreen) {
ball.die();
remove(ball);
}
The die() method basically fades the ball's colour slowly (dark_gray -> pause(50) -> light_gray -> pause(50)), but doesn't actually do anything useful.
The remove(), obviously, gets rid of the ball from the screen, which is what I want. It makes sense to me for this remove() to be a part of Ball's die() method, as opposed to it being a separate method call in the main program -- but I'm not sure how to go about this?
Can an object delete itself? And, if it can, is object suicide better than object murder, from a philosophical/methodological point of view?
Thanks!
The object can remove itself given it has some sort of reference to the view rendering mechanism. Your sample doesn't give enough information so I'll exemplify one way to do it:
public class Ball {
private ViewRenderer view;
public void remove() {
view.remove(this);
}
}
Neither suicide nor murder is better or worse. It depends on your design and requirements.
In this sample though, murder might be preferable since this way the Ball object doesn't need to know in which context it's being used.
It is possible to create a method in which the ball removes itself, but it's a bad thing to do. In order to remove itself from the screen, the Ball must have a reference to the screen. This creates a circular chain of references (Ball has a reference to screen, screen has a reference to Ball) which is going to make your design more complicated and your testing much more complicated.
Suicide is fine - the screen tells the ball to die, and the ball dies. But this is about removal of a relationship, not dying. The thing maintaining the relationship is the screen, and so it should be the thing doing the removal.
Also remember that the two do not necessarily have to happen together. The screen might want to keep a dead ball around for some reason, and it might want to remove a ball that isn't dead. Even if that doesn't happen in your app right now, allow for the possibility.
In a sense of deleting the object from memory: no, in Java that is handled by the garbage collector exclusively.
What you could do is to remove the object from collections containing it, but this would require the object to have access to those collections (which in most cases would not be feasible, since there might be a lot of collections).
I'd suggest the containing object (the screen in your case) to poll for the contained object's (the ball's) state and remove it after it is actually dead.
There is presumably some object (e.g. the Screen, or the ViewRenderer in Johan's example) that holds a reference to the Ball, and removing this reference has to be done by the Screen ("object murder"). "Object suicide" amounts to Ball passing a message to the Screen asking to be "murdered".
Since it is the Ball that knows when it has passed the boundary, it makes sense to me (without knowing the details of your design) for the removal to be initiated by the Ball. Then the Screen can find out about this change by one of several means:
The Screen can poll the Ball.
The Ball can hold a direct backward reference to the Screen, which creates an unfortunate circular dependency.
The Ball can hold a reference to the screen via a BallObserver interface. This is an application of the observer pattern.
The first is simplest, and this makes it a good choice if it fits naturally into your mechanism for painting the screen. The third is more flexible in principle, but you might not need this flexibility in practice. The middle option might be OK in a simple program, but you should probably consider it as a step on the way to the third.
And if you don't have a Screen (or ViewRenderer, or whatever) object and really mean "a separate method call in the main program" then you should probably reconsider your design.
No, objects cannot suicide. Any reference of itself is just a reference.
To "clear" the object within itself one would just clear all instance variables.
To "clear" the object outside itself one would set the variable equal to null.
Related
Making a minesweeper app and I have a GameGrid class to hold all the squares in a multidimensional arraylist of squares, and it handles initializing the squares along with determining where the mines will be. The Square class has variables for its position (x and y), and a variable hasMine. Now, due to some circumstances arising, I have needed to pass a GameGrid instance into the constructor of Square because I needed to access a method inside GameGrid. My question is, is this good design? For some reason, the fact that I'm passing a GameGrid instance into a Square just doesn't feel right.
I've tried to experiment with an Observer/Observable type pattern with unfortunately no luck. Another option would be to make GameGrid a singleton, just not sure if that's the best option here.
I bet a similar situation like this has probably come up before, just wondering what the best solution would be.
Edit:
Decided to clear a few things up and clarify the actual problem I'm running into.
So each square is responsible for changing its own icon when it's clicked (when it's flipped over). The problem arises when I want to implement the O-fill behavior when a zero is clicked (this concept is easy if you're familiar with minesweeper). When a zero is clicked on, all the zeroes around will automatically be flipped over. I need to use GameGrid for this and not Square because Square doesn't have access to all the squares around it.
But since a few comments have been posted and I've done a little research, I've figured out that I think I'll either just keep it as it is, and pass in the desired GameGrid instance into Square, or I'll try to work with a custom observer/observable like pattern where the updated argument (normally from notifyObservers(Object arg)) will be a custom Class that I can use to hold all the required information needed.
I'm creating a Pacman clone in JavaFX, but actually the language shouldn't matter at all, it's more about the logic behind it which I can't figure out.
I've taken a video of the issue, it illustrates quite well what bug I'm facing.
I want that the Player can eat a Food (eg. the Food gets deleted from the board[][] and the score is increased). This works. But I also want the Ghosts not to be able to eat the Food, but my draws are all based off of the board[][], so I can't have a Ghost and a Food at the same place.
Not sure how it should be done, my thought was that I can create a holdingObject variable which "holds" the Food object and which is then placed back to where it came from when the Ghost moves further.
My GameView has these two important fields in it:
private static GameObject board[][];
private static LinkedHashSet<Moveable> moveableLinkedHashSet;
Both variables get filled by other methods, these work fine.
The following code block seems to contain the issue, although it may also have to be dealed with in the Line #89 (see link below).
private void executeMoveWithPosition(Position positionDest) {
GameObject ghost = this;
// TODO: Fix holding object. Currently it's a mess:
// TODO: Two consecutive foods won't be handled correctly, food gets set to wrong position at the beginning
// holdingObject gets set to the current position - possibly null, that's ok
LevelManager.getBoard()[position.getX()][position.getY()] = holdingObject;
// ghost gets inserted at the new position
LevelManager.getBoard()[positionDest.getX()][positionDest.getY()] = ghost;
// holdingObject gets emptied
holdingObject = null;
// actually move the ghost
position.setX(positionDest.getX());
position.setY(positionDest.getY());
}
Ghost.java, from which I removed methods and if clauses which didn't matter for this.
If I understand correctly, you simply don't know what data structure you should use to represent your game board, including the player, enemies and items (food).
Without investigating your code in detail, I would suggest...
You create a Tile class. The board can then be made up of those. It can save information on whether it is a traversable or not and could also hold the item that is placed upon it.
Your enemies already have a class (Ghost) that holds their position, so just make sure you have a collection of enemies that you can iterate over for rendering and game logic. This way, you don't need the board to keep track of these itself.
Optionally, have an Item (or Food) class, that you handle just like your enemies: they hold their position and you keep all of them in a collection. Again, the Tiles then don't need to keep track of these anymore.
In order to figure out if there is a Ghost or Food on a Tile, you would then need to iterate over all of these and check their position. For a game with such a small and simple level, this should be no issue.
Of course, there are other solutions and ultimately only you can know which one fits your project.
EDIT: As it turns out after exchange of some comments, solving the problem at hand was as easy as just not putting the Ghosts into the board array, as they do hold their own position. The above covers that plus is a bit more general and broad and should hopefully apply to others with similar issues as well.
I have a custom UI drawn for my java application. Right now I draw the entire UI from scratch. I know for a fact some parts of the UI are static. I know I could save these static parts to an image, but will this yield a improvement in performance (Since even an image must be drawn every frame)?
Is it plausible to save a reference to the Graphics2D object after the UI has been drawn and assign that to the new graphics object every frame (starting from a point where all the static components are drawn)?
Thanks in advance,
Alan
You don't need to redraw everything in every frame. So if you have static parts of your UI (or even dynamic parts that you know haven't changed since last frame) then you simply don't need to repaint them.
In my code (Swing games and simulations mostly) I usually try to follow the following rules:
Pre-prepare static images (e.g. BufferedImage textures for UI elements)
Override the paintComponent() method for each UI element individually to do the painting
Only call the repaint() method of any given UI element if I know that something has changed
Call repaint() in a timer-based loop for animation, but only call it on the portion of the UI that is being animated (e.g. a nested JPanel)
This approach seems to work and perform pretty well (though I'd welcome comments if there are ways to improve it!!)
There are two main optimizations you can do here. The first is to make sure that when you cause your UI to be repainted, usually done by calling repaint, make sure you call the version of repaint where you specify a rectangle that has changed. Only make the rectangle big enough to encompass the parts that actually have changed, not the static parts. For this to be effective you also have to pay attention to the clipRect in the Graphics2D object you are passed in paint(). That is used by the system to tell you exactly what needs to be repainted, in the above case usually the rectangle that you passed to repaint. Don't paint anything that lies entirely outside that rectangle.
You can also get significant performance improvements by caching the static parts of your interface in an image. Writing an image is by far the fastest way of getting things onto a screen. My measurements indicate that small images are faster than even a few simple drawing primitives. However you need to make sure the image characteristics match the screen, by using createCompatibleImage().
Of course you may be using a lot of memory to get this speedup. I would recommend testing to see if you need to do image caching before implementing it.
if some parts of the screen is completely static, then never redraw that part. Don't do a full-screen/window clear, just clear the part of the screen/window that changes all the time.
This way, you don't unnecessarily redraw the static image.
EDIT: i just deleted the entire post and reformulated the question to be more generic.
I want to do a simple strategy game: map, units.
Map: one class. Units: another class, self drawn.
Simple questions:
How does an unit should redraw itself on the map.
A unit should be a JPanel or similar Swing component (just to be able to manage them as an entity with its own mousehandlers) or can be another thing, without neglecting the fact that it should be an autonomous object with its own action handlers and fields.
Is this map-units model correct of a simple game that would help me to learn in a fun way Java and OOP fundamentals.
Thats it!
There are 2 ways.
Either have a Map class which is the main JPanel, to maintain the collection of units, but keep the Unit class as non-Swing. When the Map's paint() method is called, ask each Unit to redraw itself by calling a method in each visible Unit. The Unit could be inherited from any base class, for example Rectangle, or some other data structure you use in the program. In this case, the Unit class handles painting and calculations, but the Map handles the clicks and events for each Unit. It could pass the message on to the Unit if needed; however, if the unit itself doesn't need to know about these things, this method works well. The Unit class is light and economical. You can also decide whether the Unit knows its position in the Map or not.
Or have each unit as a JComponent, and handle its own events separately. The disadvantage is that each instance of a Unit creates a pile of data for drawing it as well. So if you have hundreds of units, only a couple of which are drawn, this way is not efficient. The advantage is each unit can handle its own GUI events without translation etc. This assumes also a 1:1 mapping of actual units in the game and graphical units on the screen. Also it is trickier to implement certain event handlers in the Unit, if a Unit needs to know about what other Units are around!
A third and arguably better way is to have a purely data Unit class, containing the game information about the unit, as in (1), but which has a method to create the JComponent when needed. The JComponent could, for example, be an inner class in the Unit - it could then access the Unit data. This is great if a unit may need to be displayed in 2 places (e.g. on 2 screens or views).
--
Addendum to address comments
That is correct, in (1) the Map (main JPanel) implements the mouse handler, and asks each unit in turn if it is 'hit'. This allows you to do more complex things, such as have 2 units overlapping/on top of each other, and both could respond to the click.
Also, for example, they may not be rectangular, or may be drawn with an alpha channel (if the Units were JComponents, they will by default grab any mouse event over their whole rectangle, to themselves). If your units don't overlap and are in their own rectangles, then JComponent's own mouse handler is enough.
If you use approach (1), the Map can ask each unit whether it contains a clicked point, and the Map can then handle the 'selection' process. Remember, a unit on its own won't be able to work out what other units are selected - selection may involve deselecting another unit. In that case, the selection operation is really a Map operation, not a Unit operation, although it may change the appearance or function of the Unit as well.
If you use separate JComponents for the Units, you can override contains(Point) to determine if the mouse hits the item, but this won't let other Units also respond to the click. But each Unit could 'select itself' (set a flag used when drawing) then notify the Map (it will need to find it using getParent or by a preset property).
Key things you need to know before deciding on this design would be:
Will you ever need more than one 'Map' panel per game?
Will you ever need more Unit objects than are to be displayed?
Will you ever need to display a Unit more than once?
If the answers are yes, you should separate the 'Data' classes from the 'View' classes, as suggested in 3.
then: What does a Unit need to 'do' and what does it need to know about the Map and other Units in order to do this? e.g. moving is usually done by the Map class in this situation, as it depends on the Map and on other Units; drawing is best done by the Unit because there may be many unit subtypes with different data structures that may need to be drawn; Unit selection operations as you have pointed out lie somewhere in between. If you see how Swing implements this (e.g. ButtonGroup, ListSelectionModel), the 'selection' itself can be though of as a separate class.
I made a peg solitaire game a few years ago which was pretty much just a JPanel that extended MouseListener and MouseMotionListener. The pegs were primitive circles drawn in the paint method, but you could track where they landed by taking the cursor position and mathematically working out the square in which it landed. That lined up with an array that stored either a 1 or 0 for each square on the board depending if anything was there. You could also drag each piece by finding the current cursor position then calling repaint() in the mouseDragged method you get from implementing MouseMotionListener.
I'd probably suggest doing it that way to begin with. Create an array of whatever size and use that to track the units. Then each time you make a move just check that array and redraw your units in the paint method. If you're using mouse movement then you can get the current position of the unit on mouseDown then do what I mentioned before with mouseDragged, and then get your final location on mouseUp and also do your calculations in regards to legal moves etc in mouseUp.
In the paint method you'll just loop over the array that defines the map and if there is a unit at the current position on the array then do something like g.fillOval(x,y,x_dimension,y_dimension). That array could just have its elements set to 0 for no unit at the current position, or 1 for a team 1 unit at the current position, 2 for team 2 etc. The paint method will take those numbers and draw pieces accordingly (change color for each type or whatever).
I hope that makes a bit of sense.
I'm developing a fair sized hospital simulation game in java.
Right now, my pain method is starting to look a little big, and I need a way to split it up into different sections...
I have an idea, but I'm not sure if this is the best way.
It starts by painting the grass, then the hospital building, then any buildings, then people, then any building previews when building. The grass and hospital building will not change, so I only need to paint this once. The buildings themselves won't change very often, only when new ones are built.
I was thinking, use boolean values to determine which sections need repainting?
Ideal, id like to be able to split up the paint method, and then call each one when needed, but I'm unsure how to physically split it up.
I am still quite new to java, and learning on the go.
Thanks in advance.
Rel
Another idea is to create a super class or interface for all items that must be drawn on the screen. Lets cvall this class ScreenObject. You can then have a draw(Graphics2d g) method specified in the ScreenObject class. Next, each object that must be drawn implements the draw() method and is only concerned about drawing itself. You can even consider creating a variable that determines whether this draw method should be run at all.
In the main class that paints the screen you can have a reference to all ScreenObjects in an ArrayList and your paint() method will simply iterate over this calling draw() on each object.
I'm assuming from your description that your scene is split up into tiles. Keeping an array of booleans is a good way to keep track of which tiles need redrawn on the next update. A LinkedList might perform a little better in some situations. (I'm thinking of a Game of Life simulation where there are tons of tiles to redraw and you need to check each neighbor, so you may not need to go this route.)
Without seeing your code I can't give very specific advice on splitting up your paint method. I can tell you that in sprite animations, each sprite object typically has its own draw method that takes the main Graphics object (or more likely a buffer) as a parameter. Since the sprite should know its own image and location, it can then draw itself into the main image. Your paint method can then just loop through your list of sprites that need to be redrawn and call their draw method.
You might look to Killer Game Programming in Java for more detailed information.
Well I am not really an expert at programming but to split up my paint method Ive always just made a new method that takes a Graphics object and call that from paint, it has always helped me to keep my code organized but I have never had a big project like it sounds you are working on so it might not work for your situation.