Bagaimana perkembangan game berbeda dari pengembangan perangkat lunak lain? [Tutup]

18

Untuk pengembang perangkat lunak tujuan umum yang solid, apa yang secara khusus berbeda tentang pengembangan game, baik secara mendasar atau hanya perbedaan derajat?

Saya telah melakukan permainan mainan seperti Tic-tac-toe, Tetris, dan pemecah sudoku brute-force (dengan UI) dan saya sekarang memulai proyek menengah (menengah untuk menjadi pengembang tunggal dan tidak memiliki melakukan banyak permainan) dan satu hal yang saya temukan dengan proyek khusus ini adalah bahwa pemisahan kekhawatiran jauh lebih sulit karena semuanya mempengaruhi keadaan, dan setiap objek dapat berinteraksi dengan setiap objek lainnya dalam berbagai cara.

Sejauh ini saya telah berhasil menjaga kode itu cukup bersih untuk kepuasan saya, tetapi saya menemukan bahwa menjaga kode bersih dalam permainan non-sepele jauh lebih sulit daripada untuk pekerjaan sehari-hari saya.

Gim yang sedang saya kerjakan berbasis giliran dan grafiknya akan cukup sederhana (berbasis web, sebagian besar melalui manipulasi DOM) sehingga pekerjaan waktu nyata dan 3d tidak benar-benar berlaku bagi saya, tetapi saya masih akan tertarik pada jawaban mengenai hal-hal tersebut jika itu menarik. Paling tertarik pada logika game umum.

PS Jangan ragu untuk mengulangi ini, saya tidak begitu yakin tag apa yang berlaku.

game-design

— Davy8
sumber

23

Ada satu perbedaan utama. Menurut pendapat saya, satu-satunya perbedaan yang sangat penting.

Kita bisa membahas detail teknis mengapa itu berbeda, tentu saja. Mesin 3D, fisika partikel, banyak hal berbeda ikut bermain.

Tetapi banyak bentuk perangkat lunak yang berbeda memiliki ikatan. Perangkat lunak pemodelan harus melakukan banyak hal yang sama. Setiap perangkat lunak yang signifikan memiliki beberapa perpustakaan khusus yang harus digunakan.

Jadi apa yang membuat GAMES berbeda?

Ini dia: Perangkat lunak dirancang untuk memenuhi kebutuhan bisnis. Anda menginginkan sistem inventaris? Anda dapat menentukan jenis barang apa yang harus Anda tangani. Anda dapat menentukan apa yang Anda inginkan untuk penjadwalan produksi Anda. Anda bisa melakukan semua itu. Atau jika Anda menginginkan perangkat lunak perbankan, Anda dapat menentukan apa yang ingin Anda lakukan dengannya.

Dengan permainan, kebutuhan bisnis Anda "menyenangkan". Coba tulis spesifikasi teknis untuk "kesenangan".

Itu, menurut pendapat saya sebagai pengembang, adalah yang membuat game berbeda dari perangkat lunak biasa. Anda tidak bisa mengatakan "Hebat! Perangkat lunak ini sekarang fitur lengkap sesuai permintaan klien!" karena yang ingin mereka lakukan hanyalah bersenang-senang.

Yang sedang berkata, Anda tidak perlu grafis 3d dan fisika boros untuk sesuatu yang menyenangkan. Mengapa orang masih memainkan Tetris? Fisiknya terdiri dari "pindahkan blok ke bawah" "jangan biarkan blok keluar dari batas" dan "hentikan blok ketika menyentuh sesuatu", dan sementara selama bertahun-tahun ada banyak versi, beberapa dengan grafis yang lebih bagus daripada yang lain, tetapi Intinya adalah - itu menyenangkan !!

Jadi jika Anda ingin menjadi pengembang game yang hebat, jangan membuang apa yang telah Anda pelajari sebagai pengembang perangkat lunak biasa. Itu masih sangat berguna. Dan @Sion benar dalam memisahkan komponen Anda, sama seperti yang Anda lakukan pada perangkat lunak biasa. Tetapi satu-satunya fitur paling penting yang dapat Anda tambahkan ke gim Anda menyenangkan. Fun fun, fun, menyenangkan. Karena itulah pengembangan game ada, itulah yang Anda butuhkan untuk membuat game Anda sukses. Dan percayalah pada hal ini betapapun asyiknya bermain, setidaknya 10 kali lebih menyenangkan untuk dibuat !!

Semoga sukses dengan game-dev'ing Anda !! : D

— corsiKa
sumber

2

Jika Anda menukar "bersenang-senang" dengan "berguna", saya pikir Anda mengalami masalah yang sama dengan mendesain produk (bukan menulis perangkat lunak untuk klien). Saya kira ada perbedaan dalam derajat. Orang terkadang salah tentang apa yang akan berguna, mereka biasanya tidak tahu apa yang membuat sesuatu "menyenangkan" bagi mereka. (+1 sekalipun)

— Davy8

1

