Pikachu Volleyball, rebuilt from a 1997 binary by reading the machine code

What the repository actually is

Pikachu Volleyball, called 対戦ぴかちゅ～　ﾋﾞｰﾁﾊﾞﾚｰ編, is an old Windows game developed by SACHI SOFT and SAWAYAKAN Programmers together with Satoshi Takenouchi in 1997. The gorisanson/pikachu-volleyball repository is not the source code of that game. It is a reimplementation in JavaScript, and the source for it was obtained by reverse engineering the core parts of the machine code, including the physics engine and the AI, of the original and rewriting them in JavaScript.

That distinction is the entire project, and it determines how you should read the code. When you open src/resources/js/physics.js, you are looking at JavaScript that a person wrote to match what a disassembler produced, not at a translation of original source. The original source code for the 1997 game does not exist in this repository, and the author did not have it.

The result is playable in a browser at gorisanson.github.io/pikachu-volleyball/en/, and the repository carries a screenshot of the running game. The primary language is JavaScript, the default branch is main, and there are no GitHub releases. The last push to the repository was on 2026-10-02.

There is a licensing point to be aware of, and it is the first thing to check if you are considering anything beyond reading the code. The package manifest declares the licence as UNLICENSED, and the repository metadata reports the licence as unknown. The original game has named copyright holders. Whatever the legal position is, the practical signal from the package itself is that this is not a permissively licensed codebase, and that is a deliberate choice by the author rather than an oversight.

Running it locally, which takes four steps

The project is a webpack application, and the local setup is short enough to follow end to end.

First, clone the repository and enter the directory:

git clone https://github.com/gorisanson/pikachu-volleyball.git
cd pikachu-volleyball

Then install the dependencies, and the documentation adds a note that if errors occur you can try with node v16 and npm v8:

npm install

Next, bundle the code:

npm run build

And finally, run a local web server and open it in a browser:

npx http-server dist

The documentation says that in most cases the URL would be http://localhost:8080, and that the exact URL is supposed to be found in the messages printed on your terminal. That is a detail worth noting, because the default port assumption is the kind of thing that breaks when another process already holds 8080, and the printed message is the authoritative answer.

The package scripts are minimal. The build script runs webpack with webpack.prod.js, and the start script runs webpack serve with webpack.dev.js, so the development server is available as well as the static bundle. The test script is the default placeholder that echoes an error and exits, so there is no test suite. The tooling is webpack 5 with webpack-merge for the shared, dev, and prod configurations, html-webpack-plugin, copy-webpack-plugin for copying static resources, clean-webpack-plugin, webpack-dev-server, workbox-webpack-plugin for the service worker, eslint with the prettier plugin, and prettier itself.

Where the physics, the AI, and the rendering live

The game structure section splits the implementation into two parts, and it names the file for each.

The physics engine, which calculates the position of the ball and the players, is in src/resources/js/physics.js. The same file also contains the AI, which determines the keyboard input of the computer when you are playing against the computer. The AI is worth noting as a design decision: the computer opponent is not simulated as a separate entity with its own logic. It produces keyboard input, exactly as a human would, and the same physics code moves it. That means the AI cannot do anything a player cannot do, and any imbalance between them is a balance problem rather than a cheat.

The rendering uses the PixiJS library, and the manifest confirms it with a long list of scoped packages at version 6.4.2, including @pixi/core, @pixi/display, @pixi/sprite, @pixi/spritesheet, @pixi/sprite-animated, @pixi/ticker, @pixi/loaders, @pixi/prepare, @pixi/settings, @pixi/constants, and the canvas renderer packages @pixi/canvas-display, @pixi/canvas-prepare, @pixi/canvas-renderer, and @pixi/canvas-sprite. Sound is @pixi/sound at 4.2.1.

The rest of the detail is in comments in src/resources/js/main.js, which the README points to for other details.

The reverse engineering method, in detail

The most transferable part of this repository is the method section, which lists the tools and, more importantly, explains what each was used for.

