Halo semuanya! Saya seorang desainer UI / UX yang berspesialisasi dalam antarmuka game. Saya juga seorang humanis: segala sesuatu yang berkaitan dengan kode menimbulkan rasa takut dan ketidakpercayaan bawaan, yang tidak dapat saya atasi. Takut pada “sihir hitam” proger adalah hal yang normal bagi seorang desainer. Tetapi ada masalah yang sangat menyulitkan kehidupan.
Faktanya adalah bahwa dalam pekerjaan kami, kami, desainer antarmuka, seringkali harus mendekati situs internal dan aplikasi dan bahkan sedikit membahasnya. Kebutuhan ini sangat relevan pada tahap prototyping awal dan cepat, ketika Anda ingin mengumpulkan sesuatu di lutut Anda yang dapat memberikan gambaran tentang produk akhir, akan memiliki fungsi minimum yang diperlukan dan juga terlihat layak. Namun, sebagian besar desainer (termasuk saya) bahkan tidak memiliki pengetahuan minimum untuk membuat dan mengedit sendiri, bagian antarmuka prototipe, melalui kode. Dan ini juga normal untuk industri.
Mengetahui fitur kemanusiaan dari kita, programmer yang penuh kasih (bersama dengan orang-orang baik lainnya) menciptakan sejumlah alat yang cukup untuk membuat desain dan mengujinya pada perangkat nyata tanpa menulis satu baris kode pun. Alat-alat ini mudah di-google-kan dengan permintaan jenis "program prototyping antarmuka". Ini adalah Sketsa, Adobe XD, Figma, Prinsip, InVision, Marvel, dll. Mereka luar biasa. Mereka menyelamatkan jutaan sel perancang saraf (dan mungkin beberapa nyawa). Ratusan artikel telah ditulis tentang mereka, mereka pantas dipuji oleh desainer UI / UX di seluruh dunia.
Namun, alat ini terutama dirancang untuk pengembang aplikasi web dan seluler. Untuk game dev (dan kami di sini khusus tentang game dev) mereka tidak cocok.
"Tunggu sebentar, apa bedanya?" Anda bertanya. Game juga aplikasi, kan? Tidak juga. Khusus game membuat koreksi signifikan terhadap proses produksi.
Mari kita perbaiki.
Pertama, "biasa", aplikasi non-game paling sering dibangun berdasarkan prinsip solusi langsung untuk masalah pengguna. Misalnya, saya ingin menyelesaikan masalah tertentu - mentransfer uang ke kartu Serege - dan untuk ini saya membuka aplikasi perbankan. Seberapa cepat saya bisa menyelesaikan pertanyaan saya menentukan tingkat kepuasan saya dari interaksi ini. Setelah transfer, saya menutup aplikasi dan melupakannya sebentar. Saya puas, bank puas, Seryoga puas. Ini adalah jalur linier yang dapat dipahami dari titik A ke titik B.
Bank, seperti saya, tertarik untuk menutup tugas pengguna secepat mungkin. Dia tidak secara khusus membuat mereka. Secara skematis, tampilannya seperti ini:
Di sektor hiburan (di mana pendapatan utama berasal dari iklan), semakin banyak waktu yang dihabiskan pengguna dalam suatu layanan, semakin banyak keuntungan yang dihasilkan. Karenanya, YouTube sendiri, tanpa diminta, meluncurkan video berikutnya dan mencuri algoritma yang memilih video ini untuk minat Anda. Dalam game seluler, hal yang sama. Keinginan untuk bersenang-senang dan mendapatkan dosis dopamin dalam arti tertentu adalah tugas yang ditentukan pengguna. Tetapi dia tidak memiliki solusi final yang pasti, yang digunakan oleh para pembuat konten. Kami ingin Anda tidak terlepas dari permainan kami. Umumnya.
Oleh karena itu, permainan menggunakan siklus yang melempar tugas baru kepada pemain dan mentransfernya dari satu aktivitas ke aktivitas lainnya dengan terampil. Itu terlihat seperti ini:
Struktur seperti itu sudah jauh lebih sulit untuk dibuat prototipe. Sebut fitur permainan
penyergapan No. 1 ini . Ada yang lain.
Ambush No. 2 Permainan ini terutama merupakan gameplay. Antarmuka hanyalah penjilidan, bingkai untuk berlian (meskipun dalam beberapa game antarmuka = gameplay, tapi jangan bicara tentang hal-hal yang menyedihkan). Tanpa permata ini di tengah, seringkali sulit untuk menilai seberapa baik atau buruk antarmuka Anda (dan sekarang saya tidak berbicara tentang tampilan). Masalahnya adalah bahwa gameplay tidak dapat diintegrasikan ke dalam alat untuk prototyping, mereka ada di berbagai program, di dunia yang berbeda. Dan jika tidak ada gameplay, maka tidak ada game itu sendiri. Tidak diperlukan konteks.
Ambush No. 3 Dalam game ada elemen dan / atau animasi yang sangat tidak standar. Palet elemen jauh lebih luas daripada yang dapat ditemukan di situs web atau aplikasi kantor. Tidak semua program prototipe dapat membuatnya kembali sama sekali.
Ambush No. 4 Game dibuat di mesin game. Alat prototipe disinkronkan dengan mereka tentang ... tidak ada. Mereka sama sekali tidak dirancang untuk ini. Segala sesuatu yang telah dilakukan dalam * nama program untuk prototyping *, Anda (atau kolega Anda yang malang) akan menciptakan kembali di mesin. Dari awal. Dan itu bukan fakta bahwa pada saat yang sama akan dimungkinkan untuk mengulang semuanya setidaknya mendekati bagaimana itu dalam prototipe: kemampuan program berbeda. Itulah sebabnya mengapa pemain besar seperti Game Insight (
video ) atau Pixonic (
artikel ) meneliti alat-alat internal yang entah bagaimana menyinkronkan photoshop, memotong sprite, merakitnya di mesin, manajemen gaya, dll.
Ya, omong-omong. Catatan marjinal. Saya hanya bekerja dengan game yang dibuat di Flash atau Unity. Flash sudah mati, jadi itu terutama tentang Unity. Saya berasumsi bahwa semua plus atau minus itu benar dalam kaitannya dengan mesin game populer lainnya, tetapi ini tidak akurat.Apa yang menyebabkan duplikasi pekerjaan seperti itu? Jelas, fakta bahwa upaya untuk mengembangkan dan mendukung prototipe antarmuka
yang kurang lebih
kompleks semakin meroket. Biarlah itu menjadi jam tangan desainer manusia yang relatif murah (maaf kawan), tapi toh.
Saya tidak ingin mengatakan bahwa prototipe antarmuka game dengan alat standar adalah bodoh. Tentu saja tidak: pekerjaan persiapan apa pun dalam pembuatan antarmuka lebih baik daripada ketidakhadirannya. Hanya saja cara yang akrab bagi kita, desainer, memiliki keterbatasan dan masalah yang bisa dihindari. Lebih lanjut tentang ini nanti.
Ada orang seperti itu,
Om Tandon . Dia telah menerbitkan banyak artikel tentang game UI / UX, dan secara umum tampaknya agak meremehkan masalah ini. Setidaknya, ia menulis dengan sangat percaya diri (ngomong-ngomong, dari sanalah saya mengambil gambar dan beberapa ide untuk artikel ini). Saya menyarankan mereka yang tertarik untuk membaca siklus artikelnya di LinkedIn (jangan lupa tentang VPN): bagian
pertama ,
kedua dan
ketiga . Anda juga dapat menonton
videonya dari sebuah konferensi di London. Lebih baik untuk berhenti dan melakukannya sekarang sebelum Anda melanjutkan membaca artikel ini, karena Saya akan mengandalkan tempat pada bahannya.
Terlepas dari kenyataan bahwa secara umum, ide Ohm - untuk membuat prototipe sedekat mungkin dengan produk akhir secepat dan semurah mungkin, saya suka, khususnya saya tidak bisa setuju dengannya. Sebagai contoh, ia mengklaim bahwa untuk mencapai hasil yang sama dalam prototipe gameplay (Ohm menyebutnya prototipe dev), dibandingkan dengan yang "desainer", dibutuhkan beberapa kali lebih banyak waktu dan usaha. Angka-angka konkret diberikan: dibutuhkan
5-7 hari untuk membuat prototipe
ini menggunakan Prinsip (salah satu alat prototyping yang populer), dan akan membutuhkan waktu
20-30 hari bagi tim untuk mengimplementasikan fungsi yang sama di dalam mesin, menurut Ohm. Dan ini bukan tentang "melakukan segalanya sesuai dengan keindahan", tetapi tentang hanya mendapatkan hasil yang identik pada output. Menurut pendapat saya, angka itu sangat dibesar-besarkan.
Kedua, contoh prototipe yang dikutip Om sebagian besar masih linier. Ini bisa berupa tutorial dengan urutan satu-satunya tindakan nyata, atau rangkaian layar yang dapat digunakan untuk bepergian ke arah "di sana" dan "di sini", atau meniru interaksi mikro setempat. Ya, mereka terlihat lezat, tetapi saya tidak melihat siklus permainan atau logika yang rumit di sana.
Ketiga, dalam prototipe Ohm yang dibuat dalam Principle, karena alasan yang telah dijelaskan, tidak ada dan tidak mungkin gameplay itu sendiri. Bahkan tidak ada 3D! Mereka hanya tentang UI datar / UX, terpisah dari game itu sendiri. Menurut pendapat saya, ini mengurangi nilainya. Meskipun Om mengklaim bahwa solusi seperti itu cocok untuk meniru sekitar 80% genre game secara meyakinkan.
Keempat, Om salah satu alasan utama untuk mengembangkan prototipe antarmuka adalah penggunaan selanjutnya dalam penelitian kegunaan. Ini bagus dan benar, tetapi seberapa sering Anda menemukan studi kegunaan kompeten (oh, setidaknya beberapa) di game domestik dev? Apakah prototipe seperti itu diperlukan untuk tim dan studio kecil yang tidak melakukan studi yang sama? Jika prototipe
gameplay adalah bagian yang jelas dan tak terpisahkan dari pengembangan game
apa pun (asalkan Anda tidak membuat kertas kalkir dari proyek lain), maka apakah ada gunanya repot dengan prototipe
"perancang" - ini adalah pertanyaan terbuka.
Dalam pengalaman saya,
peta layar non-interaktif yang paling sederhana dalam bentuk satu gambar yang kuat memecahkan sebagian besar masalah pada interaksi dan koneksi antar layar. Gambar ini dikumpulkan dalam setengah jam dan tidak ada yang diperlukan selain mockup yang diambil dalam Photoshop (ilustrator). Ini paling sering mungkin untuk dihentikan.
Dalam kasus apa masuk akal untuk beralih ke prototipe yang interaktif dan sangat detail (Ohm menyebutnya
high-fidelity )? Nuuu ... Misalnya, jika pelanggan Anda membutuhkan bahan paling visual, dan bukan skema BW, untuk menerima pekerjaan. Itu terjadi.
Atau jika Anda perlu membuat demo bangunan yang indah yang dapat Anda tunjukkan kepada investor dan mengemudi di telepon.
Atau jika gameplay proyek atau bagian individualnya sangat baru sehingga umumnya tidak jelas bagaimana membangun interaksi dengannya, dan siklus konstan pengujian hipotesis diperlukan.
Atau jika Anda ingin mempercepat proses coba-coba di antarmuka, bongkar programer di sepanjang jalan.
Atau jika Anda membutuhkan produk simulasi untuk pengujian kegunaan.
Singkatnya, saya tidak akan merekomendasikan membuat prototipe terperinci dari sebuah game dengan antarmuka secara default, tetapi ada kasus ketika itu benar-benar diperlukan. Putuskan saja mengapa Anda menghabiskan sumber daya Anda untuk hal ini dan jenis knalpot yang Anda rencanakan untuk terima.
Jadi sekali lagi, sebentar. Saya melihat
tiga cara utama untuk membuat prototipe antarmuka game:
1) Terbatas pada peta layar. Jangan repot-repot dengan prototipe interaktif jika Anda tidak mengerti apa dan bagaimana Anda ingin mengujinya.
2) Buat prototipe interaktif primitif (gambar slide dengan transisi) dalam program yang akan berubah lebih cepat. Ini adalah varian untuk mereka yang mengerti apa dan bagaimana mereka ingin memeriksa, dan siapa yang tidak perlu terlalu rinci atau untuk menghubungkan antarmuka dengan gameplay (misalnya, Anda hanya tertarik pada bagian meta permainan). Itu bisa ditonton di perangkat.
Tetapi jika secara objektif Anda membutuhkan sesuatu yang lebih dekat dengan produk nyata, maka ini adalah pilihan ketiga, dan mari kita membahasnya lebih terinci. Untuk melakukan ini,
prototipe antarmuka langsung di Unity , teman-perancang yang baik. Itu lebih mudah dari yang Anda pikirkan.
Faktanya adalah bahwa Unity adalah keseluruhan ekosistem, gabungan yang sangat besar. Sebagian menakutkan, kadang-kadang mengerikan dan tidak nyaman, tetapi pasti dengan plusnya. Misalnya, tidak peduli fitur tambahan apa yang ingin Anda kencangkan ke engine, kemungkinan besar sudah tersedia untuk diunduh di
Asset Store . Terkadang kualitasnya pun lumayan. Alat desain tidak terkecuali.
Sebagai contoh, saya pribadi sangat suka
DoozyUI , yang memungkinkan Anda membuat layar terpisah tanpa banyak kesulitan, menambahkan tautan dan transisi di antara mereka, dan mempercepat animasi antar muka. Karena mereka tidak membayar ekstra untuk iklan, saya akan mengatakan apa adanya: ini jauh dari satu-satunya alat yang tersedia di pasar. Dan bahkan mungkin bukan yang terbaik. Dia menyuap saya dengan sejumlah besar tutorial, sejarah yang kaya dan sistemnya sendiri untuk menampilkan koneksi antar layar. Lihat saja keindahan ini!
Namun, ada solusi hebat lainnya untuk membuat sistem layar yang kompleks di Unity tanpa pengetahuan kode yang mendalam. Yang perlu Anda lakukan adalah menginvestasikan sedikit waktu Anda dalam pencarian mereka dan menggali lebih dalam ke dalam Asset Store.
Pada prinsipnya, Anda dapat melakukannya tanpa ekstensi sama sekali, dan menggunakan apa yang ditawarkan Unity di luar kotak. Hanya untuk jiwa kemanusiaan, itu akan jauh lebih menyakitkan. Anda perlu memahami bahwa dalam situasi apa pun di awal, orang baru Unity harus menonton NN jam pelatihan (atau terus-menerus menarik programmer, seperti dalam kasus saya). Meski begitu, mesinnya tidak dirancang untuk para desainer, melainkan sebuah lingkungan yang awalnya memusuhi saudara kita. Oleh karena itu, banyak desainer game UI / UX bahkan tidak menganggap fitur Unity sebagai alat untuk pekerjaan mereka. Tetapi Anda bukan salah satu dari mereka, bukan?
Sekali lagi, apa untungnya membuat prototip antarmuka untuk game segera di Unity:
Mereka mudah diintegrasikan ke dalam prototipe "gameplay" dan mendapatkan gambar yang lebih holistik dan mengesankan dari produk masa depan.
Bagian dari prototipe yang dibuat di Unity dapat langsung digunakan kembali dalam proyek "selesai". Ini tidak akan berfungsi sepenuhnya - programmer kemungkinan besar akan menawarkan untuk menempel ekstensi desain Anda untuk Unity di suatu tempat yang lebih dalam, tetapi di bagian dan layar terpisah itu sangat mungkin.
Prototipe seperti itu akan bekerja pada perangkat persis seperti yang Anda inginkan. Akan diregangkan dan diskalakan dengan benar. Akan mempertimbangkan poni dan area aman. Tidak ada perbedaan dengan hasil akhir, cantik!
Prototipe seperti itu dengan mudah dan cepat mengedit "on the fly." Tidak perlu mengulangi pekerjaan yang sama terlebih dahulu di Prinsip, kemudian di Unity. Anda bahkan dapat melakukan sesuatu tanpa melalui photoshop.
Owning Unity memberi perancang akses ke antarmuka tiga dimensi dan mengendalikan antarmuka dari bagian dalam mesin.
Selain bonus langsung, ada yang menyertainya: mengenal mesin sangat memudahkan kehidupan secara umum, dan juga meningkatkan nilai Anda sebagai spesialis di pasar tenaga kerja.
Secara umum, saya ingin mengatakan semua ini.
Kolega, jangan takut untuk bereksperimen! Perhatikan mesin yang Anda gunakan dan kemampuannya. Lakukan lebih banyak, susah, tertarik. Itu terbayar.
Dan untuk ini, tidak perlu menjadi seorang teknisi.