Round and Round We Go

Effectively, your code will consist of a giant loop that never ends, going round and round, each time doing what you need to do for that state. This is good because your code is never sat waiting for things. In the case of firmware for micro-controllers, you're going to need to scan the hardware for changes of input state that could trigger a state transition (for example, you may be reading switches and de-bouncing the inputs to make sure the user has really pressed the button). In the case of a game, you can use this time for rendering, reading the controls or performing the calculations for your latest and greatest physics simulation.

So let's consider a relatively simple example, the card vendor. The following pseudo code represents a few simple states:-

As you can see, the actions that are performed in each state are really quite simple, and whilst this is an extremely simple example you should always aim for clean and simple states that have one or two exit conditions. If you find yourself putting lots of logic and flow control in a state (this probably means it's doing more than one thing), then you're probably over complicating it and you should think about simplifying the state by breaking it up a little.