Apa itu Editor Unreal pertama

Retrospektif permainan klasik baru-baru ini menjadi populer, tetapi mereka jarang mengingat alat pengembangan klasik. Saya berhasil berbicara dengan Tim Sweeney tentang versi pertama Unreal Editor , atau UnrealEd .

BSP dan fallacy: "Kita perlu menulis editor kita sendiri"

David Lightbone: Terima kasih telah meluangkan waktu untuk berbicara dengan saya, Tim! Mari kita mulai dari hari-hari awal Unreal Editor. Saya membaca bahwa James Schmaltz, pencipta Epic Pinball , menunjukkan kepada Anda permainan yang dia kerjakan, dan ketika Anda melihatnya, saya menyarankan untuk membuat editor untuk itu. Apakah itu benar?

Tim Sweeney: Tepat! Ia terinspirasi oleh game Bullfrog Magic Carpet . James adalah pengembang yang sangat berbakat, tetapi ia hanya menulis kode dalam bahasa assembly, ia tidak ingin belajar C. [tertawa] Dengan demikian, ia menulis mesin 3D ini dalam assembler murni yang menjadikan latar belakang lega dan objek permainan. Dia tidak ingin membuat editor, jadi dia secara manual membuat pohon BSP dan meletakkan kapsul pada relief ini. Ketika saya melihat ini, saya berkata, "Tidak, tidak, tidak, James, James ... Anda harus melakukan sesuatu yang sama sekali berbeda." [tertawa]



James Schmalz dan Bullfrog Magic Carpet

Saya mengatakan bahwa saya akan menulis editor, jadi saya mulai membuat antarmuka pengguna Unreal Editor dari tata letak UI di Visual Basic, anehnya. Dia memiliki antarmuka perintah berbasis teks untuk berkomunikasi dengan mesin C ++ yang diberikan. Kemudian saya menulis editor wireframe, dan pengembangan berlanjut di atas fondasi ini.

Artinya, itu adalah proses belajar yang menarik. Saya pikir saya hanya akan menulis editor ini dan mengintegrasikannya ke renderer James. Suatu kali saya bertanya kepadanya, “Bisakah Anda mengirimi saya kode itu? Saya ingin memahami cara mengintegrasikan penyaji. " Dan dia mengirimi saya 30 ribu baris kode assembler. [tertawa] Di mesin rendering 3D, ada beberapa elemen Epic Pinball dan beberapa kode assembler sebelumnya, yang ia salin. Saya berpikir: “Ya Tuhan, kekacauan macam apa ini? Saya tidak ingin menyentuh ini! " [tertawa]

Tetapi saya berkata pada diri sendiri bahwa sebelum saya mulai mencari tahu, saya hanya akan menulis alat pemetaan tekstur kecil. Jadi saya membaca artikel Michael Abrash tentang pemetaan tekstur dan mempelajari kode yang dibagikan Billy Zelsnack. Bertekstur ternyata menjadi topik yang cukup sederhana, jadi saya memutuskan: "Saya akan mencoba untuk mengatasi semua ini."

Sebelum saya menerapkan pencahayaan dan sejenisnya, bagian penting dari keajaiban versi Unreal Editor sebelumnya adalah pembuatan pohon BSP real-time. Idenya adalah bahwa Anda dapat mengubah posisi kuas di ruang 3D, setelah semua pekerjaan menghasilkan BSP sepenuhnya diperbarui secara real time.


Peluang yang disediakan oleh fungsi ini tidak sesuai di kepala saya, dan hanya untuk menunjukkan semua kekuatannya, saya menciptakan alat ini untuk membuat tori. Saya menghubungi James, yang, saya ingat, membangun BSPsnya secara manual dan mengatakan kepadanya, "Coba lihat." Saya membuat dua tori yang terhubung dan menguranginya dari dunia. Dia berkata: “Wow, itu tidak mungkin! Ini luar biasa. ” Ini adalah contoh nyata ketegaran programmer.

JL: Berbicara tentang BSP, seperti yang saya pahami, John Carmack adalah salah satu yang pertama mulai menggunakan BSP di mesin permainan dan gagasan bekerja dengan BSP cukup baru di industri game pada saat itu.

TS: Carmack menulis editor yang sangat kuat di NeXT . Saya membaca semua informasi tentang dia dan melihat tangkapan layar, tetapi saya tidak pernah menggunakannya. Pada saat itu saya berpikir: "Wow, Carmack menulis editor BSP waktu nyata!" Apa yang saya tidak mengerti adalah bahwa pada kenyataannya itu tidak bekerja secara real time, ada proses pra-perakitan dan operasi lainnya. Saya tidak tahu ini dan berpikir bahwa dia telah membuat editor yang bekerja sepenuhnya secara real time, jadi dia juga menulis yang sama. [tertawa]



