[Monosyllabic]

I'm currently working on my first real project with XNA. I've done my share of tutorials, read a few books, researched my topics, and I continue to do more everyday. I'm not a beginner beginner, but I'm still a beginner, learning as I go.

In my quest, I've come across a few GameComponent examples, maybe one or two small mentions of Interfaces, and what I believe is referred to as a State Machine.

GameComponents I mostly get. I'm in the process of refactoring my code for a general sprite manager, and plan on implementing another for menu and screen management. Which brings me to some questions. Is there such a thing as too many game components? Is it better to create several different managers for each different class? Or is it perhaps more efficient to use one general manager for a parent class and all of it's children?

My current sprite manager is aimed at handling all my sprites: enemies, the player, guns... Pretty much everything that uses a sprite. As I'm developing my game, its starting to make more sense to me to group my sprite objects into managers by how they behave and/or during which GameState they are called.

Then I came across some mention of C# interfaces, and from what I understand they're basically a way to group similar methods together. Similar to a game component, but a little more limited and not tied directly into the main Update and Draw loops. I have no experience with these, and clearly need to do some more research on them, but it hasn't been a pressing issue as I've seen maybe one example use them.

I know there's many different ways to approach most every situation in programming, and I understand most times there's no real right answer, it just comes down to preference. I'm just seeking personal thoughts and opinions on these matters. I might be doing it wrong, or missing out on some time saving techniques, who knows. But I'm all for efficiency.

Thanks in advance

[stayscrisp]

*Moved to XNA*

You should get a better discussion going in here

[SMASH]

How I do it is I normally have all the Game Components in the Game1 class and if you need to load a texture through a class you would pass the Content object (which is a ContentManager class) or if you need to see the game time then pass the gameTime object (which is an object of the GameTime object).

Basically in the end I like to have as little as possible in the Game1 class so that that can be used to control the flow of the game. I will rarely load a texture in the Game1 class, ext. I love classes and they'll do it for you if you code it right .

This post has been edited by SMASH: 18 January 2011 - 08:12 AM

[Kilorn]

I hope I'm understanding your question properly, and if not let me know, but generally you'll have 1 manager for each type of component. This means 1 CameraManager, 1 LightManager, 1 GameStateManager, etc. Each manager will be responsible for handling each instance of the particular type of object that they're supposed to handle. Let's say your game has 2 different cameras that can be switched between at any time, let's just use a first person camera and a third person camera for examples. The CameraManager would be responsible for handling both of these cameras.

Here's a link to the Game State Management sample on the App Hub. It contains a ScreenManager that handles the stack of game screens and transitions between the proper screens at the right time:
http://create.msdn.c...tate_management

Let me know if you need any more information, and I can probably provide more examples.

This post has been edited by Kilorn: 18 January 2011 - 08:17 AM

[Fib]

In my first real big game project (it was a basic FPS), I had several manager classes.

GameStateManager, which would just handle changing between different games states.
GameManager, it handled points, player death/respawn, and also the win/lose condition.
SpawnPointManager, it kept a list of spawn point positions, then it had methods to get a random spawn point from the list
StaticObjectManager, it had a list of all the objects that never moved, like trees, boxes, barrels (there were no physics in my game), and would handle all the drawing of these objects.
ModelManager, this had a list of all the other objects that would move, like player models, guns, and would handle all the drawing for those
PowerUpManager, had a list of all the power ups in the game, and would handle the players picking them up and respawning them, and drawing them.

I think that's all of the managers I had.

This post has been edited by Fib: 18 January 2011 - 12:46 PM

[Kilorn]

I'm surprised you didn't have a CameraManager and a LightManager in there, Fib. Good list, though.

[Fib]

Kilorn, on 18 January 2011 - 01:45 PM, said:

I'm surprised you didn't have a CameraManager and a LightManager in there, Fib. Good list, though.

Thanks Kilorn

I should have had a CameraManager, but I handled all of the camera stuff in the player class, since the player technically was the camera. Although now that I look back on it, i should have separated the two.

I just used basic lighting with everything. I've never really done anything advanced with lighting before. I'm still learning though.

[Monosyllabic]

Thanks for the responses guys, its starting to come together a little more. So basically I shouldn't be afraid to add a game component if I find its justified in some way and could possibly make my coding life easier. I have a few different objects interacting in several different ways, but I think if I get some basics in now, I can always re-factor things if I find the need.

