In che modo lo sviluppo del gioco è diverso dallo sviluppo di altri software? [chiuso]

18

Per un solido sviluppatore di software per scopi generici, cosa c'è di diverso nello sviluppo del gioco, fondamentalmente o solo differenze di grado?

Ho fatto giochi giocattolo come Tic-tac-toe, Tetris e un risolutore di sudoku a forza bruta (con interfaccia utente) e ora sto intraprendendo un progetto di medie dimensioni (di medie dimensioni per essere un singolo sviluppatore e non avere fatto molti giochi) e una cosa che ho trovato in questo particolare progetto è che la separazione delle preoccupazioni è molto più difficile poiché tutto influenza lo stato e ogni oggetto può interagire con ogni altro oggetto in una miriade di modi.

Finora sono riuscito a mantenere il codice ragionevolmente pulito per la mia soddisfazione, ma trovo che mantenere il codice pulito in giochi non banali sia molto più difficile di quanto non lo sia per il mio lavoro quotidiano.

Il gioco a cui sto lavorando è a turni e la grafica sarà abbastanza semplice (basata sul web, principalmente attraverso la manipolazione del DOM), quindi il tempo reale e il lavoro in 3d non sono realmente applicabili a me, ma lo sarei comunque interessato a risposte su quelle se sono interessanti. Principalmente interessato alla logica generale del gioco.

PS Sentiti libero di ripagare questo, non sono davvero sicuro di quali tag siano applicabili.

game-design

— Davy8
fonte

23

C'è una grande differenza. Secondo me, è l'unica differenza che conta davvero.

Possiamo andare oltre i dettagli tecnici del perché è diverso, certo. Motori 3D, fisica delle particelle, molte cose diverse entrano in gioco.

Ma molte diverse forme di software hanno delle stringhe collegate. Il software di modellazione deve fare molte delle stesse cose. Ogni pezzo di software significativo ha una libreria specializzata che deve usare.

Quindi cosa rende GAMES diversi?

Eccolo: il software è progettato per soddisfare un'esigenza aziendale. Vuoi un sistema di inventario? Puoi definire quali tipi di oggetti devi gestire. È possibile definire ciò che si desidera per la pianificazione della produzione. Puoi fare tutto questo. Oppure, se si desidera un software bancario, è possibile definire cosa si desidera fare con esso.

Con i giochi, le tue esigenze aziendali sono "divertenti". Prova a scrivere una specifica tecnica per "divertimento".

Questo, secondo la mia modesta opinione come sviluppatore, è ciò che rende i giochi diversi dal normale software. Semplicemente non puoi dire "Fantastico! Questo software ora è completo come da richieste del cliente!" perché tutto ciò che vogliono fare è divertirsi.

Detto questo, non hai bisogno di grafica 3D e fisica stravagante per qualcosa di divertente. Perché le persone giocano ancora a Tetris? La sua fisica consiste in "sposta blocco verso il basso" "non lasciare che il blocco esca dai limiti" e "ferma blocco quando colpisce qualcosa", e mentre nel corso degli anni ci sono state numerose versioni, alcune con una grafica più elaborata di altre, ma il la linea di fondo è - è divertente !!

Quindi, se vuoi essere un grande sviluppatore di giochi, non buttare via ciò che hai imparato come normale sviluppatore di software. È ancora roba molto utile. E @Sion ha ragione a separare i componenti, proprio come faresti con un normale software. Ma la singola caratteristica più importante che puoi aggiungere al tuo gioco è divertente. Fun fun fun fun fun. Ecco perché esiste lo sviluppo del gioco, questo è quello che ti serve per rendere il tuo gioco di successo. E fidati di me per quanto divertente sia giocare, almeno 10 volte più divertente da fare !!

Buona fortuna con il tuo game-dev'ing !! : D

— Corsika
fonte

2

Se si scambia "divertimento" con "utile", penso che si verifichi lo stesso problema con la progettazione di un prodotto (anziché scrivere software per un client). Suppongo che ci sia una differenza di grado però. Le persone a volte hanno torto su ciò che sarebbe utile, di solito sono all'oscuro di ciò che li rende "divertenti". (+1 però)

— Davy8,

1