Ada putusan pengadilan tertinggi terkenal tentang industri film dewasa dan apa yang diklasifikasikan "hardcore" di tahun 60-an. Pengadilan mengatakan, "Saya tidak pernah bisa berhasil dalam [mendefinisikannya] tetapi saya tahu ketika saya melihatnya." Saya pikir hal yang sama bisa dikatakan untuk bersenang-senang. Maksud saya, saya bisa mencatat hal-hal yang saya sukai dari permainan, tetapi saya sering menemukan diri saya bermain permainan dan bertanya pada diri sendiri, "Apa yang membuat ini menyenangkan?" (Jelas saya ingin tahu sehingga saya bisa membuatnya kembali di salah satu permainan saya !!) Orang tidak tahu apa yang membuat sesuatu menjadi menyenangkan, tetapi mereka pasti tahu kapan mereka menemukannya!

— corsiKa

saya benar benar menyukai postingan ini. Kamu sangat benar. Saya sangat suka pengembangan game tetapi saya tidak benar-benar memilikinya untuk melihat apa yang "menyenangkan" bagi orang-orang "biasa". Yang memiliki efek bahwa saya hanya membuat game yang saya dan beberapa loon lain sukai saya :)

— Phil

1

@ Phil dan itu baik-baik saja. Jika Anda tahu apa yang menyenangkan bagi Anda, Anda harus ingat hanya ada beberapa ratus arketipe karakter di dunia ini. Lihatlah ke sekeliling tempat kerja Anda, dan sesuaikan kepribadian rekan kerja Anda dengan orang-orang yang bersekolah di sekolah menengah atau perguruan tinggi. Anda akan menemukan sebagian besar dari mereka dapat dicocokkan. Jadi, jika sesuatu itu menyenangkan bagi Anda, itu mungkin akan menyenangkan bagi lebih banyak orang daripada yang Anda sadari. Triknya adalah membuat mereka tahu tentang permainan sehingga mereka bisa menikmatinya!

— corsiKa

Ini adalah jawaban terbaik yang pernah saya lihat sejauh ini. Ada banyak artikel untuk ide ceruk bisnis perangkat lunak dan sebagainya, tetapi tidak banyak tentang pengembangan game. Hmmmm.

— johnny

21

Saya terutama adalah pengembang game dan bukan pengembang perangkat lunak tradisional, tetapi saya pikir ada beberapa perbedaan utama.

Ini jelas beberapa generalisasi dan tidak komprehensif:
Tim yang lebih besar. Latar belakang yang lebih bervariasi (artis, programmer, produser, dengan masing-masing variasi bahkan lebih). Siklus pengembangan yang lebih lama. Standar kinerja yang lebih tinggi. Skala proyek yang lebih besar. Risiko kegagalan yang lebih besar dan lebih mahal. Lingkungan yang lebih stres.

Adapun interaksi objek dan meletakkan arsitektur Anda, Anda masih dapat memisahkan sistem dengan benar. Objek dan perilaku gameplay Anda, jelas akan memiliki ketergantungan satu sama lain dan pada sistem ini. Itu adalah sifat dari permainan itu (pun intended), itu menggabungkan semua sistem ini menjadi satu, unit kohesif, dan tidak ada yang salah dengan itu. Ini mungkin tampak begitu karena skala semua itu lebih besar daripada yang biasa Anda lakukan.

Beberapa sistem mudah diidentifikasi dan dipisahkan?

Deteksi Tabrakan
Respon Tabrakan
Fisika
Animasi
Grafik (2D dan 3D)
Kecerdasan buatan
Input Pengguna
Input / Output File
Jaringan

— Sion Sheevok
sumber

+1 untuk jawaban yang baik untuk pertanyaan itu meskipun untuk permainan khusus saya, saya tidak harus berurusan dengan sebagian besar dari mereka (berbasis giliran dan berbasis ubin sehingga tidak ada tabrakan nyata, tidak ada fisika, grafik terdiri dari sprite dan melemparkan lebih banyak JQuery itu, 2-pemain jadi belum ada AI, input pengguna ditangani dalam cara yang sebagian besar tenang yang juga mencakup aspek jaringan) Saya tidak yakin apa yang Anda maksud dengan File IO, selain mengatakan menyimpan / memuat game apa jenis IO apa yang dibutuhkan dalam gim-gim tipikal?

— Davy8

4

Saya setuju dengan sebagian besar posting ini, dan mendapat +1 dari saya, tetapi saya akan mempertanyakan garis "risiko kegagalan yang lebih besar dan lebih mahal". Jika Anda bekerja untuk bank, atau perusahaan manufaktur besar, atau situs web traffic yang sangat tinggi, kegagalan Anda dapat diukur dalam ratusan ribu per menit downtime sebagai akibat dari kegagalan. Dalam satu jam, Anda bisa kehilangan (dalam penjualan yang hilang, pelanggan yang hilang, dll) lebih dari beberapa bulan penggajian game-dev senilai gaji penuh. Saya tidak mengatakan itu tidak bisa besar, saya hanya mengatakan saya tidak yakin itu lebih besar dari perangkat lunak tradisional.

— corsiKa

