Sono in pre-produzione su un gioco di strategia e sto cercando di determinare se il gameplay principale sarà divertente. Una buona tecnica per determinare questo è di ridurre il gioco al minimo prodotto praticabile (MVP) e vedere se è divertente. Se l'MVP non è divertente, nessuna quantità di contenuti o funzionalità extra lo renderà divertente.

Sto avendo difficoltà a determinare l'MVP per un gioco di strategia poiché sono un po 'troppo avanti tra le erbacce per vedere quali delle molte caratteristiche di design sono la meccanica di base e quali non sono necessarie.

A puro titolo di esempio, diciamo solo che StarCraft2 è il gioco di strategia che voglio realizzare. Quale sarebbe l'MVP per SC2 per dimostrare che il suo gameplay principale è divertente?

La strategia in tempo reale è un genere che combina in realtà più giochi in uno. Hai un gioco di gestione (gestione delle risorse e ordini di costruzione), un gioco di puzzle (costruzione di una base con un layout funzionale ma facile da difendere), due diversi tipi di giochi di esplorazione (esplorare la mappa ed esplorare quali unità battono quali altre unità), e un gioco di tattiche (controllo delle tue unità in battaglia). Ovviamente non puoi creare tutti questi cinque giochi contemporaneamente, quindi dovresti solo concentrarti su uno di essi all'inizio.

In questa risposta mi sto concentrando su due di questi giochi che considero più essenziali per il genere: il controllo dell'unità e la costruzione di basi.

MVP di controllo dell'unità

1. Crea un oggetto di gioco "tank" controllato dal giocatore (rappresentato come un cubo non strutturato) su un piano vuoto che si sposta in una nuova posizione quando il giocatore fa clic lì.
2. Aggiungi bersagli AI immobili (rappresentati da un cubo di colore diverso) che vengono eliminati quando i loro HP scendono sotto lo 0 e la capacità del carro armato di sparare sul bersaglio più vicino per ridurre i suoi HP.
3. Aggiungi la possibilità per i bersagli di riprendersi quando il carro armato del giocatore è a portata.

Ora hai una strategia / puzzle game giocabile: sposta il tuo carro armato da un bersaglio all'altro in modo che non combatta più di uno alla volta e li distrugga tutti prima che venga distrutto. Questo è fondamentalmente il modo in cui attacchi una base con torrette difensive in un gioco RTS.

Prossimi passi da perseguire in nessun ordine particolare:

• Aggiungi una semplice IA agli avversari in modo che possano muoversi e non solo sparare indietro
• Aggiungi più unità giocatore da controllare e l'interfaccia utente per la selezione delle unità
• Aggiungi edifici (vedi "Base Building MVP" per i dettagli)
• Aggiungi più tipi di unità con diversi range, punti di forza e punti ferita
• Aggiungi terreno bloccante alla mappa e trova il percorso all'unità AI in modo che possano navigare intorno ad esso.
• Sostituisci le unità con una grafica adeguatamente animata
• Aggiungi condizioni di vittoria e sconfitta

Edificio base MVP

1. Crea un piano vuoto e consenti al giocatore di posizionare un edificio su quel piano facendo clic
2. Aggiungi diversi tipi di edifici e un'interfaccia utente che consente al giocatore di scegliere quale edificio costruire
3. Aggiungi tempi di costruzione e contatori di risorse
4. Aggiungi edifici che creano risorse a intervalli regolari (non implementerei ancora unità di lavoro perché richiedono troppa programmazione AI per funzionare) e un set di regole per quando puoi costruire quale edificio ("puoi costruire una fabbrica solo quando hai almeno una caserma finita ").

Ora hai implementato i primi minuti di un gioco Starcraft: capire l'ordine di costruzione ideale per ottenere gli edifici che desideri il più velocemente possibile.

In effetti potresti rimanere qui e lucidarlo e hai un semplice gioco di gestione delle risorse. Ma se sei ancora sicuro di voler creare un RTS, i passaggi successivi non sarebbero in ordine particolare:

