Newsletter #81 - Physics and Game Logic

News

The seventh demo of the SHMUP has been released.  For details, click here.


From the Programmer
Written by Invisible

Now that the SHMUP has been in development for a while, it's starting to get a bit texture heavy.  Because of this, some users have been unable to run the game due to a lack of video memory.  My initial attempt at solving this was to load textures into system memory after video memory runs out.  Unfortunately, your graphics card needs to support rendering with textures in system memory for this to work.  This seems to be a somewhat rare capability, so I ended up scrapping the code.  The proper way to solve the memory issue is to load textures only when they are needed and unload them when they are not.

In the last demo, we added the ability to fire missiles at the enemies.  I experimented with steering to control the missiles, but that didn't feel quite right.  The method I eventually settled on was to generate the missile's velocity based on its heading.  If the missile is not flying straight for the target, its heading is gradually adjusted until it is.  This sometimes causes the missiles to circle a target for a long time, but that can be fixed by increasing the missile's rate of turn.

The game will no longer freeze when you press one of the alt keys.  For those wondering how to do this, it's pretty simple: All you have to do is handle the WM_SYSKEYDOWN message when it is for the VK_MENU key.

If you are creating the trail for something (such as a missile) by placing particles behind it, you should keep in mind that if the rate of placement is greater than the update rate of the game you will need to place multiple particles per frame.  If multiple particles have to be placed per frame, you need to interpolate the position of whatever they are following otherwise they will all bunch up in one spot.

As I said in a previous issue, I had to tackle the problem of calculating the intercept time and vector for your ship's mission screen blip to one of the mission blips.  And as I predicted in said issue, this was rather difficult.  I finally found a post on the GameDev forums which discusses how to go about this.  You can find the post here.  The breakthrough for me was that the distance your ship travels in the interception time is equal to the distance between the mission blip at that time and your ship at the initial time.  This provides the necessary equation to find the time of interception since only scalars (distances) are required.  Calculating the intercept vector once I had the time of interception was a simple matter of getting the vector between your ship's initial position and the mission blip's final position (at the time of interception), normalizing it, and scaling the resulting unit vector by the speed of your ship.

The code for the SHMUP is starting to become too cumbersome to easily change.  Mostly due to the way it is structured, compiling and linking takes between three and four minutes to complete.  Because of this, I have spent the past week experimenting with new techniques.

The first thing I wanted to get straight was the difference between the "game logic" step and "physics" step.  After a little research and several discussions with other programmers, the following definitions seem to be commonly used:  "Physics" is any code which moves things (this includes collision detection and response) and "game logic" is code which regenerates a character's health, counts down the timer on a trap, shoots a gun, etc.  These definitions get a bit blurry if you think through each action too much (shooting a gun is technically movement since your character is moving his finger on the trigger and the internals of the gun are moving) but the following rule should help define the line better: If the movement literally takes place in the game, it's physics; otherwise, it's game logic.  For example, if your character does not actually move his finger to squeeze the trigger, and the internals of the gun do not actually move, then it is game logic.  Sure these could be animations, but if that is all they are (they aren't separate movable entities which trigger the various parts of firing a gun) then they do not belong in the physics step.

With those definitions squared away, I was able to work on a new code structure.  The code is split up into systems, game states, and utilities.  The systems include debug, render, window, main, and input.  Utilities are things such as an interpolation macro and an exception class.  Examples of game states are banner, menu, and game.  Each game state is split up into input, state, and render.  State is further broken up into physics and game logic.  A game state could also be split up into UI and game sub-states, but I haven't experimented with this yet.  The idea behind this structure is to separate the code to make the addition of features easier (because it is more obvious where the feature belongs), make debugging easier, and reduce compile+link times.  I may have to cut out some of this structure in the end though, since adding structure to code also makes it more complicated.


Artist's Easel
Drawn by GreyKnight

iScribble Sketches #39

(Click to enlarge)


(Click to enlarge)



Community Spotlight
Written by jaythemage and miotatsu

Miotatsu has written a detailed tutorial on how to setup WINE to run IfThen Software games.  You can find it here.

The seventh SHMUP Demo has been accompanied with a Youtube video by Jay showing the new features:


If you have anything you would like to say in the next community spotlight article, please post it here.