QuakeEd di NeXT dan John Carmack

JL: [tertawa] Anda pikir dia begitu kuat, jadi Anda menerima tantangan.

TS: Ya! Banyak fitur Unreal telah muncul karena kesalahpahaman saya tentang apa yang telah dilakukan orang lain.

Selain itu, sekelompok mantan pembuat demo Future Crew mendirikan perusahaan peralatan dan merilis beberapa screenshot dengan pencahayaan surround yang sangat realistis dalam adegan indoor. Ada sumber cahaya dengan bola besar di sekitarnya, dan pencahayaan volumetrik jelas terpotong oleh semua geometri yang mengelilinginya. Itu tampak akurat secara fisik. Saya berpikir: "Ya Tuhan, saya belum pernah melihat yang seperti ini, saya harus memikirkan ini!"

Jadi saya mulai mengerti dan menyadari bahwa saya perlu menghitung integral linear dari kamera ke setiap titik di layar. Di perguruan tinggi, saya belajar matanalisis, jadi saya berkata pada diri sendiri: "Saya harus berhasil." Jadi saya membuat rumus untuk ini dengan beberapa trigonometri yang sangat rumit. Saya menerapkannya dalam kode, tetapi seratus kali lebih lambat dari yang diperlukan. Kemudian saya menyadari: "Berhenti, saya bisa melakukan perhitungan ini di ruang peta cahaya," karena peta cahaya adalah diskritisasi geometri menjadi fragmen kecil. Saya mentransfer perhitungan ke peta penerangan dan mengimplementasikan semuanya dalam waktu nyata.



Contoh Pencahayaan dari Unreal Berdasarkan Lighting Maps

Saya mengambil tangkapan layar dan mengirimkannya ke seorang teman dari Finlandia, yang bekerja untuk perusahaan peralatan itu. Dia menjawab: “Wow, ini luar biasa! Tetapi gambar kami hanyalah render dari 3D Studio Max, karena kami tidak dapat memahami bagaimana melakukan ini secara real time. " [tertawa]

JL: [tertawa] Ya!

[Catatan penulis: perusahaan yang dibicarakan oleh Tim adalah Bit Boys ]

TS: Yaitu, Unreal Engine ternyata menjadi mesin pencahayaan volumetrik pertama di dunia, seperti yang saya pikir ... dan itu didasarkan pada kekeliruan saya.

Itu adalah waktu yang luar biasa dalam sejarah awal industri game karena 3D baru mulai dimungkinkan. Beberapa perender perangkat lunak telah ditulis, tetapi belum ada yang mampu memecahkan masalah skala besar: bagaimana membuat pencahayaan bekerja di dunia besar, bagaimana membuat geometri waktu nyata bekerja di dunia besar. Proses pengembangan ini bergerak sangat cepat: Carmack menerapkan ide-ide gila baru, saya menyadari ide-ide gila baru, dan kami terus-menerus merilis tangkapan layar dari apa yang mampu kami lakukan.

Jika Anda melihatnya sekarang, hanya dalam empat tahun, kami membuat ulang sekitar 20 tahun penelitian rendering tahun 1980-an dan 1990-an, yang sebelumnya hanya mungkin dilakukan melalui perhitungan awal, dan bukan secara waktu nyata.

JL: Ya, bagaimana gagasan BSP didasarkan pada sebuah artikel yang ditulis pada tahun 1969.

TS: Tepat, sebelum kelahiran saya!

TurboPascal dan Maya: Inspirasi yang tidak nyata

JL: Sumber inspirasi apa yang Anda gunakan untuk mengembangkan filosofi desain Unreal Editor?

TS: Hanya ada beberapa sumber inspirasi.

Jika Anda melihat game ZZT , dirilis pada tahun 1991, Anda akan melihat set dasar fungsi Mesin Nyata. Intinya, ini adalah mesin game dengan game yang dibangun di dalamnya. Gim ini memiliki bahasa skrip kecil, yang, meskipun sederhana, adalah bahasa skrip lengkap yang memungkinkan Anda menulis skrip gim kecil.

[Catatan penulis: Detail ZZT dapat ditemukan di buku Anna Anthropy yang diterbitkan oleh Boss Fight Books]

Gim ini memiliki editor real-time WYSIWYG interaktif untuk membuat level. Dengan menekan beberapa tombol, Anda bisa bergerak, menambah level, dan memeriksanya di game, lalu memprosesnya. Alur kerja yang interaktif seperti itu adalah fitur kunci dari game.