• Aggiungi un'intelligenza artificiale che costruisce i propri edifici
• Aggiungi elementi del terreno che impediscono la costruzione di edifici (o sono un requisito per il posizionamento di determinati edifici, come "le fattorie possono essere costruite solo su terreni fertili")
• Aggiungi unità mobili (vedi "Controllo unità MVP" per i dettagli) che possono distruggere gli edifici nemici
• Aggiungi lavori di costruzione a singoli edifici che possono essere avviati, richiedono un certo tempo per essere completati e possono essere interrotti dal giocatore.
• Crea tipi di edifici che interagiscono tra loro in qualche modo (in Starcraft, ad esempio, sarebbero addon terrestri o tralicci Protoss)

Non vedo l'ora di giocare al tuo gioco.

Quale sarebbe l'MVP per SC2 ...?

Se la risposta fosse generalmente nota, non pensi che ci sarebbe molta più concorrenza su SC2 là fuori? SC2 è il prodotto di innumerevoli ore di decisioni progettuali; ogni patch rilasciata a SC1, il progetto iniziale di SC1, le lezioni da WC e WC2 che sono state introdotte nel design di SC1 e così via.

Il design del gioco non è una scienza esatta. Il design del gioco funziona con infinite possibilità. Certo, ci sono funzionalità abbastanza standard in RTS, ma la domanda qui non è Cos'è un RTS per tutti? perché tutti non stanno costruendo il tuo gioco, lo sei. Quindi è piuttosto, che cos'è un RTS per te? (e perché?)

Analizzare il lavoro degli altri è importante; ma iniziare sul tuo lavoro è molto più importante. La ricerca è importante; ma non lasciarti impantanare. Inizia a creare divertimento.

MVP è un'idea geniale, ma ti manca lo spirito: gli MVP riguardano la prototipazione attiva delle tue idee, non il pensare troppo al tuo e al lavoro di tutti gli altri. Sporcarsi le mani è più importante che preoccuparsi di quali siano le presunte meccaniche minime per un RTS. Molti giochi possono essere considerati RTS che esulano ampiamente dalla normale definizione di quel genere. Ottieni una demo e chiedi alle persone di giocarci; e che decideranno se il prodotto è vitale, così come genere.

Sono un po 'troppo lontano tra le erbacce per vedere

Fino a quando non inizi la prototipazione, sarà così e molte domande rimarranno difficili da rispondere.

Alcuni aspetti, direi, sono abbastanza facili da decidere di cosa hai bisogno per un RTS in generale. A seconda del tuo concetto, hai bisogno di una "unità", che può essere costruita, ordinata o il gioco inizia con essa.

A partire da Starcraft come esempio, implementa forse un'unità di lavoro, un edificio e un'unità di combattimento. Il tuo edificio dovrebbe essere in grado di costruirli entrambi. In generale, non aggiungerei nemmeno una risorsa per il raccolto, ma poiché Starcraft dipende fortemente da esso, in tal caso dovresti farlo.

La parte difficile è quali funzioni sono necessarie per implementare pure. La tua unità combattente deve essere in grado di "combattere". Quindi può sparare? può attaccare in cc? Quali sono i nemici? Hai bisogno di più unità diverse (ad es. Aria?)

Sì, dovresti iniziare solo con una gara, quindi in pratica hai solo partite a specchio per così dire. Inoltre, non hai bisogno di una mappa (se ciò non ostacola alcuna caratteristica molto importante), solo un quadrato per andare avanti. Qual è l'obiettivo? Distruzione del nemico o punti vittoria, controllo dei punti di cattura?

Penso che il problema con RTS sia che in sostanza hai così tante caratteristiche importanti ed elementi di base che devi ancora implementare per avere un MVP, mentre è davvero difficile dire quali siano gli elementi chiave dei tuoi giochi.

A mio avviso, si tratta di confrontare il tuo gioco di base con altri RTS, e ce ne sono molti, e anche continuato in un sequel, non sono gli stessi.

• Serie C&C Tiberium e Red Alert: a partire dall'edificio principale, costruisci edifici per menu senza un'unità di costruzione, costruisci unità nel menu quando esiste l'edificio corrispondente, diversi tipi di singole unità (a piedi, veicoli terrestri o aerei)
• Dawn of War 1 & 3, Company of Heroes: edificio base con unità bulding, nessuna raccolta di risorse attiva (generazione passiva mediante punti di controllo), la maggior parte delle unità sono basate su gruppi
• Battlefleet Gothic: niente edifici, niente risorse, diversi tipi di unità, non sostituibili, le abilità sono estremamente importanti

