Game updating

Hi, I am planning to make a old strategy game, in the red alert style. I am planing to use C++, pure Win32API and OpenGL(though maybe even allegro or SDL would be enough, i wont learn those when OpenGL can do the same).

I havent developed a game which is this big before, and I am wondering: Where should I update the world database
(Like what is happening, where is all the units placed, shall there be a hole in the ground after a certain explosion, update the infantry-troops positions since they are moving, etc..)?

Should I update it in the WinMain?
Or in WM_TIMER messages?

The answer is probably in WinMain, but that means I have to some time-management. So if you mean WM_TIMER isnt good enough, could you get me started, finding a good libary and function set for dealing with accurate, low-value,millisecond management, so I can compute when a update of worlddatabase would be okay or not?

It's common to see the message loop in WinMain ripped apart to look like this:

Code:

---

while(true)
{
  if( PeekMessage() )
  {
        if(WM_QUIT == msg)
            break;

        TranslateMessage();
        DispacthMessage();
  }
  else
  {
        game.Run();
  }
}

---

I forget the params to the message functions off hand, but you get the idea. The game object in this example has the Run function, which captures input, updates the game state (all that stuff you were talking about) then draws to the screen. It wouldn't be a good idea to cram all that into one big function of course, but I hope this gives you an idea on how you would like to set things up.

However, running your game off of windows messages is not a bad idea, in fact some people wouldn't sleep easily at night if they saw the above loop in WinMain. As long as it gets the job done, you're doing it right!

Yes, I know this is a common way of doing it.
BUT:
Lets say, the above function moves the soldiers 1 square on the battlescreen. Then (on mulitplayer), the computer with the quickest computer would be having the fastest units!

Which is why I want to have some usefull functions for getting, and controlling and comparing time. In secounds, miniutes, and most importantly: milliseconds.

What you want is timebased movement. Do a board search, if i remember correctly there was a thread about that just a month or so ago.

One good way I've heard of that will cause everyone to move at the same speed works like this:

Get the fps.
Infantry moves 1 square if the fps is ...60 ( 60 is the 'goal fps' )
infantry moves 2 squares if the fpr is 30
infantry moves .5 square if the fps is 120
infantry moves .1 square if the fps is 600
infantry moves 10 squares if the fps is 6


etc.

So even if someone is going through the loop at a MUCH greater fps, they'll still be moving the same amount.

Quote:

---

Originally Posted by elnerdo

One good way I've heard of that will cause everyone to move at the same speed works like this:

---

Assume you get a lag spike of several seconds, your units will move a huge distance moving through walls n stuff unless you have a very clever movement system.

My personal preference is a discrete set of update intervals. It uses a deadloop but with a sleep-system used in some real-time OS'es. basically, when you have updated the game you sleep *almost* as long as you need until the next update. This relieves the CPU a bit.

Lisen to Shakti becouse there was a recent post on this topic, i believe i was the one asking, and plz do not do what elnerdo told you, that is a sloppy mess.
You just need a velocity that your units move at and then you can base your movment on real time. Useing real time will eliminate any lag issues that you would encountor.

Last, what Magos said dose not really make sence to me becouse that would only happen if you had no collision area detections, and, if you did not, the units would still move through things any way.

What magos said does make sense if you aren't doing swept volume collision detection calculation. Depending on how complex you make it, there are often complex collision detections that can only really be solved by performing overlap tests, done by incrementing the object's position and/or orientation and checking for the collisions. The problem of when two objects move 'too much' in a single move and pass through each other in a single step is called tunneling.

If this is just single player you should be able to find about a bazillion resources for doing time based movement. Doing this over a network is, as I understand, many times more complex.

Go onto msdn.microsoft.com and look up queryperformancecounter and queryperformancefrequency. You'll need those for the most accurate/precise timing on xWindows.

Thanks for clearing that up for me Darkness

Magos, the method you mentioned is the same method I've been using on all my games, but you can still notice a difference of speed on two computers with that.

(It's especially good because it prevents your games from using 100% of the cpu)

When i made my Space Shooter, i have the user set how many FPS he wants, then leave it all to SDL_Delay(TIMER);

How that worked is i'd wait for a set amount of milliseconds, and I could limit it to 60 FPS, or untimed FPS, even .000000000000000000001 FPS.... It's not as flexible, but it works.