ZZT, mode game, dan mode editor

Inspirasi lain adalah Turbo Pascal , yang merupakan alat pengembangan pertama yang sangat saya sukai. Itu adalah editor yang sangat mudah digunakan untuk membuat kode dan kompilasi. Anda baru saja memasukkan kode, lalu setelah beberapa detik sudah dikompilasi dan Anda menjalankannya. Proses berulang membuat program luar biasa dibandingkan dengan apa yang saya gunakan pada waktu itu. Jika Anda melihat implementasi ZZT, itu benar-benar terlihat seperti versi teks dari Mesin Unreal. Seluruh model Unreal terinspirasi olehnya.

Ada sumber inspirasi serius lain yang mengarah pada penciptaan banyak elemen desain mesin: Visual Basic, mirip dengan klon Microsoft Delphi, yaitu, versi Object Pascal untuk Windows dengan pengeditan dalam antarmuka visual Borland. Tapi saya tidak pernah menggunakan Delphi, saya hanya bekerja di Visual Basic.

Idenya adalah bahwa pengguna memiliki editor formulir, ia menggambar elemen formulir, bidang dan semua yang ada di dalamnya, lalu mengkliknya dan membuka kode. Kode muncul segera dan pengguna hanya terus memasukkannya dan terus bekerja.



TurboPascal oleh Borland

Saya mentransfer prinsip-prinsip ini ke Unreal: Anda bisa menyeret objek ke level, klik dua kali untuk membuka editor skrip, lalu masukkan skrip dan simpan. Untuk mulai menulis kode, membuat objek tiga dimensi dan melakukan semuanya dalam waktu nyata, cukup dengan beberapa klik mouse saja sudah cukup.

Aspek penting lain dalam pengembangan Unreal adalah Epic membeli beberapa workstation Silicon Graphics yang meluncurkan versi pertama Maya. Maya benar-benar ketinggalan zaman pada saat itu, tetapi ada mode 3D interaktif dengan ruang latar belakang biru-merah-hitam di mana objek dan gambar rangka diambil secara real time. Ini tidak dapat dilakukan oleh program apa pun di PC; semuanya terjebak dalam kode lama dan pola UI lama.



Jadi, hal pertama yang saya lakukan ketika saya mulai bekerja pada Unreal Editor adalah membuat latar belakang hitam dengan garis-garis biru dan merah dengan menyalin Maya. Saya menulis prosedur untuk menggambar garis dan membuat kontur wireframe tiga dimensi dari semua objek. Itulah contoh yang mengilhami saya, yang membuktikan bahwa itu mungkin.

Dari Visual Basic ke Slate: Evolution of the UnrealEd Interface

[Catatan penulis: di awal wawancara, saya meluncurkan UnrealEd 1 di mesin virtual di laptop saya. Saya memberi Tim mouse agar dia bisa bekerja di dalamnya.]

TS: Wow, bagus, Anda sudah meluncurkannya!

JL: Ya! Saya mempresentasikan bahwa versi yang kita lihat di sini adalah Visual Basic.

TS: Ya, ya!

[Catatan penulis: Tim senang ketika dia menciptakan level dari awal. Dari luar, sepertinya pertemuan teman-teman yang sudah lama tidak terlihat.]

JL: Apa yang membuat Anda menggunakan Visual Basic untuk mengembangkan antarmuka untuk versi pertama UnrealEd, dan opsi apa lagi yang Anda miliki?



Alan Cooper dan Visual Basic

TS: Itu tahun 1995. Pada saat itu, kerangka kerja antarmuka pengguna untuk C ++ sangat buruk. Ada Microsoft Foundation Classes, yang merupakan API paling menyedihkan yang bisa Anda bayangkan. Pengguna mulai menggambar kontrol jendela dan kerangka kerja menciptakan sejumlah besar kode C ++ dengan banyak komentar seperti: "di sini kami membuat kontrol untuk Anda!" Jika pengguna memindahkan objek, kerangka memperbarui bagian dari kode, tetapi bukan bagian lain, dan itu terus-menerus rusak, jadi saya berkata pada diri sendiri: "Saya tidak akan menyentuh ini lagi."

