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 problem: why it mattered, what you tried, what you found, what you learned. It links the other two together.
One problem per devlog.
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 |
ictresearchmethods.nl - the DOT framework: library, field, lab, showroom, workshop
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.
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 my advice?
to others
Make falling faster than rising, and let the release of the button cut the jump.
next step
Add coyote time and a jump buffer, then test again with five new players.
# 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 my advice?
Fall faster than you rise; let go to cut the jump. Next: coyote time and a
jump buffer, 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!”
You can write a devlog about anything!
Are cats liquid?
a real physics paper, and a 2017 Ig Nobel Prize
$ cat liquid.md
The evidence
The Deborah number
De = τ / T
| τ | how long the cat takes to fill its container |
| T | how long you watch |
| De < 1 | liquid: you waited long enough for it to flow |
| De > 1 | solid: you looked away too soon |
a young adult cat: τ between a second and a minute - Fardin, "On the rheology of cats", 2014
# Devlog - Are cats liquid? ## 1. What is the problem? The internet is full of cats in jars, sinks and boxes, and people say cats are liquid. Are they? It sounds like a joke, but what makes something a liquid, and not a solid? ## 2. How did I tackle it? Criterion first: a liquid takes the shape of its container. Library: rheology, the physics of how materials flow. Field: the internet's cat photos, as observations. ## 3. What is the result? The Deborah number, De = τ / T: how long the cat takes to fill the container, against how long you watch. Under 1 it is a liquid, over 1 a solid. For a young adult cat, τ is between a second and a minute. ## 4. What is the quality? The method is the field's standard tool, not one made up for cats. Published in Rheology Bulletin (2014); 2017 Ig Nobel Prize in Physics. ## 5. What is my advice? Cats are liquid, if you give them the time to become liquid. Next: does a cat's τ change with its age?
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. The game stutters on old laptops. Our Git merges keep breaking the scenes.
Something I need to learn
How do I generate rocks or terrain so no two look the same? How do I make a fishing mechanic? How do enemies find a path around walls? How do I save and load progress? How do I build a dialogue system with choices? How do I add local co-op with two controllers?
A choice I have to make
Which engine for the client's project? Pixel art or 3D? Turn-based or real-time combat?
Same five questions.
# 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. ## 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. ## 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 my advice? Go round the circle in order and only randomise the distance. Next step: make big rocks 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.
- Write question 1, with the design challenge sentence.
- Write your criteria, before you know the result.
- Name one or two methods you will use.
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? |
| [ ] | Are there criteria, set before the result? |
| [ ] | Are the methods named, and do they fit? |
| [ ] | Will there be something to show? |
Sources
| methods | ictresearchmethods.nl - the DOT framework |
| 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
