How do I design a game from scratch? A primer on core loops
teamavocado.co
teamavocado.co
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.
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!
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.
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.
> Part of that comes from the length of the higher-level game loop.
> If you recall Pico Tennis, the essential activity is hitting the ball back and forth. But the higher-level game loop is the rally.
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 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.
I only mention this because this comment primed me for a discussion about game engine design instead of game design.
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.
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.
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.
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?
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().
entities.forEach { $0.think(delta_t) }
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.
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.
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.
There is no silver bullet. There are decades of academic research and engineering on this and we have yet to reach a good answer.
When multicore is utilized it's normally in the line of https://unity.com/dots