Ci fu una famigerata sentenza della corte suprema riguardante l'industria cinematografica per adulti e ciò che classificò "hardcore" negli anni '60. La giustizia ha detto "Non potrei mai riuscire a [definirlo] ma lo so quando lo vedo." Penso che lo stesso si possa dire per divertimento. Voglio dire, posso annotare le cose che mi piacciono dei giochi, ma spesso mi ritrovo a giocare e chiedermi "Cosa rende questo divertente?" (Ovviamente voglio sapere in modo da poterlo ricreare in uno dei miei giochi !!) Le persone non sanno cosa rende divertente qualcosa, ma sicuramente sanno quando l'hanno trovato!

— corsiKa

mi è piaciuto molto questo post. Hai ragione. Mi piace molto lo sviluppo di giochi, ma non ho davvero in me lo scopo di vedere cosa è "divertente" per le persone "normali". Il che ha avuto l'effetto di creare solo giochi che piacciono a me e ad altri criminali come me :)

— Phil

1

@Phil e va bene. Se sai cosa ti diverte, devi ricordare che ci sono solo duecento archetipi di personaggi in questo mondo. Guarda intorno al tuo posto di lavoro e abbina le personalità dei tuoi colleghi a quelle con cui sei andato al liceo o al college. Scoprirai che molti di essi possono essere abbinati. Quindi, se qualcosa è divertente per te, probabilmente sarà divertente per più persone di quanto pensi. Il trucco è far loro conoscere il gioco in modo che possano divertirsi!

— corsiKa

Questa è la migliore risposta che ho visto finora. Ci sono tonnellate di articoli per idee di nicchia nel settore del software e così via, ma non molti sullo sviluppo di giochi. Hmmmm.

— Johnny,

21

Sono principalmente uno sviluppatore di giochi e non uno sviluppatore di software tradizionale, ma penso che ci siano diverse differenze chiave.

Queste sono ovviamente diverse generalizzazioni e non complete:
team più grandi. Background più vari (artisti, programmatori, produttori, con ognuno c'è ancora più variazione). Cicli di sviluppo più lunghi. Standard di prestazione più elevati. Più ampia scala di progetti. Rischio di fallimento più grande e più costoso. Ambiente più stressante.

Per quanto riguarda le interazioni con gli oggetti e il layout della tua architettura, puoi comunque disaccoppiare correttamente i sistemi. Gli oggetti di gioco e il comportamento avranno chiaramente dipendenze reciproche e su questi sistemi. Questa è la natura del gioco (gioco di parole), combina tutti questi sistemi in un'unica unità coesa e non c'è nulla di sbagliato in questo. Potrebbe sembrare così perché la scala di tutto è più grande di quella a cui sei abituato.

Alcuni sistemi facilmente identificabili e segregati?

Rilevazione di collisioni
Risposta alla collisione
Fisica
Animazione
Grafica (2D e 3D)
Intelligenza artificiale
Input dell'utente
File Input / Output
Networking

— Sion Sheevok
fonte

+1 per una buona risposta alla domanda, anche se per il mio gioco particolare non ho a che fare con la maggior parte di quelli (a turni e a tessere, quindi nessuna vera collisione, nessuna fisica, la grafica è composta da folletti e lancia più JQuery a questo, 2 giocatori, quindi non ho ancora un'intelligenza artificiale, l'input dell'utente è gestito in modo per lo più RESTOSO che copre anche l'aspetto della rete) Non sono del tutto sicuro di cosa intendi per File IO, a parte il dire che salvare / caricare un gioco tipi di IO sono necessari nei giochi tipici?

— Davy8,

4

Sono d'accordo con la maggior parte di questo post e ottengo un +1 da parte mia, ma vorrei mettere in discussione la linea "rischio più grande e più costoso di fallimento". Se lavori per una banca, una grande azienda manifatturiera o un sito Web a traffico molto elevato, il tuo errore può essere misurato in centinaia di migliaia al minuto di inattività a seguito di un errore. In un'ora, potresti perdere (in vendite perse, clienti persi, ecc.) Più di alcuni negozi di videogiochi per mesi del totale del libro paga. Non sto dicendo che non può essere grande, sto solo dicendo che non sono convinto che sia più grande del software tradizionale.

— corsiKa

@glowcoder So cosa stai dicendo, ma penso di capire anche il punto che Sion sta cercando di chiarire, che con i giochi in generale o l'intero progetto è un successo o è un fallimento, e di solito è un fattore di ciò che hai menzionato nella tua risposta : è divertente? È possibile eseguire correzioni rapide per i bug, ma non è possibile correggere a caldo una mancanza di divertimento.

— Davy8,

3

Non sono affatto convinto che le "squadre più grandi" siano vere anche come generalizzazione. Certo, i giochi AAA hanno grandi squadre, ma lo stesso vale per i prodotti software non di gioco equivalenti alla complessità. Vasti numeri di giochi sono prodotti da singoli o team di due o tre persone.

— Peter Taylor,

@ Davy8 oh, se solo il successo commerciale di un gioco fosse proporzionale a quanto è divertente. :)