Tutte queste differenze rendono gli RTS così diversi. Cercare di sminuire un gioco con queste basi è decisamente più complicato dell'esempio del credito extra fornito con i giochi di corse: blocchi accelerati, collisioni, tutto qui.

Ciò che rende unico il tuo gioco

Il motivo principale per lo sviluppo di un MVP è che puoi testare la tua idea in anticipo e rilasciarla se necessario. Cioè, ti assicuri di finire sempre lo sviluppo con un "qualcosa", piuttosto che un nulla.

Tuttavia, ciò non significa semplicemente realizzare la versione più semplice di un RTS. Significa realizzare la versione più semplice del tuo RTS.

Capire esattamente quali caratteristiche e risorse sono necessarie è un'arte stessa. Tuttavia, il tuo obiettivo dovrebbe essere quello di ridurre al minimo la ricostruzione di cose che sai funzionare e di includere tutte le cose che non conosci. Cioè, dovresti includere solo cose che sono generiche per altri giochi - se ne hai bisogno per testare correttamente le tue idee specifiche:

• Hai bisogno di un'IA sofisticata? (Per un MVP di un livello, potresti cavartela solo con un ordine di costruzione fisso che l'opposizione usa sempre.)

• Hai bisogno di più di una fazione? (Forse il tuo gioco si concentra sulla sinergia tra due razze e questa è la chiave. Ma forse in realtà è solo un "bello da avere")

• Devi avere unità di costruzione e risorse? (Forse tutto ciò di cui hai bisogno è una scena di battaglia prefabbricata con un determinato numero di unità, forse tutte le tue idee chiave sono in realtà focalizzate sul lato abilità e tattica delle cose)

• Devi avere un multiplayer? (Se lo scopo del gioco è quello di fare un MMORTS da 6000 giocatori; allora sì, probabilmente lo fai)

Questo ovviamente include anche risorse artistiche:

• Ne hai davvero bisogno per funzionare in 3D? (forse hai caratteristiche del terreno non pianeggianti)

• Hai davvero bisogno di più modelli di personaggi? (forse lo fai, forse ogni unità ha una storia personale e questo è importante per te)

• Hai davvero bisogno di icone per l'albero tecnologico? (di nuovo, forse hai idee per innovare l'interfaccia utente per i giochi RTS e questo è il tuo punto di forza).

Ma ancora; vuoi includere solo le cose di cui hai bisogno e lasciare tutto ciò che non hai per una data successiva.

Il principio MVP non sempre funziona bene con un RTS, perché è la gestalt di tutte le tue scelte di design a renderlo divertente, ma ci sono alcuni punti chiave che puoi puntare quando capisci cosa rende divertente un RTS.

Le regole generali per rendere divertente un RTS sono:

1- Rendi possibili quante più tattiche possibili. Le tattiche META dovrebbero richiedere l'uso di più tipi di unità insieme.

Ciò richiede un elenco svuotato delle classi di unità tra cui scegliere con le loro abilità speciali finali per essere in grado di testare, ma non è necessario ogni tipo di unità. Una classe di unità è un'unità che svolge un ruolo generale nel tuo esercito e / o ha un'abilità speciale. Se il tuo piano prevede che ogni fazione abbia unità simili con skin diverse e statistiche leggermente modificate, crea una fazione. Se ogni fazione avrà diversi livelli di alcune delle loro unità che sono solo versioni migliorate l'una dell'altra, crea un livello di quell'unità. Se ogni fazione ha un set unico di unità, potrebbe essere necessario costruirle tutte. Basta essere consapevoli del fatto che si desidera testare quante più classi possibile all'inizio, perché l'aggiunta di nuove classi in seguito può compromettere completamente l'equilibrio del gioco.

2- Modifica le tattiche META man mano che il gioco procede. Questo può essere fatto introducendo nuove unità nel tempo o modificando le circostanze delle tue battaglie.

