# Games development with a game loop that's abstracted away [closed]

Most game development happens with a main game loop. Are there any good articles/blog posts/discussions about games without a game loop? I imagine they'd mostly be web games, but I'd be interested in hearing otherwise.

(As a side note, I think it's really interesting that the concept is almost exclusively used in gaming as far as I'm aware, perhaps that may be another question.)

Edit: I realize there's probably a redraw loop somewhere. I guess what I really mean is a loop that is hidden to you. Frames are something you as the developer are not concerned with as you're working on a higher level of abstraction. E.g. someLootItem.moveTo(inventory, someAnimatationType) and that will move from the loot box to your inventory using the specified animation type without the game developer having to worry about the implementation details of that animation.

Maybe that's how "real" games end up working, but from reading most tutorials they seem to imply a much more granular level of control is used, but that might just be an artifact of being a tutorial.

Edit2: I think most people are misunderstanding what I'm trying to ask, likely because I'm having trouble describing exactly what I'm trying to ask. After some more thinking perhaps what I'm referring to is more along the lines of what I believe is referred to as "scripting" where you're working at a very high level and having some game engine take care of the low level details.

For example, take custom maps in Starcraft II or Warcraft III. Many of the "maps" have gameplay that deviates enough from the primary game that they could be considered a separate game written on the same engine. What I'm referring to then is along those lines. I may be wrong because I only dabbed in the Warcraft III editor, but as far as I remember no where in the map editor do you control the game loop, and yet you can create many different games out of it. In my mind, these are games in their own right. If you're playing DotA you don't say you're playing Warcraft III, you say you're playing DotA because that's the actual game you're playing.

Such a system may impose limitations that don't exist if you're creating a game from scratch, but it greatly reduces development time because much of the "hard" work has already been done for you.

Hopefully that clarifies what I'm asking. Another example of what is I mean, is when you write a web app, of course it communicates through sockets and TCP. But does the average web developer doesn't explicitly write code for connecting sockets. They just need to know about receiving a request and sending a response. There are unique scenarios where you do occasionally need to use raw sockets, but it's generally rare in web development.

In a similar fashion, it's very possible to write a game without directly using the game loop, even though one is used behind the scenes. Probably not a AAA title, but there must be hundreds of smaller scale games that can and possibly are written this way. Are there any good resources on writing these "simpler" games?

• Update-Draw-Repeat ... what simplier should be? :) Mar 6, 2011 at 15:33
• What wouldn't have a game loop? Even something like ZORK has one. Mar 6, 2011 at 15:44
• The main loop is very common, every Windows application has one: en.wikipedia.org/wiki/Event_loop and every webserver. Mar 6, 2011 at 15:49
• Unless you're meaning games where the game loop is implicit; or at least not written by you? Mar 6, 2011 at 16:32
• @Duck that's exactly what I mean. I edited that into the question. (Do you get notifications for @Duck? I'm not sure whether SE's notification system handles that) Mar 6, 2011 at 16:57

## 8 Answers

First off, I don't think it is possible to have a game that doesn't have a loop, somewhere, unless it is absolutely trivial. A web game uses a loop, the only difference is that you aren't writing the loop, you generally just respond to events. There is still a loop happening. In a way, the distinction is immaterial anyways, you generally must repeat a sequence of code many times. If you use a loop to do so, then fine, if you use events or some other mechanism, great: the end result is that you are repeating. A loop just seems to be the more straightforward way of repeatedly executing a block of code without overflowing your stack. ;)

I can't think of any other paradigm other than event-based when there is no explicit loop, so maybe you can describe what it is you are having difficulties with or want more information about. Is it a general question of how to structure code, or how stuff gets done? For example, in Javascript/HTML5 I'd use a repeating timer to send an event every 1/30 of a second to signal the drawing of a new frame of animation.

• See my edit. Basically I mean that you don't care about frames, and what I'm thinking of is event-based, but perhaps there are others. Mar 6, 2011 at 16:52
• I'm not really having any difficulties, just general curiosity. Mar 6, 2011 at 17:09

