Lelucon “Yang disebut Verlet hanya kalau berasal dari wilayah Verlet di Prancis; kalau tidak, itu cuma Euler bersoda” itu bagus sekali
Saya penasaran bagaimana orang bisa beralih dari pengetahuan pengembangan web, Gradle, dan Java ke tahap membuat hal seperti ini
Karena tidak mengambil S1 CS, kadang saya merasa sebanyak apa pun belajar bahasa pemrograman, saya tidak akan pernah memahami hal seperti ini. Saya pernah sedikit mencoba OPENLY, LIBGDX, GODOT, dan Unity, tetapi membuat simulasi kain dari nol terasa benar-benar membingungkan
Ini jauh lebih sederhana daripada yang dibayangkan. Saya membuat demo “kain yang robek” yang ditautkan di tempat lain dalam thread ini bahkan sebelum memulai karier sebagai software engineer
Di sini digunakan integrasi Verlet dasar: memperbarui vektor 2D yang membentuk kisi berdasarkan posisi saat ini dan posisi sebelumnya, lalu membatasi agar titik-titik yang bertetangga langsung tetap menjaga jarak tertentu. Jika kita menggambar garis di antara titik-titik itu, jadilah kain. Saya menemukannya saat tertarik pada simulasi fisika dan mencari-cari, lalu mencobanya pertama kali karena termasuk salah satu yang paling mudah diimplementasikan; hasilnya sangat sepadan dengan usahanya. Tentu saja setelah itu semuanya menjadi jauh lebih rumit
Saya pernah merasakan hal serupa karena ingin belajar simulasi fisika. Seiring waktu, saya belajar bahwa kita harus memisahkan ranah pengetahuan seperti fisika dari alat pemrograman untuk mengimplementasikannya
Terutama kalau mulai dari pengembangan game, rasanya setiap simulasi utama seperti benda tegar, kain, pegas, dan fluida punya cara pemrograman yang alami dan idiomatis. Awalnya saya mengira simulasi fluida pun akan bisa diekspresikan secara alami di dalam bahasa, misalnya dengan membuat kisi lalu memilih aturan pembaruan di setiap langkah waktu. Namun kenyataannya, kita memodelkan masalahnya dengan matematika dan fisika terlebih dahulu, lalu memetakannya ke bahasa dan alat; dan alat itu tidak selalu mengekspresikannya secara idiomatis
Ada algoritma yang mudah dipindahkan ke kode, seperti posisi partikel dan simulasi kain berbasis pegas, tetapi ketika mencoba melangkah lebih jauh, justru itu menimbulkan salah paham. Pada akhirnya saya harus menggali fisika dan analisis numerik lebih dalam, lalu memindahkan masalahnya ke kode; hasil kodenya bisa tampak kasar dan penuh magic number
Pengembangan web tidak terbatas pada Java saja, dan secara umum didominasi oleh masalah integrasi komponen. Strukturnya banyak tetapi isinya sedikit; komputasi didelegasikan ke library; saat build, yang jadi masalah adalah kompleksitas integrasi, dan saat runtime, skala sistem terdistribusi
Sebaliknya, menulis simulasi membutuhkan banyak komputasi sehingga sebagian besar kode benar-benar berisi substansi. Jika pengembangan web adalah gabungan hal-hal yang heterogen, simulasi lebih homogen. Masalahnya dibatasi oleh performa proses tunggal dalam anggaran waktu yang ditentukan oleh jumlah frame per detik
Karena itu, kita bisa berfokus pada satu lingkungan eksekusi. Saya merekomendasikan browser, yang menyelesaikan masalah deployment. Ganja[1] mungkin merupakan proyek simulasi paling ekstrem yang lebih dekat ke “isi, bukan struktur”. Sangat unik dan sulit dipahami sehingga pemeliharaannya berhenti, tetapi masih berfungsi. Untuk yang sedikit lebih terstruktur ada D3, dan para pembuatnya sudah menyediakan algoritma visualisasi/tata letak modern seperti grafik berbasis gaya[2]. Titik awal yang lebih ramah mungkin keluarga Processing[3], yang dimulai dari Java lalu di-porting ke Python, JavaScript, dan lainnya
Namun satu simulasi kain saja, jika dianalogikan dengan game engine, hanya setingkat satu sel dari seekor tikus. Game engine itu sangat besar, dan bahkan di sana Anda akan lebih banyak melakukan integrasi internal daripada menulis simulasi sendiri
1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js
2 - https://github.com/d3/d3-force/tree/main/src
3 - https://processing.org/
Pada akhirnya semuanya adalah matematika dan fisika
Anda memang tidak secara khusus bertanya tentang pengembangan game, tetapi pengetahuan seperti grafika, matematika, pencahayaan, dan fisika pada umumnya banyak tersebar di bidang itu. Kalau hanya mencari topik ceruk seperti simulasi kain secara terpisah, mungkin sulit menemukan informasi yang tidak terkait dengan materi pengembangan game
Hari ini saya membaca https://alextardif.com/LearningGraphics.html, dan itu bisa menjadi penunjuk arah ke berbagai jalur. https://learnopengl.com/ tetap mendapat reputasi baik meskipun sekarang ada API yang lebih baru seperti Vulkan, Metal, dan DX12. Namun anggap saja API hanya sekitar 5% dari masalah yang harus diselesaikan. Sejujurnya mungkin lebih kecil lagi, tetapi Vulkan memang lebih berat daripada yang sering terdengar
Jika tidak ingin belajar C/C++, komunitas WebGL besar, jadi bisa mulai dari subreddit atau forum terkait. Meski begitu, API dan platform lebih seperti kulit luar yang membungkus bagian yang benar-benar menarik dan baru, yaitu simulasi fisika
Sebagai konteks, saya adalah pengembang web/Gradle/Java, dan setelah pernah mencobanya beberapa tahun lalu, sekarang saya kembali membuat game engine di waktu luang
Tidak sesulit itu. Di JavaScript, cukup representasikan setiap titik sebagai (x,y,z), beri massa, lalu terapkan gravitasi di setiap frame dan tambahkan sedikit noise bila perlu
Setiap kali partikel hendak bergerak, gunakan trigonometri untuk meneruskan gaya melalui sisi ke titik-titik lain, dan tambahkan sedikit redaman agar tidak lepas kendali. Massa kemudian menentukan seberapa besar setiap titik dipengaruhi oleh gaya. Jika 3D terasa berat, mulai saja dari 2D
Terpikir pada video Polygon yang menganalisis desain kain luar biasa di Elden Ring: https://youtu.be/wSSqx-Dh6ko
Bagian yang kurang ditekankan dalam video itu adalah bahwa kain juga punya tujuan fungsional. Kain menutupi bentuk musuh sehingga membuat modelnya lebih sulit dibedakan
Dalam game yang bertumpu pada pertarungan jarak dekat dan hit detection presisi—yang bisa dibilang salah satu aspek paling inovatif dari game FromSoft—kain yang mengalir bebas membuat pemain sulit menilai seberapa dekat karakter harus berada agar serangan mengenai, atau seberapa jauh harus menjauh agar tidak terkena. Ditambah gerakan dan pola serangan yang sulit diprediksi, tingkat kesulitannya makin naik dan setiap pertarungan terasa unik
Di dunia nyata pun kain punya sifat yang sama. Musuh yang memakai jubah atau mantel jauh lebih mengancam dan lebih sulit dihadapi
Secara pribadi saya tidak menikmati game FromSoft karena loop gameplay-nya, tetapi dari sisi desain saya menganggapnya termasuk beberapa video game terbaik yang pernah dibuat
Saya juga punya versi saya sendiri yang dibuat 14 tahun lalu: https://www.youtube.com/watch?v=G05M_Y6NQVM
Saya setuju bahwa susunan dasar seperti ini sangat sederhana untuk diimplementasikan, dan hasilnya benar-benar keren
Itu buatan saya. Versi asli yang saya unggah ke Codepen kira-kira 13 tahun lalu
Saya sendiri sulit percaya, tetapi kalau mengingat itu terjadi sebelum saya mendapat pekerjaan programming pertama, rasanya memang sudah sangat lama
Video game Hitman tahun 2000 juga punya kain, dan Mirror's Edge tahun 2008 punya kain yang bisa robek. Kemungkinan keduanya juga bukan yang pertama
Simulator kain seperti ini selalu terasa agak tidak stabil. Kalau membuat kain Grid, ia mulai melompat-lompat dan bergerak acak
Saya penasaran apakah ini karena akumulasi galat floating-point IEEE 754
Coba cari integrasi numerik dalam konteks simulasi fisika atau game engine. Sebagai titik awal, bisa lihat https://en.wikipedia.org/wiki/Numerical_methods_for_ordinary...
Sepemahaman saya, penyebabnya bukan sekadar galat floating-point, melainkan sifat pendekatan fungsi kontinu dengan langkah-langkah diskret yang sederhana. Artikel Wikipedia yang ditautkan juga punya grafik yang menunjukkan bahwa pada langkah besar, galat sudah terakumulasi jauh sebelum presisi floating-point menjadi masalah
Setiap teknik integrasi numerik punya kompromi berbeda. Ada metode Euler, Verlet, Runge-Kutta, dan sebagainya; sebagian metode cenderung mengakumulasi energi total, sementara yang lain cenderung kehilangan energi, dan keduanya merupakan perilaku yang salah. Metode yang lebih kompleks biasanya bekerja sedikit lebih baik, tetapi muncul pertanyaan apakah manfaat langkah yang lebih kompleks mengalahkan menjalankan algoritma yang lebih sederhana dan cepat dengan iterasi lebih banyak
Dalam simulasi fisika, kekekalan energi tidak otomatis berlaku kecuali dikodekan secara eksplisit. Misalnya, perlu koreksi langsung secara berkala
Penyebabnya bukan hanya galat pembulatan, tetapi juga kuantisasi waktu dan berbagai galat kecil lain dari model matematis itu sendiri
Jika galatnya mengarah ke redaman, efeknya seperti energi yang terdisipasi secara nyata sehingga gerakan akhirnya berhenti; jika mengarah ke percepatan, simulasinya menjadi tak terkendali
Saya ingin mengatakan kepada pembuat situs ini: kerja yang bagus. Berjalan apa adanya tanpa JavaScript eksternal, dan juga berfungsi di mobile
Sulit mengatakan hal yang sama untuk kebanyakan situs web berbasis teks saat ini
Ini karya yang benar-benar impresif. Sederhana tetapi membuat terus dipandangi, dan menunjukkan dengan baik betapa kuatnya integrasi Verlet untuk membuat simulasi kain yang terasa alami dan meyakinkan
Kalau tertarik, saya juga merekomendasikan makalah Jakobsen dari game engine Hitman. Itu materi klasik
Senang melihat orang benar-benar mengajukan pertanyaan sulit tentang bagaimana hal seperti ini bekerja. Setiap kali, rasanya semua hal dibuat dari begitu banyak langkah kecil yang terakumulasi selama bertahun-tahun
Saya penasaran apakah orang-orang menabrak titik ketika matematika terasa seperti tembok, atau terus mengetuknya sampai akhirnya bisa dipahami
Hal yang paling menarik adalah hanya dengan menetapkan beberapa parameter dan constraint, gerakan yang begitu realistis bisa muncul
Ini membuat saya berpikir bahwa dunia di sekitar kita mungkin hanya sekumpulan model dan gaya tersembunyi, dan tugas kita adalah menemukannya lalu menyimulasikannya. Karya yang indah
1 komentar
Pendapat Hacker News
Contoh lain yang bisa dilihat di browser: https://oimo.io/works/cloth/
Setelah membaca tulisan Marian Pekár, saya memahami integrasi Verlet dan bisa membuat simulasi kain sendiri: https://pikuma.com/blog/verlet-integration-2d-cloth-physics-...
Saya penasaran bagaimana orang bisa beralih dari pengetahuan pengembangan web, Gradle, dan Java ke tahap membuat hal seperti ini
Karena tidak mengambil S1 CS, kadang saya merasa sebanyak apa pun belajar bahasa pemrograman, saya tidak akan pernah memahami hal seperti ini. Saya pernah sedikit mencoba OPENLY, LIBGDX, GODOT, dan Unity, tetapi membuat simulasi kain dari nol terasa benar-benar membingungkan
Di sini digunakan integrasi Verlet dasar: memperbarui vektor 2D yang membentuk kisi berdasarkan posisi saat ini dan posisi sebelumnya, lalu membatasi agar titik-titik yang bertetangga langsung tetap menjaga jarak tertentu. Jika kita menggambar garis di antara titik-titik itu, jadilah kain. Saya menemukannya saat tertarik pada simulasi fisika dan mencari-cari, lalu mencobanya pertama kali karena termasuk salah satu yang paling mudah diimplementasikan; hasilnya sangat sepadan dengan usahanya. Tentu saja setelah itu semuanya menjadi jauh lebih rumit
Terutama kalau mulai dari pengembangan game, rasanya setiap simulasi utama seperti benda tegar, kain, pegas, dan fluida punya cara pemrograman yang alami dan idiomatis. Awalnya saya mengira simulasi fluida pun akan bisa diekspresikan secara alami di dalam bahasa, misalnya dengan membuat kisi lalu memilih aturan pembaruan di setiap langkah waktu. Namun kenyataannya, kita memodelkan masalahnya dengan matematika dan fisika terlebih dahulu, lalu memetakannya ke bahasa dan alat; dan alat itu tidak selalu mengekspresikannya secara idiomatis
Ada algoritma yang mudah dipindahkan ke kode, seperti posisi partikel dan simulasi kain berbasis pegas, tetapi ketika mencoba melangkah lebih jauh, justru itu menimbulkan salah paham. Pada akhirnya saya harus menggali fisika dan analisis numerik lebih dalam, lalu memindahkan masalahnya ke kode; hasil kodenya bisa tampak kasar dan penuh magic number
Sebaliknya, menulis simulasi membutuhkan banyak komputasi sehingga sebagian besar kode benar-benar berisi substansi. Jika pengembangan web adalah gabungan hal-hal yang heterogen, simulasi lebih homogen. Masalahnya dibatasi oleh performa proses tunggal dalam anggaran waktu yang ditentukan oleh jumlah frame per detik
Karena itu, kita bisa berfokus pada satu lingkungan eksekusi. Saya merekomendasikan browser, yang menyelesaikan masalah deployment. Ganja[1] mungkin merupakan proyek simulasi paling ekstrem yang lebih dekat ke “isi, bukan struktur”. Sangat unik dan sulit dipahami sehingga pemeliharaannya berhenti, tetapi masih berfungsi. Untuk yang sedikit lebih terstruktur ada D3, dan para pembuatnya sudah menyediakan algoritma visualisasi/tata letak modern seperti grafik berbasis gaya[2]. Titik awal yang lebih ramah mungkin keluarga Processing[3], yang dimulai dari Java lalu di-porting ke Python, JavaScript, dan lainnya
Namun satu simulasi kain saja, jika dianalogikan dengan game engine, hanya setingkat satu sel dari seekor tikus. Game engine itu sangat besar, dan bahkan di sana Anda akan lebih banyak melakukan integrasi internal daripada menulis simulasi sendiri
1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js
2 - https://github.com/d3/d3-force/tree/main/src
3 - https://processing.org/
Anda memang tidak secara khusus bertanya tentang pengembangan game, tetapi pengetahuan seperti grafika, matematika, pencahayaan, dan fisika pada umumnya banyak tersebar di bidang itu. Kalau hanya mencari topik ceruk seperti simulasi kain secara terpisah, mungkin sulit menemukan informasi yang tidak terkait dengan materi pengembangan game
Hari ini saya membaca https://alextardif.com/LearningGraphics.html, dan itu bisa menjadi penunjuk arah ke berbagai jalur. https://learnopengl.com/ tetap mendapat reputasi baik meskipun sekarang ada API yang lebih baru seperti Vulkan, Metal, dan DX12. Namun anggap saja API hanya sekitar 5% dari masalah yang harus diselesaikan. Sejujurnya mungkin lebih kecil lagi, tetapi Vulkan memang lebih berat daripada yang sering terdengar
Jika tidak ingin belajar C/C++, komunitas WebGL besar, jadi bisa mulai dari subreddit atau forum terkait. Meski begitu, API dan platform lebih seperti kulit luar yang membungkus bagian yang benar-benar menarik dan baru, yaitu simulasi fisika
Sebagai konteks, saya adalah pengembang web/Gradle/Java, dan setelah pernah mencobanya beberapa tahun lalu, sekarang saya kembali membuat game engine di waktu luang
Setiap kali partikel hendak bergerak, gunakan trigonometri untuk meneruskan gaya melalui sisi ke titik-titik lain, dan tambahkan sedikit redaman agar tidak lepas kendali. Massa kemudian menentukan seberapa besar setiap titik dipengaruhi oleh gaya. Jika 3D terasa berat, mulai saja dari 2D
Terpikir pada video Polygon yang menganalisis desain kain luar biasa di Elden Ring: https://youtu.be/wSSqx-Dh6ko
Dalam game yang bertumpu pada pertarungan jarak dekat dan hit detection presisi—yang bisa dibilang salah satu aspek paling inovatif dari game FromSoft—kain yang mengalir bebas membuat pemain sulit menilai seberapa dekat karakter harus berada agar serangan mengenai, atau seberapa jauh harus menjauh agar tidak terkena. Ditambah gerakan dan pola serangan yang sulit diprediksi, tingkat kesulitannya makin naik dan setiap pertarungan terasa unik
Di dunia nyata pun kain punya sifat yang sama. Musuh yang memakai jubah atau mantel jauh lebih mengancam dan lebih sulit dihadapi
Secara pribadi saya tidak menikmati game FromSoft karena loop gameplay-nya, tetapi dari sisi desain saya menganggapnya termasuk beberapa video game terbaik yang pernah dibuat
Saya selalu menyukai animasi kain seperti ini. Yang pertama saya lihat mungkin demo kain yang bisa robek di Codepen buatan dissimulate, dan sulit percaya kode itu ditulis 9 tahun lalu
[1] - https://codepen.io/dissimulate/pen/eZxEBO
[2] - https://github.com/Dissimulate/Tearable-Cloth
Saya setuju bahwa susunan dasar seperti ini sangat sederhana untuk diimplementasikan, dan hasilnya benar-benar keren
Saya sendiri sulit percaya, tetapi kalau mengingat itu terjadi sebelum saya mendapat pekerjaan programming pertama, rasanya memang sudah sangat lama
Simulator kain seperti ini selalu terasa agak tidak stabil. Kalau membuat kain Grid, ia mulai melompat-lompat dan bergerak acak
Saya penasaran apakah ini karena akumulasi galat floating-point IEEE 754
Sepemahaman saya, penyebabnya bukan sekadar galat floating-point, melainkan sifat pendekatan fungsi kontinu dengan langkah-langkah diskret yang sederhana. Artikel Wikipedia yang ditautkan juga punya grafik yang menunjukkan bahwa pada langkah besar, galat sudah terakumulasi jauh sebelum presisi floating-point menjadi masalah
Setiap teknik integrasi numerik punya kompromi berbeda. Ada metode Euler, Verlet, Runge-Kutta, dan sebagainya; sebagian metode cenderung mengakumulasi energi total, sementara yang lain cenderung kehilangan energi, dan keduanya merupakan perilaku yang salah. Metode yang lebih kompleks biasanya bekerja sedikit lebih baik, tetapi muncul pertanyaan apakah manfaat langkah yang lebih kompleks mengalahkan menjalankan algoritma yang lebih sederhana dan cepat dengan iterasi lebih banyak
Penyebabnya bukan hanya galat pembulatan, tetapi juga kuantisasi waktu dan berbagai galat kecil lain dari model matematis itu sendiri
Jika galatnya mengarah ke redaman, efeknya seperti energi yang terdisipasi secara nyata sehingga gerakan akhirnya berhenti; jika mengarah ke percepatan, simulasinya menjadi tak terkendali
Saya ingin mengatakan kepada pembuat situs ini: kerja yang bagus. Berjalan apa adanya tanpa JavaScript eksternal, dan juga berfungsi di mobile
Sulit mengatakan hal yang sama untuk kebanyakan situs web berbasis teks saat ini
Ini karya yang benar-benar impresif. Sederhana tetapi membuat terus dipandangi, dan menunjukkan dengan baik betapa kuatnya integrasi Verlet untuk membuat simulasi kain yang terasa alami dan meyakinkan
Kalau tertarik, saya juga merekomendasikan makalah Jakobsen dari game engine Hitman. Itu materi klasik
Senang melihat orang benar-benar mengajukan pertanyaan sulit tentang bagaimana hal seperti ini bekerja. Setiap kali, rasanya semua hal dibuat dari begitu banyak langkah kecil yang terakumulasi selama bertahun-tahun
Saya penasaran apakah orang-orang menabrak titik ketika matematika terasa seperti tembok, atau terus mengetuknya sampai akhirnya bisa dipahami
Hal yang paling menarik adalah hanya dengan menetapkan beberapa parameter dan constraint, gerakan yang begitu realistis bisa muncul
Ini membuat saya berpikir bahwa dunia di sekitar kita mungkin hanya sekumpulan model dan gaya tersembunyi, dan tugas kita adalah menemukannya lalu menyimulasikannya. Karya yang indah