Petite Mort and SpeedIF : how do YOU do it ?

Authoring General Design Discussions
1

On thursday night, a subset of the french if community gathered for a brainstorming session. We had a lot of fun, and during the evening, one part of the session was to gather ideas on how to make a game in less than 4 hours.

Some thoughts were written down but in the end, no one was really convinced it’s really possible. How can you write, code and design something interesting in such a short time ?!
However, we know it’s possible because each year we have new “petite mort” games in Ectocomp and the ifdb/ifwiki is full of games from past SpeedIF. It looks like it’s a “lost art” for most of us though.

How would you tackle such a challenge ? (Bonus points if you have experience doing it in the past !)

Edit : (Malus points if you suggest using AI, of course)

17 Likes
2

I think the important bit is that the “design” part doesn’t have to count against the four hours! CSS and styling and brainstorming are all explicitly not part of the time limit, so you can spend as much time as you want on those before you knuckle down and start writing. The last time I did LPM this is how I tackled it – I made a detailed outline for the game structure and had a solid idea of what needed to go where. Since I was working in Twine I then spent about 15 minutes setting up the node structure for the game and the code to go from one to the other, and everything else was writing.

Scope is another important thing to consider! For the story, obviously, but especially for gameplay. My LPM game was very uninvolved as far as programming (because I barely knew how to use Twine at the time) but the story didn’t need it. I’m much better at programming now but were I to make a Petit Mort game that revolved around a trickier mechanic I’d want to spend some time making sure I understood how to approach it first, with an alternate plan to descope should it turn out to not be possible.

(It’s been ages since I last did Petit Mort so take this all with a grain of salt. I’ll start this year’s entry any day now, I swear…)

17 Likes
3

(Please, this is not another AI thread. It’s about how we could enable rapid story development)

I know some will find this distasteful, but one of the things I believe Sharpee will enable is rapid IF story development. Write a specification of your story similar to what Textfyre did 16 years ago and direct Claude to write the code including tests.

But even without GenAI, Sharpee might provide a platform that enables rapid story development. The fluent Forge layer will be similar to Inform 6, though Typescript is a dynamic typing platform. It’s an experimental platform to see if IF on a general programming platform can alleviate common parser platform challenges.

4

It’s worth noting that ECTOCOMP explicitly does not allow LLM use to speed up the process.

17 Likes
5

I dunno, four hours is quite a long time! At least if you’re not trying to make some sort of multihour megabase. I think the best way to treat it is as a kind of writing exercise. For my entries the past two years, I figured out the structure, characters, and topics beforehand, then allocated the available time towards filling out each segment within that structure. So each section of SPILL YOUR GUT was just how much I could write about that character in an hour.

14 Likes
6

i

I’ve attempted to speed-write a game for ECTOCOMP five times, and succeeded only the last two times. The absolute most important factor for me has been preparing a complete outline in advance. My tendency in the past was to write a partial outline and plan to fill in the gaps when the time comes. Then when the time comes, I realize this is not a gap, it’s a hole in the idea, and it will take a lot more than [four hours minus however time I’ve already spent] to fix.

ii

When the timer starts, write as fast as you can. It doesn’t matter if it reads like a first draft. The first draft will probably be fine anyway. Sometimes it’s even better than if you spent more time overthinking it.

iii

Don’t get distracted by fancy new ideas. If I have a cool idea for a feature to add, I put it on a list to look at if I have time at the end. Usually there is no time, but sometimes small improvements make it in. And you can always put them in an expanded version of the game later!

14 Likes
7

I don’t think I partecipate in a spedIF: sure way for extreme bad english ! :wink: :smiley:

Seriously, I think that the first ingredient ought to be a custom skeleton containing also the favorite setup/quirk (e.g. my custom skeleton for inform 6/7 has implemented a READ verb, because I consider READ different from EXAMINE) and all these little generic things which give a more polished look.

Dunno if can be construed as cheating, but one can kept templates (not in TADS3 sense) for rooms, objects &c. which can be copypasted and used for “fill-the-blanks” quick coding. (modern editors has often a “snippet collection” system where said templates can be available with quick keystrokes…)

Best regards from Italy,
dott. Piergiorgio

1 Like
8

If anyone is interested in the Textfyre design format:

