GameComponent vs custom class

Just wondering on peoples view on GameComponent and DrawableGameComponent,

Is it any advantage to using them over your own class that has its own Update or Draw methods?

I think I read that GameComponents have their update called automatically with Game.Update and same with Drawable and Draw. Also that you can toggle GameComponents to on/off for the update/draw.

If you go for your own class, do you have to explicitly be calling Update somewhere?

Is their a collection that GameComponents are automatically added to that are constantly being called update on?

This discussion seems to be an endless talks, as seen there, and for a good example, there is Ioannis Panagopoulos’s blog
In the gamedev stackexchange talks, the guy named Andrew Russel try hard to justify using components are bad, but he miserably failed as he doesn’t gives any good fact to backup any of his claims.

So the best way would be to try both, benchmark codes, weight the pros and cons in your very own project and make a choice based on facts you’ve collected.

Of course, in your own custom classes, without any interface implementation or so, the game has no way to know it has o call a method you have named “update” (which could have been named “imlazyanddontwanttocallitmyself” or almost whatever as long as it is a valid C# method name)

You are correct. If you don’t use GameComponent you have to call the object’s update and draw manually from the game’s main class’ update or draw.

I think in the end it comes down to what you think is a more elegant solution for your game.

For example in my game I call, to update a part of a car, like a gun or something

bountyroad.update()->
ScreenManager.updater->
All active game screens (main 3D game or inventory / menu on top) ->
GameLogic.Update() ->
BasicEntity.Update() ->
EntityPart.Update() etc

I could have used the Component structure to make these things Components of each other and that would in the end work the same apart from the fact that I register / deregister everything in an identical fashion.
That may be cleaner, or it may be more complicated, really depends on how you build up the game’s architecture

I second kosmonautgames.

I tend to not use the component system except for stuff that I consider background tasks like input handling. IMO it makes code a bit harder to read using components since update and draw calls are implicit.

I use classes, and offspring classes… Like “Enemy” and “Deathbot : Enemy”, “Tank : Enemy”

Then I add and remove enemies from list active_enemies as enemies enter/exit the game;

Then I run update and draw with a foreach loop on the active_enemies list.

… This way, you dont need if statements like if (enemy.alive == true)… You would just remove them from the active list when they die…

Each enemy can this way also have multiple different draw calls for different situations,
like Draw_in_the_background(), or Draw_in_the_foreground().

-Then in your main draw method you would have

foreach (enemy e in active_background_enemies) {e.Draw_in_the_background() }
foreach (enemy e in active_enemies) {e.Draw() }
foreach (enemy e in active_foreground_enemies) {e.Draw_in_the_foreground() }

just a sidenote for some more experienced guys - foreach is worse in terms of memory than for, right?

It depends on the implementation of the iterator for the collection. For most common iterators it is no problem since the iterator exists on the stack and does not cause any boxing during iteration.

I either poll my game modes or ill register mode classes that either all have a interface or a shared base class to my engine i keep a static primary class for references to all my stuff that will be in used in each that’s usually call Engine. The engine keeps a custom delegate or sets of them that any class can self register too soo i skip components and gamescreens. There is nothing wrong with the game components. Its just that at some point you might need to go beyond them i do a lot of tests and experiments so i need lots of modes and for them to be able to interact or override each other at times ect. So i just create mode classes in game one and register them to my engine then after that i let them register to the engine what they want or disable each other or parts of each other ect. whatever i just try to control everything thru my engine class so its simple and leave my game1 fairly empty. Not really a engine of anything basically a state machine of everything.

foreach can be slower or generate garbage in special cases the general rule of thumb is when in doubt or you dont have time to figure it out the for and while is to err on the side of playing it safe.
with the for loop you can also iterate it backwards.
with while loops you can iterate just conditionally until a goal is achieved.
foreach is nice but it depends what your doing, a calculator it wont matter, but a game.

so “for list.length” is better than “for each in list”?

All answers I found are really old; But I don’t think anything changed in the meantime…

Here is a ‘Skeet’ about that topic over at StackOverflow. The whole discussion is interesting and I second Jon Skeet’s opinion on this.

TL;DR
It depends on the collection you’re iterating. Foreach on Arrays get optimized -> no penalty; Every other type -> penalty for foreach. But the boost probably doesn’t merit the unreadable code.
We certainly use foreach AND List<T> where possible and had no problems with it (in a game that is; If you’re building a high-performance framework that’s another story).

Thanks for all the advice guys,

I am thinking of sticking with my own code, maybe once I get a bit more experienced create some sort of Interface to adhere to, even if its just a light one forcing Update and Draw.

The info about foreach vs for is handy to know.

foreach (var x in y)
{
    ...
}

is expanded by the compiler to

List<T>.Enumerator y_enumerator = y.GetEnumerator();
try
{
    while (y_enumerator.MoveNext())
    {
        var x = y_enumerator.Current;
        ...
    }
}
finally
{
    y_enumerator.Dispose();
}

This is why it depends on the implementation of the enumerator for that type you are iterating through. If you look at the List < T >.Enumerator code, you can see that it does not allocate any memory on the heap. Under normal usage, it is allocated on the stack. It will incur a bit of cost (a copy of the element into the current backing field during the call to MoveNext, a call to Dispose). There are also some benefits. The enumerator will throw an exception if the list was modified during the enumeration. You don’t get that protection if using a regular for loop. So it’s up to you to choose. For most common types, there is no real disadvantage to using them. As always, do your own tests to see which one works better for you.

1 Like

how about pro and cons compare to classic for loop and List.Enumerator?