
How do I design a game from scratch? A primer on core loops - NuclearTide
https://teamavocado.co/core-loop/
======
60654
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.

~~~
shoo
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!

~~~
60654
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.

------
megameter
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.

------
rspoerri
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.

------
sunpazed
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
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.

------
mysterydip
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...](https://www.escapistmagazine.com/v2/category/yahtzees-dev-diary/) 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.

------
th0ma5
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.

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

------
nurettin
State machines are now called loops?

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

~~~
krapp
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
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
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
I see, yes, agreed.

------
maxraz
Love sport games!

------
mojuba
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
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
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.

~~~
jfkebwjsbx
That doesn't work as well as you think it does because entities cannot think
on their own. They need to refer to global shared state all the time.

~~~
mojuba
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.

~~~
meheleventyone
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.