That contains several versions of the Shadow in the Cathedral design document. Jon Ingold was already a rockstar IF author. I’ve always wondered if he’d been designing his games similarly or did this process inspire him.

1 Like
9

Templates and pre-written code are allowed and don’t count towards the four hours per the rule! I believe Andrew Schultz has used this to great effect in the past with speed wordplay games.

12 Likes
10

Plan out as much as you possibly can in advance! Maps! Flowcharts! Puzzle designs! Everything except the actual code and words. So basically what others have already said here.

I’ve started doing this for IFComp games as well and I find it very helpful.

11 Likes
11

So, I wrote several things in a short amount of time: from 36 hours VN, visuals and sound included to approximately 3 hours IF on a train, and obviously my Ectocomp 2025 entry (which I won’t link since entries aren’t publicly available yet) so there’s a bit of a range. I can’t speak about parsers and such because I’m still learning this stuff but I can say how I’m doing my stuff.

  • Don’t do anything wildly complicated. The more branches, rooms, plotpoints, characters, the more things you have to describe, write about, and code in. Set yourself limits.
  • Plan! You don’t need to write it down if you don’t like it but have at least a vague idea about where you’re going with things, how much time you have for particular segment/scene, all that fun stuff.
  • Also! It’s not necessary but it’s great if you have some sort of a reminder about how much time you have left instead of just letting a clock go on. Maybe a playlist with a specific timeframe where you know that “oh, this song means I still have 30 minutes”, or timers set in specific intervals. It can really help when you have a reminder that doesn’t depend on you focusing on time, since then you have all focus pointed towards writing and coding instead of checking how much time has passed.
  • Get yourself a theme to explore — a sort of main thing that you’re writing about, a question, a character, some type of a dilemma, anything that you find interesting. In take me to the lakes where all the poets went to die, I participated in a jam which chose the theme for me (you’re not them). In the train will always pass you by, I wanted to tackle the theme of rural exclusion. Knowing what you want to achieve with the story can make or break things. It doesn’t mean your story has to be about one thing and one thing only but having a central point really helps.
  • Write. Literally just write. You won’t make the next internationally acclaimed novel in 4 hours so don’t bother trying. You need to accept that what you make probably won’t be perfect. Set aside some time to check for typos, coding mistakes, and glaring grammar errors.
  • Something will always slip through. It doesn’t matter how thorough you thought you were when you were typing the text, some kind of a mistake will always slip through. Drop your perfectionism at the door, you can pick it up after you’re done. Don’t beat yourself up over what you could’ve done because what you did was your best.

I might edit this post later if I remember something else but that’s what I have in mind for all of my “fast” stuff.

17 Likes
12

It’s kinda wild to consider early SpeedIF events allowed only 2 hours for development, and had no carve outs for brainstorming or styling.

12 Likes
13

Wow. So, more of a “Ready … Set … Go!” sort of thing. The clock ticks for 120 minutes and you just run with the first idea that pops in your head as far and fast as you can until the bell rings.

8 Likes
14

It was a fun format as long as you don’t mind that it tended to produce zany games without a lot of thematic consistency (with one or two exceptions). Remember that these were all parser games, too; choice games weren’t a thing in that community at that time.

I’ve toyed with the idea of running a speed-IF event under something approximating those original conditions as it’s a great way to overcome prevarication and just write something. Even the idea of entering LPM has a certain level of pressure attached to it because if you didn’t put up something good in the four hours, does that mean you should have done better prep work? How do you know when your prep is good enough?

12 Likes
15

Well, having been around for the tail end of that era, I can say that it’s partly because styling wasn’t a thing that was on people’s radar at all! These were parser games and the expectation was that people would download them and play them in their preferred interpreter with their preferred settings.

I wasn’t around for the early early days when the announcement of the event theme and the deadline were literally two hours apart, but the turnarounds were still quicker in the early 2010s and there was an assumption that you were not doing extensive pre-planning, and honestly I still kind of operate that way. I don’t outline at all, actually! But I kind of thrive on the adrenaline of an impending deadline, so if your brain doesn’t work that way then you absolutely should not do what I do. Also, it does come back to bite me occasionally; no one commented on this at the time but the last couple scenes in Die Another Day are a bit shorter and more rushed because I realized I’d overreached a bit and was running out of time.