My big concern is that I have several different objects interacting in different ways at different times. Think of an RTS.. there's an "attack" round where all your points are earned killing enemies. Then there's a "build" round, where you are repairing a central structure and potentially expanding boundaries using your points. Then there is an "upgrade" round, where you can add new guns (overall stock and type), increase stats (such as gun damage and speed), and purchase skills like an RPG to be used during the attack rounds. From there it cycles back to the attack round, and continues the loop until game over (via death or beating the game).

I think my best bet would be to create classes full of accessors and methods to modify members for all my objects, and focus the components on how to handle said objects during specific game states, with a component to handle all game states.

To touch on the camera subject, I'm focusing on making solely 2D games at the moment, and haven't even looked into cameras. Is it necessary to have one or can I get away with not having one for the time being? I know it would make certain issues easier, but for this particular game I'm working on, the view is always going to be the same overhead angle, no zooming or scrolling or movement of any kind (not yet at least).

[Kilorn]

It's not necessary if you're just doing 2D. There are ways to make the current viewport have the functionality to pan around the world map based on input. There are benefits to using a camera for 2d, but I wouldn't say that it is necessary.

[SixOfEleven]

Yes, you can have too many GameComponents. GameComponents have over head associated with them and making everything a GameComponent is bad form. That can slow down your game. As others have pointed out having manager classes that are GameComponents manage a certain type of resource, sprite, model, music, game state, etc is a very good idea. One GameComponent that didn't make the above list that I always, always, always, use is an Input Manager, or Input Handler GameComponent. There are a couple ways that you can implement an input manager. Two different ones that I use a lot are static properties and methods, and creating a Game Service.

Now, about interfaces, Interfaces are a very interesting part of C#. They are contracts that any class that implements them MUST implement. If a class implements an interface you can reference a variable using the interface and that variable will only have access to the methods and properties in the interface. What that does is hide the inner workings of your class from the end user. You will more than likely always be the end user but it will still be good form to keep the inner workings of your classes from spilling over into other class. It's just good OOP to do that. So basically, you can create an interface for say your input handler like this.

public interface IInput
{
    KeyboardState KeyboardState { get; }
    GamePadState[] GamePadStates { get; }
    bool WasKeyPressed(Keys key);
    bool WasButtonPressed(Buttons button, PlayerIndex playerIndex);
    // etc
}

So, that interface gives you a contract that has to be implemented. It also gives the end user a well defined public interface for dealing with any class that implements the interface. How you implement the methods and properties is entirely up to you.

Now, for your GameComponent you implement that interface and you can add the interface as a Game Services that can be used elsewhere in your game.

// Snip

public class InputHandler : GameComponent, IInupt
{
    private KeyboardState keyState;
    private GamePadState[] padStates;

    public KeyboardState KeyboardState
    {
        get { return keyState; }
    }

    public GamePadState[] GamePadStates
    {
        get { return padStates; }
    }

    // Snip

    public InputHandler(Game game) : base(game)
    {
        game.Services.Add(typeof(IInput), this);
    }

    // Snip
}

So, if you have a component that requires input, like your player, you just retrieve that interface. You can't muck up the class though as you can only access the properties or methods in the interface. It is a good form of keeping side effects from happening.

// Snip

public Player : DrawableGameComponent
{
    // Snip
    IInput inputHandler;

    public Player(Game game) : base(game)
    {
        inputHandler = (IInput)game.Services.GetService(typeof(IInput));
        // Snip
    }

    // Snip
}

Using a game service also insures that there is only ever one instance of your component. That is because XNA enforces it. If you tried to add two IInput services an exception will be thrown.

Not sure how useful all that was. But, just a brief glimpse into it.

*edit*
I find 2D camera great with tile maps. I've implemented some advanced features like zooming, snapping to a position on the map, using transformation matrices for controlling rendering.

This post has been edited by SixOfEleven: 18 January 2011 - 02:08 PM
Reason for edit:: Insperation

[Kilorn]

Or you could just download SixOfEleven's input library called Xin and implement it. I've done that a couple of times.

[Monosyllabic]

Thanks again guys, your ideas and advice are really helping me out here. And SixOfEleven, extra thanks for the tutorials. I found your site through this site before I signed up and am getting ready to follow some of your tutorials.

Thanks again for the help, now I've got some work to do.