Visual Basic adalah alat yang hebat untuk mengembangkan antarmuka pengguna di mana Anda dapat menempatkan semua kontrol, item menu, dan bagian UI secara efisien. Itu adalah toolkit paling produktif untuk UI yang pernah saya lihat, terutama karena itu adalah program yang sangat jelas dan saling berhubungan: Anda menggambar UI, mengkliknya dan menambahkan kode sederhana untuk interaksinya. Saya menyadari bahwa jauh lebih mudah untuk membuat UI dan kemudian meneruskannya ke C ++ melalui antarmuka baris perintah, mengirim teks bolak-balik, sebagai cara untuk membuat serialisasi data. Saya pikir situasinya tidak berubah selama sekitar belasan tahun, sampai pada awal 2000-an toolkit UI yang layak untuk C ++, seperti Qt dan sejenisnya, mulai muncul.

[Catatan penulis: Versi pertama Visual Basic dikembangkan oleh Alan Cooper , sering disebut sebagai " bapak Visual Basic ." Ia juga sosok penting di bidang kegunaan dan pengalaman pengguna]



UnrealEd 3, di mana elemen wxWidgets hadir

DL : Saya pikir seiring waktu, bagian dari editor mulai digantikan oleh bagian lain. Bagaimana evolusi ini terjadi?

TS: Setelah menyelesaikan Unreal Editor 1, saya menjadi tenang dan melakukan sejumlah penelitian generasi baru, yang umumnya tidak membuahkan hasil sampai Warren Marshall muncul, yang menggunakan wxWidgets untuk menulis ulang bagian dari kode Visual Basic di Unreal Editor di C ++. wxWidgets yang pada saat itu adalah toolkit terbaik. Ini menjadi dasar bagi kerangka UI di Unreal Editor 2.

Di tengah proses pengembangan Unreal Engine 2, kode Visual Basic benar-benar hilang dari mesin. Kami memiliki kerangka kerja C ++ yang lebih nyaman dan bersih. Jadi, kami mendapat UI yang hampir sama, tetapi tanpa kesulitan bahasa. Tetapi masalah sebenarnya adalah bahwa wxWidgets tidak berkembang dan toolkit UI lainnya keluar, jadi kami terus mengintegrasikannya untuk alat khusus. Oleh karena itu, pada saat siklus pengembangan Unreal Engine 4 dimulai, kami memiliki lima toolkit UI yang berbeda ...

JL: Ini sering terjadi ...

TS: ... termasuk potongan WPF gila yang ditulis dalam C # dan terintegrasi dalam Unreal Engine 4 yang tidak berfungsi pada Mac, misalnya. Karena itu, pada saat itu dalam kode kita ada kekacauan besar.

Pada saat yang sama, Nick Atamas menciptakan prototipe dari lapisan UI baru di C ++ dan seiring waktu kami memutuskan untuk menggunakannya. Jadi dia berubah menjadi Slate. Jadi kami menulis ulang 100 persen dari antarmuka pengguna Unreal Engine, menyingkirkan semua toolkit UI plug-in dan membuatnya kembali dengan gaya yang sama. Ini memungkinkan kami untuk meningkatkan skala editor dan mencapai apa yang kita miliki hari ini.


Cuplikan layar UnrealEd dengan Slate UI

Tapi kami masih belum bisa mencapai kenyamanan yang ada pada zaman Visual Basic. Bahkan kerangka antarmuka pengguna C # hanyalah tumpukan besar XML dan kegilaan lain yang tidak perlu. Tampaknya setiap generasi baru mengimplementasikan UI dengan cara yang semakin canggih dan semakin buruk.

Screenshot dan XCopy: Pentingnya Perizinan

DL: Perusahaan mana yang pertama kali menggunakan Unreal Editor?

TS: Pada tahap awal, dua tahun sebelum rilis, kami sudah memiliki dua pembeli lisensi: Unreal Engine menggunakan Microprose, dan kemudian Legend Entertainment menggunakannya untuk Wheel of Time-nya, dan kami memberi mereka dukungan.



Roda Hiburan Legend of Time

JL: Mereka juga membantu Anda, bukan? Kolaborasi adalah bagian dari hubungan ini.

TS: Ya, pembayaran lisensi mereka membuat Epic bertahan selama proses pengembangan Unreal.

Pada waktu itu, saya menganggap serius perizinan, karena memungkinkan kami membayar tagihan, yang membawa kami ke model perizinan mesin, yang sama sekali berbeda dari model ID. Pada saat itu, ada lelucon bahwa melisensi mesin dari Id seperti membeli XCopy seharga seperempat juta dolar: Anda membayar seperempat juta, dan mereka memasukkan perintah DOS XCopy untuk memberi Anda salinan sumber ... dan hanya itu. [tertawa]

JL: [tertawa] Baiklah, jadi apa yang menyebabkan penjualan lisensi Unreal Engine kepada Microprose dan Legend Entertainment bahkan sebelum Unreal 1 dirilis?

