bV Flipbook — Development History & Engineering Effort

Project review | 22 September – 11 October 2026

bV Flipbook (AdamFlipbook) is our custom-built digital magazine reader for bversion.com, developed to replace the commercial DearFlip reader and support your collection of scanned computer magazines, including《電腦時代》.

Unlike simply installing a WordPress plugin, we developed our own reading engine, PHP backend, magazine library, database statistics and WordPress integration.

1. Development timeline

Development started: 22 September 2026

Working platform

Dates are based on our recorded discussions. Hours are engineering estimates, not measured timesheets.

Estimated development effort

~65–70 hours

Central estimate; includes our joint debugging, testing, deployment and iteration, not elapsed calendar time.

Estimated effort by development stage

Central estimate in active work hours

2. How we built it from scratch

Stage 1 — From DearFlip to our own architecture

• We initially considered improving the existing DearFlip/PDF workflow, but decided to develop a standalone reader that we could fully control.

• The important decisions were to retain original PNG scans, avoid requiring PDF conversion for reading, and keep the core reader independent of WordPress.

Stage 2 — Build the QNAP PHP image API

• We tested direct page delivery from the NAS using PHP, with files stored separately from the public web application.

• One verified example was – CA02 — Page 43 API

• This proved the browser could request a particular magazine page without loading the entire book.

Stage 3 — Create the JavaScript flipbook reader

• We developed the reader around book metadata and page images rather than relying on DearFlip.

• The design included page turning, navigation, zoom, fullscreen, mobile support, and lazy loading/preloading so hundreds of pages would not need to load simultaneously.

Stage 4 — WordPress bookshelf

• We created a WordPress plugin that displays the magazine collection and launches our own reader.

• The initial v0.1.0 bookshelf tested magazines CA03, CA04, CA05, CA06, CA08, CA11 and CA13. We then corrected URL handling in v0.1.1 and advanced to v0.2.2/v0.2.3.

Stage 5 — Reading statistics and backend separation

• We established the path from the reader through stats.php to the MariaDB bvflipbook database.

• We also moved private database configuration to /share/WebData/bVersionFlipbook/, separating credentials from public application files.

Stage 6 — Real-world debugging

• This became one of the most time-consuming phases. We investigated the overlay Close button, table-of-contents behaviour, browser history, and mobile performance.

• By October 1, our WordPress plugin had reached v0.3.13. We preserved the two-step mobile close behaviour: first close the TOC, then close the flipbook.

• We also identified performance concerns with books of approximately 250 pages and planned testing against smaller 96-page books.

3. The architecture we created

The biggest architectural achievement is the separation of the reading engine, storage, statistics and WordPress presentation. That means the reader can evolve without rebuilding the magazine library or making WordPress responsible for every function.

4. Our development approach

Our approach was incremental rather than trying to build everything in one release.

1. Establish a working standalone proof of concept.
2. Validate direct PNG page access through PHP.
3. Add the reading interface and book metadata.
4. Integrate the reader into WordPress.
5. Add database statistics and protect private configuration.
6. Test on actual magazine collections and fix one problem at a time.

This last principle became particularly important in October: one change → test → confirm → next change.

We also deliberately deferred features such as Last Page Read, bookmarks, Go-to bookmark, sharing links and PNG page sharing until the Close behaviour and mobile performance were stable. Those should not be counted as completed functionality in this estimate.

5. What was achieved, and what remained

6. Engineering effort assessment

The key distinction is that we did not build an emulator or an image-rendering library from the ground up. We built the application system ourselves using browser technology, JavaScript, PHP, MariaDB and WordPress.

My assessment is that approximately 65–70 active engineering hours is a reasonable central estimate for the working bV Flipbook platform through the last recorded development stage. It is not an audited total, and I have no confirmed additional development hours after October 2.

For a project originally motivated by replacing DearFlip, the result was considerably broader: an independent digital magazine publishing and reading platform, with its own backend and room to expand beyond WordPress.

AppleII_HOF — Development History & Work-Hour Estimate

Project retrospective | Late September – 3 October 2026

AppleII_HOF was our first attempt to turn a classic single-player computer game into a worldwide, shared high-score competition, while preserving the original Apple II gaming experience.

We started with a simple question: Can we run an Apple II game directly on your website?

Within several days, we had built and tested a much more ambitious system: an Apple II emulator, individual player disk sessions, server-side score extraction, a web leaderboard, and a shared Hall of Fame written back into the original game’s disk image.

1. Development timeline

Hours are reconstructed estimates of our active development and testing, not measured timesheets. They include your hands-on work and our joint debugging, but not two separate people’s hours added together.

Stage 1 — Concept and architecture, 29 September | Estimated 2–3 hours