The only way I imagine you can avoid a game loop is recursion, which would eventually end in a stack overflow. Even if a game is event-based, there's something outside the game looping and sending those events. IE: Flash triggering tick/update/draw events. Inherently, to have more than a single frame of a game, you need to loop. That or your game is limited to a certain number of frames that are precomputed. That limits you to a rather simple game that isn't very actively... interactive.

• What about a model that blocks until an update is issued, say a blocking queue of commands that sleeps until a command comes in to say "hey, something changed". I realize internally this queue would probably be implemented in some sort of loop, but that's an implementation detail. Mar 6, 2011 at 16:56
• Still a loop. Sure, you don't control it, but you're still subject to the architecture of a game loop. Your input will be called. Then your update will be called. Then your draw/render will be called. Ultimately, that architecture is imposed in some manner. Mar 6, 2011 at 17:01
• @Sion Right, but all programs are eventually compiled into/interpreted as machine language but that doesn't I as a programmer need to deal with it. Basically what I'm getting at is user code not dealing with the details of frames and just letting some library or engine handle any kind of interpolation and generally just "do the right thing" automatically. Mar 6, 2011 at 17:13
• There's a difference. You're talking about assembly/bytecode, which is lower than your code and has to do with language, while the game/application loop imposed on you is higher and has to do with software architecture. You are working on a higher-level than assembly/bytecode, but you are working within the game loop. Mar 6, 2011 at 17:20
• @Sion I think we're not quite understanding one another. What I'm talking about is for instance in a Java program, you may be working within on various operating systems, but the JVM abstracts away the differences for you so you don't need to know or care what OS you're on (most of the time). Similarly I'm wondering about game architectures where you don't know or care that there's a gameloop internally. With JQuery I can say "shift this div 100 pixels to the right over 3 seconds". I need zero knowledge that some loop even exists in order to implement that. That's what I'm referring to. Mar 6, 2011 at 17:30

Panda3D is entirely event driven, so the main loop of all games written in it is implicit really (one call to a library function that doesn't return until the game ends).

It's not entirely clear what you're asking. It's certainly possible for there to be no explicit game loop, eg. when the operating system essentially does your loop for you, but very little changes as far as the game is concerned.

1. Instead of calling update() in an explicit loop, you could put that function in an OnIdle handler or other Idle event callback - what exactly to use for that would be platform specific. If you have no idle events provided by your OS then you could simulate these with another thread that sets a condition each time you need to update.
2. Instead of polling directly for input, you respond to input events and then cache any values that you later need to poll for (eg. in the update function).
3. Instead of rendering directly, you might have to render in an OnPaint handler or something similar.

Beyond that though there's no real difference. However, I'm not convinced that's actually what you're asking, because you seem to be asking about how complex time-based actions take place in AAA games and the like.

E.g. someLootItem.moveTo(inventory, someAnimatationType) and that will move from the loot box to your inventory using the specified animation type without the game developer having to worry about the implementation details of that animation.

If the 'game developer' didn't have to worry about it, someone else did. Probably the same developer, earlier in the development cycle. :) Motion over time can be handled by creating an object or system to monitor that motion. Each update() call moves the item towards the destination until it arrives, at which point the motion stops.

Maybe that's how "real" games end up working, but from reading most tutorials they seem to imply a much more granular level of control is used, but that might just be an artifact of being a tutorial.

Pretty much. A much more granular level of control is used, and most games do run frame by frame, but most gameplay code won't need to take that directly into account. If I call walkTo(14, 15) then there is a separate system that slices that walking behaviour up over as many frames or loop iterations as takes to reach that destination. Same thing with something trivial such as mario.jump(). He still moves frame by frame, but there's a physics system that runs each frame which decides exactly how to move the guy. When you type mario.jump() you don't need to worry about how jumping is implemented - but someone had to work it out and implement it.

Are there any good articles/blog posts/discussions about games without a game loop?

No. Every electronic game thats some sort of updates in real time use a game loop. The Only kind of game that wouldn't really use a game loop would be txt based game that reacts to user input only.

I guess what I really mean is a loop that is hidden to you.

Sure, but even though it is hidden, everything applies. Flash for example has a loop for code execution, and you cannot specifically edit the main loop, you however can use different events to trigger code, or have code on the timeline which flash executes when it hits it.

. E.g. someLootItem.moveTo(inventory, someAnimatationType) and that will move from the loot box to your inventory using the specified animation type without the game developer having to worry about the implementation details of that animation.

That is easily doable, but the thing is, someone has to set up that Method and set up the animation. Game Development is not magic.

• Then Flash is such an example then maybe. I've never actually worked in Flash. Of course it's not magic (for some definitions of "magic") but there must be games where the developer of said game never needs to touch the game loop. I'm interested in resources about those types of games. Simple games, not AAA titles, maybe not even A titles (if such a thing exists), but fits the definition of a game, and is played on a computer. Mar 7, 2011 at 5:11
• I work in web development and I'm aware of sockets and know how they work, but I've never had to actually write my own socket connections. I'm looking for similar thing in games. A game loop could be sufficiently abstracted away such that most games using that abstraction would not have to touch it. Mar 7, 2011 at 5:14
• No but it is the same thing as having an update method. Mar 7, 2011 at 5:29

Loops are simple constructs, and they're generally easy to implement. They work on a simple synchronous environments of things happening in some definite frames. All this nicely explains while a game loop (which is not necessarily a while (true) kind of thing - that's an implementation detail) is so popular in game engines.