Ghidra was used for decompiling the machine code to C. The README is candid that the first look at the decompiled C was incomprehensible, and it gives the reason: the variable names such as iVar1 and iVar2 and the function names such as FUN_00402dc0 and FUN_00403070 in the decompiled output are meaningless. Those names are not a defect of the decompiler, they are what a decompiler produces when it has no debug symbols to work from, and no amount of reading makes them meaningful on their own.

Cheat Engine is what made it readable. The approach was to find the memory location of the significant variables, specifically the x and y coordinates of the ball and the players, and then read from those locations. Once the coordinates were identified, the decompiled C could be read as behaviour, because the values flowing through it were recognisable. That is a specific and effective technique for reverse engineering a game with no debug symbols, and it is more transferable than the tool list itself.

OllyDbg was used for altering a specific part of the machine code, and the example given is instructive: making a slower version of the game so that it would be easier to count the number of frames of the Ready? message at the start of a new round. Slowing the game down to observe timing is a classic use of a debugger, and here it was applied to the original executable rather than to a reimplementation.

Resource Hacker was used to extract the assets, the sprites and the sounds, from the original. And one file's provenance is stated precisely: the physics source was gained by reverse engineering the function at the address 00403dd0 of the original machine code.

The one deliberate deviation, and what it reveals

The README documents a single intended deviation from the original game, and it is a small one that tells you something about the reimplementation.

In this version, if there is no keyboard input, an AI versus AI match is started after a while. In the original game, that match lasts only for about 40 seconds. In the JavaScript version there is no time limit on the AI versus AI match, so you can watch it as long as you want.

The change is small, but the reason for it is not a gameplay one. The AI versus AI match is the only part of the game you can watch without input, which makes it the natural place to study the AI and the physics. In the original, that observation window was 40 seconds. Removing the limit turns it into a debugging and demonstration tool, which is exactly what a reimplementation needs while the physics constants are being tuned against the original.

That is the only documented behavioural difference, which says something about the fidelity of the port. If the physics, the AI input generation, the timing, and the asset handling all match, then the remaining work is the rendering layer, and the rendering layer was rebuilt on PixiJS rather than copied.

It also means the physics constants in src/resources/js/physics.js are the closest thing in this repository to the original source, and they are the place to look if you want to know how the ball bounce, the player movement, and the AI decision logic actually work.

Against the original, and against a from-scratch remake

The comparison with the original Windows game is the obvious one, and it has an obvious limitation. The original is a 1997 Windows binary, and running it today means running it in an emulator, on a system where it was never meant to run, with whatever compatibility layer is available. This reimplementation runs in a browser, which is the difference between a project you can open and one you need a virtual machine for.

The comparison with a from-scratch remake is the more interesting one, because the method here is the difference. Writing a volleyball game in JavaScript from scratch would start with a physics model, a rendering approach, and a design. This repository starts from a working artefact and asks what it actually does, which answers questions a designer would never think to ask. How fast does the ball accelerate at contact, is the collision detection per frame or swept, how does the AI decide where to move when the ball is on the other side of the court. Those answers came out of the binary.

What the reverse engineering buys is fidelity that a remake would not have, because the constants are the original's. What it costs is the readability of the code, since a decompilation reassembled by hand is going to be structured like the original machine code's structure rather than like something a designer would write. The physics file is a faithful reconstruction, not a clean model, and anyone extending the game would be working with code whose shape is dictated by a 1997 executable.

The last consideration is the legal and ethical framing, which the project handles explicitly by crediting the original developers and publishers. A reverse engineering project of this kind is a legitimate learning artefact and the method is instructive, but the UNLICENSED marker in the package manifest means the code itself is not offered for reuse in a way you can rely on.

Editorial conclusion

Adopt this repository as a reference for how a small game physics engine and its AI were recovered from a Windows binary, and as a runnable example of PixiJS plus webpack. Do not adopt it as a base for a commercial game, because the package is marked UNLICENSED and the original game belongs to SACHI SOFT and Satoshi Takenouchi. Verify first that the physics tuning in src/resources/js/physics.js matches the original before treating it as a faithful port, since it is a decompilation rather than the original source.

Frequently asked questions

Official sources

1. gorisanson/pikachu-volleyball on GitHub
2. Issues
3. Project website
4. README