— tenpn

2

Non penso che la programmazione dei giochi sia diversa da quella di altri domini applicativi dal punto di vista della difficoltà a scegliere la giusta separazione delle preoccupazioni. Ogni volta che porti le tue abilità in un diverso tipo di dominio applicativo, scoprirai che la transizione non è agevole come speravi perché ci sono sempre differenze. Ciò che ha funzionato nella tua applicazione di database ha molti schemi / modi di dire che non funzionano così bene nella tua app incorporata, che ha molti schemi / modi di dire che non funzionano così bene in quel sistema in tempo reale che ha anche molti schemi / modi di dire che non funziona nella programmazione del gioco. Tuttavia, i programmatori di giochi hanno gli stessi problemi quando escono dal dominio di programmazione del gioco. È solo una questione di ciò a cui sei abituato.

Detto questo, penso che la programmazione del gioco sembri più difficile per molte persone perché richiede di lavorare con parti del computer che la maggior parte dei programmatori non deve mai affrontare nel loro vero lavoro (grafica e suoni di basso livello) e più matematica applicata di molte altre le persone si sentono a proprio agio e non a causa della separazione delle preoccupazioni. Mentre ci sono sempre difficoltà a determinare la scelta giusta per la separazione delle preoccupazioni, penso che la difficoltà con la separazione delle preoccupazioni che stai vivendo si stia semplicemente spostando in un nuovo dominio problematico. Una volta create alcune applicazioni, sarà come qualsiasi altra cosa, imparerai ciò che ti piace e non utilizzerai ciò che non fai.

— inzuppare
fonte

0

e una cosa che ho scoperto con questo particolare progetto è che la separazione delle preoccupazioni è molto più difficile poiché tutto influenza lo stato e ogni oggetto può interagire con ogni altro oggetto in una miriade di modi.

Penso che tu abbia una risposta lì, ci sono molte interazioni. Ho realizzato alcuni giochi con XNA (C #), ora sto facendo un gioco di medie dimensioni come dici tu, un gioco di simulazione di strategia, ci sto lavorando da quasi 2 mesi e lo faccio da solo senza aiuto, quindi devo mantenere il mio codice semplice. Un'enorme differenza, penso, è capire e progettare alcune classi per la funzionalità e altre per il disegno, questo aiuta e rende il tuo programma più pulito. Naturalmente, se stai facendo un gioco devi avere più risorse, come immagini (2d o 3d) e musica (o suoni). Quindi ci sono differenze, penso che sia più difficile, ma è molto divertente.

— Zukki
fonte

0

Penso che la programmazione dei giochi sia più divertente. Puoi testare costantemente il tuo gioco, implementare una fisica diversa, che si traduce in comportamenti diversi.

Dalla mia esperienza, la programmazione dei giochi è in realtà molto più divertente rispetto allo sviluppo del software. Nello sviluppo del software hai alcune regole aziendali da rispettare, diventa poco noioso. Stai creando un software, non è divertente. L'uso del software è fantastico, utile, utile, ma non divertente.

I giochi sono divertenti. Forse sono solo io, ma trovo lo sviluppo di giochi molto più intrigante ed eccitante rispetto allo sviluppo di software tradizionale, indipendentemente dall'uso degli strumenti.

PS: Uso gli strumenti più recenti per lo sviluppo di software, HTML5, Asp.Net, C #, ecc. Trovo ancora DirectX, UDK, XNA, Unity più divertenti da codificare.

— harsimranb
fonte