Quali sono le maggiori insidie ​​da considerare quando si sviluppa un nuovo gioco?

In realtà ho appena iniziato a tracciare (grazie a David Young per la correzione della nomenclatura) un paio di nuovi giochi basati su Web per Facebook alcune settimane fa e sono appena stato inondato di blocchi mentali e il tempo fa schifo dal ricodificare. Sto lavorando a qualcosa di simile al gioco di ruolo a turni (Vampire Wars). Ho le competenze per codificare un gioco, ma sto cercando di ottenere i modelli di design giusti e far corrispondere il prodotto a ciò che vedo nella mia mente.

Normalmente quando costruisco un sito web mi piace "pensare nel codice" e trovo più velocemente per me cambiare il codice / HTML per modificarlo. Questo è probabilmente perché sono MOLTO a mio agio in quello che faccio e so cosa aspettarmi come ho fatto più volte. A questo punto con lo sviluppo del gioco mi ritrovo a ricominciare sulla carta (come facevo con i siti Web) e mi chiedo se questa è solo la mia mancanza di concentrazione e intuizione con la logica del gioco o se questo è un modo appropriato per esprimere i miei pensieri in anticipo della codifica.

Gradirei alcuni consigli su come attaccare correttamente questo problema e mantenermi in attività. Sto rapidamente imparando quanto differentemente un motore di gioco è da un sito Web aziendale standard! Ogni volta che riesco a mettere in atto qualcosa, mi sento solo sconclusionato e incompleto e diventa dannatamente frustrante.

estesa

Ad esempio, il motore di battaglia che mi ha dato così tanti problemi di recente prende una semplice abilità di attacco e quindi effettua un tiro casuale tra -50% e + 50% e quindi moltiplica l'abilità di attacco originale per quella percentuale. La stessa cosa viene fatta con la difesa e poi li metto in ordine per determinare se vengono fatti danni alla salute del nemico. Immagino che dovrei rendermi conto di essere sopra la mia testa quando ho iniziato a chiedermi se questo è anche il modo giusto per farlo, o se c'è anche un modo "giusto". Un grosso difetto che ho riscontrato è che due personaggi dello stesso livello possono avere diversi "tiri" in cui l'attacco è -50% e la difesa è + 50%, quindi finisco con alcune sequenze di battaglia ESTREMAMENTE lunghe in cui nessuno fa nulla. FALLIRE

Forse il mio post avrebbe dovuto chiedere link suggeriti che descrivono una semplice logica di gioco.

Fine estensione

Grazie a tutti in anticipo!

aggiungendo troppe funzionalità. Concentrati sul nucleo del gioco, costruiscilo, quindi se tutto funziona bene, aggiungi funzionalità. Le persone si concentrano troppo sull'aggiungere cose interessanti e non fare mai nulla.

Questo è un ottimo articolo su come prototipare un gioco. Dalla tua domanda sembra che ti manchi l'idea di cosa dovrebbe essere un prototipo.

Prototipazione: lo stai (probabilmente) facendo male

Blurb:

Errore n. 4: costruzione di un sistema, non di un gioco
Quando stai realizzando un prototipo, se mai ti ritrovi a lavorare su qualcosa che non fa avanzare direttamente, fermati proprio lì. Come programmatori, abbiamo la tendenza a cercare di generalizzare il nostro codice, renderlo elegante ed essere in grado di gestire ogni situazione. Troviamo che un prurito terribilmente difficile non graffi, ma dobbiamo imparare come. Mi ci sono voluti molti anni per capire che non si trattava del codice, ma del gioco che alla fine spedisci.

Non scrivere un elegante sistema di componenti di gioco, saltare completamente l'editor e cablare lo stato nel codice, evitare la follia basata sui dati, auto-analisi, XML e semplicemente codificare la cosa maledetta.

Modificare:

Sto aggiungendo questo solo per chiarire la differenza tra Prototype e Tracer Code.

Ricorda sempre: un prototipo è progettato per essere gettato via! Il codice tracer non lo è.

Il trabocchetto del prototipo

