Sweet Transit and the unique challenges of programming in 2D

gamedeveloper.com:

Game Developer Deep Dives are an ongoing series with a goal of shedding light on specific design, art, or technical features within a video game in order to show how seemingly simple, fundamental design decisions aren't really that simple at all.

This article was written by Ernestas Norvaišas, the solo developer behind Sweet Transit, a strategic city building game set in a world where the railway is king and trains are the sole means of transportation and expansion.

When designing a game, working with 2D rather than 3D graphics can often seem the easier choice. With more components, variables, and things that can go wrong, 3D can appear the more complex space and challenging option in which to build a world. Sweet Transit is an upcoming 2D isometric transport sim and city builder, and I thought I'd share the reality of working within this space, as well as some of the challenges unique to 2D programming that I've encountered since the project's inception.

To begin, let's look at 3D. In 3D games, most process sorting is done within the GPU and measured by the depth of each pixel and its proximity to the game's virtual camera. The CPU assists in optimisation and sorting transparent objects, but the majority of the heavy lifting is done by the graphics card. In 2D games, it's quite the opposite -- most sprites are transparent, giving the GPU very little to render and meaning the limitations imposed on 2D programming are those from the CPU rather than the GPU. This means that working within 2D space can come alongside a unique set of challenges you'd never encounter in 3D.

Unlike 3D, 2D graphics sorting isn't done per pixel but holistically, by individual in-game images or sprites. For the designer, this leaves a lot less space