Ide utama

Banyak buku, artikel, dan tutorial telah ditulis tentang aplikasi pembandingan, mesin, dan berbagai sistem perangkat lunak.

Inilah yang diberikan Wikipedia lama kepada kami tentang hal ini:

Uji kinerja, tolok ukur (tolok ukur bahasa Inggris) - tugas kontrol yang diperlukan untuk menentukan karakteristik kinerja komparatif dari sistem komputer.

Tetapi bagaimana jika kita sampai pada masalah pembandingan mesin game sedikit dari sisi lain? Semua mesin game dan SDK untuk pengembangan game (dan tidak hanya) sering mengiklankan diri mereka sebagai alat yang sangat intuitif dan mudah dicerna. Kami menjual kesederhanaan untuk dipelajari, kurva pembelajaran dan entri yang luar biasa, contoh-contoh ringan dan indah ditampilkan, di mana satu layar kode, ketika diluncurkan, menciptakan semacam keajaiban yang luar biasa. Jadi, dalam persiapan untuk acara Ludum Dare yang akan datang, saya sekali lagi memutuskan untuk melihat-lihat dan melihat apa yang "pasar" tawarkan kepada Emele sederhana - seseorang yang telah berada di game dev selama seminggu tanpa satu tahun. Yaitu, salah satu kelompok orang-orang dari CA yang menjual kualitas-kualitas luar biasa dari kecernaan mesin yang mudah.

Bagaimana jika kita ... mencoba mengukur diri kita sendiri ketika bekerja dengan berbagai mesin untuk menulis game? Ya, ya, artinya produktivitas mereka. Secara harfiah, ambil beberapa dari mereka, mengunci diri di gua dengan laptop, Internet, dan stopwatch dan tulis semua hasil kami dalam tablet yang rapi, dan kemudian coba buat beberapa kesimpulan. Pada saat yang sama, kami perhatikan bahwa saya menyukainya, yang mengejutkan atau tegang saat bekerja dengan satu atau beberapa mesin lainnya.

Tentang tolok ukur

Jadi, benda uji adalah tiga mesin game. Di sini mungkin layak untuk sedikit banyak secara formal (sebisa mungkin) menggambarkan "konfigurasi" Anda (ya, seperti dalam kasus hasil benchmark biasa, mereka menulis konfigurasi besi, di mana mereka menjalankan, deskripsi benchmark, dan sebagainya).

"Konfigurasi" atau Tentang Saya

Saya adalah pengembang Java. Pengalaman pengembangan industri 5+ tahun. Juga dalam karya saya menulis sedikit di JavaScript, Lua (benar-benar, sedikit), shell. Pendidikan teknis yang lebih tinggi. Saya tidak mengikuti kursus desain, saya tidak belajar desain game, saya hanya penggemar berat dari berbagai game PC. Tahun lalu dia tertarik membuat game komputer yang paling sederhana.

Tentang tugas

Sebuah proyek uji klon gim Doodle Jump dipilih. Saya yakin banyak orang tahu atau telah memainkannya, ini adalah game yang sangat keren dan dikembangkan dengan sangat baik untuk Android.

Peraturannya adalah sebagai berikut:

1. Setiap mesin memiliki waktu 4 jam. Ini termasuk belajar, berkenalan, mengupil, mencoba menulis prototipe, men-debug game, secara umum, siklus penuh pembuatan game.
2. Setiap setengah jam, dalam waktu istirahat singkat, saya akan mencoba memperbaiki apa yang telah dilakukan untuk memperbaiki pekerjaan saya, untuk menjabarkan rencana kerja selanjutnya, membuat catatan, mencatat, dan sebagainya.
3. Sebelum memulai pengujian setiap engine, kami akan mencoba menguraikan proyek game menjadi elemen-elemen penyusunnya untuk menetapkan unit konvensional pada mereka. Dengan demikian, kami mengukur "produktivitas" pengembang game kami untuk setiap engine di burung beo dan dapat membandingkan hasilnya bukan dengan kata-kata, tetapi setidaknya dalam beberapa angka.

Dekomposisi permainan menjadi komponen-komponen

Dalam bentuk yang sangat abstrak dan tingkat atas, saya melihat sendiri komponen-komponen permainan seperti ini:

