game programming: managing time and OOP

Hello!

I'm amateur who has been learning C programming for a couple of years and has recently moved to C#. I have been doing some reading on basic OOP concepts and I would like to program a very simple 2D game. I'm not using XNA, just the basic C# library and Windows Forms.

My question is: how should I manage the time? I know the "idea" behind a game loop, but how can I synchronize it so that my objects for instance will move at a determined speed? Which classes should I study to manage this? How difficulty is it?

Also, as a begginer in OOP, please tell me if this kind of design is adequate or if there are better objects.

At the beggining of the application, I create a List of objects:

Code:

---

List<Enemy> EnemyList = new List<Enemy>();

EnemyList.Add(enemyType, Xpos, Ypos); // pseudocode actually
EnemyList.Add(enemyType, Xpos, Ypos);
EnemyList.Add(enemyType, Xpos, Ypos);

---

And this how I'm thinking of handling it in the main loop:

Code:

---

foreach (Enemy t in EnemyList)
{
    Enemy.Move();
    Enemy.CheckCollision();
}

---

Is that OK? I just recently found about the List keyword (I guess that's some sort of simpler double-linked list no?) and to me it looks like an approach that could work.

Event based Windows forms aren't very well suited for games. Is there a reason you don't use xna?
Whatever you do, each time you update, you need to know the time since your last update.

For updates, you should check all movements first, and then all collisions. That is,

Code:

---

foreach (Enemy t in EnemyList)
{
    Enemy.Move();
}

foreach (Enemy t in EnemyList)
{
    Enemy.CheckCollision();
}

---

Here is why your way is wrong: Imagine object a moves to a point, checks for collisions and determines that it's not colliding with anything. Then object b moves to the same point, checks and sees that it's colliding with object a. Clearly this is wrong because if a collision occurs, all object involved need to handle it in the appropriate manner.

In .Net, a List<> is not a linked list, but more like an array (bad name, I agree). If you want a linked list, try System.Collections.Generic.LinkedList<>

Quote:

---

Originally Posted by NeonBlack

Event based Windows forms aren't very well suited for games. Is there a reason you don't use xna?
Whatever you do, each time you update, you need to know the time since your last update.

---

I'm not using XNA because my program will be very simple (an educational MIDI-input based game) and I don't want to have to learn too many things at the same time. If I can get the concept to work then perhaps someday I may apply that knowledge on a more complex framework, right now System.Drawing seems to have all I need.

Can you give a simple example how can I measure the time between updates (what classes and functions) ?

And thanks for catching the problem in the loop. Enemy.collision() is still dummy, I haven't wrote the function yet, but you just saved me some time finding a bug :).

I'm not trying to steer you away from using winforms, but it's probably going to be a lot easier to do some simple 2d drawing in xna than it would be to set up a proper game loop in winforms (honestly, I'm not really a Windows programmer, and I'd have no clue how to do this).

If you only need a few frames per second, then the easiest thing to do would be to add a timer control to your form and do updates on the tick event.

Check out System.Timers.Timer.

check this out man...
Game Programming Tutorials – Game Physics – Fix your Timestep!

Thanks for the input, I think I get the main idea behind timing events.

I also searched some articles on XNA and perhaps it may be even simpler to use it for my project, since it seems to handle timing in a very high-level way and easy way.

Quote:

---

since it seems to handle timing in a very high-level way and easy way

---

It isn't about how each one handles timing. It is about the design of WinForms. Controls and forms are normally sitting there doing nothing waiting for user input. Games rarely sit and do nothing since they are real-time.

Quote:

---

Originally Posted by Bubba

It isn't about how each one handles timing. It is about the design of WinForms. Controls and forms are normally sitting there doing nothing waiting for user input. Games rarely sit and do nothing since they are real-time.

---

I disagree on the "doing nothing" part since a Windows form its also a real-time loop (just not as visible as when working in a lower level with the WinAPI). But I get what you are saying, there are sure some additional problems using it for this purpose.

Anyway, I downloaded the XNA and after reading some tutorials I think it'll ease my work-load on a number of things, plus it's fun to learn.

Thanks for the replies.

Quote:

---

Originally Posted by papagaio

I disagree on the "doing nothing" part since a Windows form its also a real-time loop

---

That loop is the Event Selection loop and isn't normally exposed by the framework, meaning you can't -- or shouldn't -- have access to it. Winforms is an event-driven framework, for which reason the inner application loop (the event selection loop) isn't abstracted. Only events and event handlers are abstracted.

For this reason, from the perspective of event-drive programming, an application waiting for a framework event is indeed said to be doing nothing. Which, by virtue of there being no access to the event selection loop, is a perfectly accurate statement.

Now, one of the framework events is the Timer event. This event abstracts a loop. It's the fact that you have this abstraction and that you can access it, that you can they say, from the perspective of event handling programming, the application isn't sitting still; it is running a loop. But only when you use this event. When the application is sitting on the Event Selection loop, it is for all purposes -- for all that matters to event-driven programming -- doing absolutely nothing.

I'm pretty sure that's what Bubba meant. At least i can assure you you would hear the exact same comment from me, because for any event-driven programmer, the Event Selection loop isn't known to us and we don't care about it.

And just to clarify, it is exactly because event-driven programming abstracts away the Event Selection loop (and the nature of the events themselves as NeonBlack explained on post #2), that this isn't a good programming paradigm to develop real-time applications. You do well moving to XNA, considering your game requirements.

Write a game loop and you will soon find out just how much goes on in the span of 1 frame. Until you do that you will not be able to relate to what we are saying.

Quote:

---

Write a game loop and you will soon find out just how much goes on in the span of 1 frame.

---

Oh and how.. ! ;->

Event driven programming to create a dynamic 2d game like a space shootem up or something is like trying to fit a square peg into a round hole! You will find yourself writing artifices and mangled methods to try and keep things 'moving'.
Having said that i think it is fine for tetris style games and puzzle / board game stuff due to their relatively static gameplay.