Inside Hiroyuki Imabayashi's Philosophy — The Cargo That Blocks Its Own Removal

Introduction

Almost everyone knows Sokoban — the weight of that single move, pushing a crate into its slot. On this site we have covered box-pushing solving tips and the lineage descended from it many times. Yet the words of its author, Hiroyuki Imabayashi, have gone strangely unread even in Japanese. Imabayashi released Sokoban in 1982 and founded the studio Thinking Rabbit.

I take him up now because rereading old game-magazine transcripts over hot bancha is a hobby of mine. Setting an interview from over forty years ago beside a very recent conversation, I notice how strikingly he has kept saying the same thing. What follows is not a tour of the game but a study of the person. Every quotation is limited to what he has stated publicly, and I mark my interpretations as interpretations.

Background — the man who pushed cargo after three sleepless nights

By his own account on the official site, Sokoban was born in "the spring of 1981, cherry petals in the air" (Sokoban official site, Greeting). After a friend left a Sharp MZ at his house he lost himself in computers and eventually bought his own PC-8001. In the 1983 LOGiN interview (in translation) he is described as so absorbed after three sleepless days that "when he tried to get up, he found his legs couldn't support him" (shmuplations trans., LOGiN 1983).

Sokoban began as a 1981 BASIC hobby prototype. "I made a Sokoban as a hobby in 1981," he says in a recent conversation (Sokoboxes conversation, 2020/pub. 2022). A distributor's salesman who saw it on a PC in his wife's family's shop told him, in his words, "it will sell, so make it," and Imabayashi bought a tape duplicator and committed to a product (official site). In 1982 he founded Thinking Rabbit, dubbing the tapes, packaging, and selling it all himself (LOGiN 1983). In Japan the game is so famous that its author is invisible, but the starting point was this thoroughly one-man labor.

Philosophy — the fun of the stage is the whole point

Across his statements, the most consistent thread is that the game's true body is the problem (the stage), not the system or the code. In a recent conversation he puts it flatly: "The system of Sokoban is simple. You can also make it in Basic. The important point of Sokoban is the fun of the stage." (Sokoboxes, 2020). The mechanism can be plain; the delight lives in the design of the stages.

That is why he laid out stages by hand on graph paper. In 1983 he admitted, "To be perfectly honest, I'm not the best programmer," while adding, "technology is something you can buy with money, so I'd rather people focus on developing their ideas -- and enjoying themselves, that's the most important thing" (LOGiN 1983). Technique is for sale; ideas and fun are not — and that ranking never wavers across forty years.

What strikes me is that early on he framed Sokoban as "sort of like Tsume Shogi" (LOGiN 1983) — the composer's stance of handing out one crafted problem after another, each with a solution built in. In this, I read the prototype of the "a stage is a work" sensibility that runs through puzzle design as a whole.

Obsessions — obstructing cargo, and the joy of watching people struggle

At the core of Sokoban lies a single idea. On the official site he writes that his concept was "to make the cargo that must be tidied away the very thing that obstructs the tidying" (official site, Greeting). The object to be cleared becomes the obstacle — this self-referential tension, combined with the irreversibility of a push that cannot be pulled back, produces that peculiar sense of getting stuck. His obsession is not decoration; it is this one structural point.

A second obsession is the players' reactions themselves. Recalling the days he let friends play the prototype, he writes that he "smirked while watching friends and acquaintances agonize, 'not like this, not like that'" (official site). Back in 1983 too, of the telephone hint line he said it was "a lot of fun for me to hear what players couldn't figure out" (LOGiN 1983). He does not finish at his desk; other people's struggle is his fuel.

His method of building stages is consistent as well. In the recent conversation he says, "when making a stage, we make it by trial and error. As a result of that trial and error, many stages remain unadopted," and looks back on the graph-paper work as "a very difficult task" (Sokoboxes, 2020). Mountains of rejected stages from trial and error — this is exactly the process today's best puzzle authors describe in unison.

Failure and how he moved past it — the 'breakable walls'

Imabayashi speaks frankly of his early oversights. "At that time, I didn't understand the depth of the Sokoban. I didn't expect the stage to be any harder" — thinking so, he put a "breakable walls" device into stages 11-20 (Sokoboxes, 2020), a gimmick where pushing from a certain side opened a hidden path.