Proprio come il n. 1, questo può richiedere un elenco di classi di unità per lo più costruito, ma si tratta più di come testare il tuo MVP. Il tuo MVP dovrebbe essere in grado di limitare quali unità sono a tua disposizione in modo da poter assicurarti che i primi livelli siano ancora divertenti senza tutto il contenuto del gioco finale per eliminarlo.

3- Bilancia il tempo necessario per gestire la tua base con la guerra. Un errore comune con i giochi RTS è la scarsa automazione di base, il che significa che la tua produzione va all'inferno se devi smettere di controllare una battaglia.

Ciò richiede un sistema economico completamente svuotato da testare. Un test MVP con 5 tipi di edifici può giocare bene, ma un prodotto finale con 30 edifici potrebbe impantanare il giocatore con compiti economici e costringerti a rivisitare il tavolo da disegno su come gestire / automatizzare la tua economia. La scelta migliore qui è quella di rendere tutti i tuoi edifici che prevedi di avere in modo da poter avere un'idea di come si sente una base a grandezza naturale. Qui il meglio che puoi fare è tenere a bada la grafica di fantasia fino a quando la tua economia non sarà finalizzata.

4- Fai in modo che l'ambiente influenzi le tue scelte tattiche.

È qui che i test MVP ti daranno il massimo beneficio. L'aggiunta di fattori ambientali come vantaggi di altura, fianchi, armi speciali, truppe morali, condizioni meteorologiche e vari livelli di paesaggi aperti hanno entrambi il potenziale maggiore per distinguere il tuo gioco e renderlo più divertente o rovinare completamente l'esperienza perché hai creato le tue missioni notturne sono così oscure che i giocatori si sentono frustrati ogni volta che devono giocarne una. Puoi fare questi test abbastanza presto prima di avere un elenco completo di unità o economia; quindi, questo sarebbe effettivamente il mio primo obiettivo di test. Inoltre, sapendo quali ambienti dovranno affrontare le tue unità parleranno molto di come devi progettarle e bilanciarle. E'

Non tutti i generi sono favorevoli a un "prodotto minimamente praticabile". O almeno, non allo stesso modo e non raggiungeranno lo stesso scopo.

Prendi in considerazione un platform 2D basato su livelli. Un MVP per una cosa del genere riguarda principalmente la ricerca di buone meccaniche di salto. Non puoi cambiare la fisica del salto del tuo personaggio una volta che inizi a progettare livelli, quindi devi inchiodarlo presto. Quindi scegli un po 'di fisica salta, costruisci un paio di livelli di test e scopri quali tipi di fisica si sentono bene. Provi anche alcuni meccanici, come lanciare alcuni nemici e capire come vuoi che funzioni, e / o terreno specializzato e abilità (trasportare oggetti, ecc.).

La fine di quel processo è quello che sarebbe considerato l'MVP.

Un RTS non lo fa davvero. O almeno, mai davvero ferma . Ogni aspetto di un RTS si nutre di altri aspetti di esso. Mentre è vero che ci sono alcune cose che non cambiate oltre un certo punto dello sviluppo, lo sviluppo complessivo è molto più fluido. Ecco un esempio

Verso la fine dello sviluppo di StarCraft I, Blizzard ha apportato quello che considererei un bel cambiamento sconvolgente. Nelle build precedenti, ogni edificio Zerg che rendeva disponibili le unità produceva la propria larva, che veniva utilizzata solo per produrre quelle unità. Fondamentalmente, in quella build, la larva era una forma alternativa di accodamento delle unità. Questo è stato cambiato nel meccanico che conosciamo oggi lo Zerg: tutte le unità Zerg provengono da larve prodotte in una struttura centrale.

Quello cambia fondamentalmente cambiato la natura dello Zerg come razza. Per altre gare, il passaggio da una tecnologia all'altra (cambiare l'edificio principale che produce edifici) è un processo che richiede un investimento sostanziale. Per Zerg, devi solo buttare giù un edificio e l'intera infrastruttura di produzione può costruirli.

