Teks dan terjemahan asli berlisensi CC-BY.
Saat ini, Battle for Wesnoth memiliki 109 artis berbeda , jadi Jetrel tahu apa yang dia bicarakan.
Sumber .
Selain tesis utama, artikel ini juga akan menyinggung isu-isu berikut:
- Apa yang membuat kita tertarik pada pemrograman?
- Apa bahaya editor grafis untuk mod?
- Berapa lama pembuat konten menunggu?
- Apakah seorang seniman perlu mengetahui pemrograman?
- Berapa banyak seniman seni konsep yang Anda butuhkan?
- Bagaimana cara menemukannya?
- Apa hubungannya dengan bintang?
Penulis kecil kemungkinannya akan mendaftar di Habré secara mandiri. Tetapi jika Anda memiliki pertanyaan, saya dapat meneruskannya. Saya sendiri mendapat persetujuan untuk terjemahan melalui saluran Frogatto dalam perselisihan tersebut .
Berikut ini akan disajikan sebagai orang pertama.
Saya telah ditanya berkali-kali di IRC untuk artikel ini, dan akhirnya sempat menulisnya. Mungkin ada beberapa kesalahan ketik di dalamnya. Jangan ragu untuk mem-bookmark mereka dan mendiskusikan hal-hal yang menurut Anda harus ditambahkan ke artikel ini. Kemungkinan besar itu tidak cukup komprehensif.
Pada saat penulisan (2009), proyek game open source secara stereotip memiliki kelebihan programmer dan kekurangan artis yang menyakitkan. Akibatnya, hal ini berdampak negatif pada masyarakat. Banyak dari game kami yang malu untuk ditampilkan ke publik. Mereka hanya menarik bagi segelintir pemain yang tidak peduli dengan penampilan.
Sumber terbuka dan komunitas indie berada pada posisi anggur hijau. Dengan kata lain, ketampanan dianggap sebagai ciri khas game komersial yang buruk. Terkadang itu disebabkan oleh sedikit permusuhan terhadap grafik yang bagus. Artikel ini tidak akan menganjurkan pentingnya grafik. Terbukti secara ilmiah bahwa kebanyakan orang adalah visual, artinya mereka menghargai gambar yang indah dalam game. Jika Anda tidak siap menerima ini, Anda sengaja membawa diri Anda ke dalam ghetto kecil. Saya tidak dapat membantu Anda - artikel ini berasumsi bahwa Anda ingin membuat game yang akan dinikmati oleh sebanyak mungkin penonton.
Sulit untuk membantah bahwa di banyak game komersial, grafik yang bagus menutupi gameplay yang buruk, tetapi alasannya adalah tenggat waktu yang ketat, anggaran yang ketat, dan kurangnya "seleksi alam" untuk menyaring game yang tidak menyenangkan untuk dimainkan. Banyak perusahaan membanjiri permainan dengan uang dan grafik, dan kemudian menganggapnya sulit untuk dinikmati. Kesadaran ini muncul setelah sumber daya yang besar telah dihabiskan. Biasanya mereka dibiarkan belum selesai karena para eksekutif tidak mampu mendesain ulang atau takut kehilangan seni mahal yang tidak akan lagi digunakan setelah perubahan besar.
Kabar baiknya adalah Open Source kebal terhadap jenis masalah ini secara default.
Inti dari open-source berarti bahwa game open-source hanya akan menjadi populer jika menyenangkan untuk dimainkan. Itulah mengapa orang akan menghabiskan waktu untuk seni untuk permainan yang menarik. Selain itu, Open-source tidak memiliki tenggat waktu atau anggaran yang ketat, sehingga mereka mampu mengulangi semua yang mereka butuhkan untuk membuat permainan menarik di waktu luang mereka. Untuk menyenangkan para seniman dan mendapatkan seni baru, Anda harus menghargai seni yang ada sampai Anda menyelesaikan pemfaktoran ulang dan membentuk dasar dari mekanisme permainan yang menarik.
Kunci untuk menarik kreator adalah menarik banyak pemain dan menyampaikan kepada mereka bahwa Anda siap menerima masukan mereka. Secara statistik, persentase tertentu dari pemain akan menjadi pencipta. Jika Anda menargetkan subkultur tertentu, akan ada banyak orang yang tertarik dengan seni visual (seperti fantasi atau fiksi ilmiah). Untuk mempertahankan pembuat konten, Anda harus membuat mereka tetap termotivasi. Anda tidak membayar pencipta Anda, jadi motivasi adalah satu-satunya cara untuk mempertahankan mereka dalam proyek Anda. Begitu mereka berhenti menerima kesenangan atau pengakuan, mereka akan keluar dari pintu.
Buat game yang menarik
Untuk mendapatkan banyak pemain, dan juga pembuatnya, buatlah game yang sangat menarik. Itu sulit. Banyak buku yang dapat ditulis tentang subjek ini, tetapi ini adalah alasan utamanya.
Gunakan format file umum
Faktor penting lainnya adalah menggunakan format paling terbuka. Dengan keterbukaan, yang saya maksud bukan istilah open-source, melainkan "format yang biasanya digunakan orang". Seringkali mereka adalah hal yang sama, tetapi tidak selalu. Sangat penting bahwa orang dapat sepenuhnya mempersiapkan seni untuk permainan tanpa alat khusus dan pada saat yang sama dapat masuk ke dalam permainan dan segera melihat hasilnya dalam aksi, tanpa bantuan tambahan. Biasanya, ini berarti menggunakan format seperti OGG atau PNG, daripada format buatan sendiri seperti di banyak game tahun 90-an. Jika Anda menulis format musik Anda sendiri seperti MOD atau cara Anda sendiri untuk menyimpan bitmask, maka tidak akan ada yang memiliki alat untuk membuat karya seni dalam gim Anda. Mereka harus mengarungi kotak peralatan Anda. Ini akan menyingkirkan sebagian besar kemungkinan peserta,karena kebanyakan orang "mencicipi air" dalam menciptakan karya seni hanya dengan mengutak-atik salinan permainan mereka.
Selain hal di atas, sebagian besar pencipta yang tertarik untuk mengembangkan game sebenarnya memiliki keterampilan modding. Mesin Anda harus mendukung mod. Mereka harus bisa menciptakan level, makhluk, dan karakter mereka sendiri. Pembuat konten sangat tertarik dengan bagian game yang memungkinkan mereka menceritakan kisah mereka sendiri. Anda dapat mencapai ini dengan editor hebat atau format penyimpanan teks yang terjangkau untuk semuanya. Sebagian besar pembuat dalam pengembangan game cukup baik dengan komputer untuk mengedit file data teks. Editor game ini akan menjadi lebih baik lagi karena dapat digunakan oleh hampir semua orang, tetapi membutuhkan waktu yang sangat lama untuk mengimplementasikannya. Apalagi untuk konten yang jarang berubah. Bahaya cawan suci membuat GUI "untuk segalanya" adalahbahwa beberapa bagian dari permainan masih memerlukan pemrograman, tidak peduli bagaimana Anda merepresentasikannya. Karena itu, lebih baik memprogramnya dengan cara tradisional. Jika Anda mencoba membuat gui untuk mereka, Anda akan berakhir dengan bahasa pemrograman grafis, tetapi kemungkinan besar Anda hanya akan membawa bencana.
Sangat penting mengurangi ambang masuk untuk berpartisipasi dalam proyek. Pertama, seseorang perlu mencoba membuat karya seni untuk Anda, dan baru kemudian dia bisa mengerti bahwa dia menyukainya. Dalam kehidupan sehari-hari, tidak ada yang memutuskan untuk serius melakukan sesuatu dan hanya kemudian jatuh cinta padanya. Dalam kebanyakan kasus, orang tidak akan secara serius berinvestasi dalam suatu aktivitas dan kemudian memutuskan apakah mereka suka atau tidak. Pada awalnya, seseorang akan mengetahui pelajaran secara dangkal dan hanya jika dia menyukainya, dia akan memperdalam dan terus melakukannya. Jika dia tidak mendapat kesempatan untuk memanjakannya dengan santai, dia tidak akan mulai. Begitulah cara sebagian besar modder memulai perjalanan mereka - pada awalnya, sembrono memanjakan dengan editor bawaan, dia membangkitkan minat mereka, dan kemudian acara tumbuh seperti bola salju. Untuk alasan yang sama,sebagian besar pembaca memulai perjalanan mereka dalam pemrograman - Anda menulis sesuatu yang sepele dalam lingkungan yang bersahabat, berhasil, dan kegembiraan kreativitas memanggil Anda untuk lebih. Kepuasan instan sangat penting - ini menciptakan momentum dan motivasi.
Kepuasan instan sangat penting untuk membuat pencipta termotivasi. Jika pencipta mulai menyiapkan sebuah mahakarya untuk Anda, sangat penting bahwa hasil karya tersebut sampai ke master secepat mungkin. Sungguh mendebarkan melihat karya Anda dikenali dan dimasukkan dalam build resmi game. Demikian pula, dan sebaliknya, sangatlah mematikan mengetahui bahwa pekerjaan Anda tidak dibutuhkan oleh siapa pun. Pembuat konten jarang memahami betapa sulitnya pemrograman, yang berarti mereka akan merasa bahwa Anda tidak menggunakan karya mereka karena Anda tidak menyukainya. Ini sama untuk seni dan kode, pencipta tidak dapat membaca pikiran Anda. Jika Anda berencana menonton ini dalam beberapa minggu, maka tidak akan ada yang mengetahuinya. Jika Anda tidak segera mulai mengerjakan kode, seni, atau musik yang diusulkan, mereka tidak akan lagi melakukan apa pun untuk Anda. Ini bukan masalah untuk perbaikan bug satu kali. Tapi ini pertanda buruk bagi merekayang mengirimkan sampel pertama kepada Anda dan siap mengisi game Anda dengan model dan grafik. Anda perlu mengikuti mereka, Anda perlu bekerja dengan mereka dan membuat mereka tetap tertarik. Hampir semua peserta yang dapat mengisi permainan Anda akan hilang jika Anda tidak kembali kepada mereka dalam seminggu atau beberapa hari. Ini adalah salah satu argumen yang mendukung kebijakan RERO (rilis lebih awal, sering rilis).
Ini mungkin tidak jelas, tetapi artis tidak dapat menyusun game Anda. Jika rilis resmi kurang dari satu atau dua bulan sekali, Anda harus menyediakan rilis. Mereka tidak boleh terjebak dalam ghetto versi lama, karena mereka akan keluar dari aliran inovasi dalam game Anda. Mereka juga bagian dari tim dan penting bagi mereka untuk melihat bagaimana pekerjaan mereka digabungkan dengan perubahan baru. Juga sangat penting untuk merilis rilis untuk platform mereka. Saya tahu bahwa programmer Linux tidak selalu memiliki kemampuan untuk mengkompilasi untuk Mac (misalnya). Tetapi jika seseorang menawarkan sebuah mahakarya, Anda perlu memberinya pelepasan. Karena jika mereka tidak bisa memainkan permainan Anda, maka mereka tidak tertarik untuk membantu Anda. Dalam praktiknya, Anda memerlukan versi bawaan yang tersedia untuk umum untuk Mac dan Windows. Dot. Jika Anda tidak memilikinya, maka 99% pengguna komputer tidak akan memainkan game Anda,yang berarti mereka tidak akan tertarik untuk membuat mahakarya untuknya. Mac sangat penting bagi artis dan musisi karena jumlahnya tidak proporsional.
Buktikan bahwa game tersebut berhasil
Pencipta dengan tegas tidak menyetujui rencana dalam semangat "ketidakterbatasan bukanlah batas". Ada selusin proyek serupa. Sebagian besar video game (baik sumber terbuka maupun komersial) adalah underdog, dan sebagian besar pencipta yang tertarik untuk membuat seni untuk video game telah mencoba berpartisipasi dalam setidaknya satu proyek dan mengalami kesulitan melewati kejatuhannya. Semua pekerjaan mereka hilang. Masalahnya adalah pencipta tidak memiliki kemampuan untuk mengukur keterampilan pengembang. Pengembang lain mungkin melihat ke samping pada kode dan memutuskan apakah itu dapat diandalkan atau buruk, tetapi kebanyakan pembuat hanya berbicara dari mulut ke mulut. Mereka tidak tahu apakah Anda memiliki apa yang diperlukan. Untuk menunjukkan bahwa Anda serius, Anda perlu menyelesaikan gameplay dasar. Seperti dalam Return of the Jedi, Death Star tidak perlu diselesaikan, tetapi harus "berfungsi penuh".
Secara umum, ini adalah praktik desain game yang bagus. Anda terlebih dahulu membuat prototipe cepat dan membangun elemen fungsional utama game sesegera mungkin. Perlu disebutkan bahwa saya telah melihat proyek game yang tak terhitung jumlahnya yang diposisikan sebagai landasan peluncuran untuk Astronot Arsitektur. Jika Anda hanya ingin fokus pada pengembangan AI dan tidak peduli untuk menyelesaikan game, jangan memancing calon peserta dengan klaim "pengembangan game" Anda. Tidak bisa menjawab kata-katamu, dengan harapan semuanya akan berubah dengan sendirinya? Terbakar di neraka. Orang yang membuat mahakarya benar-benar serius, jika tidak mereka akan membuang-buang waktu untuk portofolio mereka di galeri seperti DeviantArt. Nyatakan bahwa Anda membuat game hanya jika tujuan utama Anda adalah menyelesaikan game yang berkualitas dan sempurna.
Jangan Biarkan Astronot Arsitektur Menakut-nakuti Anda
[kira-kira. Tautan ini ada di aslinya, saya biarkan apa adanya]
Seniman membutuhkan otoritas grafis
Mungkin Anda pikir Anda tahu yang terbaik seperti apa permainan Anda seharusnya. Jika Anda tidak melakukan semua seni sendiri, lepaskan niat Anda. Artis Anda biasanya menyukai gaya visual mereka. Ingatlah bahwa mereka tidak bekerja untuk uang, tetapi untuk kesenangan. Anda setuju dengan mereka, atau Anda dibiarkan tanpa seni sama sekali. Ini sangat berbeda dari game komersial. Anda bukan bos, Anda tidak bisa memberi tahu mereka apa yang harus dilakukan. Seniman membutuhkan carte blanche lengkap tentang seni. Sama seperti programmer diberdayakan untuk memilih bahasa pemrograman dan standar pengkodean. Anda akan benar-benar marah jika artis memberi tahu Anda apa yang harus diubah. Bagaimanapun, permintaan untuk mengulang pekerjaan karena ketidakcocokan gaya akan menghancurkan keajaiban dan merusak kenikmatan pekerjaan. Tidak ada kesenangan, tidak ada artis.
Menemukan artis untuk proyek game seperti mencari pengantin. Seperti dalam kehidupan keluarga, Anda ingin menghindari menikah (atau menikah) dengan artis yang melakukan sesuatu yang Anda benci. Jika Anda membuat gim video dan seorang seniman mendatangi Anda yang menawarkan karya dengan gaya yang sama sekali tidak Anda sukai (misalnya, anime), Anda mungkin perlu menolaknya. Yang terbaik adalah melakukan ini sebelumnya. Hal terakhir yang Anda butuhkan adalah bom waktu. Itu pilihan yang sulit. Anda mungkin tidak memiliki seni jika menolak orang ini, tetapi lebih baik jujur pada diri sendiri dan menyelesaikan masalah ini. Mungkin Anda harus menanggung gaya yang sedikit membuat Anda kesal.
Anda membutuhkan artis utama
Salah satu masalah yang jelas bisa muncul ketika beberapa seniman dalam sebuah tim menarik gerobak ke arah yang berbeda. Apa yang harus dilakukan dalam kasus ini? Persis sama dengan kodenya. Pilih orang yang melakukan pekerjaan terbaik (dan serius untuk menyelesaikan proyek) dan biarkan dia menjadi diktator. Jika dia benar-benar melakukan bagian terbesar dari pekerjaan itu, maka Anda tidak takut untuk menakut-nakuti orang yang tidak setuju dengannya. Dengan demikian, setiap orang yang ingin berpartisipasi akan membawakan Anda mahakarya yang apik dengan gaya dan kualitas yang sama. Dengan kata lain, Anda harus berpura-pura menjadi game komersial. Mempercayai seseorang dengan otoritas dan otoritas juga secara positif memengaruhi motivasi pencipta itu. Mereka biasanya akan bekerja lebih keras dan memenuhi kepercayaan Anda dalam hal grafik.
Pilihan terbaik adalah memikat orang yang sama antusiasnya dengan Anda, tetapi yang ingin membuat grafik, bukan kode. Dia akan dapat menyebut game Anda miliknya.
Penting bagi orang tersebut untuk memiliki kewenangan untuk menghilangkan bagian-bagian yang tidak sesuai dengan gaya umumnya. Ya, kedengarannya boros, tetapi perusahaan komersial melakukannya setiap saat. Oleh karena itu, permainan mereka dibuat dalam satu gaya yang tidak terpisahkan. Untuk alasan yang sama, pembuat kode membuang sekam selama pemfaktoran ulang. Anda hanya perlu khawatir bahwa jumlah total konten yang dihapus tidak melebihi jumlah konten yang dibuat. Prinsip yang sama bekerja dengan kode. Anda tidak mengikuti saran orang pertama yang datang ke proyek Anda dan menyatakan pemfaktoran ulang semuanya. Biarkan dia terlebih dahulu membuktikan bahwa dia tahu apa yang dia lakukan.
Anda dapat memiliki lebih dari satu artis utama. Jika seni masuk ke dalam kategori yang jelas dan membutuhkan keahlian yang berbeda, maka seniman secara alami akan masuk ke dalam kelompok keahlian. Banyak ilustrator terampil yang sama sekali tidak kompeten dalam pemodelan 3D (dan sebaliknya).
Anda tidak membutuhkan seniman konsep
Setidaknya dalam bentuk spesialisasi yang terpisah dan independen. Artis konsep ada dalam budaya perusahaan komersial, yang dapat membanjiri masalah "kreativitas" dengan uang. Ini adalah bentuk kepemimpinan tertinggi. Mereka menciptakan konsep, dan seniman lain harus mencernanya dan membuat bagian yang berguna dari permainan itu sendiri. Tingkat spesialisasi ini biasanya cukup boros. Selain itu, ini menghilangkan hak "pengikut" atas kreativitas mereka sendiri, yang menyenangkan dan merupakan alasan untuk partisipasi bebas mereka. Mereka bertahan dalam proyek komersial karena mereka dibayar, tetapi biasanya mereka tidak menyukainya - mereka dipaksa untuk melakukan apa yang telah dilakukan oleh seniman konsep dan tidak diberi kesempatan untuk menunjukkan bakat desain mereka sendiri.
Anda membutuhkan artis untuk membuat gambar yang dapat diterapkan pada game. Tanpa ini, Anda tidak akan memiliki game. Anda tidak akan dapat menerapkan karya seniman konsep ke dalam game. Gambar itu sendiri tidak berguna. Menariknya, kreator yang bisa membuat gambar bermanfaat juga bisa membuat konsep seni. Ini akan memakan lebih banyak waktu dari mereka, tetapi ini adalah bagian paling menyenangkan dari menjadi seorang seniman. Hampir setiap orang suatu hari akan seperti ini. Selain itu, tim seni biasanya cukup kreatif sehingga kebutuhan akan seniman konsep yang terpisah tidak muncul. Ini pasti cukup bagi Anda untuk memastikan penampilan yang layak.
Seniman berkembang dalam suasana kritik teknis
Ada banyak pencipta selebriti terkenal yang menganggap karya mereka "di atas" kritik apa pun. Adalah bijaksana bagi Anda untuk mengenali ini dan mengarahkannya ke pintu sesegera mungkin. Bahkan jika mereka baik, mereka akan melakukan lebih banyak kerugian daripada kebaikan. Ingatlah bahwa mencari artis adalah nikah / nikah yang artinya saling berjejaring. Termasuk dari sisi artis. Terlepas dari kenyataan bahwa dalam seni rupa, banyak hal yang bergantung pada pandangan dan opini subjektif, banyak hal yang dapat dinilai dengan menggunakan metrik kualitas objektif. Dibutuhkan keterampilan untuk menciptakan seni yang bagus, dan beberapa orang payah.
Bagaimana Seni Bisa Menjadi Baik
[kira-kira. Tautan ini ada di aslinya, saya biarkan apa adanya]
Bahkan seniman terbaik pun bisa membuat kesalahan teknis dalam karyanya. Misalnya anggota tubuh dari tempat yang tidak terduga; posisi aneh dan tidak wajar (karena pada kenyataannya mereka tidak mungkin atau melelahkan); perspektif dari mana Escherakan berputar di peti mati. Momen-momen ini tidak bergantung pada gaya visual atau "pemikiran mendalam" artisnya. Kerugian terjadi karena pelakunya mengacau. Gambar dengan kesalahan seperti ini terlihat bodoh bahkan bagi penulisnya begitu dia menyadari kesalahannya. Orang harus menyimpan opini mereka tentang gaya untuk diri mereka sendiri, tetapi kritik yang sehat terhadap kesalahan nyata akan menguntungkan semua orang. Suasana ini akan membuat karya seni Anda terlihat lebih baik. Ini akan memungkinkan artis Anda berkembang. Pencipta akan mendapat kesan bahwa mereka diperlakukan dengan adil. Hal ini mendorong dialog yang sehat tentang menciptakan karya seni untuk proyek Anda, dan jauh lebih baik daripada komentar "kerja bagus" yang tidak wajar dan tidak wajar saat mendiskusikan proposal baru.
Singkatnya, perlakukan pencipta (baik artis maupun komposer) sebagai mitra setara Anda dalam pengembangan game dan suatu hari Anda akan menemukan maniak seperti Anda. Agar berhasil menemukannya, Anda perlu memahami dari mana asalnya dan berupaya menyediakan lingkungan yang dapat diakses. Ingat, jika seseorang menawarkan permainan Anda beberapa tahun kerja, maka itu akan menjadi "miliknya" seperti halnya "milik Anda."
Tanya Jawab
Mengapa tidak membuat grafik dapat dialihkan? Maka dia tidak akan melihat gaya yang tidak dia sukai.
Teks asli
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:
Secara umum, saat mengembangkan Battle for Wesnoth, kami menganut prinsip "pilihan itu jahat". Setiap opsi dalam program adalah cabang kode tambahan yang perlu Anda pertahankan. Jumlah total cabang kode tumbuh sesuai dengan hukum kombinatorik. Akibatnya, kompleksitas pengujian dan "biaya tak terlihat" dari pengembangan meningkat.
Jadi Anda tidak benar-benar ingin mengambil banyak arahan seni dan memiliki bendera nonaktifkan untuk masing-masing opsi.
Pilihan itu jahat tidak hanya karena meningkatkan biaya pemeliharaan perangkat lunak. Pilihan tersebut akan mencegah Anda mencapai gaya seni yang konsisten dan konsisten dalam proyek Anda, karena pesan Anda kepada kontributor baru akan "berisik".
Pada akhirnya, jika game Anda hanya memiliki sebagian dari seni yang siap, maka keberadaannya akan menyampaikan gagasan "Saya butuh bantuan" untuk mendapatkan seni tambahan. Tetapi bagian penting dari meminta bantuan adalah merinci dengan tepat apa yang Anda butuhkan untuk menyesuaikan gaya bermain Anda secara keseluruhan.
Masalahnya, keberadaan saja sudah cukup. "Satu gambar bisa bermakna seribu kata." Jika Anda memiliki banyak contoh, Anda tidak perlu menghabiskan banyak waktu untuk menjelaskan visi Anda melalui teks. Tetapi jika contoh-contoh ini saling bertentangan, maka Anda akan menderita. Adanya dua gaya seni yang sangat berbeda akan menghalangi Anda untuk menjelaskan gaya mana yang Anda inginkan.
Biasanya, Anda tidak perlu mengganggu perkembangan gaya visual. Seni akan berbicara sendiri. Tetapi diberi pilihan, Anda tiba-tiba harus mengatur mikro dan membimbing semua orang sendiri.
Interpretasi lain. Mungkin Anda mengusulkan skenario ketika Anda memiliki peserta yang mampu mengambil alih semua karya seni, tetapi pada saat yang sama Anda, sebagai penulis, akan menyembunyikan seni ini dari diri Anda sendiri.
Saya mungkin terdengar tidak sopan, tapi ini gila.
Dan pada kenyataannya, ini hampir tidak mungkin - Anda akan menghabiskan banyak upaya untuk memastikan tampilan yang benar dari seni ini baik di awal maupun selama masa proyek.
Ini telah terjadi di benteng kurcaci dan di beberapa proyek lainnya. Pada akhirnya, "seniman luar" harus menginvestasikan banyak upaya pemrograman agar karya mereka dapat dilihat sama sekali.
Mod benteng kerdil bekerja dengan akses langsung ke RAM dari proses yang sedang berjalan. Tidak ada API langsung untuk modding atau semacamnya, tetapi bahkan jika ada, seseorang masih harus menulis kode agar lapisan tampilan grafik berfungsi. Kompleksitas tugas ini sebanding dengan mengembangkan game Anda sendiri.
... Maksud saya, Anda tidak perlu mencari game di mana pendekatan "memenangkan lotre" ini. Ini adalah contoh yang sangat berbahaya karena berhasil tidak melalui "praktek pengembangan yang baik" tetapi melalui keberuntungan yang luar biasa.
Melihat praktik pengembangan game populer dan sukses umumnya merupakan ide yang buruk. Bahkan ada istilah - "kesalahan orang yang selamat". Alih-alih mengatakan "wow, mereka mampu bertahan meskipun keputusan yang buruk" - orang mengatakan "mereka berhasil KARENA mereka membuat keputusan itu."
Misalnya, benteng kurcaci tidak menggunakan kontrol versi. Baik git maupun svn atau bahkan cvs. Mereka hanya menyalin folder ke dalam direktori.
Apa pun itu, saya pribadi merasa bahwa bekerja dengan artis yang gayanya tidak Anda sukai adalah rasa tidak hormat yang tidak wajar bagi diri Anda sendiri. Anda bisa berpura-pura, bersikap sopan dan menerima seni meski Anda tidak menyukainya, tapi akan lebih mudah bagi Anda untuk menolak dan jujur pada diri sendiri.
Ini sangat mirip dengan nikah / nikah.
NB Jika Anda menemukan kesalahan ketik atau kesalahan dalam teks, beri tahu saya. Ini dapat dilakukan dengan memilih bagian teks dan menekan "Ctrl / ⌘ + Enter", jika Anda memiliki Ctrl / ⌘, atau melalui pesan pribadi . Jika kedua opsi tidak tersedia, tulis tentang kesalahan di komentar. Terima kasih!