However, the synchronicity breaks apart quickly as you make the game more complex - a prominent example being the addition of multiplayer features. Asynchronous actions are a very poor match for game loops. Suddenly, you're doing tons and tons of work to synchronize somehow, your abstractions leak like crazy and you're dealing with tons of bugs and latency issues and everything.

Now, most multiplayer games still use game loops, but to a big degree, this is so for performance reasons and familiarity. As compilers and virtual environments and computers themselves get better and better, we're getting more options to add abstractions that fit the asynchronous model better. Granted, in the end, there might be some loop hiding under all these abstractions (at the very least it's down there in the OS :)) ), but we don't care about the "loop-as-implementation-detail", we are interested in the "loop-as-abstraction".

A great example of a game that dispenses with the usual game loop is EVE online, and I do mean the client. That's why the client is (partially) written in Python - the whole GUI is made using asynchronous patters, tasklets. Basically, when you click a button, it starts an asynchronous flow that eventually results in you getting eg. a window showing current market data. The usual synchronous flow would be "button press -> ask the server -> get the data -> show the form". This is all fine and dandy as long as the "ask the server -> get the data" part is very fast - it has to take much less time than a single frame. If it's not fast enough, using the synchronous model means that your game updates / frames lag while the data is received. And combining the asynchronous model with a simple game loop gets tedious very soon. Suddenly you're crawling through tons of queues, and concurrent collections, and you have no idea what happens when and why, and all your code is full of if's and switches and state machines...

In practice, tasklets are basically syntactic magic ("syntactic sugar" doesn't quite cover it). You're writing code as if it were synchronous (simplicity), but it is actually executed asynchronously, without giving you the headaches of multi-threading. If you're not familiar with Python, a related concept is await/async in C#. The concept isn't all that new, it's the fact that it works pretty much automagically. Instead of hacking your game loop like crazy, you're back to the simple synchronous model - that automatically happens asynchronously (and in fact, without creating useless threads that are stuck on I/O operations).

This is IMO the future for GUI-heavy multiplayer (especially MMO) games. It vastly reduces the complexity of the code, and we can now easily afford the performance loss (which is actually quite low nowadays). And as the gap closes even more, it might one day become the go-to solution for everything. Perhaps the thing that enables this will be that everyone will have a 100-core CPU where each core is running at 500 MHz (after all, look at the GPU :)), or maybe the abstractions will have their overhead lowered enough to be even more negligible than today. And the garbage collector will be "free" and ...