TS: Saya pikir itu terjadi karena kami masih pada tahap awal, sekitar 1995, merilis tangkapan layar yang luar biasa tidak hanya permainan kami, tetapi juga tangkapan layar editor kami. Ini membuat perusahaan menghubungi kami. Mereka memanggil kami dari Microprose dan berkata: "Kami ingin melisensikan mesin Anda!", Dan kami seperti: "Mesin? Mesin yang mana? Ah, mesin kami! Itu akan sangat merugikan Anda. ” [tertawa] Itulah percakapan yang sesungguhnya.



Salah satu tangkapan layar pertama dari Unreal Editor dan Unreal

Dinosaurus dan Kadal: Terminologi dan Ikonografi Tidak Nyata

DL: Berbicara tentang tangkapan layar: di sini adalah salah satunya yang dipublikasikan di Blue's News pada akhir 90-an. Ada sedikit perbedaan nyata dari versi yang berjalan di mesin virtual saya: misalnya, di sudut kiri atas terdapat tombol Play, Help dan Epic, yang tidak ada dalam versi final.

Bisakah Anda ceritakan sedikit tentang itu?


Cuplikan layar UnrealEd diterbitkan di Blues News pada tahun 1998

TS: Ini jelas Unreal Engine 1, sekitar tahun 1998, karena memiliki kode Steve Polge, yang pada saat itu mengoordinasi permainan multipemain.

Tombol "Epic" hanyalah tautan ke halaman web, yang terasa menjengkelkan bagi semua orang karena mereka terus-menerus mengklik dan merasa terganggu: "Ah, browser terbuka lagi!" [tertawa]

JL: [tertawa] Baiklah, bisakah Anda berbicara sedikit tentang ikonografi?

TS: Untuk semua elemen UI, saya menggambar ikon yang benar-benar mengerikan, dan kemudian mengirimnya ke Dan Cook, seorang seniman yang terlibat dalam grafis untuk penembak awal kami Tyrian .

Dia perlu menggambar ikon untuk elemen Gadai, jadi dia menciptakan bidak catur. Saya berkata, "Tidak, tidak, tidak," dan dia menjawab, "Kalau begitu, maka katakan padaku apa bidak itu." Saya mengatakan bahwa itu adalah sesuatu seperti monster, sesuatu yang sangat keren, jadi dia menggambar kepala makhluk yang tidak dapat dimengerti: mereka mengatakan bahwa itu adalah dinosaurus, kadal, atau sesuatu yang lain ... tetapi ikon-ikon ini tetap bersama kita selama sekitar sepuluh tahun.



Daniel Cook dan ikon yang ia ciptakan untuk UnrealEd. Ikon "Add Pion" ada di bagian bawah, ketiga di sebelah kanan.

DL: Kami sudah berbicara tentang kata "pion." Apakah kita membuat sendiri, atau kita melihatnya di suatu tempat?

TS: Saya pikir itu diusulkan oleh Steve Polge atau James Schmalz.

JL: Bagaimana dengan "aktor"?

TS: Carmack datang dengan terminologinya sendiri, dia menyebut benda "entitas", dan saya berpikir, "Tidak, kita perlu sesuatu yang unik."

JL: [tertawa]

TS: Kami memutuskan bahwa kami akan memiliki objek yang ditunjuk sebagai aktor, karena pada 1980-an, SmallTalk , yang saya sukai pada saat itu, mengusulkan prinsip-prinsip pemrograman berdasarkan model aktor . Model itu berorientasi objek dan tampak seperti awal yang baik bagi kami. Oleh karena itu, kami datang dengan ide pion dan penghasut, yang menentukan awal dari serangkaian peristiwa dan semua terminologi lainnya.

Schmalcism dan Brain Voodoo Virus: Membuat UnrealScript

JL: Ceritakan lebih banyak tentang bagaimana James dan Steve berkontribusi dalam menggunakan dan menciptakan UnrealScript.

TS: James Schmalz adalah berlian yang unik, tukang. Dia adalah artis terbaik tim, seorang desainer tingkat hebat, dan dia juga bisa memprogram dalam UnrealScript dan assembler.

DL: Dalam kredit Unreal, namanya muncul dalam sepasang kategori yang sangat berbeda.

TS: Di seluruh industri game ada sangat sedikit orang dari tingkat bakat ini dan dia layak mendapatkan semua kesuksesan yang diraih.

Tapi dia beralih dari assembler ke UnrealScript dan menulis kode UnrealScript yang gila, di mana dia hanya memalu baris sementara mereka terus bekerja, dan di malam hari aku mendekatinya dan menyederhanakan kodenya. Dia memiliki ekspresi multi-baris seperti "sesuatu penghasut dot blah blah dot", dan saya menggantinya dengan sesuatu seperti ... "diri". [tertawa]