• We investigated Apple II emulation, how CPU opcodes, registers, memory and I/O work, and whether WebAssembly could execute an emulator in the browser.

• Decision: Reuse an existing emulator rather than writing an Apple II emulator from scratch.

Stage 2 — Build the web emulator, 29 Sep – 2 Oct | Estimated 5–8 hours

• We selected web-a2e, prepared the Windows build environment, installed Node.js, Emscripten, Ninja, CMake and Git, and built the JavaScript/WebAssembly emulator.

• Achievement: Successfully generated a2e.js and the WASM binary, allowing the Apple II emulator to run in a browser.

Stage 3 — Reverse-engineer Sea Dragon scores, 2 October | Estimated 4–6 hours

• We used an original Sea Dragon disk image, investigated where the game stored its Hall of Fame, and searched for known score data, including a test score of 1,425.

• The important change in approach was to work with the game’s native disk-based score records, rather than relying on screen recognition or rewriting the game.

Stage 4 — Shared Hall of Fame backend, 2–3 October | Estimated 6–9 hours

• We designed and implemented the master disk/session disk approach, PHP gateway, backend score processing and shared leaderboard.

• Each player could use a separate disk session, while qualifying scores were merged into the shared master disk.

Stage 5 — Browser integration and validation, 3 October | Estimated 5–9 hours

• We connected the public browser emulator through the PHP gateway to the QNAP backend, worked on session handling and score submission, and tested the complete game-to-server-to-game cycle.

• Key milestone: A score survived a fresh browser session and appeared inside Sea Dragon’s original Hall of Fame.

Stage 6 — Clean baseline, 3 October | Estimated 3–5 hours

• We established a clean baseline with an empty master Hall of Fame and leaderboard, while preserving the functioning emulator, backend, PHP gateway and score-persistence mechanism.

• This gave us a working foundation for future Apple II games.

2. How the architecture evolved

Our most important architectural decision was not to modify the original game executable to communicate with the internet. Instead, we made the original disk image the bridge between the game and the online competition.

The original design also kept the master DSK in WebData, with a separate session disk for each browser/player identity. This avoided players directly overwriting the shared master.

3. Work-hour breakdown

Estimated active development hours

Midpoints of estimated ranges, total approximately 33 hours.

My central estimate is approximately 33 hours, spread across several days. That is a realistic estimate, but we cannot establish the exact hours from chat timestamps alone.

4. What we achieved versus what remained

The distinction is important: we reached a working end-to-end production-style baseline, not a fully validated large-scale public service.

5. Why this project mattered

AppleII_HOF proved three concepts that later influenced Arcade1LC.

First, an original retro game could run inside a modern web browser without rewriting the game.

Second, game-native score data could be extracted and managed by an external server, turning an offline game into a worldwide competition.

Third, a shared leaderboard could be integrated back into the original game experience, rather than existing only on a separate website.

The technical approaches subsequently diverged. AppleII_HOF used disk-image score persistence, while Arcade1LC moved toward live MAME memory inspection, game-specific configuration, and one-life challenge enforcement.

Overall assessment

What made AppleII_HOF particularly interesting was that we didn’t simply embed an emulator on a website. We built a mechanism for an approximately 40-year-old game to participate in a modern, shared online Hall of Fame while retaining its original gameplay and score display.

That was the technical foundation and proof of concept that helped make the more ambitious Arcade1LC project possible.

Arcade1LC — Development History & Engineering Effort

Project retrospective | 3–11 October 2026

ARCADE 1 LIFE CHALLENGE ONE LIFE · NO CONTINUE

From experimenting with a browser-based MAME emulator to building a self-hosted, multiplayer competitive arcade platform with shared leaderboards, player accounts, rankings and automated Facebook announcements.

1. Executive summary

2. Development stages

Stage 1 — Concept and feasibility, 3 Oct Estimated 3–5 hours

• We started with a question: could a real arcade game run inside a browser, and could players worldwide compete on a shared Hall of Fame?

• We selected MAME, Emscripten and WebAssembly rather than rewriting the original arcade game. Raiden became our first experimental title.

Stage 2 — Building MAME for the web, 3–4 Oct Estimated 8–12 hours

• We established the WSL Ubuntu build environment, Emscripten toolchain, SDL3 dependencies and MAME driver configuration.

• Successfully compiled raidenhof.html, raidenhof.js and a roughly 25 MB WebAssembly module.

• Breakthrough: A genuine arcade machine could now execute in a browser without a server running the game for every player.

Stage 3 — Reverse engineering game memory, 4–6 Oct Estimated 12–18 hours

• This was one of our most technically demanding stages.

• We built experimental score-finding tools, monitored emulator memory, identified score values, investigated stage information and tested death/game-over detection.

