Your timing for your user interface should be decoupled from your actual game loop, as should your rendering. Say for example your world runs at 4x speed. Lets say that at your basic (1x) speed, your game runs 30 updates per second.
You would then have something like the following, when in fast-forward mode:
- World logic runs 4 updates for every update of UI and renderer. This means it needs to run 120 updates per second. Thus, your world model (data) is updated at this rate.
- Renderer and UI logic both continue to poll or do whatever at 30 updates per second.
In other words, the game as a whole is not running faster. The simulation part is.
You can deduce two things from this:
You need to keep your game logic simple enough that you can easily run it four times faster on your target platform, OR you need to introduce methods to extrapolate various aspects of gameplay more quickly -- this can result, though, in a model that is different from *what it would have been if you had simply used a more rapidly paced simulation. So the tradeoff would be processing cost for accuracy.
It is the seperation of concerns that allows you to easily speed up your world simulation, that separation being model, view and controller (MVC). If your world data(M), render logic(V), and game logic(C) are all mixed up, you really won't be able to do this, at least not with a massive migraine.
This gives you the general outline. Your language choice is your own, presumably you either know how to do that in Unity or you don't. If you don't know how to work with Unity's timing, that a separate issue you'll need to research, because timing in any language requires you to understand the ins and outs in detail.