4 replies to this topic

[netwalker]

Hi All,

I would like your opinions and advices on how to structure a game loop because I'm not really sure on how to proceed on this subject. I know that this depends hugely on the type of game being implemented, so for arguments sake you can assume that the games are of a scrolling type and 2D based. These types of games cover platform and racing only. Role playing, "GOD" and all other game types can be discarded. Okay for this particular "game" I have the following loop.

1. gather input (from keyboard and mouse)
2. player update
3. calculate the view -> compute which area(s) are to be displayed
4. update area(s) in view
5. collision (objects that are in the view)
6. calculate the view -> compute which area(s) are to be displayed
7. draw frame

The problem that I have with this is that I'm having to compute the view twice :(. Why I'm I doing this?. Well after the collision detection (and response) is completed, there is a likely chance that the player will not be in the same position as they were before the collision took place. Therefore the view has to be recalculated in order for the current frame to be displayed correctly.

I would like to know is this the best way to implement a game loop for my particular "game". I would ideally like to calculate the view once per frame. Your opinions and advices are much appreciated.

netwalker.

[Jare]

Look at it this way: in step 3 you are not calculating the display view, but the gameplay view. It just so happens that it's the same size as the display view, but they are two logically different things and you will often want the gameplay view to be a bit larger. For example, in your description, if the player is moved a large distance during the collision, you will end up displaying objects that haven't been updated, and for some things this may look goofy.

Another option is to rearrange things so your player update only stores "intention", but the actual movement of the player is performed just like with any other entity, during step 4. Then, the view in step 3 is exactly the same as the view in the previous step 6 and doesn't need to be recalculated. In practice, same result if you just switch places between step 2 and step 3.

I imagine in practical terms this is a non-issue, but it's always interesting to reflect on the details and subtleties of game loops.

[netwalker]

"Jare" said:

Look at it this way: in step 3 you are not calculating the display view, but the gameplay view.

I see...I've been pondering on this for much more time than I care to spend on a problem. Actually looking at it as gamespace and viewspace (as I like to call them) does make sense. I mean the calculations needed for gamespace (this will be used for collision testing/response etc.) and viewspace are approximately the same. Gamespace is a little more involved because your having to compile a list of areas in which objects are moving around. However when you come to determine the viewspace most of the calculations have already been done. The only flaw that I can see here is that if the player object moves a large distance after collision system has resolved all collisions, it may be that the view actually spans areas that are different from those that were determined during the gamespace calculation. Therefore as a result, objects that are in the view could potentially not be displayed since the viewspace does not know that the gamespace has spanned different areas.

I don't know if I'm being overly concerned here, but I would be interested in your opinions and thoughts.

netwalker.

[Jare]

In practical terms, it may not be a problem in many small games because the calculations you repeat will not be so expensive as to *require* optimizing.

You hint at another possible solution: keep the calculations separate, but before you go to calculate the viewspace, check out if the results of calculating the gamespace can be safely reused. Most of the times you probably will, and one frame out of every N you won't.

I'd say you have given it enough thought that you can probably move on and wait to see if there are real problems surfacing. Theorizing only gets you so far without a practical application that defines real needs and real limitations.

[netwalker]

Thanks. :D