... L'approccio del codice tracciante risolve un problema diverso. Devi sapere come l'applicazione nel suo insieme si blocca. Vuoi mostrare ai tuoi utenti come funzioneranno nella pratica le interazioni e vuoi dare ai tuoi sviluppatori uno scheletro architettonico su cui appendere il codice. In questo caso, potresti costruire un tracciante che consiste in una banale implementazione dell'algoritmo di imballaggio del contenitore (forse qualcosa come primo arrivato, primo servito) e un'interfaccia utente semplice ma funzionante. Una volta che tutti i componenti dell'applicazione sono stati collegati, hai un framework per mostrare i tuoi utenti e i tuoi sviluppatori. Nel tempo, si aggiunge a questo framework con nuove funzionalità, completando le routine stub. Ma il framework rimane intatto e sai che il sistema continuerà a comportarsi come ha fatto quando il tuo primo codice tracciante è stato completato.

La distinzione è abbastanza importante da giustificare la ripetizione. Il prototipo genera codice usa e getta. Il codice del tracer è snello ma completo e fa parte dello scheletro del sistema finale. Pensa alla prototipazione come alla raccolta di ricognizione e intelligence che ha luogo prima che un singolo proiettile tracciante venga sparato.

Ulteriori informazioni sulla progettazione del codice tracer, da The Pragmatic Programmer

Proiettili e prototipi di tracer

Insidie: non separare la logica dai dati. Non testare che i tuoi dati producano i risultati desiderati.

Dal tuo commento sul post di Joe:

Vuoi che codifichi un motore di battaglia per incontri con mostri, BOOM! Ho riscritto il mio motore almeno tre volte questa settimana e non mi sento mai bene. Voglio dire, la matematica funziona, ma quando lo provo mi sento solo traballante. Ha senso?

Sembra che tu stia fondendo il motore con i dati qui. Il tuo motore di incontro dei mostri dovrebbe essere guidato dai dati. Se i dati che influiscono sul tuo equilibrio / divertimento di gioco sono errati, non dovrebbe essere necessario riscrivere completamente il tuo motore: modifica le variabili del tuo equilibrio fino a quando non ti sembra giusto.

Tuttavia, poiché le variabili di equilibrio sono talvolta interdipendenti, la modifica di una variabile in uno scenario migliore può avere un effetto notevole (negativo) su altri scenari.

Al fine di verificare che i dati appena modificati non raccolgano un sacco di altri casi, è utile tenere alcuni casi di test in giro e assicurarsi che non siano rotti dopo la modifica. Ecco un esempio ammirevolmente inventato di come lo testeresti.

TestResult TestPlayerKillsMonsterDuringAttack(PlayerStats, MonsterStats, seed)
{
   Player player(PlayerStats);
   Monster monster(MonsterStats);


EncounterEngine.SeedRNG(seed);

   while(1)
   {
     result = EncounterEngine.Attack(player, monster);
     if (result == PLAYER_DEAD)
       return TEST_FAIL;
     if (result == MONSTER_DEAD)
       return TEST_PASS;
     // result == MONSTER_DAMAGED, PLAYER_DAMAGED is expected. 
   }
}

Per esempio. Se lo chiami con PlayerStats.Level == 5 e MonsterStats.Level == 3, ti aspetteresti che alla fine il giocatore sconfigga sempre questo mostro.

Il problema qui, per quanto posso vedere, è che stai trattando la programmazione e la progettazione del gioco come lo stesso compito, quando in realtà sono compiti separati. Come suggerisci, questo non è un problema di programmazione o algoritmico (puoi codificare il sistema di battaglia nel modo che preferisci), riguarda ciò che è divertente e interessante per il giocatore.

La risposta è cercare le risorse sulla progettazione e sull'equilibrio del gioco. In realtà ci sono università che dedicano un intero programma di studi di quattro anni agli argomenti che stai sollevando, quindi è impossibile darti una risposta rapida e sporca (allo stesso modo in cui verrai probabilmente sconcertato se qualcuno dicesse " sì, ho questa idea per un gioco ma non so come programmarlo, a cosa dovrei fare attenzione? "). Ci sono libri, corsi e scritti online sul design del gioco; cercali.

La più grande trappola quando si scrivono i giochi è preoccuparsi se si stanno usando i giusti schemi di progettazione invece di scrivere semplicemente il codice per cui ci si sente bene.

Vorrei raccomandare gli articoli di Steve Pavlina sulla gestione del tempo e sull'automotivazione: http://stevepavlina.narod.ru/

Anche lui è programmatore. I suoi esperimenti sullo stile di vita hanno suscitato un certo interesse da parte dei media.