Giving the update function a history

Question

I am using Unity but this is an issue, that can be applied to every programming language.

I only have one Update-Function.

function Update ()
{

}

This function runs each frame. If I want to include a history, like "Has player already been at x, show z, else show g" I work with

function Update ()
{
  if(playerwasatx == true)
  {
    showz = true;
  }
  else
  {
    showg = true;
  }
  if (showg == true)
  ...

  if (showz == true)
  ...

}

You get the idea. Losing track is just too easy. Which approach helps me include a history, like an animation to be played.

For instance(pseudocode)

task1: if player is at z, play animation xy smoothly. If something interrupts animation xy by entering object u's space, do m

task2: if it's already night in the game(night == true), move person a to position b, then let him wait there for a certain amount of time(time = x) until night is false again.

All of this can be solved with if then else but to not lose track, which approach is more human friendly?

Answer 1

It kind of sounds like you're doing things on update that should be done on trigger. Let's take an example I thought of:

You want a particular puzzle-related light to shine much more brightly if the hero is standing in a particular spot in the room, to alert his attention to it.

You probably shouldn't be checking each frame whether he's there; you should be setting up a system of triggers, with functions like 'onEnter', or 'onLeave'.

onEnter: function() {
  shineEffect.visible = true;
}
onLeave: function() {
  shineEffect.visible = false;
}

I'll also try to extend the idea of the "has been to" sample. Let's say the hero got a new ability after visiting an oracle, and for the rest of the game, it's in his HUD. I'd imagine your current code might say:

drawHUD: function() {
  drawHealth();
  drawMagic();
  if (hero.hasVisitedOracle) {
    drawSpiritSummon();
  }
}

Your target might be something like this;

drawHUD: function() {
  foreach(var hudElement in hudStuff) {
  hudElement.draw()
}

onVisitOracle: function() {
  userMessage('You got the "Song of Spirits"! You can now [Summon Spirits] at any time.');
  hudStuff.add(new SpiritSongHudElement());
}

It kind of sounds like you're trying to make the transition to event-based programming. You're right to think it weird to be doing so many 'if' checks in an Update loop. Really stingy programmers (not practical ones) pride themselves on not using any 'if's, ever, in routine logic.

Answer 2

@Zurechtweiser

Going from what you wrote:

It's about procedural animations. For instance, I want to move a character from A to B. As soon as he is at B, he should rotate around 20°. Then he should wait for event z to happen.

It would be prudent to follow the Single Responsibility Principle. The principle states that a class, or in this case an object, should have a single responsibility, and that responsibility should be encapsulated entirely in that class/object.

What I mean by this is that the character object should know how to move from A to B, should know how to rotate 20 degrees, and should know what to do after event Z. How the character "knows" these things can be represented by different methods inside the character 'object'. For example, you could have the following method in a script attached to the character gameObject:

rotateCharacter(rotateTo : Transform)
{
     // implement code to rotate character
}

However, the character shouldn't know when to rotate, just how to rotate. That's an important distinction. By following the Single Responsibility Principle, it is more object oriented to have another object, for example a gameController object, know when the character should be doing certain things. The character's Update() function isn't the best place to put code that controls event timing and animations in your game. You don't have to worry about having a "history" inside the character object's Update() function, when that implementation should be in another object all together; possibly stored as game state information.

You can read more about the Single Responsibility Principle here: http://en.wikipedia.org/wiki/Single_responsibility_principle