I definitely agree about making the gameplay simple. My parser speed IF games are mostly about walking around and looking at things, while my Twine LPMs each have 2-3 variables that increment based on your choices and then you get different endings depending on the state of those variables, and that’s really it.

11 Likes
16

Oh, I meant to say and forgot—if you are going to be like me and not outline, it helps if you have a preexisting narrative to lean on. Wedding Day and Die Another Day were both based on short stories I’d tried to write (though none of the original text is in either game) and Something Blue is a fairytale retelling.

(Also, a fun fact about Die Another Day is that I did essentially do it old-school style, in one sitting on the day of the deadline. This is why it was so unsubtle and so autobiographical, because I didn’t really have time to make things up out of whole cloth. But I guess people enjoyed that!)

12 Likes
17

I wasn’t going to chime in but it seems like people are mostly saying “plan ahead” (or they were when I started writing this) so…

I barely ever write IF: I tend to say that I’m not a fiction writer (not because I doubt that I can (learn to) write half-decent fiction, but because writing fiction has never grabbed me enough to prioritize it over however many other hobbies).

But I have done a couple tiny IF (or IF-adjacent) things, and most of my itch.io page is graphical games that I’ve made in 1-8 hours (or that started that way and I then polished/extended).

And for me it’s not about planning ahead but about asking what I CAN do in a small amount of time and what I can make out of that. And also just… going for it and ruthlessly side-stepping anything that gets in the way instead of getting bogged down in trying to make something good.

So for instance Walk in the Rain was me wondering about limiting a Carta game to a digital implementation and what that might look like: it’s a very minimal prototype which has basically no mechanics so it was (I think?) about 90 minutes of coding and then I just sat down and wrote whatever – we have a farm, we’ve been here for 18 years, we’re outside in all weathers, so I just wrote as many little rainy-day events as I could think of. IIRC it was about 3.5 hours total, idea to completion.

I tend to be pretty bad at “write a story” but pretty good at “write 30-50 words about something that could happen when you’re out in the rain” so that’s another way I’ll try to write quickly. Come up with 50 hat descriptions. That kind of thing.

But also yeah, scope down. No, scope down more than that. Put some features back. That’s still too many features.

So Walk in the Rain just grabs 24 text snippets from a shuffled set of… more than that (?) and lays out a four by six table of “cards” and then lets you move around between them, and when you move to a card it adds that card’s text to the text output.

Exquisite Poem Generator was a collaboration with a bunch of people, but again, the code is pretty simple and then it’s all writing. You have a “lock” where you enter a four-letter “code” and it uses each letter to grab a line from 26 different poems, mashes them together and shows the result to you. I spent I think about an hour on the implementation: scribbled two hearts on paper, photographed them, lined them up, wrote the code, dumped everyone’s poems in there, and go.

Again, with speed-gamedev I usually start with one thing. And it’s better if it’s one thing you know you can do. RGB Jet was a One Hour Game Jam entry: I made a single point that moved around, and had sideways friction based on its speed so it acted kind of like an airplane wing, and I made it accelerate toward the mouse. It’s something I’ve done before, I know the movement is amusing to play with. And then I had 15 minutes left so I put red/green/blue circles on screen and if you fly through one of them it increments (wrapping) that component of the background color.

Spacemail Chimp was also in my one-hour phase: one button, latch on to the nearest “star” and restrict your distance so you swing around it. Again, simple vector math, it’s something I like and have done a bunch of. No screen scrolling, nothing. I got that working fast enough that I added some “envelope” rectangles that you could pick up and “deliver” when you swung through them, and a count-up variable for how many spawn at once.

If you have four hours, what can you code in one hour? A quarter of the time is about right, I find. If you’re working in a parser engine, can you make a couple rooms, and a button to press that… unlocks a door? Cool, now go make a game about that. What kind of silly story can you tell with just that one mechanic? Or maybe your one mechanic is that something happens when you put an object down in a particular place.

In choice IF, can you find something to make the choices about and just brainstorm a bunch of those? Dick McButts, for instance. All the choices are about the same thing, they all have two options, one lets you keep going, the other ends the game and you have to back up. No state tracking, right? Just ridiculous scenarios; how many can you come up with in four hours?

