Remember when a whole generation of kids kick-started the games industry by digging through 8-bit hardware manuals?
I do.
Back then, we made things simply because coding was how you made things.
Nobody cared how it looked on a CV. Nobody waited for permission, or worried about “best practices” or “the perfect engine.” We experimented. We shared ideas. We read magazines (ask your parents what a magazine is!). We broke things and fixed them. We layered idea upon idea until the impossible suddenly wasn’t.
People called it talent.
It wasn’t.
It was curiosity, consistency, and a methodical approach to building skills.
Today? We’re drowning in information. Thousands of tutorials, hundreds of languages, endless opinions echoing in your head: Do this. Don’t do that. You must learn this first. No, learn that.
It’s no wonder beginners freeze before they even start.
But here’s the truth:
If you want to learn to code, pick a language — any language — and give it a shot.
The specific language matters far less than people claim.
Once you understand the basics in one, those skills transfer. Moving to another becomes easier. Concepts repeat. Patterns reappear. You build momentum.
Start small.
Be proud of the little victories.
And if your first attempt doesn’t stick? That’s normal. Try again later. You’ll be surprised how much your brain held onto.
Where you start isn’t where you’ll finish — and that’s the whole point.
Reality was the name of our Wolfenstein 3D-style game engine, which became an umbrella term for anything related to that pursuit. The project aimed to create a fast and efficient first-person engine on a near-stock Amiga 1200 (020+FastRAM) in the mid-1990s. This archive contains the last known remaining compiled executables from my various attempts to achieve reasonable performance on the platform.
Originally, the Reality project was most active between 1994 and 1995. Apart from a few screenshots shared with close friends, it was never publicly released. The executables included here represent alpha-stage software—functional but far from stable. While they take over the system in as OS-friendly a manner as I knew at the time, modern systems may not handle them well.
About the Demos
Reality.exe - Ray Casting Experiment
This was the initial test of the engine, developed sometime in late 1993 or early 1994. The first major challenge was the chunky-to-planar (C2P) problem, where my initial attempts using unrolled bit sets failed spectacularly. While this approach might have worked for particle effects, it was a disaster for general-purpose rendering. However, after several iterations, I moved on to a bit-parallel rotation solution, which significantly improved performance.
This is the only version of Reality that employs a true ray-casting method. The scene is constructed by casting rays outward from the camera’s field of view, step by step, checking for wall collisions. Each map pixel represents a vertical wall strip, likely stored as 8-bit data, allowing for 256 unique wall textures.
Color depth was either 16 or 64 colors, which struck a balance between visual quality and conversion speed. This version laid the foundation for later advancements.
Map.exe - 64-Color 2D Polygon Walls
As development progressed, I re-evaluated the engine’s structure and opted for a different approach. Instead of a traditional grid-based map, I structured levels as a grid of evenly spaced vertices, where walls were formed by linking vertex pairs. This allowed for non-orthogonal walls and greater flexibility in map design.
Rendering involved rotating and projecting the sector vertices, which determined floor and ceiling heights. The scene was then processed polygon-by-polygon. For each wall, I interpolated across its top and bottom, computing its Z-depth and texture U-values. Instead of rendering strips immediately, the engine stored them in a Z-buffer, ensuring proper visibility sorting.
A unique optimization was that textures were stored rotated in memory, enabling rapid texel fetching using a simple 8-bit V-offset.
Project Reality - 256-Color Rendering & 3D Objects
By early 1994, the gaming world was in the grip of DOOM fever, and we ambitiously aimed to push Reality further. As Commodore's decline loomed, we set our sights on creating something akin to Blake Stone, but with even more complex environments and polygonal objects.
This demo showcases the most advanced features we implemented:
256-color rendering
Textured walls with transparency support
Depth-based lighting effects
Early support for floors & ceilings
Multiple rendering modes
Initial 3D polygon rendering
For polygonal objects, we experimented with a method where triangles were clipped against the depth buffer. The goal was to calculate the screen-space width of an object, scan across the depth buffer, and determine the visible clipping edges. This technique would have allowed objects to be properly occluded by walls while enabling partial visibility. While not perfect, it was an innovative approach at the time.
Unfortunately, time and talent ran out. By the time we reached this stage, the Amiga community had already embraced Fears, Gloom, Breathless, and Alien Breed 3D. The dream of completing Reality faded, but looking back, I still wish I had been able to bring my full vision to life on screen.
System Requirements
System: Amiga 1200 / Amiga 4000
Processor: 68020 or higher
Video: AGA chipset
RAM: 2MB + 2MB FastRAM
Sound: Not required
Final Thoughts
Reality remains a fascinating relic of my early game development journey. While it never reached a finished state, it reflects the passion and creativity that fueled many indie Amiga developers during the 1990s. This archive preserves those efforts—flawed but ambitious, a glimpse into what could have been.
Thesius XII: Developing a Classic Amiga Shoot 'Em Up
Back in the golden age of the Amiga, I developed Thesius XII, a fast-paced shoot 'em up inspired by the arcade classics of the time. The game was my attempt at pushing the limits of the Amiga hardware while delivering an engaging and action-packed experience. Sadly, the game was never fully completed, but in 2000/2001, I released an 'as is' version featuring three levels. Despite missing final polish, it remains a nostalgic favorite for many retro gaming enthusiasts.
Inspiration and Design
The concept for Thesius XII was heavily influenced by IREM’s R-Type and Tecmo’s SilkWorm, two of my personal favorites. I wanted to create a game that blended intense shooting mechanics with strategic enemy patterns, requiring both reflexes and tactical movement. The art style and design leaned into the aesthetic of futuristic space battles, filled with vibrant explosions, detailed sprite work, and smooth scrolling backgrounds.
Technical Development and Features
The game was designed for a stock Amiga 500 running a 7MHz 68000 CPU, 512K memory, and the original chipset. Developing on this hardware came with its own set of challenges. Memory constraints, CPU limitations, and optimizing the rendering pipeline were crucial to maintaining smooth gameplay. One of the biggest hurdles was handling a large number of on-screen enemies without bogging down performance. To solve this, I implemented efficient sprite management and custom routines for object culling and collision detection.
Some of the standout features of Thesius XII included:
Three Levels, Over 35 Screens Long: Each level featured unique environments and enemy designs.
Two Major Guardians Per Level: Massive boss battles tested players’ reflexes and strategic thinking.
Pre-Mission Briefing Terminals: Before each level, a terminal screen provided mission details, utilizing dynamic palette and resolution splitting to create an immersive effect.
Dynamic Copper Display System: This allowed up to 384 colors on screen, even on OCS/ECS machines.
Advanced Memory Management: Using a solid hunk file system and smart RAM disk buffering, the game optimized load times and performance.
Parallax Scrolling & Hardware Sprite Multiplexing: With up to 13 layers of parallax, the game maintained smooth visuals and animation.
Auto CPU Detection & Optimization: Gameplay remained consistent across different Amiga hardware from A500 to A4000.
High Score Entry Screen: Featuring one of my favorite pieces of music in the game, this screen brought a satisfying end to each play session.
Development Challenges
One of the trickiest aspects of development was optimizing graphical effects for smooth performance. The intro, while simple by today’s standards, was particularly challenging to run efficiently on a stock Amiga 500. The Terminal Screen in Level 1 was another technical feat, combining both low and high resolution modes within the same screen, with palette splits on every scanline and dynamic text rendering.
Another personal highlight was the homing missile system, which I spent a great deal of time perfecting. Even now, looking back, I think it worked out quite well.
Release and Reception
Prior to September 16, 2003, a multi-level version had never been released, as the game remained incomplete. However, we felt it was a shame not to share what we had, even though it lacked the final two levels and additional polish. Thesius XII v95 was first reviewed in Amiga Format (August 1995) in their PD section, and it was featured again in a follow-up issue, highlighting promising Amiga developers.
Legacy and Follow-Up
Years after Thesius XII, I revisited the concept with Thesius XIII, a tech demo for PlayBASIC. While it wasn't a full game, it showcased advanced techniques for handling sprites, movement, and rendering in a modern game development environment.
Even though the full vision of Thesius XII was never realized, the game remains one of my favorite projects from the Amiga days. It was a challenging but rewarding experience that shaped my approach to game development. For those interested, an emulated version of Thesius XII is available online, best played using the latest version of WinUAE.
Would you like to see a modern reimagining of Thesius XII? Let me know your thoughts!