It drew divided opinion. In his words, "it became a hot topic with pros and cons. Some people got angry that it wasn't a puzzle." His answer was clear: "Because I thought that noticing that trick was also a puzzle. Since then, there is no such gimmick." (Sokoboxes, 2020). He first defended it — noticing the trick is itself a puzzle — yet decided never to use it again. Not swallowing the criticism whole, nor rejecting it, but confirming his own standard and then withdrawing the device.

What interests me is that he even discloses the unreliability of his own memory. Granting permission for the conversation, he cautioned, "there are some parts of my memory that aren't accurate. We cannot guarantee the accuracy of the information. It's okay to write it as a just episode" (Sokoboxes, 2020). I take this as a stance that guards against mythologizing his own work.

A design dilemma — 'is that a puzzle, or a gimmick?'

The breakable-walls episode goes beyond a failure story: it contains a dilemma Imabayashi himself put into words. While players fumed that "it wasn't a puzzle," he held that "noticing that trick was also a puzzle" (Sokoboxes, 2020). What to call a "puzzle" and what to call an "unfair gimmick" — that line is a question authors handling hidden elements and narrative tricks still face today. He crossed it exactly once, at the very start of his catalog, and then stepped back on his own.

Another tension he voiced concerns limited skill and where to pick your fight. Asked why puzzle and adventure games, he answered, "We couldn't make advanced games because we weren't very good at programming at first. If you make it a thinking type like a puzzle or an adventure game, you can compete by ideas, I thought." (Sokoboxes, 2020). If you cannot win on technique, win on ideas. Framing the constraint not as a weakness but as the choice of a winnable arena feels very much like him to me.

Influences — a Hudson action game, tsume shogi, SF novels

Imabayashi is explicit about Sokoban's direct seed. "Sokoban was inspired other video game. It's a Hudson game. It was an action game in which luggage was moved as a wall to prevent radiation. I made that movement into a puzzle." (Sokoboxes, 2020). An action game in which cargo is moved as a wall to block radiation — he took only that "movement" and turned it into a puzzle. He names the game as Hudson's ALDEBARAN and even links a video of it (ibid., 2020). Not conjecture, but a lineage he identified himself.

As a design frame there is the tsume shogi mentioned above, and he welcomed a culture of many people composing problems (LOGiN 1983). He is candid about his private wellsprings too: in 1983 he cited Arthur C. Clarke's Rendezvous with Rama, calling SF novels and card games "the root of my inspiration," while adding, "I don't want to just convert them as-is to computer games. That would be boring" (LOGiN 1983). Extracting only the movement or structure rather than porting a source whole — the very way he takes influence mirrors the way he builds puzzles.

Kizuki's reading

From here on is my own reading as Kizuki, one step beyond his statements. I read Hiroyuki Imabayashi as an author who guards purity by subtraction. What he says over and over is a discipline of simple mechanisms, buyable technique, and never porting a source as-is; what he keeps is a single point — the fun of the stage and the structure of cargo that obstructs. That he once added "breakable walls" and then removed them himself is, I think, the clearest gesture of protecting that purity. He is a person who bares a work's core by taking away rather than adding.

And one more thing. When he writes that he "smirked" at friends agonizing, and even discloses the unreliability of his memory, I feel a lightness there — a willingness to release the work as a mere "episode" rather than a myth. He lacks the gravity that so often clings to authors of masterpieces. This lightness may be the very reason he could keep saying the same thing, unwavering, for over forty years — though I add that as my conjecture.

Closing

To meet Hiroyuki Imabayashi you need no detour. Try solving stage 1 of Sokoban as one problem someone placed by hand on graph paper. In the weight of a single move you cannot undo, nearly all of his philosophy is packed. Read the "Greeting" on the official site and you can trace, in his own words, even the spring air in which that problem was born.

To widen out along the lineage, read him alongside the box-pushing heirs this site has covered — Alan Hazelden, Arvi Teikari, Patrick Traynor, and Stephen Lavelle's Sokobond. You will see how the single structural point Imabayashi laid down has been inherited and transformed by so many authors.

Sources

Primary sources referenced in this article:

・shmuplations.com, “Thinking Rabbit – 1983 Developer Interview” (English translation of the LOGiN Dec. 1983 interview)

・Sokoboxes, “My conversation with Mr Hiroyuki Imabayashi” (2020 conversation, published 2022-05-22)

・Sokoban Official Site, “Greeting” (text written by Hiroyuki Imabayashi himself)