Inside The Making Of Easy Delivery Co.

Easy Delivery Co. has a very distinctive PS1-inspired visual style. What led you to commit to that low-poly, pixelized aesthetic early on, and how did it shape your overall production approach?

I'm more of a programmer than an artist, and all of my practice doing art has been directed towards 2D pixel art more than anything. The art style is really just me working within the limits of what I can do, or whatever was fastest, so I could get back into the programming, which often takes the most time. Committing to as low-poly as I can get with either pixel art or photobashed textures, everything stays pretty unified while also being really quick to make.

As more of a 2D artist, I like to use as little geometry as possible and rely on textures for details, which also makes it easier to iterate and create variations of objects.

The game blends cozy elements with an eerie, almost surreal tone. How did you approach art direction to balance those contrasting moods across environments, lighting, and character design?

It was a little bit intentional: all of the playable assets, like the truck, packages, and characters, are simple pixel art textures meant to look cute, while the environment uses real photo textures. Even though they look cute, the characters themselves are animated with fake rounding errors and jitters to imply something isn't quite right. I think ultimately the contrast is what makes the warm and cozy elements stand out that much more.

There are no shadows or sunlight, just one ambient colour that changes based on the time of day, which allows me to blend things nicely into the fog without much effort. I tried my best with the fog and lighting to invoke that really specific, scary but somehow calm feeling of being alone in a snowstorm or at dusk on a winter day.

Can you walk us through your full asset pipeline, from concept and reference gathering through modelling, texturing, and final in-engine implementation?

For each feature, I'll design it on paper and jump right into modelling and texturing to get that out of the way asap before moving onto the implementation. When implementing a feature, I usually make it as polished as possible every step of the way instead of roughing it out and refining it later (there's just no time!). I also rarely go back and improve the geometry, so I try my best to get it right the first time. Most of the details are in the texturing, which is much easier to change on the fly.

Early on, I did the texturing right in Blockbench, but for the environment, I did a lot of photo-bashing in Photoshop.

I don't actually do too much explicit reference gathering, I like to take pictures of things when I'm out, or I'll do a quick image search, but often I just wing it based on the vibes. One of the perks of solo dev is that I don't ever have to communicate my designs before starting production. 

Which software do you use, and how do those tools and techniques fit together in your workflow?

The game is made in Unity. I use Blockbench for modelling and texturing, and I used to use Photoshop for photo-bashing, but I've been recently trying to use Aseprite for that. I use Aseprite heavily for sprites and UI, and I use it to edit any textures on the fly that are in the game already.

It's a really simple but not very efficient pipeline. I'm still trying to figure it out and work on my own custom tools in Unity that suit my needs and development style. I would love a more streamlined way of changing geometry after it's already in the game. 

The game's visuals feel intentionally constrained, with low resolution and simple geometry. How do you decide where to embrace limitations versus where to push for more detail or fidelity?

It's not very set in stone, but I like to imagine I'm developing in a fictitious engine made a long time ago. I've always been a huge fan of PICO-8 and its really specific set of limitations to work creatively around. So I'm imposing my own limitations to match that vibe, while keeping the conveniences of Unity and 3D. I just try to keep things low-poly and rely on textures and shaders wherever possible, and it all has to read well on the made-up 456x256 resolution screen. I don't have any hard rules, I just try to keep it all looking cohesive.

How do you approach lighting and post-processing to achieve that nostalgic yet readable look, especially given the heavy use of fog, darkness, and weather effects?

For lighting, as I mentioned earlier, there are no shadows or sunlight, just one ambient colour that changes based on the time of day. The fog shares the same colour, so anything white (or snowy) already naturally blends into the background. The flat lighting also helps when making shaders and particle effects because you can make it just slightly brighter or darker than the ambient colour to make it stand out from the background or match it and perfectly blend in. For example, the snow particles during the day are a little bit darker, so they are visible against the background, and at night they're a bit brighter. There are also extra fog particles or drifting snow that happen in extreme weather, and it blends perfectly into the fog to really obscure where you're going.

I try my best to shade objects within their textures, but I cheat a little bit with some screen space ambient occlusion to make sure objects pop a little against the environment. 

As a solo dev, how did your production workflow evolve over time, especially as the project grew from a small prototype into a full commercial release?

I definitely got a lot more efficient with all my tools as I went, and as complexity increased, I had to be a lot more efficient with my time. Other than that, I'm still working the way I usually do, which is just... constantly. It works, but it's not very sustainable long-term.

The game has now expanded beyond PC to additional platforms. What were the biggest technical challenges when porting Easy Delivery Co. to consoles and mobile devices? Did porting require changes to your content pipeline?

Fortunately, I had two great teams that handled porting, Meteorbyte Studios for consoles,
and Doghowl Games for mobile, so I don't have much to say about this.

As far as I know, there didn't have to be any changes. It worked out for me that with modern hardware, it seems like my assets were low-fidelity enough to work. 

Looking back on development, what were the biggest lessons learned about building a scalable art pipeline for a stylized indie game?

Going forward, I'm going to lean even heavier into this idea of these fictional engine constraints and build even more custom tools and systems to suit my exact needs. In my workflow, the art and the coding are so intertwined that it only makes sense to bring them even closer together.

Sam C., Game Designer

Interview conducted by David Jagneaux