In a small java swing 2D game, what is the best solution for creating the board view?
Use a component for the board and custom paint it and each square of the checker at once?
Use a component for the board and create another component modelizing the square with its own paint component doing the job for the square only. Use a layout to place each Square instance in the board?
I know this is subjective and I don't want a fight about it. I just need some clues to figure myself which way I should go. I've begun a side project and I've using 1), with the feeling that there is something wrong.
Just go with one drawing panel/container for everything.
Consider a tile based game. Using your second solution each tile would be an object, memory would skyrocket and the game would slow to a crawl.
Using the first option you are flexiable. You draw what you want, you have the panel coordinates so everything is relative to this. Using the tile based example you'd know the height and width of the panel, draw your square and increment in the X and Y coordinates as appropriate.
GUI frameworks such as Swing or .NET's Winforms are expensive as they have a whole lot of other stuff that a game won't need. So to answer your question, go with option one, rather than say using a panel for every checker on your board.
One nice solution to using the second method, in combination with the first method is the Flyweight Design Pattern. You still get to use OO objects, but you'll have a fraction of the amount you normally would. Check it out.
Like Finglas, I lean toward your first approach. This tile-based game is a concrete example. In contrast, this component-based game uses a GridLayout of JToggleButton. The former is somewhat more complex but plays well even on large screens; the latter is simpler yet sufficient for reasonable games. You may have to experiment with your game's geometry and logic to decide which to prefer.
Related
Similar to the game Factorio im trying to create "3D" terrain but of course in 2D Factorio seems to do this very well, creating terrain that looks like this
Where you can see edges of terrain and its very clearly curved. In my own 2D game Ive been trying to think of how to do the same thing, but all the ways I can think of seem to be slow or CPU intensive. Currently my terrain looks like this:
Simply 2D quads textured and drawn on screen, each quad is 16x16 (except the water thats technically a background but its not important now), How could I even begin to change my terrain to look more like a Factorio or other "2.5D" games, do they simply use different textures and check where the tile would be relative to other tiles? Or do they take a different approach?
Thanks in advance for your help!
I am a Factorio dev but I have not done this, so I can only tell you what I know generally.
There is a basic way to do it and then there are optional improvements.
Either way you will need two things
Set of textures for every situation you want to handle
Set of rules "local topology -> texture"
So you have your 2d tile map, and you move a window across it and whenever it matches a pattern, you apply an appropriate texture.
You probably wouldn't want to do that on the run in every tick, but rather calculate it all when you generate the map (or map segment - Factorio generates new areas when needed).
I will be using your picture and my imba ms paint skills to demonstrate.
This is an example of such rule. Green is land, blue is water, grey is "I don't care".
In reality you will need a lot of such rules to cover all cases (100+ I believe).
In your case, this rule would apply at the two highlighted spots.
This is all you need to have a working generator.
There is one decision that you need to make here. As you can see, the shoreline runs inside the tile, not between tiles. So you need to chose whether it will run through the last land tile, or the last water tile. The picture can therefore be a result of these two maps (my template example would be from the left one):
Both choices are ok. In fact, Factorio switched from the "shoreline on land" on the left to the "shoreline on water" on the right quite recently. Just keep in mind that you will need to adjust the walking/pathfinding to account for this.
Now note that the two areas matched by the one pattern in the example look different. This can be a result of two possible improvements that make the result nicer.
First is that for one case you can have more different textures and pick a random one. You will need to keep that choice in the game save so that it looks the same after load.
Another one is more advanced. While the basic algorithm can already give you pretty good results, there are things it can't do.
You can use larger templates and larger textures that span over several tiles. That way you can draw larger compact pieces of the terrain without being limited by the fact that all the tiles need to be connectable to all (valid) others.
The example you provided are still 2D textures (technically). But since the textures themselves are 'fancy 3D', they appear to be 3D/2D angled.
So your best bet would be to upgrade your textures. (and add shadow to entities for extra depth).
Edit:
The edges you asked about are probably layed-out by checking if a 'tile' is an edge, and if so it adds an edge-texture on top the background. While the actual tile itself is also a flat image (just like the water). Add some shadow afterwards and the 3D illusion is complete.
I hope this answers your question, otherwise feel free to ask clarification.
Finally decided to learn 2d (for now) java game programming. Am working on a game that has a central object that the user will guide with the directional keys. I have that working perfectly, cobbled together from examples and tutorials I've found.
I'm using this method of generating colored background tiles but I'd like to scroll (move) the background as the primary object the user is moving reaches the window edges. I'm fairly sure I can make that work, I have the basics in place, but I can't find a good tutorial or actual demonstration of a way to continue to generate additional tiles to fill in the space the user is moving too.
At this point, this is purely background and I have no need to save the exact tiles generated - but eventually I would like this ability. I'm sure I'll have to find a way to divide the areas into "chunks" like minecraft does.
But for now - how can I continually fill in the area with the same pattern? Or is there a better way to create the tiles that's better for this?
Instead of a solid color you can use a TexturePaint, as shown here. Let your model contain a reference to the desired texture for each grid cell. Let your view use a flyweight pattern for rendering, as illustrated here.
Java Beginner.
Hi, I haven't got any much experience with GUI programming. So I'm after some hints on how to tackle this next project. Hopefully I can explain myself well enough.
(source: mobilehomeservicesltd.com)
(see above photo as a reference)
This GUI aspect of my program will be a 2D - Birds-eye-view of a static caravan and veranda/balcony made with basic shapes. So typically the caravan will be represented by a rectangle (just a rectangle, ignore the fill in diagram). Sometimes static caravans have shaped fronts so that would be represented by a polygon as opposed to a rectangle. All in scale dependant on the users input, as all caravans have their individual dimensions.
After the caravan unit is in place I then need to draw another polygon surrounding the caravan representing the balcony/veranda, all to scale. Understand so far?? Good. Here comes the challenge part (for me anyway).
On the polygon representing the balcony I need to be able to draw lines to represent the decking that will be nailed down as a surface (like the diagram above). Now because the caravan could possibly have a shaped front, the decking must follow the shape of the caravan. In other words, if the caravan has an oval or angled front the decking will have to be cut to follow that shaped.
Without boring you all too much with detail. The idea is to let the user decide whether they want the decking fitted in such a way that its running in the same direction as the caravan, or against. Once the user has decided I will then attempt to calculate from the drawing (as it will be to scale) how many full lengths of decking will it take to build this veranda (among various other items).
Now my knowledge is limited on GUI, but I'm up to scratch with panels and drawing lines, rectangles, polygons etc... My original idea was to manually draw the caravan using the g.drawLine method, same with the veranda and then base my calculations on pixel counting to calculate all the various components.
Am I out of my depth attempting this, or is this something relatively easy to program?? Is there a more efficient way of doing this that I should look up before attempting this?
What you want to do is achievable, but its not the simplest of tasks. But don't let that slow you down.
You'll want to get started by understanding how to draw in Swing. Take a look at
Graphics 2D
Custom Painting
You'll also want to be familiar with Swing in general
Creating a GUI with Swing
The basic concept with scaling, is assigning a weight to a pixel. The more distance that a pixel is responsible for, the small your image will become
I don't know exactly how to design a project. It's my first year at my computer science department. I'm still learning a lot of information about Java, such as inheritance, polymorphism, abstract classes, interfaces, and so on. I am really curious about these lectures and I'm willing to learn them well. Actually I've not missed any point in these lectures and I got those very well. But nobody teach me how to desing a project and we are supposed to design a decent Java project at the very end of school.
I and my 3 classmates have decided to make a new game. It is played with only one ball and the ball has changeable two colours. Also two players have the same colour with this ball's colours. When the ball is at one player's colour, this player will be able to move the ball and try to score to another player's goal. These are our idea's basic logic and we can add some new facilities and options for this game. We are so willing to achieve this project. But... although we listen and learn from our lectures, we are really confused about to design this project step-by-step. I've just tried to demonstrate our project's logic. Meanwhile, we are still learning about GUI but we are at the very beginning of GUI. So I want to understand about what kind of ways we have to follow in order to design and make this kind of project. I just want to know about tricks and shortcuts and make the most of our knowledge about class hierachies, abstract classes, superclasses, overriding, etc.(We know everything about this terms but just don't know how to use them to design a project). If you can indicate even a little info about these, I would be so so so happy and able to change my point of view. And it would facilitate our progress. Thank you!
You might want to have a look at this Java Pong Game - it's pretty simple and includes some source code that you can study.
More general advice:
You need some way to display what is happening in the game. Probably the easiest way to display the screen in a very simple game is to use a JPanel and override it's paintComponent() method to draw the game screen correctly (e.g. draw players at the right x,y locations)
You will also need a game loop that should do the following things:
Reads any input from players
Update the positions of the objects in the game
call repaint() on the JPanel so that the screen gets redrawn
Waits a short amount of time using e.g. Thread.sleep(30) to sleep for 30 milliseconds
Loops back to the start of the game loop
I would recommend separating the classes that define the user interface (frames, panels etc.) from classes that define the game logic (players, balls etc.). Ideally the game logic classes shouldn't contain any code that relates to how they are displayed or interacted with.
For a game this simple, you don't actually need many classes. I'd recommend something like:
App - contains the main(...) function which launches the game. At a minimum it should create a JFrame and add a single GamePanel inside it, but you can create other UI elements if you like. You may choose to implement your game loop also in this class - in which case the main method should call this once all the setup has been done.
GamePanel (which extends JPanel) - contains the screen drawing logic, also perhaps detects mouse movement
Game - class that represents the entire state of the game, including the locations of both players and the ball
Player - small class to represent the player, with x,y co-ordinates
Ball - small class to represent the ball, with x,y co-ordinates and dx,dy velocity
GUI isn't really suitable for making a game.
a GUI (Graphical User Intreface, Swing in java) is a set of buttons and other text/image content, as opposed to something you can make a game with: a 3D rendering engine, such as OpenGL (most commonly used on java, be it in a framework or through low level libraries).
You here have a choice:
you can either decide to do a simpler project, for example a console program, but that will run on a GUI, for example a GUI program to move files.
or you can get to learning OpenGL or similar (JOGL for java) and make that game!
(JavaFX also might work, but I don't know much about it)
Now about design.
Generally you want to have a main "looping" class that will output every frame etc.
The main "looping" class should inherit from an interface that allows all other components to get the rendering particle, the time counter etc.
Then you want several components, one for the ball, one for any other physics object (don't forget to make them implement a "physics" interface and add them as "physical object references" in your main class, so that the physics for them are calculated each frame!), one for the background, and one for user input.
You can also add multiple others that will each do a specific action.
Im making a game in Java with a few other people but we are stuck on one part of it, making the collision detection. The game is an RPG and I know how to do the collision detection with the characters using Rectangles, but what I dont know how to do is the collision detection for the maps. What I mean by that is like so the character cant walk over trees or water and that stuff but using rectangles doesnt seem like the best option here.
Well to explain what the game maps are gonna look like, here is an example http://i980.photobucket.com/albums/ae287/gordsmash/7-8.jpg
Now I could use rectangles to get bounds and stop the player from walking over the trees and water but that would take a lot of them.
But is there another easier way to prevent the player from walking over the trees and obstacles besides using Rectangles?
Here's a simple way but it uses more memory and you do the work up front... just create a background collision mask that denotes the permissible areas for characters to walk on in a binary form. You can store that in some sort of compressed bitmap form. The lookup then is very simple and very quick.
Rectangle collision detection seems to make sense; However, alternatively you may also try sphere-sphere collision detection, which can detect collision much quicker. You don't even need a square root for distance computations since you can compare the squared distances to see if the spheres overlap. This is a very fast method, and given the nature of your game could work very well.
ALSO! Assuming you have numerous tiles which you are colliding against, consider some method of spacial partitioning. Let me give you an easy example - subdivide your map into several rectangles (http://www.staff.ncl.ac.uk/qiuhua.liang/Research/Pic_research/mine_grid.jpg) and then depending on which rectangular area your player is currently residing in - check collision only against the tiles which are located within that area.
You may take it a step further - if you have more tiles in any given area than the threshold that you set - subdivide that area further to make more smaller areas within it.
The idea behind such subdivision is called Quadtree, and there is a huge quantity of papers and tutorials on the subject, you'll catch on very quickly.
Please let me know if you have any questions.
There are many solutions to this type of problem, but for what you're doing I believe the best course of action would be to use a tile engine. This would have been commonly used in similar games in the past (think any RPG on the SNES) and it provides you with a quick and easy means of both level/map design and collision detection.
The basic concept of a tile engine is that objects are stored in a 2D array and when your player (or any other moving game entity) attempts to move into a new tile you perform a simple check to see if the object in that tile is passable or not (for instance, if it's grass, the player may move; if it's a treasure chest, the player cannot move). This will greatly simplify checking for collisions (as a naive check of a list of entities will have O(n^2) performance). This picture might give you an idea of what I'm talking about. The lines have been added to illustrate a point, but of course when you're playing the game you don't actively think of everything as being composed of individual 32x32 pixel tiles.
While I don't personally have any experience with tile engines in Java, it looks like Mappy supports Java, and I've heard good things about PulpCore. You're more than welcome to create your own engine, of course, but you have to decide if your effort is better spent reinventing the wheel (but, of course, it will be your wheel then, and that is rather satisfying) or spend your time making a better game.