Java-Gaming.org Hi !
 Featured games (90) games approved by the League of Dukes Games in Showcase (780) Games in Android Showcase (233) games submitted by our members Games in WIP (856) games currently in development
 News: Read the Java Gaming Resources, or peek at the official Java tutorials
 Home Help Search Login Register
Pages: 1 [2] 3
 ignore  |  Print
 Car rotation problem in top down  (Read 32137 times) 0 Members and 1 Guest are viewing this topic.
dishmoth
 « Reply #30 - Posted 2011-02-24 09:38:42 »

That code looks pretty close to what I'd expect, except - as ra4king says - for the time stuff.

Things would be simpler if you had a 'fixed frame rate' game loop (so deltaTime is the same on every update, and on every machine) rather than a 'variable' one.  But sticking with things as they are, I'd say that the function should look something like:

 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33 `private void move(int deltaTime) {  final double deltaSeconds = (deltaTime / 1000.0); // seconds since last update  currentSpeed *= Math.max(0.0, (1 - friction*deltaSeconds));  if ( Math.abs(currentSpeed) < tinySpeed ) currentSpeed = 0.0;         if (up) {    currentSpeed += acceleration * deltaSeconds;    if (currentSpeed > topspeed) currentSpeed = topspeed;  }  if (down) {    currentSpeed -= acceleration * deltaSeconds;    if (currentSpeed < bottomspeed) currentSpeed = bottomspeed;  }  if (right) {    carAngle += rotationStep * (currentSpeed/topspeed) * deltaSeconds;  }  if (left) {    carAngle -= rotationStep * (currentSpeed/topspeed) * deltaSeconds;  }        double ax = Math.sin(Math.toRadians(carAngle));  double ay = -Math.cos(Math.toRadians(carAngle));  x += ax * currentSpeed * deltaSeconds;  y += ay * currentSpeed * deltaSeconds;}`

You'll need to do some trial-and-error to find sensible values for the different constants.  Start by setting friction to zero until everything else is working.  I don't know if it's necessary to have the car always slow down when turning, but I've omitted that from the code above for simplicity.

Fingers crossed that's the sort of thing you're after.

Simon

deadly72

Junior Devvie

 « Reply #31 - Posted 2011-02-25 06:11:47 »

So I've tried what you've mentioned dishmoth and it seems that with the seconds being used I need outrageous numbers in acceleration to be able to show motion for the car itself. I've reverted to the previous solution using the proportion ra4king proposed and now have motion with variables with are much smaller.  I'm guessing this is due to the fact that in your solution - you base time on seconds; which I very much like and would prefer using.  What I'm trying to do though, is implement something along the line of knowing only the acceleration for example 0-62mph or 0-100kph in 3.5 seconds for example.  So we could say that acceleration = (62-0)/3.5 seconds seeing as the vehicle was at rest.  The problem I seem to face when I try to implement this is beause deltaTime is such a low number, that acceleration must be very high; higher then ~17.71 for us to see adequate motion happening.  Please note that I am using the base game code provided by Gudradain which has included desiredFPS.  I might be totally wrong here, but that might have a huge roll to play in the operation of the move function.  Anyway as I said, I'd very much like to use seconds so I can simulate real car physics with the notion that maybe 1px = 1mph? or 1kph? - still haven't decided on either or, and either or will probably be fine seeing as doing conversions between is a peice of cake
ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #32 - Posted 2011-02-25 07:19:25 »

dishmoth is using seconds to divide the "per second" between the multiple calls to update() every second.
I was using scale to fix any deviation from the regular calls to update() since Thread.sleep() and javax.swing.Timer are not that accurate sometimes.