Ma questo ha alimentato la dinamica di Zerg in termini di design dell'unità. Vedi, gli Zerg di SC1 erano fondamentalmente costruiti attorno a tre unità fondamentali: Zerglings, Hydralisks e Mutalisks. Queste sono le tue unità di base e tutto il resto è essenzialmente un'unità di supporto per loro. Quindi Zerg non cambia tecnologia come le altre razze; aggiungono qualche X in più alla loro composizione dell'esercito esistente. I grandi interruttori tecnologici per lo Zerg riguardavano principalmente l'unità fondamentale su cui è costruito il nucleo del tuo esercito.

Ogni elemento di design alimenta l'altro. Se si modifica il modello di produzione, ora è necessario modificare il design dell'unità per compensare.

Un "prodotto minimamente praticabile" per un RTS non funziona in generale; tutte le meccaniche di un RTS interagiscono in troppi modi perché un prodotto "minimale" sia qualcosa di più che, essenzialmente, un gioco completo.

Quindi suggerirei di creare un RTS su piccola scala come MVP. Un RTS completo . Non ha bisogno di tutta la grafica lì, ma ha bisogno di tutte le cose che un RTS possiede effettivamente. Sarà in grado di servire la funzione di un MVP: capire come fare per creare il gioco che vuoi realizzare.

Ci sono diverse risposte qui su misura per gli RTS, ma volevo sottolineare qualcosa che è universale al concetto di un prodotto minimamente vitale (MVP).

MVP è un concetto che esiste da molto tempo, ma è diventato molto popolare quando lo sviluppo Agile è salito sulla scena. Il concetto è abbastanza semplice nel suo nucleo: è il prodotto più piccolo che è "abbastanza buono". Questo è tutto.

Ciò che rende difficile MVP è che è soggettivo e dipendente dal contesto. Se stai lavorando alle ultime pietre miliari di un contratto militare, MVP non è altro che "il prodotto supera i test di qualifica". La qualificazione del tuo prodotto comporterà la verifica di ogni singolo requisito stabilito per te all'inizio del contratto (forse anni fa). A dir poco qualificabile come MVP.

All'inizio di un progetto, MVP è una barra molto più bassa (meno male!). Tuttavia, è anche ancora soggettivo. Quello che penso sia il prodotto minimo come sviluppatore è molto diverso da quello del proprietario del prodotto, e comunque diverso da quello che potrebbe pensare il vicepresidente della mia azienda. Devi scegliere quale prospettiva dell'attore stai usando quando definisci un MVP.

La voce più critica, secondo me, è quella della persona che gestisce risorse limitate: il tuo tempo e il tuo denaro. In una società, potrebbe essere un capo progetto o qualcuno in finanza. Potrebbe essere un vicepresidente. Se sei una piccola compagnia indipendente o qualcuno che sta scrivendo giochi da solo, quella persona potresti essere tu . Ma tu non sei il normale sviluppatore di giochi . E 'il te che chiude gli strumenti di codifica e software art e tira su Excel per assicurarsi la possibilità di pagare le bollette di questo mese. È tu che devi soppesare l'equilibrio tra passare un'altra notte a programmare il tuo piccolo progetto di passione piuttosto che uscire con gli amici.

Dato che stiamo parlando di piccoli MVP (questo è ciò di cui parlava il video che hai collegato), possiamo iniziare a utilizzare l'approccio di Agile al concetto. Lo direi così:

L'MVP per ogni iterazione / sprint / fase è il prodotto minimo che giustifica la spesa di risorse nel tempo impiegato a costruire quel prodotto.

Questa definizione è il motivo per cui la definizione militare di MVP che ho usato prima è valida: per loro, l'unica cosa che può giustificare i milioni spesi per un contratto militare è un prodotto di successo che fa tutto ciò che è stato promesso. Ma per te, potresti giustificare una settimana o un mese di tempo. La barra è più bassa.

Quindi, per questo, togliti il ​​cappello da sviluppatore, indossa l'abito e i pantaloni su misura e parliamo di cosa succederà dopo. Lo sviluppatore termina di pubblicare un prodotto. Cosa ve ne farete?

