Pixel Art Tips for Programmers
Postedabout 2 months agoActiveabout 2 months ago
jslegenddev.substack.comTech Discussionstory
informativepositive
Pixel ArtProgrammingGame DevelopmentArt
Key topics
Pixel Art
Programming
Game Development
Art
Discussion Activity
Moderate engagementFirst comment
1d
Peak period
10
42-48h
Avg / period
6.8
Key moments
- 01Story posted
Nov 21, 2025 at 8:25 AM EST
about 2 months ago
Step 01 - 02First comment
Nov 22, 2025 at 6:53 PM EST
1d after posting
Step 02 - 03Peak activity
10 comments in 42-48h
Hottest window of the conversation
Step 03 - 04Latest activity
Nov 24, 2025 at 12:16 AM EST
about 2 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 46004326Type: storyLast synced: 11/23/2025, 12:07:04 AM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Testing on a reasonable amount of different screens (and software-based filters etc.) is excellent advice for too many people forget this. Of course that's also always a money, time or motivation (goal) question...
...and different screen brightness levels
Also, just like in coding: Constraints don't hide your flaws (per se); you fuck up, people will (let you) know. And pieces in constrained environments can be much, much harder to pull off.
I had hoped for something closer to the intersection of pixel art and graphics programming. Well, maybe in the future.
Agreed. I would also speak out again the uninformed use of pre-configured color combinations. As someone who teaches art/design these are the bane of my life… students use them as a replacement for color theory. A designer should at least know how to parse a color into its hue, saturation and lightness components. Most everything else should follow naturally.
Full stop. There are quite a few coders with artistic talents. And even if some specific individual does not have such talent, they are allowed to have their own taste - we do not need to train ourselves to mimic other people's preferences.
I also know plenty of programmers who are great musicians. Programming itself is creative work... Completely lost interest in art due to AI though.
Such overgeneralizations are not helpful. People gravitate stronger towards certain creative disciplines, or a selection of them; how long it exactly takes to develop-out "reasonable" skills is dependent on a litany of factors, some of which cannot be controlled (e. g. force majeure). Both programming and pixel art requires unwavering commitment and exercise´; there is no way to "wing it" if you are intellectually honest and take your craft seriously.
Art is all about repetition. Even if you've done it successfully many times, you still need to keep doing it until it's second nature.
Programming is more like solving puzzles. Once you've solved it once, you can pull the solution out of your head as many times as you need, as long as you still remember it.
With art, it doesn't matter if you remember how to do it, it still takes practice to get reproducible results. Of course it takes longer.
First and foremost, contrary to you it seems, I see art as a measure of quality, not as a simple descriptor of manifestations of human personal, and therefore cultural, expression (albeit using a, naturally technically imprecise, colloquialism such as "pixel art" to describe a school of aesthetics, or style). See also: The Art of Programming.
And furthermore, I see both disciplines as fields which humans engage in to solve specific identified problems, rationally or intuitively; in both it takes practice to get reproducible results, in both you need to keep doing it until it becomes "second nature". This refers to the process itself, the process to hone one's craft.
I don't understand what you mean by this. Do you mean to say the worth of an artwork for you is tied to how well it executes technque? "Art" is a word so nebulous that it's hard to pin down a definition, but I think the billions of people that prefer a punk rock song over an academic figure drawing study would disagree with this.
>And furthermore, I see both disciplines as fields which humans engage in to solve specific identified problems
Well, I'm both an artist and a programmer, and I can tell you I engage in neither to solve problems. I do both because the process of doing them is enjoyable. If they stop being fun, I'll stop doing them, and there wouldn't be any lingering problem in my life to go unsolved.
If you say picked up art faster than programming I'll believe you, because I only meant it as a general observation.
Art is like playing Dark Souls -- maybe you beat the hardest boss once, but that doesn't mean you won't die ten more times before beating then again.
Programming is likr Zelda. Once you know the solutions to the puzzles, you're basically going through the motions.
This isn't me guessing based on philosophy -- this is my lived experience as both an artist and a programmer.
Art, to me, is a marker of excellence in the already mentioned confines. Technique is just a part of it.
> "Art" is a word so nebulous that it's hard to pin down a definition, [...]"
On that we agree; hence me informing you about mine, otherwise we just run circles around each other.
> "[...] but I think the millions of people that prefer a punk rock song over an academic figure drawing study would disagree with this."
As you probably can deduce by now, I see both examples as having the potential as being art. The rest of your rather labored example is an appeal to preference based on form or expression; such a thing is neither static (e. g. it change change with one's moods, a. s. o.) nor does it have to be a false dichotomy (i. e. I can enjoy both manifestations, even at the same time, and, more importantly, recognize both as art). But this is also all very basic stuff and in itself tedious, and also often useless, to engage in online.
> Art is like playing Dark Souls -- maybe you beat the hardest boss once, but that doesn't mean you won't die tent more times before beating them again. Programming is like Zelda. Once you know the solutions to the puzzles, you're basically going through the motions.
Such comparisons, as relatable as they might sound to someone who is familiar with these titles, are often useless as well (I am aware of these games, and their cultural weight, but have never played them nor care to do so). Furthermore, for the reason outlined in the post you responded to, they're a misfire anyway as art, to me, is first and foremost about the result, and not the way towards the result.
I suppose it was a mistake to get distracted by trying to find out what exactly you're trying to say -- it's now completely clear that it has nothing to do with whether art or programming takes longer to gain proficiency.
>labored [...] tedious
Saying my points are long-winded or redundant also doesn't support your point. You're doing a lot of philosophizing about what art is or whether my points are "useless," but you still haven't reasoned about why it's not true that art takes longer to learn than programming. Which is rich sice you've spent more words on this matter than me.
>Such comparisons, as relatable as they might sound to someone who is familiar with these titles, are often useless as well (I am aware of these games and their game mechanics, but have never played them nor care to do so).
So, you haven't played the games, therefore you have no insight into the analogy, so you're not really in a position to say whether the comparison is useless.
You've also used the word "useless" a handful of times here. What "use" are you referring to here?
In the context of a programmer wanting to know how learning to draw compares to learnong to program (something I've only been asked once, but even once is enough to prove it's useful), to say "expect drawing proficiency to take longer, because it requires more repition" is useful.
Once again, this isn't deduction or hypothesis. It's my own experience with both crafts.
I just replied directly to your comment, as I usually do in discussions. Besides, your point of contention, i. e. what takes longer to gain proficiency in (whatever you define as art or the act of programming), has already been adressed multiple times.
> "So, you haven't played the games, therefore you have no insight into the analogy, so you're not really in a position to say whether the comparison is useless."
You misunderstood. The comment was not about me but about the general value of such comparisons. True, I haven't played the games, but I have seen them being played countless times, have some material where they come up in (reference books, art books, magazines, documentation, etc.), and can therefore make sense of your analogy. In the end it's useless mostly for entirely different reasons, though; reasons I have already explained as well.
> "You've also used the word 'useless' a handful of times here, all without any follow-up as to why exactly. What 'use' are you referring to here?"
These discussions are often cumbersome as one has to find common, agreed-upon language in the first place. And more often than not such online discussions don't lead to deeper insights (e. g. performativity measurements who "spent more words" is not something of relevance to me). That has at least been my experience. Don't take it personal.
> "In the context of a programmer wanting to know how learning to draw compares to learnong to program (something I've only been asked once, but even once is enough to prove it's useful), to say "expect drawing proficiency to take longer, because it requires more repition" is useful."
That's, as you've stated, an anecdotal hypothesis based on your life's experience. To me, programming, writing, making music, painting pictures, etc. require creativity, rigorous exercise, repetition, and so on. What discipline was, is, or will be the easier or easiest way for you to get to whatever your goal is I cannot know for this depends on way too many factors, many of them, to top it off, outside of any parasocial (online) prism.
Besides, they could be known for this and it could be a misconception! The sentence is still true.
Finally, "full stop" is what you say when something isn't up for debate. It's like saying "Apple makes better hardware, period." Like the conversation ends there. It doesn't mean you stop reading.
So I don't know where did the "generally known" comes from. In my 20 years experience, I knew hundreds of programmers and probably majority of them were extremely artistic. Writing games as a hobby, drawing miniatures, some were writing books, music bands...
> Finally, "full stop" is what you say when something isn't up for debate.
Is it the only way you can say "full stop"? Can't you just say it to yourself in the way of "full stop, this shows ME this is based on wrong premise, and I don't need to waste time on keep reading it"
Well yeah, there are only so many hours you can put towards a thing. It's not a statement about programmers or artists, it's just about how effort works.
Does that discount your personal experience as an artist? Of course not! That would just be reading into the phrasing way too much.
Quite the opposite. The fewer pixels, the more each one has to be perfectly in place. Honestly should've been obvious in hindsight. If I have any games left in me after my current one's finished, I'll just use as high a resolution as I'm comfortable with.
Unless the sprites are truly tiny, like 16x16 with 2 or 3 frame animations, I don't know if pixel art makes a good shortcut to an aesthetically appealing game. Then again, it might be easier than six years of every day practice.
The traditional workflow of creating a rough sketch on paper or tablet then progressively refining it just entirely doesn't apply.
For many a pixel artist that is a typical workflow, especially when working from reference, e. g. by retracing/"converting", say, an architectural period piece such as a street view to be used in a period- and location-accurate adventure game. In other words a classic line-to-pixel A/D conversion.
Another thing that helped me was to experiment with different canvas sizes and styles. I was surprised how changing these affects my process, speed and results. Then again, this can be difficult in an ongoing project.
[1]: https://apps.apple.com/app/nonoverse-nonogram-puzzles/id6748...
Contrast seems to be also one of those things I see even very experienced pixel artists get wrong, especially in the context of games where visibility can be crucial. There's many games with beautiful spritework but actually playing them is very tiring because all of the sprite work uses the same range of the palette. You want to consider if things are in foreground or background, interactable or not, dangerous or friendly and then limit how much the range of their colors intersect. Creating contrast through hues is more common (, see red hostile vs blue friendly), but differentiation through saturation and value/luminosity is much more effective and readable at a glance while also being more accessible to color blind people by default.
I started off simply cribbing all the tiles from Ultima IV for the Apple II, then gradually adding some rudimentary new tiles as the need arose. Starting with a pixel "rock" and "stick", changing the clothes on existing characters, then eventually gaining a bit of confidence and launching off on more complicated things. Eventually coming back and redoing all the "borrowed" tiles, and launching off into new, more detailed, characters and items.
"Constraints hide your flaws" got me a long way. I've relaxed those constraints a bit as I got better at shading, so it's easy to tell which tiles were drawn at what point in my "career"
[1] https://valtima4.com/, the Survival Crafting RPG you would have played on you Apple II in the '80s. It's essentially Valheim crammed into Ultima IV's interface.
Single player works up through the first couple bosses, but it's not really ready to ship into early access yet.