Well timed. I've been going through this process as a non-artist forced to churn out some tiles for a game I'm building [1].
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.
After classical art training, I thought pixel art would be fast and easy -- the low resolution would disguise any mistakes.
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.
More than a dozen artists I've talked to told me pixel art is entirely it's own discipline - they're no more comfortable approaching it than a layman would.
The traditional workflow of creating a rough sketch on paper or tablet then progressively refining it just entirely doesn't apply.
> "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.
I've seen at least one indie game (Ta*dQuest) use Midjourney to create pixel art sprites for some NPCs that appear in the dungeon. Extra art, like portraits for those NPCs, was drawn by hand to complement the sprites after they were generated, so it all feels deliberate. I would have never guessed
Constraints help because they favor harmony. If you reuse the same limited palette for all your sprites it's more likely all objects will seem like they share the same lighting. It's very similar to making music. You can create sounds on a full spectrum of of frequencies but we have constraints like tonality to limit our pitches to semitones and center our compositions around keys. Sometimes we actually want to create feelings of dissonance and then stepping out of these limitations while adhering to them otherwise helps contrasting them even more.
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.
> Programmers are known to not have a strong suit for art related disciplines
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.
Just because they are "[generally] known" for not having artistic skills doesn't mean there can't be a few exceptions.
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.
Have you ever heard the famous "he did not have enough imagination to become a mathematician" quote?
There is a reason it is famous and it could be very much projected on programming.
Programming requires be creative.
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"
This debate strikes me as misguided. It's just basically "someone who's really good at one thing is unlikely to be really good at a second thing".
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.
Why is it generally known? It's a completely anecdotal statement, that the author should have just avoided. General statements like that are hard or impossible to prove and insensitive to those it does do wrong.
As someone who in fact _doesn't_ have a strong suit for art (and is a programmer) - I don't feel this is an unfair statement. It says "programmers are known" which is not an absolute statement but more of a vibe - and it's a vibe I would definitely say is true on average.
Does that discount your personal experience as an artist? Of course not! That would just be reading into the phrasing way too much.
Gotta agree, I used to draw portraits before I started programming a few years ago...
For reference, my last ever portrait:
https://imgur.com/a/sEQiLu4
I also know plenty of programmers who are great musicians. Programming itself is creative work...
Completely lost interest in art due to AI though.
I would wager that's how it goes for most people that are both good artists and good programmers -- they were artists first, then learned to program. It takes a lot longer to become a reasonably good artist than it does to become a reasonably good programmer. I suspect that might be why the article opens the way it does.
> "It takes a lot longer to become a reasonably good artist than it does to become a reasonably good programmer."
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.
I think it is helpful for certain purposes, and I think you'll be hard pressed to find exceptions to the general rule.
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.
> "Art is all about repetition. [...] 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. Et cetera.
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 millions 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 you 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 them again.
Programming is like 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.
> "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, 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 of 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 artful). But this is also all very basic stuff and in itself tedious, and, especially for the reason you stated, 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 game mechanics, but have never played them nor care to do so).
Furthermore, for the reason outlined in the posts 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 (as long as certain conditions have been met) as well as life itself being much more complicated... with significant implications for the process of making art and the development of an artist in one or more disciplines.
> As you probably can deduce by now, I see both examples as having the potential of being art
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 since 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, all without any follow-up as to why exactly. What "use" are you referring to here?
In the context of a programmer wanting to know how learning to draw compares to learning 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 repetition" is useful.
Once again, this isn't deduction or hypothesis. It's my own experience with both crafts.
> "[...] it's now completely clear that it has nothing to do with whether art or programming takes longer to gain proficiency."
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.
> 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.
> 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.
These are all the words you've said so far that address whether art takes longer to learn than programming. Your points boil down to
1) People have different strengths and weaknesses
2) Both require practice
But neither of these contradicts the statement "art generally takes longer to learn than programming."
> In the end it's useless mostly for entirely different reasons, though; reasons I have already explained as well.
Here are all the words you've spent explaining why the observation is useless:
Oh... actually nothing. This whole discussion started when you said
> Such overgeneralizations are not helpful
But they've already been helpful to me before, and no fewer than one other person. Even if it's not much, "useless" is untrue. I said "this is what I've found to be true, and observed in others like me," and you said "this is not a useful observation." You never said why, you just jumped straight to "I already adressed that."
> "But neither of these contradicts the statement "art generally takes longer to learn than programming."
Man alive, I've already explained this multiple times, and you misread each and every time. You even postulate programming as something outside of art; a statement I have fundamentally disagreed with. You're fighting strawmen, and we therefore run rings around each other.
> "Oh... actually nothing. This whole discussion started when you said [...]"
The discussion started when I objected to your statement that "it takes a lot longer to become a reasonably good artist than it does to become a reasonably good programmer".
To me it's nothing but an imprecisely articulated, sweeping generalization constructed around the anectodal "evidence" that's your life (with an unknown sample size of people you've met or read about that might agree with you to some extent). In other words it's nothing but tedious fallacies, a thing oft observed in such discussions.
It's also a massive red flag; I at least would never be so presumptious and arrogant to make myself the yardstick and declare cocksure that one discipline will take longer than the other for some to me completely unknown reader. I know many a great artist who paints and/or writes but could not program their way out of a wet paper bag (they're practically computer illiterate and have absolutely no ambitions or time to change that), let alone reach the same heights there as in their chosen medium of expression. And vice versa. So what's useful to you, and what might be useful to me, is not automatically applicable to others and therefore it's useless to generalize, at least without any hard data to back it up (and even then the addressed party might be an outlier).
If one wants to find out which form(s) of expression is/are best suited for oneself, one needs to spread the wings and take to said form(s). How long that will take no one can say for sure; therefore what takes longer if one gravitates to more than one form, no one can can make reasonably accurate predictions about either. Especially not without knowing at least a modicum of relevant information about the individual any advice is supposed to enrich in the first place.
Hence, when addressing a general audience, better concentrate on giving detailed and sound advice on how to get better, or speak to useful mitigation strategies/life hacks, as opposed to shallow and often unapplicable generalizions about the future. In German there's a terminus technicus for such sillyness: Glaskugelei.
To these fine tips I would add: ‘test on as many devices as you are reasonably able’. Something can look fine on your laptop but lousy on the platform for which you are aiming to disseminate.
> "[...] I would add: ‘test on as many devices as you are reasonably able’."
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...
This also applies to webdev. I develop a lot with the chrome devtools but once stuff is in mobile it doesn't quite work out due to people using different browsers. The browser bar sometimes being on top or on the bottom hiding controls... I started to just center stuff in mobile ignoring like 20% of space in top and the bottom.
Good advice. I draw pixel art for an image logic puzzle game [1] and these resonate, especially 2. (Negotiate) and 5. (Constraints).
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.
These are just incredibly basic, and oft repeated, pixel art 101 guidelines. And, quite frankly, some of those tips are what I consider bad advice (e. g. a pixel artist has to deal with color theory as much as a character artist or animator has to deal with anatomy; a good understanding of color theory is also necessary to nurture good taste in the first place... so the quicker one gets into that, the better).
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.
> a good understanding of color theory is also necessary.
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.
I hate to be that guy but the quality of OP’s showcased pixel art is pretty mediocre. Strikes me as someone who’s still learning and figuring things out and not in a particularly solid position to teach others.
I'm a programmer who started doing pixel art for a personal project in 2022 and this is solid advice. I didn't really think about it too hard but I do find myself negotiating with the canvas to get something to look right when it's just a few pixels off lol
Well timed. I've been going through this process as a non-artist forced to churn out some tiles for a game I'm building [1].
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.
After classical art training, I thought pixel art would be fast and easy -- the low resolution would disguise any mistakes.
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.
More than a dozen artists I've talked to told me pixel art is entirely it's own discipline - they're no more comfortable approaching it than a layman would.
The traditional workflow of creating a rough sketch on paper or tablet then progressively refining it just entirely doesn't apply.
> "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.
If you want to see someone who has truly done wonders with pixel art - the game Look Outside has so much incredible (and disturbing) pixel art.
Makes me wonder if GenAI can get these kinds of subtleties right.
I've seen at least one indie game (Ta*dQuest) use Midjourney to create pixel art sprites for some NPCs that appear in the dungeon. Extra art, like portraits for those NPCs, was drawn by hand to complement the sprites after they were generated, so it all feels deliberate. I would have never guessed
Constraints help because they favor harmony. If you reuse the same limited palette for all your sprites it's more likely all objects will seem like they share the same lighting. It's very similar to making music. You can create sounds on a full spectrum of of frequencies but we have constraints like tonality to limit our pitches to semitones and center our compositions around keys. Sometimes we actually want to create feelings of dissonance and then stepping out of these limitations while adhering to them otherwise helps contrasting them even more.
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.
> Programmers are known to not have a strong suit for art related disciplines
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.
Just because they are "[generally] known" for not having artistic skills doesn't mean there can't be a few exceptions.
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.
Have you ever heard the famous "he did not have enough imagination to become a mathematician" quote? There is a reason it is famous and it could be very much projected on programming. Programming requires be creative.
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"
This debate strikes me as misguided. It's just basically "someone who's really good at one thing is unlikely to be really good at a second thing".
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.
yeah, it's just that programmers tend to have self images as ultimate polymaths, and such a person can't have poor taste in art, therefore...
Why is it generally known? It's a completely anecdotal statement, that the author should have just avoided. General statements like that are hard or impossible to prove and insensitive to those it does do wrong.
Yes, I agree. It comes off as condescending. I guess he is trying to peddle pixel art assets, so gatekeeping is beneficial to his future sales.
As someone who in fact _doesn't_ have a strong suit for art (and is a programmer) - I don't feel this is an unfair statement. It says "programmers are known" which is not an absolute statement but more of a vibe - and it's a vibe I would definitely say is true on average.
Does that discount your personal experience as an artist? Of course not! That would just be reading into the phrasing way too much.
Gotta agree, I used to draw portraits before I started programming a few years ago... For reference, my last ever portrait: https://imgur.com/a/sEQiLu4
I also know plenty of programmers who are great musicians. Programming itself is creative work... Completely lost interest in art due to AI though.
I would wager that's how it goes for most people that are both good artists and good programmers -- they were artists first, then learned to program. It takes a lot longer to become a reasonably good artist than it does to become a reasonably good programmer. I suspect that might be why the article opens the way it does.
> "It takes a lot longer to become a reasonably good artist than it does to become a reasonably good programmer."
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.
I think it is helpful for certain purposes, and I think you'll be hard pressed to find exceptions to the general rule.
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.
> "Art is all about repetition. [...] 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. Et cetera.
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 see art as a measure of quality.
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 millions 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 you 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 them again.
Programming is like 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.
> "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, 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 of 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 artful). But this is also all very basic stuff and in itself tedious, and, especially for the reason you stated, 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 game mechanics, but have never played them nor care to do so).
Furthermore, for the reason outlined in the posts 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 (as long as certain conditions have been met) as well as life itself being much more complicated... with significant implications for the process of making art and the development of an artist in one or more disciplines.
> As you probably can deduce by now, I see both examples as having the potential of being art
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 since 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, all without any follow-up as to why exactly. What "use" are you referring to here?
In the context of a programmer wanting to know how learning to draw compares to learning 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 repetition" is useful.
Once again, this isn't deduction or hypothesis. It's my own experience with both crafts.
> "[...] it's now completely clear that it has nothing to do with whether art or programming takes longer to gain proficiency."
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.
> 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.
> 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.
These are all the words you've said so far that address whether art takes longer to learn than programming. Your points boil down to 1) People have different strengths and weaknesses 2) Both require practice
But neither of these contradicts the statement "art generally takes longer to learn than programming."
> In the end it's useless mostly for entirely different reasons, though; reasons I have already explained as well.
Here are all the words you've spent explaining why the observation is useless:
Oh... actually nothing. This whole discussion started when you said
> Such overgeneralizations are not helpful
But they've already been helpful to me before, and no fewer than one other person. Even if it's not much, "useless" is untrue. I said "this is what I've found to be true, and observed in others like me," and you said "this is not a useful observation." You never said why, you just jumped straight to "I already adressed that."
My last post from me on this.
> "But neither of these contradicts the statement "art generally takes longer to learn than programming."
Man alive, I've already explained this multiple times, and you misread each and every time. You even postulate programming as something outside of art; a statement I have fundamentally disagreed with. You're fighting strawmen, and we therefore run rings around each other.
> "Oh... actually nothing. This whole discussion started when you said [...]"
The discussion started when I objected to your statement that "it takes a lot longer to become a reasonably good artist than it does to become a reasonably good programmer".
To me it's nothing but an imprecisely articulated, sweeping generalization constructed around the anectodal "evidence" that's your life (with an unknown sample size of people you've met or read about that might agree with you to some extent). In other words it's nothing but tedious fallacies, a thing oft observed in such discussions.
It's also a massive red flag; I at least would never be so presumptious and arrogant to make myself the yardstick and declare cocksure that one discipline will take longer than the other for some to me completely unknown reader. I know many a great artist who paints and/or writes but could not program their way out of a wet paper bag (they're practically computer illiterate and have absolutely no ambitions or time to change that), let alone reach the same heights there as in their chosen medium of expression. And vice versa. So what's useful to you, and what might be useful to me, is not automatically applicable to others and therefore it's useless to generalize, at least without any hard data to back it up (and even then the addressed party might be an outlier).
If one wants to find out which form(s) of expression is/are best suited for oneself, one needs to spread the wings and take to said form(s). How long that will take no one can say for sure; therefore what takes longer if one gravitates to more than one form, no one can can make reasonably accurate predictions about either. Especially not without knowing at least a modicum of relevant information about the individual any advice is supposed to enrich in the first place.
Hence, when addressing a general audience, better concentrate on giving detailed and sound advice on how to get better, or speak to useful mitigation strategies/life hacks, as opposed to shallow and often unapplicable generalizions about the future. In German there's a terminus technicus for such sillyness: Glaskugelei.
To these fine tips I would add: ‘test on as many devices as you are reasonably able’. Something can look fine on your laptop but lousy on the platform for which you are aiming to disseminate.
> "[...] I would add: ‘test on as many devices as you are reasonably able’."
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 software-based filters etc.
...and different screen brightness levels
This also applies to webdev. I develop a lot with the chrome devtools but once stuff is in mobile it doesn't quite work out due to people using different browsers. The browser bar sometimes being on top or on the bottom hiding controls... I started to just center stuff in mobile ignoring like 20% of space in top and the bottom.
Good advice. I draw pixel art for an image logic puzzle game [1] and these resonate, especially 2. (Negotiate) and 5. (Constraints).
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...
From great constraints comes great creativity.
I don't think the author's two samples look good.
The samurai one looks pretty good to me. The Kirby and Mario ones are… well they’re awfully derivative, natch.
These are just incredibly basic, and oft repeated, pixel art 101 guidelines. And, quite frankly, some of those tips are what I consider bad advice (e. g. a pixel artist has to deal with color theory as much as a character artist or animator has to deal with anatomy; a good understanding of color theory is also necessary to nurture good taste in the first place... so the quicker one gets into that, the better).
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.
> a good understanding of color theory is also necessary.
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.
It's for an uninformed audience so it's not like it's supposed to be some deep insights
I hate to be that guy but the quality of OP’s showcased pixel art is pretty mediocre. Strikes me as someone who’s still learning and figuring things out and not in a particularly solid position to teach others.
They’re your pixels for your project, not some conformation challenge.
I'm a programmer who started doing pixel art for a personal project in 2022 and this is solid advice. I didn't really think about it too hard but I do find myself negotiating with the canvas to get something to look right when it's just a few pixels off lol
[dead]