Ceritanya tentang bagaimana saya memutuskan untuk mulai mengembangkan game tanpa pengetahuan dan pengalaman di bidang ini, tanpa mesin dan investasi. Mengapa saya membutuhkan ini? Kenapa orang lain? Tentang kegagalan dan kesuksesan, tentang awal posting pengembangan indie.
Halo semuanya! Nama saya Roma dan selama beberapa tahun saya telah mengembangkan untuk tertanam, maafkan saya, C / C ++. Pemrograman bagi saya lebih dari sekadar pekerjaan. Karenanya keinginan untuk memiliki proyek sendiri yang akan tumbuh, dan dengan itu profesionalisme saya. Saya percaya akan hal itu. Banyak bahasa dan teknologi telah dicoba, banyak ide dan banyak kegagalan. Saya pikir seseorang mengenali dirinya sendiri. Posting ini akan berbicara tentang memulai pengembangan game komputer di C ++ menggunakan OpenGl. Berikutnya akan tentang hal-hal berikut:
- Kesulitan yang muncul di depan saya dan pendekatan untuk solusi mereka.
- Ikhtisar teknologi yang digunakan dan alat pengembangan.
- Tautan ke sumber daya yang digunakan di jaringan.
Apa yang tidak akan terjadi selanjutnya:
- Tentang seluk-beluk pengembangan C ++. Bahasa akan disebutkan dengan tingkat abstraksi sehingga dapat dengan mudah digantikan oleh OOP lain yang mendukung secara asli.
- Tentang mesin siap pakai dan penggunaannya. Aku tidak menentang, aku bahkan UNTUK. Tetapi posting tentang sesuatu yang lain.
- Tentang gambar luar biasa menggunakan shader generasi terbaru. Sejauh ini sejauh ini.
Jadi, posting tentang petualangan dan seni. Pendekatan pengembangan yang dideskripsikan di akhir tulisan ini bagi saya setidaknya tidak bersifat kanonik. Namun, saya pikir dia punya hak untuk hidup. Jika Anda membaca hingga tempat ini dan Anda ingin merancang dari tongkat dan pergi Berimprovisasi artinya, maka Anda tidak akan kecewa.
Mulai dan gagal
Tinjauan singkat alat untuk mengembangkan game 2D tanpa mesin menunjukkan bahwa Anda harus segera memilih kerangka kerja untuk memproses mouse, keyboard, serta mendukung audio dan menampilkan grafik primitif. Perpustakaan SFML dipilih. Butuh sekitar satu minggu untuk mengenal satu sama lain, ada yang dibuat sketsa: tank melaju di sepanjang lapangan persegi panjang dan saling membunuh, adalah mungkin untuk membangun pabrik mereka dan sejenisnya dalam semangat RTS awal 2000-an. Tampaknya membosankan dan ingin 3D. Saya kurang tahu tentang 3D daripada javascript tentang keamanan jenis. Google adalah yang pertama merilis OpenGl, yang sudah ketinggalan zaman. Dan juga tentang rekomendasi untuk menggunakan apa yang disebut Core Profile dari OpenGl ini. Siapa yang harus saya tulis dengan metode yang sudah ketinggalan zaman? Dari upaya untuk menyeberang Profil Inti dengan SFML, ternyata SFML tidak mendukung profil ini pada saat yang sama menggunakan modul grafiknya. Itu adalah pukulan moral yang kuat, karena sumber daya dihabiskan untuk belajar SFML. Selain itu, tidak semua basis kode disarikan dari perpustakaan grafik.
GLFW dan harapan baru
Seperti yang disarankan oleh bagian ini, Profil Inti OpenGl dan GLFW rukun. Sumber daya utama yang saya gunakan di OpenGl. Ya, ya, tanpa VPN, kemungkinan besar itu tidak akan terbuka, terima kasih kepada para pembela Runet. Helper Dalam satu atau dua minggu, elemen geometris sederhana dengan tekstur akan mengambang di sekitar layar. Beralih ke GLFW dengan SFML akan mengajarkan seseorang untuk menghargai prinsip inversi Ketergantungan (D dalam SOLID). Akibatnya, ia lahir
Saya tidak punya ilusi tentang sisi estetika masalah, tetapi prototipe itu hidup. Ya, dia jelek, tapi semua orang tahu dongeng yang terkenal. Suasana menjadi lebih baik. Pada saat itu, tugas yang paling sulit bagi saya hari ini diselesaikan: membuat model dengan animasi. Tugas ini dibagi menjadi beberapa subtugas:
- Membuat animasi di editor, misalnya, di Blender.
- Ekspor ke format yang mendukung animasi, seperti Collada.
- Impor dalam C ++, misalnya, dengan pustaka Assimp.
- Merancang kelas dan implementasinya menggunakan OpenGl.
Dengan demikian, tank menerima menara yang berputar.
Saat bangga bekerja, tetapi malu menunjukkannya
Ya, hari ini tidak semua orang bisa menghargai abstraksi yang dirancang dengan indah, khususnya ketika mereka tidak . Sesuatu dibutuhkan untuk menyenangkan mata. Ini adalah sesuatu dari lanskap prosedural. Generator sudah lama dikenal semua orang, tapi tidak untukku suara Perlin . Ternyata ada parameter yang membutuhkan seleksi empiris. Rekompilasi adalah pukulan bagi jiwa, jadi ada kebutuhan untuk GUI untuk prototyping. Pencarian menghasilkan perpustakaan ImGui yang brilian. Dengan itu, parameter numerik, warna, mode tampilan, kustomisasi adalah kesenangan. Hasil generator yang dihasilkan
Sedikit kabut
Kabut ditampilkan pada ketinggian tertentu dengan saturasi yang diberikan dalam shader fragmen menggunakan fungsi yang dipilih secara empiris. Jika perlu, Anda dapat menambahkan beberapa lapisan kabut dengan parameter Anda sendiri, termasuk warna. Contoh lanskap sebelum dan sesudah menerapkan simulasi kabut:
Saat ketika algoritma diperlukan
Ya itu benar. Kedua kalinya dalam 5 tahun. Ini tentang menemukan jalur antara dua titik di hadapan rintangan, karena unit darat tidak dapat bergerak di sekitar pegunungan! Algoritma A * datang untuk menyelamatkan. Pseudocode mengambil dari sini . Implementasi membutuhkan profiling dan optimisasi, serta banyak tempat lain, namun, dalam versi saat ini, unit melewati rintangan, jika jalur ada sama sekali. Di suatu tempat pada saat itu gagasan permainan mulai terbentuk.
Ruang kita adalah ...
Gagasan kerja yang akan berkembang adalah penjelajahan planet ini oleh para pelopor. Penciptaan bio-, atmosfer- dan, akhirnya, ekosfer. Saya akan memberi contoh. Pada awalnya, kehidupan hanya akan mungkin di dalam kubah yang dibuat secara artifisial, yang di dalamnya dimungkinkan untuk menumbuhkan makhluk hidup: tanaman, hewan. Mereka, pada gilirannya, akan mempengaruhi lanskap. Berikut ini adalah contoh kubah dan lanskap di bawahnya melalui iterasi N dan M, N <M.
Tentang Mercator, Bumi dan Politik
Pemandangan datar sudah menjadi sesuatu, tetapi hanya salah satu pemandangan di planet ini. Dari sudut pandang saya, jauh lebih menarik untuk melihat tubuh kosmik yang lebih nyata. Waktu kartografi!
Jika persegi panjang tidak bisa ditarik bola tanpa distorsi, saya curiga, maka jumlah metode tampilan menjadi wahyu. Proyeksi Mercator yang paling umum memiliki masalah dengan tampilan di kutub dan sangat mendistorsi proporsi ketika bergerak menjauh dari khatulistiwa. Sedemikian rupa sehingga tampaknya bahwa Federasi Rusia lebih besar dari Afrika, dan Amerika Serikat - Australia.
Ternyata, ukuran distorsi juga dapat dihitung secara analitis. Secara kasar, sebuah lingkaran di pesawat menjadi elips di bola dan sebaliknya. Tugasnya adalah sebagai berikut: menambahkan tampilan benda berbentuk bola ke tampilan datar. Oleh karena itu masalah - jenis mana yang harus dipilih untuk yang utama, dan yang akan ditampilkan dengan distorsi. Diputuskan untuk menampilkan tampilan datar tanpa distorsi sebagai tampilan yang memungkinkan lebih banyak operasi, termasuk memilih dan memindahkan unit. Pandangan benda bulat ditinggalkan untuk operasi dengan pesawat terbang, misalnya, satelit buatan. Sebagai tampilan, proyeksi stereografi Gall digunakan sebagai salah satu kompromi. Distorsi dihitung menggunakan elips distorsi, mereka juga merupakan Tisso indicatrix. Sebagai hasilnya, Anda dapat melihat yang berikut ini: tangkapan layar menunjukkan pandangan planet ini sebagai benda bulat dengan dua kubah, yang satu memberi makan dua sumber energi, yang lain - satu sumber.
Modul Perangkat Lunak dan Siklus Pengembangan
Tugas minimum pada tahap "Haruskah saya mulai?" Adalah sebagai berikut: untuk berevolusi dari yang sederhana menjadi kompleks dan indah sepanjang tahun. Sangat mudah untuk merasa jijik dalam beberapa minggu dari cinta proyek. Saya punya lima alasan untuk ini:
- Alasan pertama adalah kodenya. Tanpa dukungan untuk arsitektur waras dan refactoring, sebagian besar waktu akan menjadi perbaikan bug, tapi apa kesenangannya?
- Konsentrasi yang tidak memadai pada satu. Terlibat dalam algoritma satu jam, satu jam - model di Blender, saya tidak bisa mencapai tujuannya.
- Konsentrasi berlebihan. Setelah terlibat dalam mesin dan algoritma untuk waktu yang lama, gambarnya tidak berubah dan sepertinya tidak ada kemajuan.
- Kesulitan dalam menguasai alat. Kekayaan antarmuka Blender atau API OpenGl menginspirasi rasa hormat, jika tidak takut. Mungkin perlu beberapa hari dari awal hingga bukti konsep pertama, yang merupakan pukulan moral.
- Harapan yang tinggi dan ketidaksiapan untuk kegagalan. Terkadang sulit untuk mengabaikan pendekatan "Desain, implementasi, dan tidak kembali" demi "Prototipe / Implementasi / Penyempurnaan Antarmuka"
Menjadi juara TDD, saya harus mengatakan bahwa saya tidak melihat kemungkinan menerapkannya dengan persentase R&D. Saya akan senang jika Anda, pembaca yang budiman, beri saya alasan untuk ragu.
Saat ini, bidang pengembangan berikut telah menonjol:
- Merancang model dalam Blender.
- Implementasi algoritma dan matematika, misalnya, A * atau Perlin Noise.
- Pengembangan bagian "mesin". Ini dipahami, misalnya, sebagai generator medan atau mengimpor model dari Blender.
- Pengembangan modul yang bertanggung jawab untuk rendering.
- Pengembangan logika game. Itu mengharuskan dia menggunakan mesin dan modul rendering.
- Refactoring
Rencana termasuk pemisahan modul 2-5 di tingkat perpustakaan dengan fasad di masing-masing. Salah satu alasan yang mungkin: menambahkan fungsionalitas kontrol kamera memerlukan kompilasi cascading sejumlah besar kode sumber.
Latihan menunjukkan bahwa ternyata bekerja secara produktif jika Anda fokus pada satu area selama 5-10 jam. Kurang - fokus hilang, lebih banyak - mata kabur.
Secara berkala, untuk mencapai tujuan, saya melihat kemungkinan untuk melanggar beberapa aturan perkembangan normal, asalkan tempat pelanggaran ditandai dan waktu dialokasikan untuk refactoring. Yang terakhir terjadi setiap 7-10 hari. Contoh: untuk sementara membuat variabel global. Saya akan menyingkirkan mereka dengan meneruskannya ke konstruktor / metode selama refactoring, yang akan membantu membedakan kelas dengan konektivitas rendah dan gearing tinggi. Apa yang akan memerlukan putaran baru refactoring. Keuntungan dari pendekatan ini:
- Kesediaan untuk mengimplementasikan ide-ide baru. Penolakan yang lama.
- Kemampuan untuk mengembangkan antarmuka.
Cons:
- Refactoring mungkin tertunda.
- Saya melihat dukungan yang tidak realistis untuk tes unit / tiruan.
- Beberapa mengatasi kesulitan dalam Vim. Mengapa Vim jika itu menambah kontra? Lalu apa kelebihannya bagi saya lebih.
Untuk dilanjutkan
Terima kasih atas perhatian Anda pada postingan saya yang sederhana! Semua kode ada di sini . Selain tugas-tugas yang dijelaskan di atas, butuh banyak waktu untuk berkenalan dengan Blender, kustomisasi vim dan refactoring di dalamnya. Jika itu setidaknya sedikit menarik, silakan tulis. Saya dapat membahas sesuatu secara lebih rinci di salah satu tulisan berikut. Video dengan detail implementasi sedikit lebih banyak ada di sini .