Ok so acceleration and friction are fully added every second, so you take a fraction of them every call to update();
Let's say that when you press up, you add 1 to acceleration every second and subtract 1 when you press down (you can tweak this by testing).
So you would have:

 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23 `double vx = 1.0;double vy = 0.0;double acceleration = 0.0;double friction = 0.05public void update(int deltaT) {   double deltaSeconds = deltaT/1000.0;      if(up)      acceleration += 1.0*(deltaSeconds);   if(down)      acceleration -= 1.0*(deltaSeconds);   if(right)      carAngle += rotationStep * (vx/topVX) * deltaSeconds;   if(left)      carAngle -= rotationStep * (vx/topVX) * deltaSeconds;      vx = Math.min((vx + (acceleration*deltaSeconds)) * (1-(friction*deltaSeconds)),topVX);   vy = Math.min((vy + (acceleration*deltaSeconds)) * (1-(friction*deltaSeconds)),topVY);      x += Math.sin(Math.toRadians(carAngle))*vx;   y += -Math.cos(Math.toRadians(carAngle))*vy;}`

 Games published by our own members! Check 'em out!
Eli Delventhal

JGO Kernel

Medals: 42
Projects: 11
Exp: 10 years

Game Engineer

 « Reply #33 - Posted 2011-02-25 15:52:12 »

I usually don't bother trying to convert everything into real-world values, and instead just measure everything in pixels per timestep. Therefore my delta becomes a scale of the "ideal" FPS (usually 60), so if we have a higher FPS than that we have a lower delta and vise versa.

Although these days I do almost everything with a fixed frame rate because I think it's a lot easier to avoid mistakes (if you forget multiplying by delta anywhere then you're not in trouble, because there is no delta) and it's a lot better for networked situations and applying physics.

See my work:
OTC Software
dishmoth
 « Reply #34 - Posted 2011-02-25 18:17:45 »

So I've tried what you've mentioned dishmoth and it seems that with the seconds being used I need outrageous numbers in acceleration to be able to show motion for the car itself.
In my example, velocity has units of 'pixels per second', and acceleration has units of 'pixels per second per second'.  It doesn't mean there's a problem if the numbers are very big (or very small), that's just how the units work out.  But use whatever units you're comfortable with.