Another interesting concept for basic game architecture is things like reactive frameworks (ie. when you get shot, the damage is propagated to all the observers of your health, and they can update at the very moment, rather than checking every single frame if you have been damaged). As the performance gap closes, and the game get less bound on "100% CPU", those abstractions gradually become more and more viable, and in fact, writing a multi-threaded game without those abstractions is a huge pain.

So, just like game development moved from assembly, through C, C++ to Java, Flash, .NET... it will move to even higher abstractions as long as they are better suited for the task at hand. Is there still a loop in there somewhere? Sure. Does it matter? Hell no.

The problem with games is they need things to be done in a specific order. Physics must be done before graphics because otherwise what would be the point of drawing the picture if nothing changed. Scripting needs to be done before physics since if you move an object the physic engine needs to process it.

The only alternative I could think of would be a distributed Actor model.

Basically each object is given control of it's own resources and everything must talk to it through some communication channel such as a message que. It could be done with shared memory across threads, over IPC for separate processes or networked for separate systems. It can be massively parallel (each object could potentially have it's own thread).

There is all kinds of fancy shenanigans you can pull, your objects could be on different servers, with IPv6 you could even give each object it's own ip address, of course it makes sense to keep objects likely to interact together on a thread to cut out overhead but maybe each level/chunk has it's own server process and the player is transferred from process to process.

That would result in a lot of overhead. But for some game types it might be ok, a SNES style MMO JRPG might be fine but not a FPS.

Physics might be kind of complex in such a situation. It would be non-deterministic since you can guarantee the order of operations, that would make saving/loading/replays unstable and mean more network overhead since you can't just transfer the state and let the client simulate it. But not everything needs physics other than basic collisions. Although even that can still have issues, if you step into a space at the same time as another character, who gets right of way? Different systems might see a different result depending on where they are located.

Rendering the graphics would be a pain since it would have to 'ask' each object to report its position each time (or request a subscription to be told when the location of any visible objects is changed and also request to be informed when a object becomes visible to the camera or is created). This could end up with a lot of chatter.

Another idea is an event loop. Probably not as a replacement for a main game loop but more for things like resource management. Rather than loading a directory of textures you could spawn a thread and tell it to 'watch' that directory. Any time it sees a file that hasn't been loaded it can spawn off another thread to handle the I/O. It can return 'dummy' objects for placeholders that then load the real object into place when ready. A nice feature is your game can be edited live. It can watch the filesystem for changes and when you edit a texture the game can pull it in straight away. You could also have things 'pop' into existence which might be useful for something like a virtual world (ie Second Life). Or you could have low detail ones that then resolve into clearer images.

What I understand of your question, with its edits, is that you're writing a game by coding, but never actually writing any of the code that is executed on every single frame. For instance, rather than:

onFrame()
drawMarine()
if (collisionTest(marine, cutsceneTrigger)) {
gameState = cutscenePlaying(C1M1_FranklinDies);
}
}


You'd just specify in a designer mode system, that when marine collides with cutsceneTrigger, then start playing C1M1_FranklinDies. Very little of this has to do with a "loop".

In some ways, I think your example of X-Craft's editors is well-put. Many people have even made entire mods for Half-Life 2 with just levels and various triggers in the Hammer Editor. Those are abstracted game systems in many senses. The reason people don't all make their games in the StarCraft 2 editor is a mix of game exposure/licensing, and the need for more fine-grained control.

In addition, some engines like Unity can help in terms of only exposing you to code on actual events, like collision, or more expanded time intervals; and do so without being specialized to specific types of games like RTSes.

All game engines will have that loop at the low level, so what you're essentially looking for is using a helpful engine without doing much of the base-level coding. That may remove your capabilities a little bit, but for many games that's not a concern.