Writing a Devlog
the five magic questions
$ cat devlog-02.md
Who hates writing devlogs?
| Monday | worked on the jump |
| Tuesday | watched some tutorials |
| Wednesday | changed the gravity |
| Thursday | playtest |
| Friday | the jump is better now |
Better than what? Says who?
A devlog is not a diary
Products
The bigger, "finished" things, often made with others: a GDD, a prototype, a level.
Stepping stones
The in-between work you did to get there: a genre analysis, a test plan, three versions of a jump.
Devlogs
The story of one design problem: why it mattered, what you tried, what you chose, and what comes next. It links the other two together.
One problem per devlog, and it ends in a design.
The 5 Magic Questions
Our example: the jump
version A / last jump: -
click the game, arrows to move, space to jump, Esc to give the keys back
What is the problem?
vague
"The jump is not good."
specific, and why it matters
Testers call the jump floaty, and 3 of 5 missed the narrow pillar after the pit. Jumping is the core loop of my game, so if it feels bad, the whole game feels bad.
Write it as a design challenge
Design a <form of solution> to enable <users> in <context> to <perform activity> in/with <target performance>
Design a jump to enable players in my platformer to land on narrow platforms within two tries for most testers.
## 1. What is the problem?
Testers call my jump floaty, and 3 of 5 missed the narrow
pillar after the pit. Jumping is the core loop of my game,
so if it feels bad, the whole game feels bad.
Design challenge: design a jump to enable players in my
platformer to land on narrow platforms within two tries for
most testers.
Criteria first
Before you change anything: when is it good enough?
- a full jump is under 0.8 s in the air
- 4 of 5 testers land the pillar within two tries
- testers no longer call it "floaty"
No criteria beforehand means every result is a success.
Name your methods
| library | available product analysis: how do Celeste, Super Mario Bros. and Hollow Knight jump? |
| workshop | prototyping: three versions of the jump |
| lab | A/B test: have a different group of testers play each version, and compare the feedback |
Triangulation
Use methods from three different strategies.
| library | what others found: the jump in three famous games |
| workshop | what I made: three versions to choose from |
| lab | what I measured: which version testers actually land |
Every method has a blind spot. Three that point the same way are hard to argue with.
Two method sites
ictresearchmethods.nl
The building side: available product analysis, prototyping, A/B testing, code review, unit test, decomposition, root cause analysis.
cmdmethods.nl
The design side, and many are not on the other site: thinking aloud, sketching, mood board, persona, Wizard of Oz, heuristic evaluation, tinkering.
Same five strategies on both. Pick the method that fits your question.
Look with a question
Don't just play it. Write down what you're looking for FIRST:
- Is it a symmetric jump?
- Can the player control how high it goes?
- What happens at the top of the jump?
- What happens if you jump just too late, or too early?
Watching a whole let's play is not an analysis. Answering your questions is.
Take screenshots, make clips
| record | a short clip of the moment you care about (OBS, or the console's capture button) |
| slow down | step frame by frame in VLC with the E key |
| count | frames: at 60 fps, 6 frames is a tenth of a second |
| compare | the same moment in each game, with the same questions |
the clips/screenshots you make are evidence too: put it in the devlog
Turn a jump into a curve
Celeste
from 9:42 - Game Maker's Toolkit, "Why Does Celeste Feel So Good to Play?"
Celeste, slowed down
Celeste, frame by frame
how the game forgives the player - source: Maddy Thorson, "Celeste and Forgiveness" (2018)
Super Mario Bros.
from 14:20 - Kyle Pittman, "Math for Game Programmers: Building a Better Jump", GDC 2016
Super Mario Bros., the slides
Super Mario Bros., frame by frame
the jump arc - source: Kyle Pittman, "Math for Game Programmers: Building a Better Jump" (GDC 2016)
Hollow Knight
from 9:17 - Lucid Tales, "Game Dev Pantry: Hollow Knight, Basic Movement"
Hollow Knight, slowed down
Hollow Knight, frame by frame
an expressive jump and a capped fall - after the Lucid Tales analysis
Using the same questions
| what I look for | Celeste | Super Mario Bros. | Hollow Knight |
|---|---|---|---|
| rise and fall | falls faster than it rises | falls much faster than it rises | faster down: ~28 frames up, ~22 down; capped |
| jump height | hold for higher, let go to cut | hold for higher, let go to cut | very expressive: hold or cut |
| at the top | a short hang while holding | no hang: heavy gravity takes over | broad, rounded top, no flat hang |
| too late / too early | forgiven: coyote time, jump buffer | ? | ? |
For my game: try a heavier fall (B) and a short hop on release (C). The hang and coyote time come later.
The prototype
version A / last jump: -
## 1. What is the problem? Testers call my jump floaty ... (see above) ## 2. How did I tackle it? Criteria, set before testing: - a full jump is under 0.8 s in the air - 4 of 5 testers land the pillar within two tries - testers no longer call it "floaty" Available product analysis (library): Celeste, Super Mario Bros. and Hollow Knight fall faster than they rise, and letting go of the button cuts the jump short. Celeste also forgives late and early presses (coyote time, jump buffer). [clips, table] Prototyping (workshop): three versions, A (same gravity), B (falling twice as heavy), C (B plus short hops). A/B test (lab): a different group of five classmates played each version. Three strategies: library, workshop, lab.
Show, don't tell
tell
"I changed the gravity and now it works."
show
- a GIF of A, B and C side by side
- the jump arcs as a picture
- the code that changed
- a link to the commit
before - version A
const JUMP_VELOCITY := -640.0
var gravity: float = ProjectSettings.get_setting(
"physics/2d/default_gravity")
func _physics_process(delta):
if not is_on_floor():
velocity.y += gravity * delta
if Input.is_action_just_pressed("jump") and is_on_floor():
velocity.y = JUMP_VELOCITY
move_and_slide()
after - versions B and C
const JUMP_VELOCITY := -640.0
@export var fall_multiplier := 2.0 # B, C
@export var low_jump_multiplier := 3.0 # C
var gravity: float = ProjectSettings.get_setting(
"physics/2d/default_gravity")
func _physics_process(delta):
if not is_on_floor():
var g := gravity
if velocity.y > 0:
g *= fall_multiplier
elif not Input.is_action_pressed("jump"):
g *= low_jump_multiplier
velocity.y += g * delta
if Input.is_action_just_pressed("jump") and is_on_floor():
velocity.y = JUMP_VELOCITY
move_and_slide()
What is the quality?
| version | air time | landed within 2 tries | what testers said |
|---|---|---|---|
| A | 0.90 s | 2 of 5 | "floaty", "like the moon" |
| B | 0.77 s | 4 of 5 | "better", "a bit heavy" |
| C | 0.77 s | 5 of 5 | "tight", "I can do small hops" |
example data: your own table will have your own numbers
What is the next step?
Let the quality of the result decide:
implement
It meets the criteria: build it into the game.
iterate
Close, but not there yet: another round on the same design.
research
The wrong direction: back to the analysis, with new methods.
C meets all three criteria, so C goes into the game. Next cycle: the ? in my analysis table, coyote time and a jump buffer.
Advice sits between the phases
what is possible advice on
what to make advice on
what to test advice on
the quality,
input for the next cycle
# Devlog 2 - Making the jump feel right
## 1. What is the problem?
Testers call my jump floaty, and 3 of 5 missed the narrow pillar after the
pit. Jumping is the core loop of my game. Design challenge: design a jump
to enable players in my platformer to land on narrow platforms within two
tries for most testers.
## 2. How did I tackle it?
Criteria: full jump under 0.8 s; 4 of 5 land within two tries; not "floaty".
Library: available product analysis of Celeste, Super Mario Bros., Hollow Knight.
Workshop: prototypes A, B, C. Lab: A/B test with three groups of five classmates.
## 3. What is the result?
[GIF: A, B and C side by side] [image: the three jump arcs]
[code: fall_multiplier and low_jump_multiplier] [commit: a1b2c3d]
## 4. What is the quality?
[table] C: 0.77 s, 5 of 5, "tight". C meets all three criteria.
## 5. What is the next step?
Implement C: it goes into the game. Next cycle: coyote time and a jump
buffer, the open question from my analysis, tested with five new players.
In your portfolio
- Evidence description: two sentences about what this devlog proves
- Learning outcomes: link it in LO6, not everywhere
- Group work: say what you did
- AI: say if and how you used it
“But... I’m working on [insert thing here] and I don’t know how to write a devlog about that!”
Not everything is a devlog
A devlog leads to a design: a plan for how you will make something.
not a devlog
a week of activities
an error message you googled
a tutorial, followed step by step
a devlog
options, compared against criteria
a choice, and why
a plan to make it
Development questions lead to a technical design. That is still a design: you make choices.
What can a devlog be about?
Something doesn't work
The jump feels floaty. Testers don't notice when they get hit. Nobody finds the dash.
Something I need to learn
How do I make a fishing mechanic that feels satisfying? How do I teach the controls without a tutorial screen? How do I make a boss fight feel fair? How do I generate rocks so no two look the same? How do enemies find a path around walls?
A choice I have to make
Pixel art or 3D? Turn-based or real-time combat? Hand-made or generated levels?
Same five questions.
Make it a design challenge
The jump feels floaty.
→
Design a jump for my platformer that feels <the feeling I want it to have>.
Testers don't notice when they get hit.
→
Design feedback for the player character being hit, so that the player notices.
Nobody finds the dash.
→
Design a way to teach the player of my platformer to discover and use the dash, in a situation where the dash is the only solution.
Too small for a devlog
The game stutters on old laptops.
→
Fine development work, but no design: it is a how do I question, not a why question.
Our Git merges keep breaking the scenes.
→
The size of an error message you google. Make the topic bigger: design a CI/CD pipeline for our team.
Too small? Zoom out until there is something to design.
# Devlog 3 - Rocks that all look different ## 1. What is the problem? My asteroid game needs dozens of rocks, and drawing them by hand is too much work. I don't know yet how to generate a polygon that looks like a rock. Design challenge: design a rock generator for my asteroid game that makes rocks no two alike, which also work as their own collision shape. ## 2. How did I tackle it? Criteria: every rock looks different; edges never cross; looks like a rock to testers; works as the collision shape too. Library: the Godot docs for Polygon2D, and two articles on random polygons. Workshop: two prototypes. A: random points, then their convex hull. B: walk around a circle, giving each point a random distance from the centre. Lab: five testers pick which set of 20 looks most like rocks. ## 3. What is the result? [GIF: 20 rocks from A and 20 from B] [code: the B function, 12 lines] [commit] ## 4. What is the quality? A: edges never cross, but every rock is convex: no dents, more pebble than rock. B: rough, dented outlines, and edges never cross because the points go round in order. 5 of 5 testers picked B as "rocks". B meets all four criteria. ## 5. What is the next step? Implement B as the rock generator. Next cycle: big rocks that split into smaller ones along their own edges.
Your turn
Pick one thing from your current challenge: something that doesn't work, something you need to learn, or a choice you have to make. It has to lead to something you design.
- Write question 1, with the design challenge sentence.
- Write your criteria, before you know the result.
- Name three methods, from three different strategies.
then swap with your neighbour and check each other with the next slide
$ sleep 600
10:00
10 min
problem - criteria - methods
Check each other
| [ ] | Is it one problem, not a week of activities? |
| [ ] | Does it say why it matters for the game? |
| [ ] | Is there something to design, or is it a fix you can google? |
| [ ] | Are there criteria, set before the result? |
| [ ] | Are the methods named, from three different strategies? |
| [ ] | Will there be something to show? |
Sources
| methods | ictresearchmethods.nl - the DOT framework |
| methods | cmdmethods.nl - the CMD Methods Pack, for the design side |
| Celeste | Game Maker's Toolkit - Why Does Celeste Feel So Good to Play? |
| Mario | Kyle Pittman - Math for Game Programmers: Building a Better Jump (GDC 2016) |
| Hollow Knight | Lucid Tales - Game Dev Pantry: Hollow Knight, Basic Movement |
the GIFs and stills in this deck are short excerpts from the three game videos