JL: [tertawa]

TS: Kami menyebut kode ini "Schmalcism." Dan Polge memiliki angka ajaib seperti "kecepatan berjalan = kecepatan lari x 3.072" dalam kodenya. Saya bertanya kepadanya: "Apakah benar-benar ada 3,072 konstan dalam fisika yang saya tidak tahu?" [tertawa]



TS: UnrealScript terinspirasi oleh Java; pada saat itu, bahasa ini tampaknya merupakan penerus C ++. Pembuat bahasa menyalin banyak solusi konstruktif, dan di atas menambahkan banyak konsep baru. Dalam UnrealScript, dasar-dasar wadah dasar ada yang hanya beberapa generasi kemudian muncul di Jawa.

Saya selalu berpikir bahwa ketika mengembangkan bahasa C #, penulis mengikuti UnrealScript karena saya melihat beberapa fitur UnrealScript yang muncul di C #. Saya selalu berharap mereka meminjam sebagian dari ide-ide ini.

Tetapi semakin saya membenamkan diri dalam pemrograman berorientasi objek dan dalam SmallTalk, mempelajari penelitian paling canggih tentang metaclasses, semakin saya menyadari bahwa itu adalah sejenis virus voodoo otak yang tidak memiliki dasar teori nyata. Pada gilirannya, jika kita melihat korespondensi Haskell dan Curry-Howard , serta prinsip-prinsip pemrograman modern lainnya, kita akan melihat sumber dan struktur untuk inspirasi.

SoftDisk, Id, dan jutaan dolar dalam bentuk cek

JL: Apakah Jay Wilbur dan Mark Rein, dengan orientasi bisnis dan pengalaman mereka dengan shareware, memengaruhi mesin, peralatan, editor, atau sumber daya yang mereka miliki?

TS: Pada tahap awal, Epic bekerja karena fakta bahwa saya terlibat dalam sisi teknis, dan Mark - dalam bisnis. Mark terbang ke seluruh dunia, membuat transaksi bisnis gila yang membawa kami uang tunai. Itu sangat penting, jika bukan karena dia, kita tidak akan selamat pada tahap awal ini.



Mark Rain dan Jay Wilbur

Pada titik tertentu kami kandas dan semua pengeluaran kami dibiayai dari kartu Mark's American Express, yang akhirnya dibatalkan.

JL: [tertawa]

TS: Lalu dia terbang ke pertemuan dengan TG Interactive dan kembali dari sana dengan cek seharga satu juta dolar. Itu menyelamatkan kita. Dan begitulah diulang beberapa kali dalam sejarah kita. Sangat penting untuk memiliki pengusaha yang hebat yang dapat bernegosiasi. Dia adalah presiden pertama Id, dan setelah Mark Jay menjadi CEO pertama Id.

DL: Sebelum itu, dia dan Carmack ada di SoftDisk, kan?

TS:Benar! Dan ini lucu, karena sebenarnya saya menjual game ZZT pertama saya ke SoftDisk. Adalah Jay Wilbur yang menangani kontrak saya dengan SoftDisk. Sebagai hasil dari negosiasi ini, saya menerima tiga ribu dolar dari SoftDisk, jadi saya mengenal Jay untuk waktu yang sangat lama.


Hari-hari awal Perangkat Lunak Id. Jay Wilbur di sebelah kanan.

Bekerja dengan orang-orang dari Id menginspirasi saya dari awal. Saya pergi ke konferensi shareware bodoh dan Id muncul di sana. Mereka adalah favorit industri pada saat itu karena mereka merilis Wolfenstein 3D, yang merupakan kesuksesan terbesar dalam sejarah shareware. Mereka mengobrol dengan kami, dan kemudian diundang untuk makan malam. Sungguh luar biasa melihat bahwa para bintang industri hanya orang-orang yang sederhana. John Romero adalah pengembang game paling lucu di dunia.

[Catatan penulis: Saya setuju. John Romero banyak menghabiskan waktunya untuk wawancara TEd kami.]

WYSIWYG dan kemudahan penggunaan: paling penting - perspektif alat

DL: Jadi, pada November 1998, rilis PC Maksimum muncul, di mana ada wawancara dengan Anda, di mana Anda juga berbicara tentang berbagai teknologi yang ada pada saat itu. Artikel ini mengatakan bahwa "[Unreal Editor] lebih unggul daripada semua orang dalam hal kesederhanaan" dan "sulit untuk bekerja dengan teknologi Quake."

