As it stands, I have a map with roads on it and vehicles are able to drive back and forth from south to north and east to west (and opposite ways as well). I have used JPanels thus far to represent the vehicles. However now it's becoming a bit difficult to handle because I want to turn the vehicles at junctions and smooth lane changing etc.
So it doesn't seem like JPanel is the optimal choice for this. What I've tried so far is to use the Shape interface to draw polygons and use these as vehicles, however I'm not sure that this is the right choice.
I will eventually want to construct my own vehicle image so the solution will have to either be able to add the image as it's background or something similar and still be able to perform operations such as rotation, transformation etc.
Any guidance on this will be much appreciated.
Personally, using JPanel isn't a bad choice, what you need to be able to do is extend it's capabilities to allow you to paint changes in orientation of the vehicle as it turns.
This is going to require some animation - you going to want to know how long it would take a vehicle to complete a turn so you can calculate the angel of the vehicle over time.
For this, I would be using AffineTransformation, check here for some examples.
You will also need to change the size of the component as the vehicle turns, check here for the answer.
Lane changes would be a similar (if easier) concept. The basic idea would be to have a start position and end position of the translation and move to that position over time. Again, you would need to know the amount of time it would take to complete the translation.
Related
I'm working on a simple game with libGDX and want to make the main character to be fixed in the center of the screen and the world move when I press a button. I was wondering how to do... I was thinking to add a physicsBody to the world that contains other bodies and apply impulses to it when the button is pressed, is this possible in libGDX? And if it is, can i apply other impulses or forces to the bodies contained in the world's physicsBody? I think this way would be the best for me if it is possible, because i have to work a lot with physics, but if you have other ideas tell me please
There's no need to think about applying forces to all the non-character objects, that's just going to get messy very quickly.
The simple solution is to move your camera so that it always looks at your character. So your game loop may look something like:-
Process input
Update physics, character and other entity positions.
Move camera to point at character's new position.
Render
This way, you can update your game world without having to think about the camera at all. Then, when it comes to rendering, you can position your camera and render your graphics without needing to know anything about the game physics. It keeps the physics and rendering relatively independent, and makes it much easier to change things in the future.
For example, you may later decide that you want the camera to follow your character for the most part, but then follow a baddy whilst it is their turn. This is now easy to do, you just specify the character / entity to look at in your game logic, and then position the camera to look at whatever target that is, before you render.
Basicly, I want to make a game of chess.
The idea is that I have a picture of a chessboard and the individual chess pieces. What I could get to work is a JPanel where I would repaint everything everytime with the new positions of the chess pieces, but this would require to get the positions of all chess pieces and repaint the board with up to 33 pictures, with double buffering and all.
A bit resource consuming I think. AFAIK, there is the option to only repaint a certain area, but I guess there're still better ways. What I could imagine is, just moving or removing one or two pictures or rather chess pieces each time rather than repainting something.
I sadly have only very limited knowledge of the classes out there and so I ask if there is such a way or even an entirely different one, that does the job more efficient than painting/repainting.
Instead of inventing the wheel again, use a game engine with sprite support like JGame to do the rendering.
Also note that today, the resource consumption to render chess is so small that spending a minute to optimize it is a minute wasted. What you should aim for is a framework which takes the least time to implement the rendering of the game so you don't have to spend too much time on this part of the game.
If you feel a game engine to be overkill, how about using a table with a custom cell renderer which draws each cell? The table will make sure that updates are rendered in an optimal way. You might even be able to use a custom TableModel to define the playing field.
I'm currently working on my 2D game project (Java), but so far any kind of game logic or AI has been crudely implemented. For instance, say I need to randomly position a bunch of sprites a long the top of the screen, I'd be using the Random class to do this. I'd simply use Random.nextInt( size of x axis on which to spawn ); Although this does work I'd be interested to hear how I should really be going about this kind of thing.
As a second scenario (this is why I put AI in the title, although it's not really AI), say I want to have my characters randomly blink in a life-like fashion. What I'd do here is use the Random class to calculate a % (say 20% chance) of blinking and call it every second.
Any suggestions on how I should really be going about this would be greatly appreciated.
Google for a paper titled "Steering Behaviors" by Craig Reynolds. It address just this and you'll find great ideas to start with specifically some nice ideas for giving groups of sprites the appearance of 'intelligent' movement. The key for him in his different behaviors, i.e. flocking, etc. is making properties of any given sprite dependent on those of some other sprite. You could even go so far as to say, like -- any given sprite will blink only if it's two neighbors just have blinked. Something or other along those lines.
Hope this helps!
Are you using an OOP (Object-Oriented approach)? If not, you should definitely look into it. It's really simple with java and can speed up your development time and neaten your code.
I would make a sprite class, and give them a function, say actionSpawn, or actionMove (I like to start my "action" functions with the word action so they are easily identifiable). In this function you would encapsulate the Random.nextInt function, to set the sprite's x and/or y position.
You could use the same approach to make them blink.
I have a simple game that uses a 3D grid representation, something like:
Blocks grid[10][10][10];
The person in the game is represented by a point and a sight vector:
double x,y,z, dx,dy,dz;
I draw the grid with 3 nested for loops:
for(...) for(...) for(...)
draw(grid[i][j][k]);
The obvious problem with this is when the size of the grid grows within the hundreds, fps drop dramatically. With some intuition, I realized that:
Blocks that were hidden by other blocks in the grid don't need to be rendered
Blocks that were not within the person's vision field also don't need to be rendered (ie. blocks that were behind the person)
My question is, given a grid[][][], a person's x,y,z, and a sight vector dx,dy,dz, how could I figure out which blocks need to be rendered and which don't?
I looked into using JMonkeyEngine, a 3D game engine, a while back and looked at some of the techniques they employ. From what I remember, they use something called culling. They build a tree structure of everything that exists in the 'world'. The idea then is that you have a subset of this tree that represents the visible objects at any given time. In other words, these are the things that need to be rendered. So, say for example that I have a room with objects in the room. The room is on the tree and the objects in the room are children of the tree. If I am outside of the room, then I prune (remove) this branch of the tree which then means I don't render it. The reason this works so well is that I don't have to evaluate EVERY object in the world to see if it should be rendered, but instead I quickly prune whole portions of the world that I know shouldn't be rendered.
Even better, then when I step inside the room, I trim the entire rest of the world from the tree and then only render the room and all its descendants.
I think a lot of the design decisions that the JMonkeyEngine team made were based on things in David Eberly's book, 3D Game Engine Design. I don't know the technical details of how to implement an approach like this, but I bet this book would be a great starting point for you.
Here is an interesting article on some different culling algorithms:
View Frustum Culling
Back-face Culling
Cell-based occlusion culling
PVS-based arbitrary geometry occlusion culling
Others
First you need a spatial partitioning structure, if you are using uniform block sizes, probably the most effective structure will be an octree. Then you will need to write an algorithm that can calculate if a box is on a particular side of (or intersecting) a plane. Once you have that you can work out which leaf nodes of the octree are inside the six sides of your view frustum - that's view culling. Also using the octree you can determine which blocks occlude others (sometimes called frustum masking), but get the first part working first.
It sounds like you're going for a minecraft-y type thing.
Take a look at this android minecraft level renderer.
The points to note are:
You only have to draw the faces of blocks that are shared with transparent blocks. e.g.: don't bother drawing the faces between two opaque blocks - the player will never see them.
You'll probably want to batch up your visible block geometry into chunklets (and stick it into a VBO) and determine visibility on a per-chunklet basis. Finding exactly which blocks can be seen will probably take longer than just flinging the VBO at the gpu and accepting the overdraw.
A flood-fill works pretty well to determine which chunklets are visible - limit the fill using the view frustum, view direction (if you're facing in the +ve x direction, don't flood in the -ve direction), and simple analyses of chunklet data (e.g.: if an entire face of a chunklet is opaque, don't flood through that face)
I need to make a text-based RPG game with java. The first part of the assignment is super simple. we just use vertical lines and underscores to make a little rectangle and then add symbols inside the rectangle as things move, act, die, etc.
I've never done this before, so I want to run my idea by you:
What do you think about doing something like angry birds but with flying moving targets? There would be a little "bird tank" at the bottom left of the screen that would shoot birds. Another question: I'm not entirely sure how I would create a gun that shoots at different angles in a text-based format. And how would it work with aiming and shooting and timing, and such?
Update:
I think I'm going to try out a tank game. But I'm confused about how to implemenent the angle of the turret.
I would put the tank in the bottom left corner, put I only have text symbols at my disposal. I don't see how its possible to let the user control the turret, and make it move up and down by small amounts (at least, not until we start using images/gui's.)
Any ideas?
First, in order to make your idea meet the criteria of an RPG, you would have to add a few components. Your gun would need to gain experience as you hit your targets, and would have to level up after enough time. It could gain better speed or accuracy. It could also earn upgrade points that you could spend on different birds to shoot. It would probably also be cool if your targets had hit points and you had to hit some of them multiple times to kill them. You could show the damage by changing the color of the text. These elements will give it more of an RPG feel so that you can meet the criteria of the assignment.
As for the mechanics of the game, you're going to have to write some sort of physics engine. It doesn't have to be very complicated, just enough to be able to calculate or modify a trajectory and determine if there was a collision. This engine would have some sort of a tick() method on it where it would advance the positions of the birds and targets and then you could call a getCollisions() method and handle each one. That's the simple way. The more complex way would involve giving the engine its own thread where it runs constantly, as fast as it can. Then, when there is a collision, it fires off an event to a listener, and you set up some sort of handler to apply the damage to the target, award points, etc.
I would recommend you model the world in finer resolution than your text console. Make the text console simply mark the birds and targets by rounding them to the nearest 80x25 console location, but internally use a much higher resolution. This will keep it looking more realistic, even in an environment with such a poor resolution.
For the controls of the game, I would recommend putting a target reticule on the screen. The user can move it around with their arrow keys to aim and press the space bar to shoot. They wouldn't hit the target because gravity should pull the bird downward, or perhaps because the bird is a special shot that splits into pieces. Regardless, they would learn how to lead their targets appropriately, and that would be the skill of the game.
It's a complicated project. Good luck!