1. Pemain (sprite, perilaku lompat, reaksi terhadap tombol yang ditekan)
2. Objek tingkat: platform, musuh, dll.
3. Fisika: kecepatan lompat pemain, akselerasi jatuh bebas, platform seharusnya hanya menangani tabrakan jika mereka melompat dari atas dan membiarkan pemain melewatinya jika ia melewatinya dari bagian bawah platform.
4. Generasi level prosedural: inisialisasi dan penambahan level (ke tempat sewenang-wenang, tetapi dengan aturan dan batasan tertentu) dengan cepat dari platform dan musuh baru, menciptakan situasi permainan yang memikat bagi pemain
5. "Kamera" yang mengikuti pemain saat dia naik ke atas. Kamera harus menjaga agar visibilitas pemain terhadap pemain dan secara bertahap "terpental" dengannya, menampilkan platform baru yang muncul di area render (dalam visibilitas kamera)
6. Mekanisme pemicu Game Over . Seorang pemain kalah jika dia mencapai tepi bawah area yang terlihat (setelah dia melompat setidaknya sekali)
7. Mencetak pemain. Kami hanya akan memperbarui penghitung tinggi pemain. Kami akan memperbarui konter sesuai dengan platform terakhir yang dicapai (platform yang ia tolak terakhir kali)
8. HUD : kemajuan tampilan pemain. Tampilan tinggi.

Untuk kesederhanaan, kami menetapkan setiap komponen satu poin dari unit parrot kami. Total maksimum - mis. Versi yang dapat dimainkan penuh dari proyek ini adalah 8 poin.

Di bawah ini adalah aset yang digunakan pada layar. Ini digambar tangan (saya bukan seorang seniman, seperti yang Anda lihat) karakter dan platform sprite dengan dimensi format 64x64, * .png.

Dan juga berikan beberapa diagram alur:

1. Dengan demikian, perhitungan "gender" untuk pemain akan dilaksanakan (ingat, dengan lompatan ke atas, layar bergeser, dan keberangkatan di tepi layar berarti selokan)
   
2. Maka kami menghitung dan memperbarui kecepatan vertikal ( y_velocity ) dan koordinat y pemain dengan setiap ketukan, hal ini dipengaruhi oleh dua faktor: percepatan gravitasi ( GRAVITY ) dan platform, setelah mencapai yang mana, pemain ditolak dengan kecepatan yang sepenuhnya pulih.
   
3. Algoritma untuk menghitung kecepatan horizontal, seperti mekanisme lainnya, tidak dimasukkan dalam ruang lingkup artikel.

Ngomong-ngomong, saya masih memiliki pertanyaan:

1. Bagaimana bisa lebih baik menerapkan pelacakan kamera untuk pemain? Sejauh ini, itu akan dikaitkan dengan koordinat vertikal dari platform tertinggi terakhir yang dapat dijangkau pemain, sehingga platform ini berada di bagian bawah area yang terlihat, dan kami melihat potongan-potongan baru dari level yang dihasilkan.
2. Algoritma generasi platform itu sendiri. Menurut ide saya, ini akan menjadi semacam "pabrik platform", yang di setiap siklus siklus permainan ( dt ) mengetahui platform tertinggi yang ada di level dan dengan nilai ketinggian acak (ambang tertentu, tidak lebih dari ketinggian lompatan pemain, tetapi juga tidak kurang dari sebagian kecil dari ketinggiannya, sehingga platform tidak menempel satu sama lain) menambahkan platform baru ke level ketika pemain telah maju. Pertanyaan meningkatkan kompleksitas permainan juga menarik di sini, bagaimana cara menghasilkan platform ini harus berubah.

Saya akan sangat senang dengan ide-ide Anda, hacks kehidupan dan saran dalam komentar dan PM tentang dua masalah desain-game ini.

Tentang mesin

Tiga kandidat dipilih dengan fitur yang sangat menarik bagi saya. Jadi, parameter yang akan berguna untuk diingat ketika menganalisis hasil tes Anda dirangkum di bawah ini.

Jadi, kami melihat bahwa pemilihannya cukup menarik. Sangat menarik karena kami akan berurusan dengan kombinasi berbeda dari kualitas dan karakteristik mesin kami. Dan mari kita lihat apa yang terselesaikan pada akhirnya: mesin di mana saya sudah mendapatkan tangan saya sedikit, YP dipompa atau mesin yang benar-benar segar dan baru bagi saya dengan chip yang menjanjikan, tetapi tidak dikuasai sama sekali, dan juga tidak dalam bahasa pengembangan utama saya.

