It’s hard to deny that things have been somewhat quiet regarding “Wright Files: Egerton’s Pickle” for some time now. Development work stalled towards the end of 2023 (I wrote about this – and the reasons – in an earlier post from July 2024). However, this doesn’t mean that nothing has been happening on the development front. Actually, most of what I’ve been working on in the meantime is essentially an evolution of the technology that I use in “Egerton’s Pickle” (yes, I’m that classic hopeless case of a game developer who, instead of simply finishing the project and publishing the game, constantly improves and polishes things that no player will ever see, i.e. technical guts of the game). Today, however – in another technical post with another cliche title – I’d like to show something I’m really proud of (and which most players will probably either not appreciate or ignore completely).

I’ll start by saying that from the very beginning, one of my fundamental assumptions was that “Egerton’s Pickle” is going to be a retro-style game (both visually and gameplay-wise). This is largely tied to my fascination with games from the transition period between 8-bit and 16-bit computers (the era when typical screen resolution was 320x200 pixels, when pixel artists just started to notice that pixel-art can actually be art, and 3D games were still in their infancy with no one yet thinking about texturing, shading, or anti-aliasing). The aesthetics of games from that period were largely dictated by hardware technical limitations. Today, such aesthetics are a conscious artistic choice driven by nostalgia, economic considerations, or the creator’s technical abilities (in my case, all three reasons are equally important).

In the case of “Egerton’s Pickle” the retro visualization is tied to three aspects: low-polygon 3D environments, 2D sprites, and low resolution (around 320x200 pixels). The first two aspects are largely dictated by economics and skills: my graphic abilities are limited, so simple (not to say primitive) 3D environments and low-resolution 2D sprites seem to be within my capabilities. The low resolution is a nostalgic-economic choice – it’s easier to hide graphical imperfections when you’re displaying pixels the size of Minecraft blocks.

After starting work on the game (around July/August 2021) and creating several visual style prototypes, it quickly became apparent that combining the aforementioned aspects in the way I envisioned would be challenging. This is mostly to the fact that while combining 3D scenery with 2D characters is trivial and has been used since Wolfenstein (if not earlier), achieving precise control over the appearance of displayed objects in low resolution requires some work. It’s manageable when the game uses an orthographic camera view (like isometric or top-down). The real problem begins with a perspective camera view, where objects shrink as they move away from the camera. Remember 3D games with 2D characters and freely moving cameras on PlayStation 1 (PSX)? They looked horrible. Really awful. It’s a miracle players could even decipher what was happening on screen. For this reason, I’ve decided that yes, “Egerton’s Pickle” would have low-polygon 3D scenery and 2D characters, but everything rendered in high resolution. However, I kept returning to the original idea of achieving the graphic style I had envisioned in various side projects.

And this brings us to the gist of this post – presenting the results of my latest game graphics styling test. I feel I’ve finally achieved an effect that well combines all the previously mentioned aspects, and the breakthrough moment came when I adopted the assumption that 2D sprites should maintain a constant size regardless of their distance from the camera. At this point, it’s worth mentioning that such an assumption only makes sense with very specific game world presentation parameters. For example, it won’t work at all in a situation where a perspective camera view shows a game area far away. In such a situation, a 2D sprite of the same size both near and far from the camera will look very strange and will probably confuse the player. However, “Egerton’s Pickle” uses a fairly limited view of the game world (divided into rooms seen from above, so the convergence of perspective lines and resulting scene depth is minimal), making such an assumption sensible.

It’s best to show this graphically, so below is an example scene using the trick described above in low resolution – each character maintains the same screen size at all times:

Constant sprite size is most noticeable if you look at Manfred (the butler, in the blue suit) at the beginning when the camera moves toward the center of the entrance hall and he’s quite far from the camera.

For comparison, the video below shows the same scene in high resolution, but character size changes with their distance from the camera (as perspective dictates):

This was the display method I adopted after the first failed prototypes. Pay attention to Eugene’s height (the main character in glasses and fedora) when he goes through the portal to the next room, or when he stands by the grandfather clock in parlour. The height difference is easy to notice when compared to the first video.

And the final comparison: the same scene in low resolution with character size changing based on their distance from the camera:

This best shows the problem that discouraged me from using this method – as characters move away from the camera, their sprites decrease and pixel-art deforms, resulting in a very unpleasant visual effect. This method is visually correct and useful for scenes with great depth, but only if we accept ugly downscaling of sprites (similar to Wolfenstein or Doom). Side note: texture interpolation could have been used to downscale the sprite more evenly but this would be only usable for high resolution. In low resolution interpolation would result in highly blurred sprites with most of the details lost (which would probably look even worse that what can be seen above).

In summary, the visualization shown in the first video is currently closest to what I envisioned for “Egerton’s Pickle”. At this point, I can’t say whether it won’t cause new visual problems that weren’t there before (which would again force me to return to the version shown in the second recording). I know it’s not a universal solution and only works within a very narrow range of game world presentation parameters, but for my purposes it seems quite well-suited and I believe it adds charm to the game.

I’m curious about your opinions – is the difference noticeable to you? Would you be interested in a more precise technical description of the entire solution? Let me know in the comments!