• We also experimented with maximum weapon power and invincibility for debugging. Raiden’s maximum displayed score was established as 99,999,999.

• Important lesson: A score appearing in RAM is not sufficient evidence of a completed, valid game.

Stage 4 — One-life challenge enforcement, 4–7 Oct Estimated 8–12 hours

• We developed the logic for the one-life, no-continue challenge and reliable score submission after death.

• Several attempts failed because the arcade game’s Game Over animation continued after the player lost their life.

• We tested multiple approaches before retaining the proven TEST032 timing baseline, with a 30-second post-qualification window replacing the insufficient 10-second window.

• Approach: Observe the game’s real internal state rather than relying exclusively on visible screen changes.

Stage 5 — Generic multi-game architecture, 5–8 Oct Estimated 9–13 hours

• We moved beyond a Raiden-only demonstration.

• The design became configuration-driven: each game supplies its ROM settings, score memory definitions, stage information, leaderboard rules and score limits through configuration.

• We established a generic HTML frontend and PHP leaderboard backend, preserving the DEV018 player-interface baseline.

• Major architectural decision: Adding a new game should primarily involve configuration and validation, not rewriting the platform.

Stage 6 — Player Center and competition, 6–9 Oct Estimated 9–13 hours

• We developed the wider player experience: registration, profiles, place flags, age groups, searchable selectors, series navigation, Hall of Fame and King rankings.

• We also developed King of the Kings rankings, allowing players to compete across multiple arcade titles rather than only one game.

• The platform evolved from a score table into a competitive gaming community.

Stage 7 — NAS hosting and public website, 6–10 Oct Estimated 5–8 hours

• We deployed to the QNAP NAS, configured the Arcade1LC subdomain and worked through virtual-host and favicon issues.

• We discussed PHP gateway security, protecting WebData, exposure of server files, NAS capacity and the implications of serving many simultaneous players.

• The public address became arcade1lc.bversion.com.

Stage 8 — Social integration and launch controls, 9–11 Oct Estimated 11–14 hours

• We implemented and tested server-side Facebook announcements for new Kings and King of the Kings results.

• We developed the Founding 50 launch concept: first-come-first-served registration, a server-enforced 50-player cap and permanent F001–F050 identities.

• We also refined leaderboard refresh behaviour, UI controls, score submission flow and registration/player-count presentation.

3. Estimated work hours

The following is a task-based reconstruction. Several stages overlapped on the same day.

Estimated hours by development stage

Midpoint of estimated active effort for each stage

These are combined project-effort hours, not 80 hours independently spent by each of us. Your testing, debugging, architecture decisions and deployment were essential; my contributions included code generation, analysis, troubleshooting and design iterations.

4. How our development approach changed

Our engineering methodology evolved as the project became more complicated.

Experiment first – Build a small MAME proof of concept and establish that the browser emulator works.

Measure and reverse engineer – Use RAM inspection, debugging features and repeated real gameplay to discover reliable state transitions.

Generalise what works – Replace game-specific assumptions with JSON configurations and a reusable frontend/backend.

Preserve working baselines – Keep proven versions such as TEST032 and DEV018, reject regressions, and make small, targeted modifications.

Prepare for real players – Add registration limits, rankings, social announcements, security reviews and production performance refinements.

5. What we actually built

The most important technical decision was running MAME locally in each player’s browser. This keeps the computationally expensive arcade emulation away from the NAS. The NAS handles the comparatively lightweight work of account management, score storage and leaderboard delivery.

This architecture is also what makes supporting additional games practical.

6. Current status and next steps

The first five-game milestone is particularly important. After that, we can investigate MAME input recording and replay as a possible score-verification mechanism.

7. My assessment of the engineering achievement

The interesting part of Arcade1LC is not merely that we compiled MAME to WebAssembly. Others have already demonstrated browser-based emulation.

Our additional engineering work was integrating several different problems into one coherent system:

• Reverse engineering arcade memory to extract game-specific scores.
• Translating native arcade behaviour into a standard one-life competitive format.
• Designing a reusable multi-game architecture rather than separate websites.
• Building the surrounding player community and competition mechanisms.
• Deploying everything on your own NAS, with control over the application and its data.

The largest technical risks were around game-state detection, trustworthy scores and avoiding regressions when adding new features. Our repeated gameplay tests and decision to preserve known-good baselines were particularly valuable.

Overall: We went from an initial technical experiment to a functioning, publicly reachable arcade competition platform in roughly nine days, with an estimated 80 hours of active collaborative engineering effort.

It is a substantial prototype and early production platform, although the remaining security, anti-cheat and load testing should be completed before treating it as a fully hardened public service.

One distinction worth keeping in the project record: this estimate covers Arcade1LC itself, not the earlier AppleII_HOF work that helped establish the shared-leaderboard concept.