java race game

Java 2D
#21

the problem is we had to choose a game and we can’t change it anymore.

so we’ll try to do what we can to have a game.

I have to make the applet and I hope at least to succeed to move the car in the applet. With your help I could start but I guess I am missing something. If my velocity is 1 the car stays always on the same point and when I rotate my car is jumping and not driving.

I have a Car with attributes x, y, dx, dy, vel and angle.

in the applet I change the velocity when I move up: car.setVel(1); but when I rotate then my car is jumping so I guess I am wrong again. Math is not really my best part.

#22

[quote] I guess I am missing something. If my velocity is 1 the car stays always on the same point and when I rotate my car is jumping and not driving.

I have a Car with attributes x, y, dx, dy, vel and angle.

in the applet I change the velocity when I move up: car.setVel(1); but when I rotate then my car is jumping so I guess I am wrong again. Math is not really my best part.
[/quote]
Remember that a “rotation” has to be take place about a point…by default, J2D rotates about the origin (0,0). If you haven’t moved the origin (using graphics.translate(x,y)), then it’ll be the top-left corner of your GUI.

You probably want to rotate about the centre of the car when turning the car (for a more impressive effect, you could rotate about a point between the front-two wheels, making it look like the car “swings” around each corner - try it and see!). There is an alternative version of the rotate method that lets you specify the x and y of the point to rotate about.

#23

the rotation is in the middle of my car. When I steer left or right without anything else the angle and the position of the car are correct but it is when I use dx and dy that the car jumps when I rotate the car.

#24

ok, how about a SpaceShip racing game :smiley:

does it realy have to involve cars? ::slight_smile:

#25

maybe we could try a race with something else but what is the difference then?

#26

modelling car physics is NOT easy ::slight_smile:

Modelling any non-trivial real object is always hard.

Modelling things that don’t exist is much ezier, cos you can make up the handling characteristics as you go along :smiley:

#27

For the XML stuff I can whole heartedly recommend JDOM. It’s worked like a charm for me.

I’m with Abuse on this one. With real life you have stuff like friction, wind resistance (a.k.a. wind friction), center’s of gravity, the track altering the physics as we all know grass behaves differently than dirt which is different than pavement, etc. The list goes on and on.

Although unless you handed in a design doc specifically stating you’ll be implementing all that, I’d just assume fixed car weight, fixed road friction, make all terrain pavement, have no weather and a bunch of other simplifications. At that point you can make your racing game almost like that space game. Only problem is that it’ll feel floaty and very unrealistic. But hey, it’s your interpretation, right? Who says it’s got to be Gran Turismo on the first go?

#28

P.S. I’d cheat on the map vs. avatar collision if I were you. First, I’d have the course be on infinite pavement and the track be simple bounding lines drawn on the pavement. That way you can just have the car “correct” it’s course if it gets to the track edge. Cheating yes, but since this doesn’t sound like this needs to be super advanced I’m go that way. You can always add features later.

#29

If you want a really simple physics engine for a racing game, I wrote a game a while ago. 2d overhead graphics, and the “cars” handle like hovercraft. It is also networked, but the code is a bit shonky (ie won’t work over anything but a LAN).

http://website.lineone.net/~john.montgomery/RacingGame/

Got some notes on how it works too.
You are more than welcome to look at the source, but I wouldn’t recomend copying it, as it’s a bit hacked.

cheers,
John

#30

wow, didn’t expect so much replies :o
Anyway thx for tips. Meanwhile we have been able to make an applet that lets a car move over a certain field. The problem is now the collisions. How should we let the car folow a a circuit. Is there something like pixel recognition, pixelgrabber ? eg. the car should drive normal on tarmac ( grey) and should slow down or stop on gras, mud …
what do you guys suggest ?

grz,

varistor

#31

You could use BufferedImage.getRGB(int x, int y) to get the color of a certain pixel in a BufferedImage, but then you’ll make everything depending on the color of the background. It could be a quick, simple and dirty solution, but it depends on how you plan to create your tracks and IMHO it won’t be a good solution if you want your game to look good and be flexible.

You might want to make the background tiled (made up of small square images) so you have to check which tile your car is on to decide how to behave instead of checking for pixel colors.

I’m sure a couple of folks will jump in here now to plug their tile based libraries. :slight_smile:

Erik

#32

Check out my response here:

http://www.JavaGaming.org/cgi-bin/JGOForums/YaBB.cgi?board=2D;action=display;num=1052919932;start=5

Not sure if that’s what you need, but it would work.

#33

[quote]wow, didn’t expect so much replies :o
Anyway thx for tips. Meanwhile we have been able to make an applet that lets a car move over a certain field. The problem is now the collisions. How should we let the car folow a a circuit. Is there something like pixel recognition, pixelgrabber ? eg. the car should drive normal on tarmac ( grey) and should slow down or stop on gras, mud …
what do you guys suggest ?
[/quote]
You will pretty much end up having two maps - the “visual” one which you draw to the screen and the “virtual” one, which just differentiates between different terrains. This way, the visual one can be really pretty - even texture-mapped - and the virtual one is just for collision detection etc.

If I interpreted the GAGE posts correctly, it uses a virtual map made of 16x16 pixel squares? EDIT: I stand corrected - it can use arbitrary precision (which is obviously a very good thing, and shows how you can get better features out of a purpose-built API like GAGE rather than a generic one like J2D)

Personally, for the virtual map I’d use Java2D Shapes and Areas to define the different parts of your map (e.g. one Area for “tarmac” a different Area for each separate chunk of grass, etc). This gives you arbitrarily fine detail, and it’s easy to use, built in to the standard libraries, and works. (I’m not suggesting you DON’T use GAGE or etc, just that personally I’d do it that way since I already know j2d, and have never used GAGE before).

Then you create a rectangle to represent each of your cars, and use the intersects() tests you were originally attempting to use :).

#34

If I interpreted the GAGE posts correctly, it uses a virtual map made of 16x16 pixel squares?

Err, no. The idea is that the collision map can be as fine as you need it, right down to the pixel level. You’d tend to use a larger collision map for something like Pac-Man, where you have relatively large tiles. Also, the CollisionMap is a standalone piece of code I haven’t yet folded into GAGE. It doesn’t have any dependencies.

Given a collision map, the drag formula is:

distance += speed - getCollision(x, y)

In that case, zero would be road, while non-zero would introduce drag (e.g. 1 for grass, 2 for sand, etc). When collision value == speed, you’ll hit a wall. When collision value > speed, you’ll bounce off (like a tire-bumper wall).

#35

Thank you very much everybody for your help.

We had to show our project today, it was really basic but it was a carGame.

the communication didn’t work but they sai too that communication between two cars is not so basic.

One week before we had to finish it we were almost hopeless but with the goed hints we had a basicgame.

When I have more time I’ll try to improve it and matbe I’ll start with something easier :).

See you later