@ glowcoder Saya tahu apa yang Anda katakan, tetapi saya pikir saya juga mengerti maksud yang Sion coba buat, bahwa dengan permainan umumnya seluruh proyek itu sukses atau gagal, dan biasanya merupakan faktor dari apa yang Anda sebutkan dalam jawaban Anda. : Apakah itu menyenangkan? Anda dapat melakukan hot-fix untuk bug tetapi Anda tidak bisa hot-fix karena kurang menyenangkan.

— Davy8

3

Saya sama sekali tidak yakin bahwa "tim yang lebih besar" benar bahkan sebagai generalisasi. Tentu, game AAA memiliki tim besar - tetapi begitu juga produk perangkat lunak non-game yang setara dengan kompleksitas. Sejumlah besar permainan diproduksi oleh individu atau tim yang terdiri dari dua atau tiga orang.

— Peter Taylor

@ Davy8 oh jika hanya kesuksesan komersial dari sebuah game sebanding dengan betapa menyenangkannya itu. :)

— tenpn

2

Saya tidak berpikir pemrograman game berbeda dari domain aplikasi lain dari sudut pandang itu menjadi lebih sulit untuk memilih pemisahan yang tepat dari kekhawatiran. Setiap kali Anda membawa keahlian Anda ke jenis domain aplikasi yang berbeda, Anda akan menemukan bahwa transisi tidak semulus yang Anda harapkan karena selalu ada perbedaan. Apa yang berfungsi di aplikasi basis data Anda memiliki banyak pola / idiom yang tidak berfungsi dengan baik di aplikasi tertanam Anda, yang memiliki banyak pola / idiom yang tidak bekerja dengan baik dalam sistem waktu nyata yang juga memiliki banyak pola / idiom yang tidak bekerja dalam pemrograman game. Namun, programmer game memiliki masalah yang sama ketika mereka meninggalkan domain pemrograman game mereka. Ini semua hanya masalah apa yang biasa Anda lakukan.

Dengan mengatakan itu, saya pikir pemrograman game tampaknya lebih sulit bagi banyak orang karena mengharuskan Anda untuk bekerja dengan bagian-bagian komputer yang sebagian besar programmer tidak perlu berurusan dengan pekerjaan mereka yang sebenarnya (grafis dan suara tingkat rendah) dan matematika yang lebih banyak diterapkan daripada banyak orang merasa nyaman dengan dan bukan karena pemisahan kekhawatiran. Meskipun selalu ada kesulitan dalam menentukan pilihan yang tepat untuk pemisahan masalah, saya pikir kesulitan dengan pemisahan masalah yang Anda alami hanyalah pindah ke domain masalah baru. Setelah Anda membangun beberapa aplikasi maka itu akan menjadi seperti yang lain, Anda akan belajar apa yang Anda suka dan tidak menggunakan apa yang tidak Anda sukai.

— Celup
sumber

0

dan satu hal yang saya temukan dengan proyek khusus ini adalah bahwa pemisahan kekhawatiran jauh lebih sulit karena semuanya mempengaruhi keadaan, dan setiap objek dapat berinteraksi dengan setiap objek lainnya dalam berbagai cara.

Saya pikir Anda punya jawaban di sana, ada banyak interaksi. Saya membuat beberapa game dengan XNA (C #), sekarang saya sedang melakukan game ukuran sedang seperti yang Anda katakan, sebuah game simulasi strategi, telah mengerjakannya selama hampir 2 bulan sekarang, dan saya melakukannya sendiri tanpa bantuan, jadi saya harus menjaga kode saya sederhana. Satu perbedaan besar menurut saya, adalah memahami dan mendesain beberapa kelas untuk fungsionalitas, dan lainnya untuk menggambar, ini membantu dan membuat program Anda lebih bersih. Tentu saja, jika Anda melakukan permainan, Anda harus memiliki lebih banyak sumber daya, seperti gambar (2d atau 3d) dan musik (atau suara). Jadi ada perbedaan, saya pikir ini lebih sulit, tetapi sangat lucu.

— Zukki
sumber

0

Saya pikir Pemrograman Game lebih menyenangkan. Anda dapat terus menguji game Anda, Anda menerapkan fisika yang berbeda, yang menghasilkan perilaku yang berbeda.

Dari pengalaman saya, pemrograman game sebenarnya jauh lebih menyenangkan dibandingkan dengan pengembangan perangkat lunak. Dalam pengembangan perangkat lunak Anda memiliki aturan bisnis tertentu untuk dipatuhi, itu menjadi sedikit membosankan. Anda sedang membuat perangkat lunak, itu tidak menyenangkan. Menggunakan perangkat lunak itu bagus, bermanfaat, bermanfaat, tetapi tidak menyenangkan.

Game itu menyenangkan. Mungkin itu hanya saya, tetapi saya menemukan pengembangan game jauh lebih menarik dan menyenangkan daripada pengembangan perangkat lunak tradisional, terlepas dari alat yang digunakan.

PS: Saya menggunakan alat terbaru untuk pengembangan perangkat lunak, HTML5, Asp.Net, C #, dll. Saya masih menemukan DirectX, UDK, XNA, Unity lebih menyenangkan untuk dikodekan.

— harsimranb
sumber