Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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;
    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?

share|improve this question
Kind of like: managing a complex game storyline or quests system – Byte56 May 14 '13 at 21:05
You need to implement more abstraction. Detailed design, such as events and the like, should not be hard coded in your update function. You should be abstracting high level concepts such as scripting and other game-content away from your low level functionality. This sort of implementation makes large amounts of content or any changes to content difficult. – Attackfarm May 15 '13 at 0:27
@Attackfarm I have no idea what you are talking about. – Zurechtweiser May 15 '13 at 1:06

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() {
  if (hero.hasVisitedOracle) {

Your target might be something like this;

drawHUD: function() {
  foreach(var hudElement in hudStuff) {

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.

share|improve this answer
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. Currently I do it like move = false -> if keypress -> move = true... I simply want to define a whole set of events that should be executed without having to think frame-wise. Also think multiple levels of character traits. In other words: history. – Zurechtweiser May 15 '13 at 0:16


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:

share|improve this answer
Can you give a small unity script example? – Zurechtweiser May 30 '13 at 8:31
You need to be more precise regarding unity as your common explanation is useless. – Zurechtweiser Jun 1 '13 at 7:22
@Zurechtweiser Why so hostile? The whole concept of StackExchange is to be helpful; having an attitude won't help matters. The premise of having an Update function to perform game logic isn't unique to Unity, so the answer to your question won't necessarily be unique to it either. The 'history' your wanting is really a way to track game state; which can be done multiple ways. My whole point was that game state code shouldn't be in the character object if you want your code to be object oriented; which is the best way to write code, in Unity or otherwise. – RabbitEar Jun 1 '13 at 13:45
I guess you mean "useless". There is no hostility. "Useless" means "not of any use for this purpose". That's descriptive not offensive. You are writing it to be useful but it is not as it is too abstract. Which is why I asked you for a script sample. – Zurechtweiser Jun 1 '13 at 17:04
The problem, adding 'history' to a function, is an abstract problem. There is no one script to write that will solve it. Programming is all about taking the abstract and making it concrete through your own interpretation in how to solve the problem. My entire point was that your premise of needing 'history' in an Update() function is incorrect, according to object oriented programming theory. There is no script to write. I was suggesting a new course of action that nullifies the initial problem. It's up to you if you want to rework your code to follow the principle or not. – RabbitEar Jun 1 '13 at 21:51

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.