Car rotation problem in top down

Hahaha, yea my bad!! I totally forgot inserting the image for the car
Here it is if you want it :smiley:
http://img168.imageshack.us/img168/7438/car1e.png

I got it off another board, so no worries about copyrights or anything like that, especially since I’m extremely bad at drawing :slight_smile: 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? :smiley:

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 :P, 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!

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! ;D

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.

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?

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.

I love maxing out efficiency, I’m actually all for it. Thanks for the heads up! :slight_smile:

Just design-wise, I think it could have been simplified. But this is just an opinion. :wink:

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.

Glad to help! ;D

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).

Yes those were my thoughts too when I looked at the code.

Yup, I figured. :slight_smile: Forgive me if I ran a little further with your point.

Oh no it was all good ;D

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 :P.

Think of it in an OO fashion.


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<Entity> 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.

@Eli Delventhal
Wow that is exactly what I was thinking. Hmmmm are you reading my mind or are we somehow psychologically linked? ;D
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 ;D

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.

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!

@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 ;D

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.


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 bullets = new ArrayList(); 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 :slight_smile: and the project is moving along!

Thanks for all the help everyone!

Oh no the shock I was talking about was from seeing other people using the same system we were helping you use :stuck_out_tongue:
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.

[quote=“ra4king,post:55,topic:36326”]
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.


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).

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.

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.

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