Più avanti nel processo, un'opzione sarà quella di spedirlo - per fare soldi rilasciando il gioco. E in effetti, questa è una definizione chiave di MVP che non dovrebbe mai essere ignorata. Se un prodotto può essere spedito, è un MVP candidato, perché fare soldi giustifica molte risorse di sviluppo. Ma all'inizio non lo rilascerai. Quindi il MVP è più sfumato:

Nei primi sviluppi, l'MVP è il prodotto minimo che ti consente di imparare qualcosa che vale la pena impiegare a produrlo.

Nota: questo potrebbe non essere quello che intendevi imparare. Se la cosa che impari è "questo gioco non ce la farà mai, quindi dovremmo smettere ora ... ma dannazione è valsa la pena provare a farcela", allora hai vinto. Hai fatto un po 'di lavoro e hai pensato che valesse la pena. D'altra parte, se decidi di poter giocare e pensi "dannazione, abbiamo appena sprecato quanti mesi della nostra vita?!?" allora questo è un forte suggerimento che non stavi facendo un buon lavoro limitandoti a MVP. Se ti stessi limitando a MVP correttamente, le iterazioni passate sarebbero già state considerate come un pagamento per se stessi - nessun rimpianto.

Quindi ora possiamo arrivare agli esempi che altre persone hanno scritto qui. Queste sono risposte che esplorano qual è l'importo minimo necessario per imparare qualcosa. Ma tutti mancano di un dettaglio generale: qual è la tua prossima mossa?

L'MVP dipende da cosa pensi di fare con quell'MVP una volta creato. Prendi la grande risposta di Philipp e il commento di bxk21. La risposta di Philipp sosteneva due "minigiochi", uno di controllo unità e uno di costruzione base. bxk21 ha sostenuto che quelli non sono importanti quanto l'aspetto della gestione del tempo. Quindi chi ha ragione?

Questa è una domanda trabocchetto. Hanno entrambi ragione, in determinati ambienti. Presumibilmente stai per consegnare l'MVP rilasciato ad alcuni playtester per ottenere feedback. Che tipo di playtest intendi utilizzare? Sono RTS pro? Se i tuoi playtester non sono esperti di RTS, allora la risposta di Philipp è probabilmente esatta. Stai guardando i piccoli pezzi di cemento del gioco. Avranno abbastanza background per poter commentare quel genere di cose.

Ora supponiamo che tu abbia in qualche modo dei playtester come TLO, Day [9] o MVP. Questi sono giocatori RTS di livello professionale (o nel caso del Day [9], almeno una menzione d'onore, dato che non credo che giochi professionalmente). Se questi sono i tuoi playtester, allora l'opinione di bxk21 è probabilmente quella giusta. Non si preoccuperanno dei piccoli dettagli sul fatto che tu costruisca edifici o se gli edifici si costruiscano da soli. Si preoccuperanno di cose sottili e sfumate, come la gestione del tempo e l'equilibrabilità. Ora non avrai questo tipo di cose inchiodate nei primi test, ma dovresti essere in grado di far trasparire il loro sapore . Dovresti concentrarti sulla creazione di un gioco che dimostri la sensazione che desideri che il gioco mostri ad un alto livello di abilità.

Quindi cerca di capire quale vuoi che sia la tua prossima mossa. Cosa vuoi fare con il tuo prodotto. Quindi capire qual è il tuo MVP rispetto a tale obiettivo.

La parola chiave in "Prodotto minimo praticabile" è prodotto.

Un prodotto è qualcosa per cui si paga denaro con l'aspettativa che qualcuno lo comprerà. Se la cosa che vuoi è un MVP, deve essere abbastanza buono per qualunque prezzo tu abbia in mente. Cioè, può avere una portata limitata, ma deve essere abbastanza completo da essere idoneo alla commerciabilità.

Immagino che probabilmente non vuoi davvero un MVP, perché sei nel punto in cui hai qualche idea ma non sai nemmeno se vale la pena trasformarlo in un prodotto. Sembra che quello che vuoi costruire sia una demo o qualche altro prototipo. Il modo tipico per farlo è quello di creare una singola fetta verticale del gioco che includa tutti i meccanismi che si desidera testare. In un RTS di tipo SC2, quella potrebbe essere una singola missione (se stai facendo un giocatore singolo) o una singola mappa multiplayer.