Original text and translation licensed under CC-BY.
At the moment, Battle for Wesnoth has 109 different artists , so Jetrel knows what he's talking about.
Source .
In addition to the main thesis, the article will also touch upon the following issues:
- What attracts us to programming?
- What is the danger of graphic editors for mods?
- How long do creators wait?
- Does an artist need to know programming?
- How many concept art artists do you need?
- How to find that one?
- What to do with the stars?
It is unlikely that the author will register on Habré independently. But if you have questions, I can forward them. I myself got the consent for the translation through the Frogatto channel in the discord .
The following will be presented in the first person.
I've been asked many times on IRC for this article, and finally got around to writing it. There may be a few typos in it. Feel free to bookmark them and discuss things that you think should be added to this article. Most likely it is not comprehensive enough.
At the time of writing (2009), open-source game projects stereotypically had a surplus of programmers and a painful lack of artists. Consequently, this negatively affected the community. Many of our games are ashamed to be shown to the public. They are only attractive to a handful of players who don't care about looks.
Open-source and the indie community are in the green grapes position. In other words, good looks are considered the hallmark of bad commercial games. Sometimes it comes down to a slight hostility to good graphics. This article will not advocate the importance of graphics. It is scientifically proven that most people are visuals, which means they appreciate a beautiful picture in games. If you are not ready to accept this, you are deliberately driving yourself into a small ghetto. I can't help you with that - this article assumes that you want to make a game that the widest possible audience will enjoy.
It's hard to argue that in a lot of commercial games, good graphics cover up poor gameplay, but the reason for this is tight deadlines, tight budgets, and a lack of "natural selection" to filter out games that aren't fun to play. Many companies flood games with money and graphics, and then find them hard to enjoy. This realization comes after huge resources have been spent. Usually they are left unfinished because executives cannot afford to redesign or are afraid of losing expensive art that will no longer be used after major changes.
The good news is that Open Source is immune to these kinds of problems by default.
The very essence of open-source means that an open-source game will only become popular if it is fun to play. That is why people will spend time on art for interesting games. In addition, Open-source has no strict deadlines or budget, so they can afford to redo everything they need to make the game interesting at their leisure. To please the artists and get new art, you must cherish the existing art until you complete the refactoring and build a foundation of interesting game mechanics.
The key to attracting creators is to attract a multitude of players and communicate to them that you are ready to accept their input. Statistically, a certain percentage of players will be creators. If you target a specific subculture, there will be a disproportionate number of people interested in visual arts (such as fantasy or science fiction). In order to retain creators, you need to keep them motivated. You don't pay your creators, so motivation is the only way to keep them in your project. As soon as they stop receiving pleasure or recognition, they will walk out the door.
Make an interesting game
To get a lot of players, and therefore creators, make a really interesting game. It's difficult. Many books can be written on this topic, but this is the main reason.
Use common file formats
Another important factor is to use the most open formats. By openness, I don't mean the terms open-source, but rather “the formats that people usually work with”. They are often the same thing, but not always. It is very important that people can completely prepare art for the game without special tools and at the same time can go into the game and immediately see the result in action, without additional help. Typically, this implies using formats like OGG or PNG, rather than self-made formats, as in many games of the 90s. If you write your own music format like MOD or your own way of storing bitmasks, then no one will have the tools to create art in your game. They will have to wade through your toolbox. This will drive away a large percentage of possible participants,because most people "taste the water" in creating art by simply fiddling with their copy of the game.
In addition to the above, most of the creators interested in developing a game actually have modding skills. Your engine must support mods. They should be able to create their own levels, creatures and characters. Creators are very attracted to the part of the game that allows them to tell their own story. You can achieve this with a great editor or an affordable text storage format for everything. Most creators in game development have a good enough command of a computer to edit text data files. The game editor will be even better because it can be used by almost everyone, but it takes a very long time to implement. Especially for content that rarely changes. The danger of the holy grail of making a GUI "for everything" isthat some parts of the game will still require programming, no matter how you represent them. Therefore, it is better to program them in traditional ways. If you try to make gui for them, you will end up with a graphical programming language, but most likely you will just bring disaster.
Reducing the entry threshold for participating in a project is really important. First, a person needs to try to make art for you, and only then he can understand that he likes it. In everyday life, no one decides to seriously do something and only then fall in love with it. In most cases, people will not seriously invest in an activity and then decide whether they like it or not. At first, a person will get to know the lesson superficially and only if he likes it, will he deepen and continue to do it. If he doesn't get a chance to casually pamper with him, then he won't start. This is how most modders began their journey - at first, frivolous pampering with the built-in editor, he aroused their interest, and then events grow like a snowball. For the same reason,most of the readers started their journey in programming - you wrote something trivial in a friendly environment, it worked, and the joy of creativity beckoned you to more. Instant gratification is really important - it creates momentum and motivation.
Instant gratification is essential to keep creators motivated. If the creator starts preparing a masterpiece for you, it is very important that the result of the work gets to the master as soon as possible. It's thrilling to see your work recognized and included in the official build of the game. Likewise, and vice versa, it is killer to know that your work is not needed by anyone. Creators rarely understand how difficult programming is, which means they will think that you are not using their work because you are not happy about it. It's the same for art and code, creators can't read your mind. If you planned to watch this in a few weeks, then no one will know about it. If you don't immediately start working with the proposed code, art or music, then they will no longer do anything to you. This is not a problem for a one-time bug fix. But this is a bad sign for thosewho sends you the first sample and is ready to fill your game with models and graphics. You need to follow them, you need to work with them and keep them interested. Almost all the participants who can fill your game will be lost if you do not return to them in a week or a couple of days. This is one of the arguments in favor of the RERO (release early, release often) policy.
It may not be obvious, but artists cannot compile your game. If the official releases are less than once a month or two, you should provide them with releases. They shouldn't be stuck in the ghetto of outdated versions, because they will fall out of the stream of innovations in your game. They are also part of the team and it is important for them to see how their work is combined with new changes. It is also very important to release releases for their platform. I know that Linux programmers don't always have the ability to compile for Mac (for example). But if someone offers a masterpiece, you need to provide him with a release. Because if they cannot play your game, then they are not interested in helping you. In practice, you need a publicly available pre-built build for Mac and Windows. Dot. If you do not have one, then 99% of computer users will not play your game,which means they will not be interested in creating masterpieces for her. Mac is especially important for artists and musicians because there are disproportionately many of them.
Prove that the game is successful
The creators categorically disapprove of plans in the spirit of “infinity is not the limit”. There are a dime a dozen such projects. Most video games (both open-source and commercial) are underdogs, and most creators interested in creating art for a video game have already tried participating in at least one project and have had a hard time taking it down. All their work is gone. The problem is that creators don't have the ability to measure developer skills. Other developers may look sideways at the code and decide whether it is reliable or terrible, but most creators only have word of mouth. They have no idea if you have what it takes. To show that you are serious, you need to complete the basic gameplay. As in Return of the Jedi, the Death Star does not need to be completed, but must be "fully functional."
In general, this is good game design practice. First, you make a quick prototype and build the main functional elements of the game as soon as possible. It is worth mentioning that I have seen countless game projects that are positioned as a launching pad for Architectural Astronauts. If you only want to focus on AI development and don't care about completing the game, then don't lure potential participants with your "game development" claims. Can't answer for your words, in the hope that everything will turn out by itself? Burn in hell. The people who create masterpieces are really serious, otherwise they would be wasting time on their portfolios on galleries like DeviantArt. Only declare that you are making a game if your primary goal is to complete a quality and flawless game.
Don't Let Architecture Astronauts Scare You
[approx. This link was in the original, I leave it as it is]
Artists need graphics authority
Perhaps you think you know best what your game should look like. If you don't do all the art yourself, give up your intentions. Your artists usually enjoy some of their visual style. Remember that they do not work for money, but for pleasure. You either agree with them, or you are left without art at all. This is totally different from commercial games. You are not the boss, you cannot tell them what to do. Artists need a complete carte blanche about art. Just like programmers are empowered to choose the programming language and coding standard. You would rightly be outraged if the artists told you what to change. In any case, requests to redo the work due to inappropriate style will destroy the magic and spoil the pleasure of work. No pleasure, no artist.
Finding an artist for a game project is like finding a bride. As in family life, you want to avoid marrying (or getting married) to an artist who does something you hate. If you are creating a video game and an artist has come to you who offers work in a style that you absolutely do not like (for example, anime), you may need to turn him down. It's best to do this beforehand. The last thing you need is a time bomb. It's a tough choice. You may not have art if you refuse this person, but it is better to be true to yourself and resolve this issue. Maybe you should put up with a style that slightly pisses you off.
You need a lead artist
One of the obvious problems can arise when several artists in a team pull a cart in different directions. What to do in this case? Exactly the same as with the code. Pick the one who does the best job (and is serious about getting the project through) and let him be the dictator. If he really does the lion's share of the work, then you are not afraid to scare away people who disagree with him. Thus, everyone who wants to participate will bring you neat masterpieces of the same style and quality. In other words, you need to pretend to be a commercial game. Trusting someone with authority and authority also positively influences the motivation of that creator. They will usually work harder and live up to your confidence in terms of graphics.
The best option is to hook the same enthusiastic maniac like you, but who wants to do graphics, not code. He will be able to call your game his own.
It is important that such a person has the authority to remove unfortunate fragments that are out of the general style. Yes, it sounds wasteful, but commercial companies do it all the time. Therefore, their games are made in a single integral style. For the same reason, coders throw away the husk during refactoring. You just need to worry that the total amount of removed content does not exceed the amount of content created. The same principle works with code. You don't follow the advice of the first person who comes into your project and declares the refactoring of everything. Let him first prove that he knows what he is doing.
You can have more than one lead artist. Where art falls into obvious categories that require a different skill set, then artists will naturally fall into skill groups. Many skilled illustrators are completely incompetent in 3D modeling (and vice versa).
You don't need concept artists
At least in the form of a separate, independent specialization. The concept artist exists in the culture of commercial companies, which can flood the issue of "creativity" with money. This is the highest form of leadership. They create concepts, and other artists have to digest them and create useful pieces of the game itself. This level of specialization is usually quite wasteful. In addition, it deprives "followers" of the right to their own creativity, which is enjoyable and is the reason for their free participation. They put up with it in commercial projects because they get paid, but usually they don't like it - they are forced to do exactly what the concept artist has done and are not given the opportunity to show their own flair for design.
You need artists who will create images that can be used in the game. Without these, you won't have a game. You won't be able to apply the concept artists' work to the game. Images by themselves are useless. Interestingly, creators who can create useful images can also create concept art. It will take more time from them, but this is the most enjoyable part of becoming an artist. Almost everyone will one day be like this. In addition, the art team will usually be creative enough that the need for a separate concept artist simply does not arise. This is definitely enough for you to ensure a decent appearance.
Artists develop in an atmosphere of technical criticism
There is a notable multitude of celebrity creators who consider their work "above" any criticism. It is wise of you to recognize these and point them to the door as soon as possible. Even if they are good, they will do more harm than good. Remember that the search for an artist is marriage / marriage, which means mutual networking. Including from the artist's side. Despite the fact that in the visual arts, a lot depends on the subjective view and opinion, a lot of things can be assessed using objective quality metrics. It takes skill to create good art, and some people suck.
How Art Can Be Good
[approx. This link was in the original, I leave it as it is]
Even the best of artists can make technical mistakes in their work. For example limbs from unexpected places; strange and unnatural positions (because in reality they would be impossible or tiring); perspective from which Escherwould spin in a coffin. These moments do not depend on the visual style or "deep thoughts" of the artist. Misses happen because the performer screwed up. An image with errors like this looks silly, even to the author, as soon as he realizes his mistake. People need to keep their opinions about style to themselves, but sound criticism of real mistakes will benefit everyone. This atmosphere will make your art look better. This will allow your artists to grow. The creators will get the impression that they are being treated fairly. This encourages healthy dialogue about creating art for your project and is much better than the one-line, unnatural "great job" comments when discussing fresh proposals.
In summary, treat creators (both artists and composers) as your equal partners in game development and one day you will find a maniac just like yourself. To find it successfully, you need to understand where it might come from and put your efforts into providing it with an accessible environment. Remember, if a person offered your game a few man-years of work, then it will be as "his" as it is "yours."
Q&A
Why not make the graphics switchable? Then he won't see a style he doesn't like.
Original text
In general, a major software-development principle we held when working on Wesnoth (and which I think is generally pretty smart) was: «options are bad».
Every option in a software program is another code path you have to support, and the combinatorial complexity of multiple code paths, when it comes to testing and all sorts of similar «hidden costs» of doing development, really adds up.
So you don't want to accept multiple kinds of art, and gate each kind of art behind an option flag which users (or the author) can turn off.
It's bad because not only does it increase the support costs of the software, but it also makes it harder to achieve the goal of having a single, coherent art set for the project you're on, because it severely «confuses» your messaging to new contributors.
Ultimately if you've got a game that only has a portion of the art done, your game's mere existence is the best «help wanted» ad for getting additional art. But a critical part of asking for this additional art is a detailed description of what you need to do to match the game's current style.
The thing is — just existing is usually enough. «A picture is worth a thousand words». You don't need to waste a huge amount of time explaining what you want if you've got a large body of examples.
But — if these examples severely contradict themselves, then you're in for a lot of pain. If you've got two radically different visual styles, it's very difficult to explain to new contributors «which style» you'd like the game to actually be in.
All of a sudden you go from a hands-off, «no work for the project lead» matter of just letting the art speak for itself, to having to be deeply, personally involved in steering people.
— Alternate interpretation: It's possible you're suggesting a scenario in which someone's offering to make art for the game in a single, coherent style, and this is a situation where the entire game would get art, but you, the developer, would hide the art from yourself.
At the risk of being impolite, this is absolutely insane.
Which is to say it's «impossible» — there's an enormous time-cost and ongoing maintenance cost of time you'll have to spend getting the graphics to display correctly, and making sure they continue to display correctly as development continues and features get added and removed.
In almost all cases where this has happened (dwarf fortress being a key example), these external «artists» essentially did an enormous amount of programming to make their work viable.
Dwarf fortress mods operate by literally doing direct memory access and looking at the RAM state of the app as it runs, since there's no mod API or anything, but even if you did have a mod API — somebody has to pay the enormous cost of writing the code to get the entire graphics-drawing layer working correctly, and the complexity of doing this is usually equivalent to writing an entire game of its own.
… I mean — any game where this succeeds has essentially «won the lottery», and is an extremely dangerous target to imitate the habits of, because it succeeded not due to «good developer practices» but because it got insanely lucky.
A dangerous thing when looking at the dev practices of other games, especially «popular, successful» games, is a phenomenon called «survivor bias».
Survivor bias is when someone looks at the behavior of a very successful thing, and instead of thinking «oh, they were really successful, so they were able to survive even though they made a bad choice» — instead, one assumes «oh, they succeeded BECAUSE they made this choice».
For example — dwarf fortress doesn't use source control. :ohno:
Not git, not svn, not cvs. They just have old copies of the code in folders.
Anyways, when it comes to art — I honestly personally believe you're going to be entering a really toxic/awkward relationship if you're working with an artist who's producing a style you really don't like.
You can try to «fake» it by being nice, and accepting the art even though you don't like it, but you're far better off just living without and being honest.
It's a lot like getting married. :neutral_face:
Every option in a software program is another code path you have to support, and the combinatorial complexity of multiple code paths, when it comes to testing and all sorts of similar «hidden costs» of doing development, really adds up.
So you don't want to accept multiple kinds of art, and gate each kind of art behind an option flag which users (or the author) can turn off.
It's bad because not only does it increase the support costs of the software, but it also makes it harder to achieve the goal of having a single, coherent art set for the project you're on, because it severely «confuses» your messaging to new contributors.
Ultimately if you've got a game that only has a portion of the art done, your game's mere existence is the best «help wanted» ad for getting additional art. But a critical part of asking for this additional art is a detailed description of what you need to do to match the game's current style.
The thing is — just existing is usually enough. «A picture is worth a thousand words». You don't need to waste a huge amount of time explaining what you want if you've got a large body of examples.
But — if these examples severely contradict themselves, then you're in for a lot of pain. If you've got two radically different visual styles, it's very difficult to explain to new contributors «which style» you'd like the game to actually be in.
All of a sudden you go from a hands-off, «no work for the project lead» matter of just letting the art speak for itself, to having to be deeply, personally involved in steering people.
— Alternate interpretation: It's possible you're suggesting a scenario in which someone's offering to make art for the game in a single, coherent style, and this is a situation where the entire game would get art, but you, the developer, would hide the art from yourself.
At the risk of being impolite, this is absolutely insane.
Which is to say it's «impossible» — there's an enormous time-cost and ongoing maintenance cost of time you'll have to spend getting the graphics to display correctly, and making sure they continue to display correctly as development continues and features get added and removed.
In almost all cases where this has happened (dwarf fortress being a key example), these external «artists» essentially did an enormous amount of programming to make their work viable.
Dwarf fortress mods operate by literally doing direct memory access and looking at the RAM state of the app as it runs, since there's no mod API or anything, but even if you did have a mod API — somebody has to pay the enormous cost of writing the code to get the entire graphics-drawing layer working correctly, and the complexity of doing this is usually equivalent to writing an entire game of its own.
… I mean — any game where this succeeds has essentially «won the lottery», and is an extremely dangerous target to imitate the habits of, because it succeeded not due to «good developer practices» but because it got insanely lucky.
A dangerous thing when looking at the dev practices of other games, especially «popular, successful» games, is a phenomenon called «survivor bias».
Survivor bias is when someone looks at the behavior of a very successful thing, and instead of thinking «oh, they were really successful, so they were able to survive even though they made a bad choice» — instead, one assumes «oh, they succeeded BECAUSE they made this choice».
For example — dwarf fortress doesn't use source control. :ohno:
Not git, not svn, not cvs. They just have old copies of the code in folders.
Anyways, when it comes to art — I honestly personally believe you're going to be entering a really toxic/awkward relationship if you're working with an artist who's producing a style you really don't like.
You can try to «fake» it by being nice, and accepting the art even though you don't like it, but you're far better off just living without and being honest.
It's a lot like getting married. :neutral_face:
In general, when developing Battle for Wesnoth, we adhered to the principle of "choice is evil". Each option in the program is an additional branch of code that you need to maintain. The total number of code branches grows according to the laws of combinatorics. As a consequence, the complexity of testing and the "invisible cost" of development increases.
So you don't really want to take a lot of art directions and have a disable flag for each one in the options.
Choice is evil not only because it increases the cost of maintaining software. The choice will prevent you from achieving a consistent and consistent style of art in your project, because your message to new contributors will be "noisy".
Ultimately, if your game has only a part of the art ready, then its very existence will best convey the idea "I need help" to get additional art. But the important part of asking for help is detailing exactly what you need to match your overall play style.
The thing is, existence alone is enough. "One picture is worth a thousand words." If you have many examples, then you don't have to spend a lot of time explaining your vision with text. But if these examples contradict each other, then you will suffer. The existence of two radically different styles of art will prevent you from explaining which style you yourself would like to end up with.
Normally, you don't need to interfere with the development of the visual style. Art will speak for himself. But given the choice, you suddenly have to micromanage and guide everyone on your own.
Another interpretation. Perhaps you propose a scenario when you have a participant who is able to take over all the work with the art, but at the same time you, as the author, will hide this art from yourself.
I may sound impolite, but this is crazy.
And in fact, this is almost impossible - you will spend enormous efforts in order to ensure the correct display of this very art both at the beginning and throughout the life of the project.
This has already happened in dwarf fortress and in several other projects. Ultimately, the "outside artists" had to invest a lot of programming effort in order to get their work to be seen at all.
Dwarf fortress mods work with direct access to the RAM of the running process. There is no direct API for modding or anything like that.But even if there was one, someone would still have to write code to make the graphics display layer work. The complexity of this task is comparable to developing your own game.
... I mean, you don't have to look up to games where this "won the lottery" approach. This is a very dangerous example because it succeeds not through "good development practices" but through incredible luck.
Looking at the development practices of popular and successful games is generally a bad idea. There is even a term - “survivor's mistake”. Instead of saying "wow, they were able to survive despite bad decisions" - people say "they succeeded BECAUSE they made those decisions."
Well, for example, dwarf fortress does not use version control. Neither git, nor svn, not even cvs. They just copy a folder into a directory.
Whatever it is, I personally feel that working with an artist whose style you don't like is unnatural disrespect for yourself. You can pretend, be polite and accept art even if you don't like it, but it will be much easier for you to refuse and be honest with yourself.
This is very similar to marriage / marriage.
PS If you find typos or mistakes in the text, please let me know. This can be done by selecting part of the text and pressing "Ctrl / ⌘ + Enter", if you have Ctrl / ⌘, or through private messages . If both options are not available, write about errors in the comments. Thanks!