Kingdom: New Lands and 2D pixel art

(Richard Dodd (Dodj)) #1

I really love Kingdom: New Lands (K:NL). I guess you’d classify it as a RTS, but it’s not really like other RTSs. For one, it’s 1D, and for another you interact with the world through a character, rather than as a god.

I’m thinking of experimenting with this kind of 1D side-scroller view strategy game in amethyst, but there are a number of problems to solve in terms of 2D graphics that may be of interest to others in the community.

The first is what the source images are for sprites in the game. K:NL uses a mixture: pixel images for game content and vector graphics for UI. I figured this out by resizing my window a lot and seeing how the sprites change. Because UI uses VG, it’s fairly easy to see how it works so I’ll just skip over it.

Then there is the problem of dealing with different window sizes. The approach of K:NL is to have an exact 1:N number of screen pixels per image pixel, which gives you pixel-perfect graphics and means we can ignore anti-aliasing etc. (apart from possibly in the UI). They decide on the N by some function of width and height (I don’t think their function is particularly good so I don’t see any value in digging into it any more). What this means is that you’re going to either get some black lines around your scene (if N is too small to exactly fill the screen), or crop some of the scene (if N is too big). In K:NL seeing further is a minor advantage but doesn’t really impact the game, because you’re making strategic decisions about how to build your army/castle, that don’t require up-to-the-minute info on what’s just out of sight.

I’m going to begin by making some sprites, and then experimenting with how to scale them to fill the screen whilst still being pixel perfect. If I make any progress, I’ll update this thread. :slight_smile:

3 Likes
(Erlend Sogge Heggen) #2

Would love to see a project explore the Kingdoms design! I recently found this deeper alternative, which seems to have more of the types of complexity that an ECS engine can handle especially well:

Your graphics requirements should be very similar to those of #showcase:space-menace.

Are you describing the same as this YouTube comment about Songbringer?

I didn’t like the graphics, but not “because of the pixels” like many others who hate pixel art.
I love pixel art. The problem however is that I also have a keen eye (working with graphics for a living).

The developers of this game made a crucial error for a pixel artist: pixels don’t adhere to a grid of internal resolution (this game has none), and you get ugly pixel wobbling in objects when camera moves due to nearest neighbour interpolation, made a hundred time worse by the fact that this kind of artifaction happens per-object, which leads to different objects being affected by it differently at the same time.

To give you point of reference: for a person with keen eye on pixel-art it’s like watching a Full-HD movie that was horribly compresed to fit onto 700mb CD - you get crisp and clear image one moment, then it gets parts of it get horribly blocky jpg-style.

Absence of internal res also leads to pixelmixing - where one “pixel” of a sprite is neither here nor there on a pixel map - halfway on one pixel of the background and halfway through the other for example.

Absence of internal resolution is one of key signs that whoever made this game used pixel-art as a way to cheapen production or to apeal to a certain audience, not because they like it.

In Hyper Light Drifter for example, a game similar in style, an internal resolution of 480x270 was chosen for the game and every pixel adheres to that grid. Same with most other pixel-art games, because people who made those games cared. Dev’s of this game obviously didn’t.

edit: also relevant:

2 Likes
(Richard Dodd (Dodj)) #3

Thanks for replying! :slight_smile:

I spent a while trying to find the comment then realised you’d copied it in below haha.

Yes, but more than this you need that pixel grid to be expanded so that each virtual pixel occupies a whole number of real pixels. This way you get nice clean edges and your work actually looks like pixels. But say if your virtual box is 300x200 and your real window is 640x480, there is no whole number of real pixels to give a virtual pixel to make the virtual window exactly cover the real window. So in this case you either need to crop, or to show some border. K:NL solves this by vertically cropping or showing a border depending on the ratio, in such a way that you really don’t notice. Horizontally they don’t have an issue, since you just show as much of the scene as is possible given your vertical choice of “n real pixels to 1 virtual pixel”. So you handle the vertical and then just show as much horizontal as possible.

I hope this answers your question. It would be easier if we were sitting next to a blackboard haha.

2 Likes