Quote
Please note that I am using the base game code provided by Gudradain which has included desiredFPS.
Ah, okay, so if that code is working as advertised (I've not tried it, but it looks reasonable) then deltaTime should have roughly the same value every time, and it won't hurt to just ignore it completely.  That simplifies the physics code a lot, and means you can ignore just about everything I've said.

Is your game actually running as you'd expect it to now?  What happened to the choppy rotation?

Simon

deadly72

Junior Devvie

 « Reply #35 - Posted 2011-02-26 06:04:29 »

dishmoth, I have come to an understanding that speed would be calculated in pixels / second since I guess converting to real world would probably cause way more headaches then solutions .  Also I did get kind of carried away by the resulting constant variables being either too high in one way or too low if implemented differently.

As for the game code, deltaTime does have roughly the same value every time, but I still wish to use it to 'perfect' if you wish the current movement.  I'm not one to give up because the problem doesn't necessarily have an easy solution , although sometimes it can be an annoyance .

As far as for how the game is actually running, its still not exactly what I want, since like I said I was considering implementing acceleration in the form of 0-62 for matters sake (pixels/second) in 3.5 seconds, although ra4king has probably given me the solution ie (acceleration += (62/3.5) * deltaSeconds)?

As for choppy rotation, thats still is the case, but I'm starting to get to a point where it will be passable with more trial and error, because as some of you said, that would be the only way to go about it to calculate the rotation angle?

Oh and one last thing. Why do most of you ignore increasing friction while the vehicle is turning? or reducing velocity?
dishmoth
 « Reply #36 - Posted 2011-02-26 07:48:46 »

Oh and one last thing. Why do most of you ignore increasing friction while the vehicle is turning? or reducing velocity?
For simplicity.  It makes sense to get the basic car physics working correctly before adding more complicated effects.

Also, there are lots of different ways that things like friction can be applied (e.g., pjt33's post above) and you're the only person who can decide what 'feels' right for your game.

Simon

ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #37 - Posted 2011-02-26 08:40:21 »

Could you give us your current game code? I want to compile it and run it to better understand the rotation. Plus I work better with the code on hand

deadly72

Junior Devvie

 « Reply #38 - Posted 2011-02-26 17:01:22 »

Could you give us your current game code? I want to compile it and run it to better understand the rotation. Plus I work better with the code on hand

Ya sure, no problem.  I totally understand that, I also work better with code in front of me .

Please do note that it is somewhat messy, and probably not anywhere near professional level code, but I think it is easy to manage and get around.

The source code is here http://rapidshare.com/files/449959015/ShootEm_UP.zip

EDIT: Note that this was built using eclipse, so it might be easier to just add the folder to your workspace and let eclipse handle the rest
ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #39 - Posted 2011-02-26 20:41:07 »

The car wouldn't show up for some reason then, after 30 minutes of rummaging through the code, I found out that you use an image, which was not in the zip file so the getBounds().width and height on the Car would be -1. So I set those to 20 and the game runs fine! I don't see any choppiness in the rotation. I moved the car around while shooting and everything works beautifully and smoothly. With some tweaking you could probably increase friction and acceleration a bit. Also, you need to fix the bounds checking. Other than that I found no other problems. Maybe the choppiness is caused by your computer?

Best of luck!

BTW: Your code is quite complex for my taste. It could have been 20x simpler and with less classes and singletons.

 Games published by our own members! Check 'em out!
deadly72

Junior Devvie

 « Reply #40 - Posted 2011-02-26 23:01:46 »

Hahaha, yea my bad!! I totally forgot inserting the image for the car
Here it is if you want it
I got it off another board, so no worries about copyrights or anything like that, especially since I'm extremely bad at drawing I often opt for the open source root.  Note that I did rotate it 90 degrees counter-clockwise before using it*

And since you've taken the time to rummage through it, might I ask you to take the time to ask what was so complex, and what I would be able to simplify to make it even better?

Oh and one more thing, after having spent an hour just trial and error the rotation seems to have been fixed, apart from the fact that I must reach a certain velocity before you actually notice the rotation, something which I'm asking myself why... I'm guessing it has to do with the multiplication of acceleration, but I think again with a bit of trial and error that should be easily fixable.  I also did notice that the bounds weren't correct when the car was rotating , but it really isn't that much of a problem right now, seeing as I've got bigger fish to fry (IE. If you you were indeed shooting at a different rotation then the original the bullets don't seem to be created at  the right location, something which requires slightly more attention).

Anyway, I'm glad you took the time to look through the code, Thanks!
ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #41 - Posted 2011-02-26 23:17:08 »

You have too many singletons that seem a bit overkill, eg GameManager, CarManager, HudManager, BulletManager, AIManager....

MenuController is also a waste of memory since you're creating a object just to set up a menu when those 16 lines of code could have just been integrated in GameLayout.

MouseController and KeyboardController are fine but they could have been combined into an InputController class or just used Game as the listener.

Of course, these points are mainly about efficiency. When you smooth out most of the kinks, I suggest you take another look at your design.

Good luck!

deadly72

Junior Devvie

 « Reply #42 - Posted 2011-02-28 01:53:00 »

You have too many singletons that seem a bit overkill, eg GameManager, CarManager, HudManager, BulletManager, AIManager....

How can it be overkill when I manage everything separately? I think I can probably get rid of HudManager, but apart from that how do you want me to handler multiple object of type cars or ais, even bullets? GameManager is more of a state manager if you will.

MenuController is also a waste of memory since you're creating a object just to set up a menu when those 16 lines of code could have just been integrated in GameLayout.

True that, I was thinking about what would happen if I would expand the menu though. Wouldn't it be smarter to have a separate object controlling all of the menu?

MouseController and KeyboardController are fine but they could have been combined into an InputController class or just used Game as the listener.

Agreed, I don't know why I actually made two classes there.  Seems much smarter to handle them in one class which handles all input.

Of course, these points are mainly about efficiency. When you smooth out most of the kinks, I suggest you take another look at your design.

I love maxing out efficiency, I'm actually all for it.  Thanks for the heads up!
ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #43 - Posted 2011-02-28 02:26:25 »

You have too many singletons that seem a bit overkill, eg GameManager, CarManager, HudManager, BulletManager, AIManager....

How can it be overkill when I manage everything separately? I think I can probably get rid of HudManager, but apart from that how do you want me to handler multiple object of type cars or ais, even bullets? GameManager is more of a state manager if you will.
Just design-wise, I think it could have been simplified. But this is just an opinion.

MenuController is also a waste of memory since you're creating a object just to set up a menu when those 16 lines of code could have just been integrated in GameLayout.

True that, I was thinking about what would happen if I would expand the menu though. Wouldn't it be smarter to have a separate object controlling all of the menu?
I was thinking instead of an object that creates the menu, you could add a method in GameLayout that creates the menu.
MenuController doesn't really "control" the menu, it just creates it.

Of course, these points are mainly about efficiency. When you smooth out most of the kinks, I suggest you take another look at your design.

I love maxing out efficiency, I'm actually all for it.  Thanks for the heads up!
Glad to help!

Eli Delventhal

JGO Kernel

Medals: 42
Projects: 11
Exp: 10 years

Game Engineer

 « Reply #44 - Posted 2011-02-28 16:20:35 »

Manager classes are the Java equivalent of globals - you should only use them in cases when being object-oriented doesn't make any sense. So for example an InputManager class makes sense because it simply collates a bunch of static (and global) data coming in from some devices into some format the game can use. It doesn't make sense to create an Input object because what's an input anyway? And you're not actually making one, you're just managing data related to input.

However, a Game or GameState class makes sense because they are actual tangible objects that contain data they should know how to affect. You are not managing the game, you are actually holding an instance of a game. Similarly, the game contains a reference to a World, which contains a bunch of Car's, Bullet's, etc. It might make sense to have an AIManager because once again an "AI" isn't really a tangible object so you might have a class to handle all the different AI scripts you can have, but more likely it makes sense to tie each AI to a certain type of Entity like a ScriptedEntity or something like that. Then Car and Bullet can be a subclass of that.

I personally wouldn't describe using managers as a loss of efficiency, I would instead say it's a lack of clarity and safety. You are turning an object-oriented language into a functional programming language with a bunch of globals, which is a huge no-no. When absolutely anybody can get at a variable or data member to change it, bugs are then 50x more difficult to track down. Not to mention that it is no longer possible to visualize the way the game functions in a real-world way (here's my world with a bunch of cars and bullets in it).

See my work:
OTC Software
ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #45 - Posted 2011-02-28 21:58:55 »

I personally wouldn't describe using managers as a loss of efficiency, I would instead say it's a lack of clarity and safety. You are turning an object-oriented language into a functional programming language with a bunch of globals, which is a huge no-no. When absolutely anybody can get at a variable or data member to change it, bugs are then 50x more difficult to track down. Not to mention that it is no longer possible to visualize the way the game functions in a real-world way (here's my world with a bunch of cars and bullets in it).
Yes those were my thoughts too when I looked at the code.

Eli Delventhal

JGO Kernel

Medals: 42
Projects: 11
Exp: 10 years

Game Engineer

 « Reply #46 - Posted 2011-02-28 23:03:36 »

I personally wouldn't describe using managers as a loss of efficiency, I would instead say it's a lack of clarity and safety. You are turning an object-oriented language into a functional programming language with a bunch of globals, which is a huge no-no. When absolutely anybody can get at a variable or data member to change it, bugs are then 50x more difficult to track down. Not to mention that it is no longer possible to visualize the way the game functions in a real-world way (here's my world with a bunch of cars and bullets in it).
Yes those were my thoughts too when I looked at the code.
Yup, I figured. Forgive me if I ran a little further with your point.

See my work:
OTC Software
ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #47 - Posted 2011-02-28 23:10:19 »

I personally wouldn't describe using managers as a loss of efficiency, I would instead say it's a lack of clarity and safety. You are turning an object-oriented language into a functional programming language with a bunch of globals, which is a huge no-no. When absolutely anybody can get at a variable or data member to change it, bugs are then 50x more difficult to track down. Not to mention that it is no longer possible to visualize the way the game functions in a real-world way (here's my world with a bunch of cars and bullets in it).
Yes those were my thoughts too when I looked at the code.
Yup, I figured. Forgive me if I ran a little further with your point.
Oh no it was all good

deadly72

Junior Devvie

 « Reply #48 - Posted 2011-03-01 05:26:09 »

I personally wouldn't describe using managers as a loss of efficiency, I would instead say it's a lack of clarity and safety. You are turning an object-oriented language into a functional programming language with a bunch of globals, which is a huge no-no. When absolutely anybody can get at a variable or data member to change it, bugs are then 50x more difficult to track down. Not to mention that it is no longer possible to visualize the way the game functions in a real-world way (here's my world with a bunch of cars and bullets in it).
Yes those were my thoughts too when I looked at the code.

To be totally honest I understand the point itself, but I don't see any other way to manage ais or cars or anything else for that matter.  The managers themselves don't really have global variables, they just contain reference to their respective 'managed' classes.  I think maybe the problem is because they might be because you think of them as middle men classes?  But if I don't use them, wouldn't spaghetti code be appearing in the game manager for instance? I understand a debugging process can seem lengthy if you use a type of system which has global variables all over the place, but I can't see how that is the case for my code.  I wouldn't mind though understanding how you both came to that conclusion .
Eli Delventhal

JGO Kernel

Medals: 42
Projects: 11
Exp: 10 years

Game Engineer

 « Reply #49 - Posted 2011-03-01 17:03:56 »

I personally wouldn't describe using managers as a loss of efficiency, I would instead say it's a lack of clarity and safety. You are turning an object-oriented language into a functional programming language with a bunch of globals, which is a huge no-no. When absolutely anybody can get at a variable or data member to change it, bugs are then 50x more difficult to track down. Not to mention that it is no longer possible to visualize the way the game functions in a real-world way (here's my world with a bunch of cars and bullets in it).
Yes those were my thoughts too when I looked at the code.

To be totally honest I understand the point itself, but I don't see any other way to manage ais or cars or anything else for that matter.  The managers themselves don't really have global variables, they just contain reference to their respective 'managed' classes.  I think maybe the problem is because they might be because you think of them as middle men classes?  But if I don't use them, wouldn't spaghetti code be appearing in the game manager for instance? I understand a debugging process can seem lengthy if you use a type of system which has global variables all over the place, but I can't see how that is the case for my code.  I wouldn't mind though understanding how you both came to that conclusion .
Think of it in an OO fashion.

 1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  65  66  67  68  69  70  71  72  73  74  75  76  77  78  79  80  81  82  83  84  85 `public class GameModel{    private World world;    private InputHandler inputHandler;    private Player[] players;    //etc.    public void mainLoop(float delta)    {        for (int i = 0; i < players.length; i++)        {            players[i].processInput(inputHandler);            players[i].update(delta);        }        world.update(delta);    }    public void draw()    {        world.draw();    }}public class World{    private Level level; //the level we're in, has tile information, parallax settings, what have you.    private ArrayList entities; //both cars and bullets, and pedestrians, etc.    private Physics physics; //maybe some kind of class that deals with your physics, whatever    //etc.    public void update(float delta)    {        physics.update(delta);        for (entities)        {            entity.update(delta);        }        //blah blah etc    }    public void draw()    {        level.drawBackground();        entities.each().draw();        level.drawForeground();    }}public abstract class Entity{    protected float xPos, yPos, width, height, etc;    public abstract void update(float delta);    public abstract void draw();}public class Car extends Entity{    public void update(float delta)    {        xPos += velocityX * delta;        yPos += velocityY * delta;        applyTurningTorque(delta);        doBrakesMagic(delta);        getInAnAccident(delta);    }    public void draw()    {        drawImage("car.png", xPos, yPos, width, height, rotation);    }}public class Bullet extends Entity{    public void update(float delta)    {        xPos += velocityX * delta; //pretend we only travel along the X axis        tryToMurderSomeone(delta);    }    public void draw()    {        drawImage("bullet.png", xPos, yPos, width, height, rotation);    }}`

Make sense? Obviously a lot of that is not real code.

See my work:
OTC Software
ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #50 - Posted 2011-03-01 21:55:52 »

@Eli Delventhal
Wow that is exactly what I was thinking. Hmmmm are you reading my mind or are we somehow psychologically linked?
Or does OOP make us all think alike? (<-- scary thought)

@deadly72
What annoyed me about your code was, just like Eli said, that it was not really object-oriented. My way would have been to have an abstract superclass GameObject (or Entity, like Eli) which Car, Bullet, and AI or Enemy extend. Then have a GameWorld class that holds all the game objects and has an update() method that loops through all the GameObject's update(). Your Game class will be the one to initialize everything and hold the main game loop that calls GameWorld's update() then repaint()'s everything.

So basically, almost just like Eli said

Eli Delventhal

JGO Kernel

Medals: 42
Projects: 11
Exp: 10 years

Game Engineer

 « Reply #51 - Posted 2011-03-01 23:39:00 »

Yeah, it's a pretty common way of designing games, I've seen it or similar ways done in a lot of places.

I have also seen people using managers for everything several times, but this has always been people who are relatively new to game programming.

See my work:
OTC Software
ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #52 - Posted 2011-03-01 23:51:42 »

What's weird is that the design that I just described, I thought it up by myself! I use it for almost all of my games that would benefit from it.
I was shocked to see it in other people's code when I first joined JGO.

So the idea that OOP makes us all think alike is quite true!

deadly72

Junior Devvie

 « Reply #53 - Posted 2011-03-04 23:35:53 »

@Eli Delventhal
Thanks for the pseudo code, that really did clear up things, I guess my problem wasn't breaking things into their simplest forms!  It will really clear out a lot of 'garbage' my code clearly contains, but hey we all got to go through it once at least I'd think we do .  Now the thing is trying to get that class as complete as possible so that when I extend it I'll be sure not to miss out on anything

Actually referring to your way, how would you handle collections? For example the managers used to handle collections of their respective classes, so when using an entity do you just handle collections within thier own classes or do they relate to the entity in any way?

Heres an example of what I mean -- this was the old way.
 1  2  3  4  5  6  7 `public void mousePressed(int mouseX, int mouseY) {   if (ammo > 0) {           BulletManager.addBullet(new Bullet(constructorParameters));           BulletManager.addBullet(new Bullet(diffConstructorParameters));      ammo -= 1;   }}`

This added 2 bullets to the collection inside my bullet manager.  So how would we add collections to the entity? ArrayList<Entity> bullets = new ArrayList<Entity>(); and when I want to add a bullet bullets.add(new Bullet); ?  The problem with that is because should my car class really hold a collection of bullets? I really don't know I'm just spewing ideas.

@ra4king
Like I mentioned, Eli's pseudo code really cleared that up for me and extending one main class really is the smart way to go.  I really don't know what I was thinking with all those managers... I really feel ashamed for having went through a thought process like that .  And on a side note, I hope my code wasn't too big of a shock when you saw it!  I know some places were probably totally weird, problem being I started out with a class called person, and then just renamed that to car, which was why you saw some calls to like getPerson instead of getCar, but thats fixed now and the project is moving along!

Thanks for all the help everyone!
ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #54 - Posted 2011-03-05 06:24:00 »

Oh no the shock I was talking about was from seeing other people using the same system we were helping you use
When I first started game programming, I thought up of this system by myself and didn't know if this idea was already popular.

But regarding your question about your bullets, you don't really need a central bullet manager. You just add the bullets to the world and your person class holds the number of bullets they have.

Eli Delventhal

JGO Kernel

Medals: 42
Projects: 11
Exp: 10 years

Game Engineer

 « Reply #55 - Posted 2011-03-05 12:15:08 »

But regarding your question about your bullets, you don't really need a central bullet manager. You just add the bullets to the world and your person class holds the number of bullets they have.
Yes exactly. If you really want to have a separate list for bullets and cars (IMO the wrong way to go, typically you just have a single list of Entities), then just have both those lists in the World. Think of it conceptually again. Does it make sense for each car to contain a bunch of cars? Definitely not. Maybe if you've got a shotgun shell you could have a bullet containing a bunch of bullets, but more likely once it explodes it spawns more bullets within the World - there is no need to know about every single little shell before that point.

The Game/World would also handle making new bullets.

 1  2  3  4  5  6  7  8 `public class Game{    //Probably called from your InputManager or something    public void mousePressed(int x, int y)    {        world.addEntity(new Bullet(x,y,foo));    }}`

A good way to think about all this is Model-View-Controller. Although I definitely don't keep to that strictly when I make games, it can help to conceptualize. The World is your model because it contains the data state of everything (it has all entities, the blocks you can collide with, etc.). The World itself doesn't know how to do anything, it just manages its state and will update it when told. The Game class is the controller - it tells the World when to update, add new entities, move the player object around, etc. We haven't really talked about the view, but that would be what handles the rendering (so with Java2D that's your Canvas or whatever).

See my work:
OTC Software
deadly72

Junior Devvie

 « Reply #56 - Posted 2011-03-05 20:53:40 »

Alright I guess I've figured out that my problem is handling situations by incorrectly conceptualizing them if that makes any sense.

When I look at what you tell me about game and world, I think to myself, that means game contains the main loop.  No problem there.  The problem comes when handling inputs.  I use an InputController class and thats where all the actions occur.  Should I have an InputController variable inside the game class?  Does this variable use get calls inside the main loop to initialize the world, which the initializes all entities?  I'll be honest and say that I agreed that changing everything to using an abstract interface is the smart thing to do, but with it comes problems because of how my original thought pattern was placed out.

For example Old way was: GameLayout -> InputController (press new game: static call to GameManager.startGame()) -> initialized a thread of the Game class which was handled through GameManager.

Now with the new way: GameLayout -> InputController -> what's next? I say this because the new way doesn't use GameManager correct?  I think like this because of the snippet of code you posted.  How am I supposed to call mousePressed in the Game class without using a static method? (If that is the way you have to do it, then that means my world variable would be static, and I thought the point of this way to avoid having static references all over the place)

I know it might seem unclear, so if it is please point out how I could bring some light on the matter so it can be fixed.

Thanks a bunch.
ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #57 - Posted 2011-03-05 22:56:27 »

InputController should be a private inner class of Game so it can use Game's instance variables and methods.

Eli Delventhal

JGO Kernel

Medals: 42
Projects: 11
Exp: 10 years

Game Engineer

 « Reply #58 - Posted 2011-03-05 23:12:19 »

InputController should be a private inner class of Game so it can use Game's instance variables and methods.
Yeah, anything like this.

I typically have InputHandler contain a reference to Game, then Game has a bunch of methods to handle things the InputHandler gives it.

See my work:
OTC Software
ra4king

JGO Kernel

Medals: 508
Projects: 3
Exp: 5 years

I'm the King!

 « Reply #59 - Posted 2011-03-05 23:14:10 »

Anything as long as the InputController has a way of accessing the Game and World in a non-static way.

Pages: 1 [2] 3
 ignore  |  Print

 hadezbladez (712 views) 2018-11-16 13:46:03 hadezbladez (355 views) 2018-11-16 13:41:33 hadezbladez (699 views) 2018-11-16 13:35:35 hadezbladez (175 views) 2018-11-16 13:32:03 EgonOlsen (2368 views) 2018-06-10 19:43:48 EgonOlsen (2502 views) 2018-06-10 19:43:44 EgonOlsen (1465 views) 2018-06-10 19:43:20 DesertCoockie (2131 views) 2018-05-13 18:23:11 nelsongames (1927 views) 2018-04-24 18:15:36 nelsongames (2600 views) 2018-04-24 18:14:32
 Deployment and Packagingby mudlee2018-08-22 18:09:50Java Gaming Resourcesby gouessej2018-08-22 08:19:41Deployment and Packagingby gouessej2018-08-22 08:04:08Deployment and Packagingby gouessej2018-08-22 08:03:45Deployment and Packagingby philfrei2018-08-20 02:33:38Deployment and Packagingby philfrei2018-08-20 02:29:55Deployment and Packagingby philfrei2018-08-19 23:56:20Deployment and Packagingby philfrei2018-08-19 23:54:46
 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