Ia juga mengatakan, “Teknologi [Quake III: Arena] benar-benar mengesankan” dan “Prey dan Trespasser terlihat dan bekerja lebih baik daripada Unreal. Tetapi jika ternyata lebih sulit untuk bekerja dengan mereka, maka pengembang akan tetap bersama Unreal. "

Artinya, apakah Anda memiliki tujuan sejak awal untuk menciptakan alat yang keunggulan kompetitifnya adalah kemudahan penggunaan?



PC Maksimum, November 1998

TS: Ya, itu benar. Anda tahu, ini selalu menjadi hal yang paling penting bagi saya: menulis editor yang memungkinkan desainer level untuk membuat kreasi yang luar biasa. Dari awal sudah jelas bahwa aspek yang paling penting dari ini adalah pekerjaan real-time dan iterasi desain ultra cepat, implementasi penuh dari prinsip "apa yang Anda lihat, Anda dapatkan" ("apa yang Anda lihat adalah apa yang Anda dapatkan", WYSIWYG) . Maka Anda hanya akan dibatasi oleh imajinasi dan kemampuan Anda untuk menghasilkan ide-ide baru. Bagi kami, Epic selalu memiliki alat yang sangat penting.

JL: Proses apa yang digunakan Epic untuk memberikan banyak perhatian, menginvestasikan waktu dan tenaga dalam menyederhanakan penggunaan alat?

TS:Proses pengembangan dalam Epic adalah kombinasi dari tim pengembangan mesin, menciptakan sistem, fungsi dan alat, dan tim game, menghabiskan semua ini untuk membuat game. Kami menggunakan proses berulang ketika tim pengembangan mesin membuat ide-ide baru, dan kemudian membagikannya dengan tim game dan mendapatkan umpan balik yang konstan tentang apa yang berhasil dan yang tidak. Beginilah proses teknis kami dibuat: fakta bahwa pengembang alat seharusnya membantu pengembang game membuat mereka jujur.

Kami tidak hanya ingin membuat alat yang mudah digunakan, tetapi juga memastikan bahwa mereka memberikan kompromi yang benar yang benar-benar memungkinkan Anda untuk membuat konten yang dibutuhkan untuk merilis game.

Ini adalah sisi lain dari kemudahan penggunaan. Tidak mungkin untuk mempertimbangkan kemudahan penggunaan sebagai konsep terpisah. Ini buruk ketika alatnya sangat mudah digunakan, ketika Anda mulai membuat game, tetapi sangat sulit bagi mereka untuk menyelesaikan pembuatan game, karena mereka membatasi alur kerja atau fungsionalitas.


Jika Anda melihat lima atau enam tahun terakhir pengembangan mesin, maka persaingan antara Epic dan Unity ditentukan oleh kemudahan penggunaan awal, di mana Unity memiliki keunggulan. Pada saat yang sama, dalam siklus pengembangan perilisan game, dalam hal kinerja pada platform yang berbeda, Unreal memiliki keunggulan. Ini karena kami fokus untuk dapat merilis game skala epik, yaitu yang kami lakukan. Sebenarnya, ini jauh lebih rumit daripada menyederhanakan pekerjaan tiga orang dengan cepat melepaskan sesuatu yang sederhana.

Saat ini, ukuran kode Unreal Engine sekitar 20 lebih besar dari kode Unreal Engine 1. Alat menjadi sepuluh kali lebih rumit, dan ada alasannya. Orang-orang meluncurkan Unreal dan tersesat karena ada begitu banyak pilihan menu. Kemudian mereka beralih ke Unity dan melihat bahwa semuanya lucu dan sederhana. Dan kemudian mereka mencapai tahap ketika Anda perlu merilis produk, dan ternyata Anda perlu membeli lisensi untuk kode sumber untuk menambahkan fitur yang tidak ada di menu ke mesin. Ada dikotomi seperti itu.

Sumber Inspirasi dan Warisan: Dampak UnrealEd

JL: UnrealEd menginspirasi beberapa pengembang game, termasuk saya, untuk tidak hanya mulai membuat game, tetapi juga untuk menulis alat mereka sendiri. Menurut Anda apa dampak UnrealEd pada industri?

TS: Saya pikir setiap editor game yang ada telah meminjam sesuatu dari UnrealEd. Ini adalah salah satu editor pertama, kami membuat banyak keputusan mendasar yang benar, misalnya, bagaimana pengguna harus bekerja dengan kisi-kisi 2D, menempatkan objek dan bergerak di seluruh dunia. Saya pikir Anda dapat melacak warisan yang diteruskan dari editor Doom pertama ke editor Quake, dan kemudian ke Unreal. Hari ini, semuanya sampai batas tertentu berdasarkan ini.


