Gamedev here. Slight correction: what they're describing is the smallest viable loop, not necessarily the core loop.
The core loop is the smallest engagement loop in the game, where the player goes through it inside a single session, and reaches some kind of a stopping point, but also wants to come back and go through it all over again (right away, or next time). It can be the smallest loop, maybe, sometimes, but usually isn't.
For example, in this article, they focus on the loop "player returns the ball <-> opponent returns the ball". This is the smallest loop for sure.
But the core loop here is on the point level: "Someone serves, players exchange the ball back and forth, someone finally misses, the other person scores points. Repeat." Or maybe game or set level, for more advanced players who are no longer challenged by point play.
Similarly in a racing game: the core loop would be a race, not a single lap, or a single pass of an opponent's car. Or in an RPG: hitting the enemy and having the enemy hit you is a tiny loop, but it's not the core loop: doing a quest and coming back for a reward is much closer to what we're looking for in a core loop.
I guess in some games there are many loops within loops within loops.
E.g. in "slay the spire", a game i am very fond of, the smallest loop could be "you draw a hand of cards from your deck and decide which card to play on what target" - usually taking a few seconds to decide or perhaps a few minutes if you are in a very tricky situation where you might win or lose unless you make a carefully considered move. The next loop up could be fighting an encounter, where you repeatedly draw and play cards until the encounter ends, and gain a small reward after completing the encounter successfully (improve your deck of cards). Then the next loop up could be charting a course through a short sequence of encounters & shopping opportunities & boss fights, where you're making a sequence of longer-term planning decisions to improve your deck according to a particular strategy you have in mind and also trying to best exploit the opportunities or unfortunate situations you are presented with. Then the next loop up would be a "run" taking a few minutes (for an early failure) to one or two hours (for a win) where you start the game with a new character and you repeatedly chart a course across 1-2-3 small levels until you either win the run or your character dies in an encounter ending the run -- but in both cases unlocking some meta progression reward. Then the next loop up being unlockable meta progression and actual skill/experienced-based progression repeatedly playing "runs" and losing or winning while unlocking content and also getting better at playing the game.
I'm not sure which of the loops above to think about as the core loop!
All games have loops within loops within loops! :)
The best games have a layering of loops of different frequencies, which complement each other. That's what gives games that "one more turn" feeling, if at every turn you're confronted with multiple decision points with different result horizons. So at every point in time, some decisions ripen and are ready to collect, while others require attention but will have payoffs at very different times in the future.
Edit: for roguelites like STS I would count a single run as the core loop. Especially in the presence of metagame, the benefits gathered during any single run add up, and make the player that much more interested in coming back and giving it another try.
I haven't played slay the spire, but I've been enjoying monster train which is mostly the same game.
I would consider the core loop to be each encounter/game. This is a core loop that's shared across most card games whether that's gwent, hearthstone, magic, or Yu-Gi-Oh. It is the smallest self-contained unit of gameplay. The minimum viable loop would be each turn, but you can't really stop and pick up the game between turns, right?
All of the other loops, the build-play-build loop, the "finish a run" loop, the "cross-run-progress" loop, are all features that are enabled by/rely on the core loop of gameplay.
In analogy to tennis and the OP, each hit of the ball is the minimum viable loop, each point is the core loop. This is enhanced by the match loop and on top of that the "tournament" loop.
Alternately, find the entry point to a chaotic interaction and design rules around structured exploration of that interaction. Then adjust into a legible, well-paced gameplay loop to taste.
That's how you can come up with a game like pinball(ball-on-plane physics), Tetris(tetronimos), or Sokoban(box-pushing on the grid) - interesting interactions with a lot of inherent complexity, and core loops that are immensely mundane in description. This strategy applies as well to conventional narrative: Set up some absolute rules of the world, then start simulating what happens.
Loop-based workflows are useful in terms of establishing the "economic model" and fleshing out the core concept, but they've only really been in the practiced parlance since the rise of MMOs and subsequently popularized through reduction to the simple compulsion loops that now drive most mobile games. They really don't deserve the central role they've been given lately.
The article simplifies too much to be insightful. Looks like clickbait for hacker news ;-)
The core loop already being discussed in other comments.
The vertical slice is when you implement _a part_ of the game to be completely finished (like a demo). It's not a step that is always done after the horizontal slice, but might be done before, simultaneously or after.
In smaller projects neither of those two prototypes is fully implemented, rather it's the challenge of the developers to agree on a equal idea / concept of the project you are working on. The game design document is the documentation
of these prototypes. Most often all these aspects are worked on in parallel. A change in mechanics influencing the visuals, a story element influencing the mechanics, etc. and vice versa.
panopticon is correct that this talk is sort of off-topic, because it's about game-dev gameloops, not game-design gameloops, which are not the same thing at all.
And rishav_sharan is correct that it's nonetheless lovely, so thank you for linking it.
It's interesting that, being from 2014, it uses a lot of patterns that would be completely imprudent (though still possible) in modern post-2015 Javascript, so on a line-by-line basis more than half the lines are not how I would recommend doing this today, while the approach is still totally perfect.
Hard to believe, though, that that video has so few views/likes/comments, because she really nails it.
This was awesome! I'm going to code this with my son this weekend! It's simple enough to comprehend and should allow us to code this in a few hours with his basic programming knowledge.
If you're interested on a more visual/animated explanation for this and other gamedev topics, I highly recommend Yahtzee's Dev Diary series (starting with episode 1 and going forward chronologically): https://www.escapistmagazine.com/v2/category/yahtzees-dev-di...
He sets out to make 12 games in 12 months, so he experiments with many different themes and mechanics, while showing what makes a game a game.
I would recommend a more flexible definition of "from scratch" that doesn't require reimplementing everything including the stdlib and which allows using libraries like SDL or GLFW or OpenGL so maybe you'll actually finish something.
I mean... Handmade Hero started in 2014. It's 2020. He still doesn't even have the basis for a game yet. It's a great source to learn theory and low level implementation details, but no one would actually approach making a game that way.
The purpose of the project is to show how a high quality game can be created. It is educational project, finishing the game is not the main goal. The series are on ~600 episode. Which is around 800 hours. I don't think that is much considering that
- until episode ~200 soft renderer was used to show how exactly rendering works, then he switched to openGL.
- he is diving into complicated topics, like right now advanced light system.
- ~50% or more of time is spent on detailed explanations.
A high quality game can be created in Unity, Unreal or Godot. No one needs to know how to implement a renderer from scratch to do that.
I'm not disputing that Handmade Hero is valuable - there is a lot of good theory and insight into process there, but what it does not teach is how to make a game.
I've never designed games beyond tetris, could someone explain in a few words, what the architecture of a RPG looks like?
Some assumptions that may be terribly wrong:
- The user input loop (keyboard, mouse) is still the main loop somewhere at the very bottom. Or is it different in RPGs?
- Spawn threads each with their own inner loop, for each complex agent. Not necessarily an OS thread, but something that has its main loop and a stack.
- Objects that don't have a "brain" don't need a thread, e.g. the ball in the tennis game. All such objects are managed from a single thread.
- There's a rendering loop, possibly with its own complex multithreaded architecture.
I don't know, did I come close to what's actually happening in complex RPG games?
I did some big game dev for some years 10 years ago. The loop was (there was only 1 loop):
delta_t = time between last frame and now
fetch input status
for each entity:
entity.think(delta_t) (for example, if a monster is in the state of moving towards me, it will move speed*delta_t units)
Render()
Never saw loops with real threads, that looks like asking for trouble.
If it was a multiplayer game then the think part was on the server and the client would just ready entity state from the network, sent input to server, and render().
is essentially cooperative multitasking, whose efficiency is questionable in general and especially on multicore hardware - but I don't know about games. Let alone programming think(delta_t) adds complexity and introduces more states within each entity, compared to real threads with their own stacks.
John Carmack has some ideas on how to use immutable copies of the game state and functional programming concepts to create something that's easily parallelized. I saw it in an old QuakeCon keynote: https://youtu.be/Uooh0Y9fC_M
In low level audio you have something similar: there's a thread that pulls audio data all the time and it can't stop; at the same time you have potentially lots of things happening in other threads, including the UI one. You can always find ways of minimizing the synchronization overhead by e.g. having a single fast entry point to any changes that happened since the last cycle. With audio you basically end up passing immutable blocks of data with minimal synchronization. So should be possible to do in games, too.
The evolution has been from single threaded engines to different core elements being on seperate threads (e.g. renderer and io) to task based scheduling.
Typically though the updating the game itself is a relatively small part of the frame time and can be reasonably tricky to get real gains through parallelisation.
Audio is a very different problem that is typically about a chain of streaming buffers. The thread pulling audio data (and all the others processing it) is independent from the UI etc., that is not an issue.
Copying and passing immutable data around is not always fast enough and definitely not trivial to merge the results back.
In summary, it is a hard problem with no general solution. If you could solve it, then you have solved multithreading design for any problem.
Having a system thread for every entity in a game doesn’t scale. Also having to synchronise the threads of entities by hand would be quite a nightmare.
It scales a lot better to have a thread pool, with a thread for each core, and then running lightweight jobs on them. So pretty much the same idea like e.g. the goroutines in Go or the green threads of Erlang.
Having such a job system you also have a lot less hassle with thread synchronisations. I’m working on an interactive 3d application and the job system we’ve have works like a charm for parallelization.
The benefit of threads - green or not - is also that you can maintain the state in the stack and benefit from functional style programming, which is generally more robust and easier to write compared to state machines.
Parallelism has many forms and from my experience you can always find ways of minimizing synchronization in particular tasks. For example, you can sometimes replace a whole queue with a single atomic pointer when you know messages override previous ones semantically, i.e. the consumer is only ever interested in the most recent one.
Here's an interesting presentation on Overwatch's ECS system, though he doesn't go into great detail in terms of multithreading, he points out how the design makes it easy to identify what parts of the system can be safely run in parallel.
Two reasons like I said elsewhere: (1) using multi-core architecture more efficiently and (2) eliminate state machines and use functional style instead, which is possible when you have threads (green, pseudo, OS threads, whatever) each with an execution stack. Functional code is more robust and is easier to write and maintain too.
The core loop is the smallest engagement loop in the game, where the player goes through it inside a single session, and reaches some kind of a stopping point, but also wants to come back and go through it all over again (right away, or next time). It can be the smallest loop, maybe, sometimes, but usually isn't.
For example, in this article, they focus on the loop "player returns the ball <-> opponent returns the ball". This is the smallest loop for sure.
But the core loop here is on the point level: "Someone serves, players exchange the ball back and forth, someone finally misses, the other person scores points. Repeat." Or maybe game or set level, for more advanced players who are no longer challenged by point play.
Similarly in a racing game: the core loop would be a race, not a single lap, or a single pass of an opponent's car. Or in an RPG: hitting the enemy and having the enemy hit you is a tiny loop, but it's not the core loop: doing a quest and coming back for a reward is much closer to what we're looking for in a core loop.