7 ms·

How do I design a game from scratch? A primer on core loops

241 points by NuclearTide 6y ago

60654 6y ago
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.
- Johnjonjoan 6y ago
  Thanks for explaining this so concisely
  - 60654 6y ago
    Glad to hear it was useful!
- shoo 6y ago
  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!
  - Jarwain 6y ago
    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.
  - 60654 6y ago
    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.
- airstrike 6y ago
  I think this is a matter of semantics as the article does describe what you're saying. > 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.
sunpazed 6y ago
I really love this talk by Mary Rose Cook — she illustrates step-by-step how to code a game loop from scratch in 30 minutes. https://youtu.be/hbKN-9o5_Z0 https://youtu.be/hbKN-9o5_Z0
- panopticon 6y ago
  Note that the article being discussed here is about gameplay loops; not a game engine loop. I only mention this because this comment primed me for a discussion about game engine design instead of game design.
- rishav_sharan 6y ago
  Thank you. That's a lovely resource
- marai2 6y ago
  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.
- jholman 6y ago
  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.
megameter 6y ago
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.
th0ma5 6y ago
I always felt the game loop was the most commodity thing, it is the whole rest of the content and design that is about damn impossible.
tomaszt 6y ago
I recommend handmade hero project to learn how to create a game from scratch
- krapp 6y ago
  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.
  - tomaszt 6y ago
    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.
    - krapp 6y ago
      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.
      - tomaszt 6y ago
        I see, yes, agreed.
mojuba 6y ago
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?
- popotamonga 6y ago
  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().
  - mojuba 6y ago
    Interesting. Something suggests a loop that does entities.forEach { $0.think(delta_t) } 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.
    - popotamonga 6y ago
      Also you can check games like quake, doom etc which have opened their source, they are all done like that.
nurettin 6y ago
State machines are now called loops?
daiyanze 6y ago
I thought a game was developed from a blink of inspiration. And will start polishing the game to its proper state.
lindaberry22 6y ago
Hello let I’m Linda let chat on hangout lindaberry229@gmail.com
lindaberry22 6y ago
Hello I’m Linda from Georgia let chat more on hangout to get know more about each other lindaberry229@gmail.com
mysterydip 6y ago
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-diary/ 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.
maxraz 6y ago
Love sport games!
rspoerri 6y ago
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.

241 points by NuclearTide 6y ago

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.

Johnjonjoan 6y ago
Thanks for explaining this so concisely
- 60654 6y ago
  Glad to hear it was useful!
shoo 6y ago
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!
- Jarwain 6y ago
  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.
- 60654 6y ago
  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.
airstrike 6y ago
I think this is a matter of semantics as the article does describe what you're saying. > 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.

sunpazed 6y ago

I really love this talk by Mary Rose Cook — she illustrates step-by-step how to code a game loop from scratch in 30 minutes. https://youtu.be/hbKN-9o5_Z0 https://youtu.be/hbKN-9o5_Z0

panopticon 6y ago
Note that the article being discussed here is about gameplay loops; not a game engine loop. I only mention this because this comment primed me for a discussion about game engine design instead of game design.
rishav_sharan 6y ago
Thank you. That's a lovely resource
marai2 6y ago
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.
jholman 6y ago
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.

megameter 6y ago

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.

th0ma5 6y ago

I always felt the game loop was the most commodity thing, it is the whole rest of the content and design that is about damn impossible.

tomaszt 6y ago

I recommend handmade hero project to learn how to create a game from scratch

krapp 6y ago
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.
- tomaszt 6y ago
  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.
  - krapp 6y ago
    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.
    - tomaszt 6y ago
      I see, yes, agreed.

mojuba 6y ago

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?

popotamonga 6y ago
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().
- mojuba 6y ago
  Interesting. Something suggests a loop that does entities.forEach { $0.think(delta_t) } 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.
  - popotamonga 6y ago
    Also you can check games like quake, doom etc which have opened their source, they are all done like that.

nurettin 6y ago

State machines are now called loops?

daiyanze 6y ago

I thought a game was developed from a blink of inspiration. And will start polishing the game to its proper state.

lindaberry22 6y ago

Hello let I’m Linda let chat on hangout lindaberry229@gmail.com

lindaberry22 6y ago

Hello I’m Linda from Georgia let chat more on hangout to get know more about each other lindaberry229@gmail.com

mysterydip 6y ago

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-diary/ 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.

maxraz 6y ago

Love sport games!

rspoerri 6y ago

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.