Kenapa tidak Unity / Unreal Engine / Other Awesome Engine dll?

Banyak yang mungkin bertanya-tanya mengapa, saya tidak mengikuti cara standar, dan tidak menggunakan flagships paling umum di zaman kita: Unity atau Unreal Engine? Saya akan merumuskan pikiran saya dengan cara ini: Saya ingin membangun gim yang sangat sederhana, minimalis dan mungil. Dengan beberapa elemen gim yang membentuk mekanik gim, satu karakter yang dapat dimainkan, generasi level yang sederhana dan tanpa efek khusus atau efek khusus yang sangat konvensional, seperti pada mesin arcade lama. Jadi, secara kiasan, tugas saya adalah menggambar lingkaran merah di kotak hitam, dan untuk ini saya diundang untuk mengambil Photoshop . Sederhananya, serangkaian fitur, mode, dan kemampuan Unity membuatku takut. Pada tahap ini, saya ingin memahami setiap detail permainan saya.

Ini paling baik dilakukan oleh mesin sederhana dan kecil, dengan serangkaian fitur terbatas, mungkin tidak dengan penyetelan dan ekosistem terbaik, tetapi kesederhanaan dan keterbatasan juga memiliki keindahannya sendiri. Dengan hanya seperangkat alat terbatas - dan dalam kasus Love2D, alat Anda adalah kode Anda dan tidak lebih, Anda fokus pada kipas, menulis sesuatu yang keren, menghidupkan kembali karakter atau lingkungan pemain. Mesin yang lebih rumit memperluas pilihan Anda, dan menulis kode dengan lancar mengalir ke banyak hal: menulis skrip (kode), menghubungkan skrip, memetakan aset, menambahkan konfigurasi, mendefinisikan ulang konfigurasi, mencampur plugin pihak ketiga, menulis skrip dan konfigurasi untuk plugin pihak ketiga, beberapa kali klik pada puluhan dan puluhan dialog dan jendela ... Anggap saja untuk saat ini saya masih takut dengan mesin pengembangan game yang begitu canggih dan kuat. Ya, saya tidak ingin mengingat C # / JS / C ++ lagi dan menulisnya.

Saya akan merangkum motivasi saya ketika memilih mesin dengan tautan ke video ini, di mana bagi saya tampaknya penulis benar-benar menghapus dari bahasa saya apa yang saya coba rumuskan dengan kata-kata untuk diri sendiri dan orang lain selama ini: https://www.youtube.com/watch ? v = JH8xwNOQ0TM

Defold

Defold adalah mesin lintas platform dari King.
Platform yang didukung:

• Html5 (WebGl)
• Android 2.3 (API level 9) +
• iOS 8.0+
• Windows Vista +
• OSX 10.7+
• Linux

Fakta yang aneh adalah bahwa King dimiliki oleh Activision Blizzard .
Di mesin, saya tertarik dengan bahasa pengembangan - Lua , dukungan untuk banyak platform untuk pembuatan game, serta distribusi IDE lintas-platform mereka sendiri - dapat diinstal di Linux juga. Ini menyuap saya ketika memilih antara Defold vs. Corona SDK .
Dan di bawah ini adalah log dari apa yang dilakukan pada titik kontrol:

Di bawah ini, di spoiler, ada beberapa animasi gif yang menunjukkan perkembangan waktu:

Hasil, poin tolok ukur:

1. Pemain (sprite, perilaku lompat, reaksi terhadap tombol yang ditekan) (V) Yes
2. Objek tingkat: platform, musuh, dll. (V) Yes
3. Fisika: kecepatan lompat pemain, akselerasi jatuh bebas, platform seharusnya hanya menangani tabrakan jika dilompati dari atas dan membiarkan pemain melewatinya jika ia melewatinya dari bagian bawah platform. (V) Yes
4. Generasi level prosedural: inisialisasi dan menambah level (ke tempat sewenang-wenang, tetapi dengan aturan dan batasan tertentu) dengan cepat menerbangkan platform dan musuh baru, menciptakan situasi permainan yang memikat bagi pemain (X) No
5. "Kamera" yang mengikuti pemain saat dia naik ke atas. Kamera harus menjaga pemain dalam bidang tampilan untuk pemain dan secara bertahap "bangkit" dengannya, menampilkan platform baru yang muncul di area render (di bidang pandang kamera) (X) No
6. Mekanisme pemicu Game Over. Seorang pemain kalah jika dia mencapai tepi bawah area yang terlihat (setelah dia melompat setidaknya sekali) (X) No
7. Mencetak pemain. Kami hanya akan memperbarui penghitung tinggi pemain. Kami akan memperbarui penghitung sesuai dengan platform terakhir yang dicapai (platform yang ia tolak terakhir kali) (V) Yes
8. HUD: kemajuan tampilan pemain. Tampilan tinggi. Secara opsional, tampaknya tidak ada indikator kemajuan dalam game asli. (V) Yes