And then just… be willing to side-step any obstacles and don’t get hung up on them. If you’re experimenting with a mechanic, do that first. If you don’t do it first and you get in the middle and you run into trouble implementing the mechanic, ask yourself how you can cut it. If you cut it, how can the story you’re writing still continue? It’s not about making something good, it’s about making SOMETHING. Anything.

Although I usually don’t do planning ahead, so that changes things some. I do have a Type-Help inspired static deduction game I’m hoping to do for Ectocomp in the next few days and I have put about 75 minutes of planning into that: made up a tiny scenario, broke it down into a handful of timesteps and which groups people are going to be split up into, what’s generally going to happen in each scene. No commands other than “enter filename.”

So I’m expecting I’ll spend about an hour implementing it, I’ll sit down and bang out some words for each scene, and kinda feel my way through how they connect (and exactly which ones connect)? IDK. I’m a math guy, I think rules are fun but I also think they’re all made-up so… where was I going with that? Oh, right: I like rules and patterns and planning but I also tend to trust my intuition a lot so I kinda alternate just winging it and then coming back from the other end to see what the patterns are and making it fit a scheme, and trusting that I’m smart enough to make it work out.

We’ll see. It’ll probably be terrible. But that’s fine: the real value of speed-gamedev is what you learn about completing a thing, not about the final object.

My artist brother and his friends did a thing for a few years where they’d get together every day for half an hour, they’d each throw in a prompt and then randomize who got who else’s, and then set a 30-minute timer and draw something. And it grew out of someone saying that commercial artists have a big tendency to get into a rut: people keep hiring you to do the thing that you’ve demonstrated you’re good at. So this was intentionally an exercise in giving yourself room to experiment, to try and probably fail at things, to keep from getting stale.

And then one year when he went on vacation the other guys made a Facebook group that grew to like 120K people at one point (?) and then of course social media makes it a competition about the quality of the object which completely misses the point. Oops.

OK, that was a lot of stupid words, but… I think you don’t have to plan ahead, just:

  • Pick one mechanic, or gimmick, or choice type, or something.
  • Something that you can create one of in far shorter than the time limit.
  • What can you do with that?
  • Just keep going, don’t stop or look back; if something doesn’t work, roll with it and keep going.
17 Likes
18

I have participated in the 48-Hour Film festival once where you create, shoot, edit, and present an 8-minute movie in two days. It’s super-crazy like a reality competition but a ton of fun and people manage to do it every year it’s been running.

One thing to remember with Speed-IF is “scope small.” As @JoshGrams says above, focus on one neat mechanic or element. Speed-IF is often not going to be as story-focused with tons and tons of prose. People know the games have been made quickly and aren’t usually as harsh judging them knowing the constraints.

The other thing about Speed-IF is it’s not a time-commitment. Most people can find four free hours in their busy life to try to make a game. The thing to keep in mind is it is sort of a stunt, and you might fail. The good thing is Ectocomp has the Grand Guignol category so if you fail the Speed-IF due to the time requirement, you can still enter the game.

My Ectocomp entries were incredibly tight. Going Down was just concentrated on the “Elevator Game” Creepypasta/Urban Legend and simulating that.

My other one Psychomanteum was built just on me playing with an Inform 7 extension that allowed you to write text on a notepad and store it. That’s the one where I got stuck and couldn’t make it work in time to enter it as Petit-Mort, but the next year I opened it up, instantly figured out what was wrong, and was able to enter it as Grand Guignol - I bet it’s probably the only Ectocomp game to have a year-long development time! (Even though it was only like 6 hours total in that year.)

8 Likes
19

As another example of an adjacent community effort, there is the Seven Day Roguelike Challenge every year, where participants make a Roguelike game in seven days. If you think of your Nethacks and Angbands that have gestated over decades, this seems impossible. But the common advice is to have your tools ready. These are not the place to try out new technology or tackle particularly technical problems. Have a single idea and execute it.

So I think the idea is: have a framework ready, have it ready to build, have a scope, probably halve that scope and then write like the Dickens.

9 Likes
20

Yes, I can verify it helps a ton … I also use the planning heavily. And when I think of writing code, I try to write different similar types of code at once, so I can cut and paste.

One other thing, for narrative stuff I use speech to text. while speaking takes time from the 4 hours, but it’s faster than even the fastest typing, and it is less fatiguing too. It’s been really useful this year.

I also break up my activities a lot, too. I say, okay, focus on this part for 5 minutes.

7 Likes