Diagram riwayat mesin FPS dari Wikipedia. Klik untuk membuka versi yang lebih besar.

Beberapa aspek dipengaruhi oleh prinsip-prinsip umum, misalnya, Maya, tetapi beberapa secara khusus terkait dengan Unreal - cara menyusun hierarki kelas, menerapkan sistem undo dan semua masalah serius lainnya dalam pengembangan game. Setiap orang yang memasuki industri pada awal tahun 2000-an biasanya melalui Unreal atau Quake. Meskipun Quake adalah permainan yang jauh lebih besar, menurut saya sebagian besar desainer datang melalui UnrealEd karena alat-alatnya sangat nyaman.

Penggandaan dan Divisi Produktivitas: Kiat untuk Pengembang Game

JL: Pada 2011, Anda memberi Kotaku wawancara. Saya akan membaca beberapa kutipan yang, menurut saya, berhubungan dengan topik kita:

“Kami selalu mendekati pengembangan game dalam hal alat. Kami menciptakan alat yang kami butuhkan, menciptakan seperangkat alat yang ramah pengguna, dan terus bekerja dengannya. ”

"Kami di Epic berpikir jauh ke depan. Kami seperti Intel. Kami berpikir tentang apa yang akan kami lakukan dalam lima hingga sepuluh tahun dan memilih arahan yang sesuai untuk pengembangan, sementara bagi sebagian besar perusahaan batas perencanaan adalah pelepasan game berikutnya. Mereka memasukkan semua sumber daya mereka ke dalamnya, dan kemudian melakukan pertandingan berikutnya. ”

"Perusahaan game besar seperti EA atau Activision tidak berinvestasi dalam alat, mereka tidak memiliki perencanaan jangka panjang seperti yang kita lakukan, dan kesadaran kita bahwa kita perlu membuat proses pengembangan game seefisien mungkin."



Dalam wawancara saya dengan John Romero, dia memahami dengan sangat baik, mengatakan: "Alat hidup lebih lama dari game."

Apa saran yang bisa Anda berikan kepada pengembang game agar mereka dapat menghindari kesalahan ini dan memahami nilai investasi jangka panjang dalam alat?

TS: Ya ... Anda tidak harus "sepertinya" membuat mesin. Baik membangun mesin, atau tidak melakukannya. Sekarang begitu banyak perusahaan melumpuhkan proses produksinya, menciptakan mesin dengan alat yang tidak berguna. Ini adalah alat yang membunuh orang.

Lihat semua mesin yang dibuat secara internal oleh perusahaan ... Misalnya, Frostbite memiliki fungsi rendering yang lebih canggih daripada kami, dan dalam banyak kasus ini menarik piksel yang lebih indah daripada kami, tetapi pengembang Unreal dapat membuat konten lebih produktif, kira-kira 30-50 persen lebih produktif. Artinya, sebuah tim dapat membuat game dengan kualitas yang sama dengan setengah kekuatan Itu bisa melakukan lebih banyak iterasi dan mengasah game lebih baik daripada dengan alat yang kurang berkualitas. Oleh karena itu, semua orang perlu membuat keputusan yang tepat - baik berinvestasi sepenuhnya dalam menciptakan alat yang sangat baik untuk penggunaan internal, atau menggunakan mesin pihak ketiga.

DL: Karena Anda pikir pengembang menderita setengah tindakan?

TS: Ya. Di suatu tempat di dalam perusahaan-perusahaan ini adalah akuntan yang sangat bodoh, berpikir seperti ini: "Oh, dengan membatasi pengeluaran untuk pengembangan alat, kita dapat menghemat dua persen dari anggaran." Akibatnya, ini mengarah pada peningkatan 50 persen dalam anggaran, karena lebih banyak waktu dan tenaga harus diinvestasikan untuk menciptakan permainan. Oleh karena itu, ini menciptakan penghematan biaya yang gila, tidak membenarkan.

Saya pikir setiap perusahaan harus membuat keputusan - berinvestasi lebih banyak pada alat, atau tidak melakukannya sama sekali.


Dan itu berlaku untuk semuanya. Tidak hanya untuk editor 3D untuk membuat level, tetapi juga untuk sistem perakitan, ke bahasa pemrograman, teknologi pengembangan, alat DCC, untuk semua ini.

Alat harus meningkatkan produktivitas, dan jika ternyata mereka menguranginya, maka Anda harus menyingkirkannya.

JL: Bagus. Terima kasih telah meluangkan waktu untuk mengobrol dengan saya.