Skor Benchmark: 5/8

Love2d

Ini adalah mesin yang sangat minimalis, tetapi cukup kuat dan fleksibel untuk membuat prototipe. Secara umum, dengan ketangkasan karena, bahkan cocok untuk menerbitkan game penuh ke pasar. Ada beberapa contoh inspirasional yang baik. Begitu saja, Satu dan Dua .

Secara umum, untuk mesin ini saya merekomendasikan serangkaian tutorial yang sangat cocok dari Habr, yang memacu saya dan memberikan dorongan kuat untuk pengembangan mesin ini, saya hanya akan memberikan tautan ke bagian pertama, maka akan mungkin untuk mendapatkan dari itu ke bagian yang tersisa: Membuat game di Lua dan LÖVE - 1

Jadi, di bawah ini adalah log dari apa yang dilakukan di pos pemeriksaan:

Hitung "performa" mesin:

1. Pemain (sprite, perilaku lompat, reaksi terhadap tombol yang ditekan) (V) Yes
2. Objek tingkat: platform, musuh, dll. (V) Yes
3. Fisika: kecepatan lompat pemain, akselerasi jatuh bebas, platform seharusnya hanya menangani tabrakan jika mereka melompat dari atas dan membiarkan pemain melewatinya jika ia melewatinya dari bagian bawah platform.
   (V) Yes / (X) No // * Diimplementasikan, tetapi tidak cukup sempurna, dengan kekurangan yang signifikan. Saya akan menempatkan di sini 0,5 poin untuk menyelesaikan item.
4. Generasi level prosedural: inisialisasi dan penambahan level (ke tempat sewenang-wenang, tetapi dengan aturan dan batasan tertentu) dengan cepat dari platform dan musuh baru, menciptakan situasi permainan yang memikat bagi pemain (V) Yes
5. "Kamera" yang mengikuti pemain saat dia naik ke atas. Kamera harus menjaga visibilitas pemain terhadap pemain dan secara bertahap "memantul" bersamanya, menampilkan platform baru yang muncul di area render (dalam visibilitas kamera) (V) Yes
6. Mekanisme pemicu Game Over. Seorang pemain kalah jika dia mencapai tepi bawah area yang terlihat (setelah dia melompat setidaknya sekali) (V) Yes
7. Mencetak pemain. Kami hanya akan memperbarui penghitung tinggi pemain. Kami akan memperbarui penghitung sesuai dengan platform terakhir yang dicapai (platform yang ia tolak terakhir kali) (V) Yes
8. HUD: kemajuan tampilan pemain. Tampilan tinggi. Secara opsional, tampaknya tidak ada indikator kemajuan dalam game asli. (V) Yes

Skor Benchmark: 7.5 / 8

Jawa

Mungkin langkah logis dan logis adalah untuk melihat lebih dekat pada mesin, di mana bahasa pengembangan adalah di mana saya memiliki pengalaman dan ketangkasan yang paling, bukan? Sebenarnya, intuisi dan beberapa sensasi internal membuat saya sedikit dari ini. Faktanya adalah sebagai seorang siswa, saya entah bagaimana menyaksikan teman sekelas saya dengan mesin jMonkey . Perkakas, bekerja dengan mesin, dokumentasi, semua ini bersama-sama menciptakan semacam gambar yang tidak terlalu menyenangkan. Sepertinya mesin itu sama sekali tidak memberi Anda kesempatan untuk berteman dengannya, sangat banyak penggunaannya yang tampak tidak menyenangkan.

