Updating the WorldOur next step is to code the UpdateWorld() function. This should be very simple; all your application variables, surfaces and interfaces have already been initialized, and now you just have to update and render them. That’s an easy task. Yes indeed, it’s an easy task, but only if you plan that your game will have only one screen, no menus, no options, and nothing. Let’s suppos that we wanted to build a simple DirectX application that shows a splash screen, then goes into the game, and then shows the same splash screen again. In the most traditional linear programming way, we would do something like this:
Now, with our UpdateWorld() function, we will have use a finite state machine instead:
And not only this, but we will also have to define our Splash() and PlayTheGame() functions to return a finish state when they have finished. Now suppose that the Splash() function performs a FadeIn() and a FadeOut(). Splash() would look like this:
Note that we must set the state to 0 when we finish the last step, because we must be able to invoke this function again later in the code. If we are resetting the state, then we must inform our invoker that we have finished, and that he can continue to his next state. Well, what we have just done is just a very simple application. Now imagine thirty or forty of these functions, each one with a couple dozen states - as I had to do to port Malvinas 2032 from DOS4GW to DirectX - and you will be facing a very big monster. Try to debug, or even follow this code, and you will get really insane. As you can see, this finite state programming model is far more complicated that the simple one achieved by old linear programs.
|
|||||||||||