Namun demikian, saya memutuskan untuk melihat apa yang tersedia hari ini, dan saya hanya melihat ke arah mesin yang hanya menjamin 2D , saya tidak peduli tentang dukungan 3D . Salah satu mesinnya, Lightweight Java Game Library 3 , memiliki namanya dan kata pengantar Lightweight . Ironisnya, contoh-contoh dasar paling sederhana di halaman utama, beberapa layar panjangnya, hanya ditakuti.

Ya, tentu saja, Java sangat verbose, apa yang Anda inginkan, katamu. Tetapi saya tahu bahwa Anda dapat menulis hal-hal yang sangat ringkas dan sangat ekspresif. Saya melihat API yang indah dan ringkas.
Dan pada akhirnya, pilihan jatuh pada FXGL . Pada awalnya, saya tidak memiliki antusiasme dan kegembiraan yang menyenangkan, yang terjadi sebelum awal pengembangan beberapa hal atau perpustakaan yang menarik. Tapi sudah dari contoh pertama dan halaman singkat dokumentasi dan contoh, mesin ini sangat mengejutkan saya. Semuanya logis, dapat dimengerti dan konsisten dalam pendekatan dan API yang ia usulkan. Ini jelas membantu Anda membangun loop yang jelas dan fleksibel untuk gim, logika handler, HUD , AI , tabrakan, dan elemen lainnya.

Momen menarik dan chip FXGL:

• Seperti namanya, untuk bagian visual, mesin menggunakan JavaFX API ( JavaFX digunakan sebagai kerangka grafis) dengan semua barang dan anti-barangnya untuk rendering dan tata letak. Secara umum, saya pikir ini adalah keputusan yang bagus dan cukup masuk akal. Dengan demikian, penulis menghindari sejumlah masalah (tidak perlu menerapkan dan memelihara komponen rendering Anda, Anda dapat menggunakan solusi yang disempurnakan dari ekosistem Java ). Inilah yang penulis sendiri katakan dalam salah satu tutorial pertamanya, dan saya sangat menyukai frasa ini:

  
  

  "Untuk sebagian besar objek UI, kami cukup menggunakan objek JavaFX, karena tidak perlu menemukan kembali roda."

  Tetapi secara umum, tentu saja, Anda mendapatkan banyak fitur dan beberapa kerugian JavaFX , juga (saya tidak tahu banyak tentang detail), tetapi sejauh yang saya tahu, ada beberapa pembatasan lisensi pada penggunaan JavaFX dalam proyek Anda, dan tampaknya JavaFX pergi dan hanya akan berjalan dalam pengiriman JDK terbatas ( Oracle , mungkin beberapa lagi).

  
  

• Sebuah proyek uji, miring dari repositori, atas dasar di mana saya mulai memahat permainan, silakan meletakkan log di logs/ proyek setelah setiap permainan dimulai. Ini sangat mudah, Anda dapat langsung melihat keluar dari kotak debug-informasi, sangat berguna untuk diagnosis, memahami di mana Anda mengacau jika Anda tiba-tiba bertemu dengan plug dalam studi mesin.

  
  

• Juga (tampaknya sekali lagi, dengan pengaturan dasar) permainan menyediakan menu pop-up dengan menekan tombol Esc . Juga bonus yang bagus, saya harap ini disesuaikan atau setidaknya dinonaktifkan oleh kode atau konfigurasi.

  
  

• Debag akhirnya bekerja di sini ! Akhirnya! Dalam Love2D untuk sedikitnya, tidak nyaman dan tidak menyenangkan.

  
  

  Log pengembangan

  
  

  Di bawah ini adalah ringkasan singkat dari kemajuan saya, di mana saya secara singkat mencatat apa yang dicapai setelah interval 30 menit, serta beberapa pemikiran dan komentar saya. Lihatlah log kesadaran saya dalam 4 jam ini!

  
  

GIF- , .

"" … , , , ? .

Benchmark Score: 8

, ,

:

, , , ( ). , , Java FXGL , , Lua , . , , .

:

1. FXGL ? . Love2D , Defold , , , , Love2D - , .
2. , . , . (, ), . , - . , , , , . , , , . .
3. gif-, . . , , "" , .

?

, - , ?

Jadi:

1. , . , , , , . - , - ( Love2D ).
2. - , Love2D , . F to pay respect .
3. . , , , - - , , (, , )
4. . 4 , . - Game Jam , .
5. ! , , - Roadmap , , . (!) (?) . 30 . , . , , ! , pet- 44 - Ludum Dare .