Modi per gestire la modifica dei dati dei designer insieme alla modifica dei dati dei giocatori

Ho un gioco online in cui i giocatori possono modellare il mondo in qualche modo, ad es. Gli alloggi di Ultima Online, dove puoi costruire le tue case direttamente su alcune parti della mappa del mondo. Questi sono cambiamenti che dovrebbero persistere nel tempo come parte del mondo persistente.

Allo stesso tempo, il team di progettazione sta aggiungendo nuovi contenuti e modificando i vecchi contenuti per migliorare ed estendere il gioco ai nuovi giocatori. Lo faranno prima su un server di sviluppo durante i test e poi dovranno unire il loro lavoro con il "lavoro" dei giocatori sul server live.

Supponendo di risolvere i problemi di progettazione del gioco, ad es. i giocatori possono costruire solo in aree designate, quindi non si scontrano mai geograficamente con le modifiche dei designer: quali sono i modi migliori per gestire i dati o organizzare le strutture dei dati in modo da evitare conflitti quando i dati dei nuovi designer vengono uniti a quelli dei nuovi giocatori?

Esempio 1: un giocatore crea un nuovo tipo di oggetto e il gioco gli assegna l'ID 123456. Le istanze di quell'elemento si riferiscono tutte a 123456. Ora immagina che i progettisti di giochi abbiano un sistema simile e un designer crei un nuovo oggetto anche numerato 123456. Come può essere evitato?

Esempio 2: qualcuno crea una mod popolare che dà a tutti i tuoi draghi un accento francese. Include uno script con un nuovo oggetto chiamato assignFrenchAccentche usano per assegnare le nuove risorse vocali a ciascun oggetto drago. Ma stai per distribuire il tuo DLC "Napoleon vs Smaug" che ha un oggetto con lo stesso nome: come puoi farlo senza molti problemi con il servizio clienti?

Ho pensato alle seguenti strategie:

• È possibile utilizzare 2 file / directory / database separati, ma le operazioni di lettura sono notevolmente complicate. "Mostra tutti gli elementi" deve eseguire una lettura sul DB di progettazione e una lettura sul DB di lettore (e deve comunque distinguere tra i 2, in qualche modo).
• È possibile utilizzare 2 spazi dei nomi diversi all'interno di un negozio, ad es. usare le stringhe come chiave primaria e prefissarle con "DESIGN:" o "PLAYER:", ma la creazione di questi spazi dei nomi può essere non banale e le dipendenze non sono chiare. (ad es. in un RDBMS potrebbe non essere possibile utilizzare in modo efficiente stringhe come chiavi primarie. È possibile utilizzare numeri interi e allocare tutte le chiavi primarie al di sotto di un determinato numero, ad esempio 1 milione, per essere dati di progettazione e tutto quanto sopra quel punto deve essere i dati del giocatore. Ma quelle informazioni sono invisibili all'RDBMS e i collegamenti delle chiavi esterne attraverseranno il "divario", il che significa che tutti gli strumenti e gli script devono aggirare esplicitamente.
• Puoi sempre lavorare sullo stesso database condiviso in tempo reale, ma le prestazioni potrebbero essere scadenti e il rischio di danni ai dati dei giocatori potrebbe essere migliorato. Inoltre, non si estende ai giochi eseguiti su più di 1 server con dati mondiali diversi.
• ... altre idee?

Mi viene in mente che, sebbene questo sia principalmente un problema per i giochi online, i concetti possono applicarsi anche al modding, in cui la community crea mod allo stesso tempo in cui gli sviluppatori modificano il proprio gioco. Ci sono strategie qui utilizzate per ridurre la possibilità di rottura del mod quando escono nuove patch?

Ho anche etichettato questo come "controllo della versione" perché a un livello è quello che sono: 2 rami dello sviluppo dei dati che devono essere uniti. Forse alcune intuizioni potrebbero venire da quella direzione.

EDIT: alcuni esempi aggiunti sopra per aiutare a chiarire il problema. Sto iniziando a pensare che il problema riguardi davvero lo spazio dei nomi, che potrebbe essere implementato in un negozio tramite chiavi composite. Ciò semplifica la strategia di unione, almeno. Ma potrebbero esserci delle alternative che non vedo.

Penso che le risposte che propongono soluzioni DB stiano saltando a un'implementazione specifica senza capire il problema. I database non rendono facili le fusioni, ti danno solo un framework in cui archiviare i tuoi dati. Un conflitto è ancora un conflitto anche se si trova in un DB. E il check-out è la soluzione di un uomo povero al problema: funzionerà, ma a un costo paralizzante per la tua usabilità.

Quello di cui stai parlando qui rientra nel modello di sviluppo distribuito del problema. Il primo passo, credo, non è pensare ai giocatori e ai designer come a tipi separati di creatori di contenuti. Ciò rimuove una dimensione artificiale del problema che non influisce sulla soluzione.

In effetti hai la tua linea principale: la versione canonica approvata dagli sviluppatori. Potresti (probabilmente) avere anche altre filiali: server live dove le persone stanno attivamente sviluppando e condividendo mod. Il contenuto può essere aggiunto su qualsiasi ramo. Fondamentalmente, i tuoi designer non sono niente di speciale qui - sono solo creatori di contenuti che vivono in casa (e puoi andare a trovarli e colpirli quando si rovinano).

Quindi accettare il contenuto generato dall'utente è un problema di unione standard. Devi ritirare le loro modifiche sulla linea principale, unirle, quindi estrarle di nuovo, oppure tirare le modifiche della linea principale sul loro ramo e unirle (lasciando la linea principale "pulita" delle cose generate dall'utente). Come al solito, andare al tuo ramo e sistemare lì è più amichevole che chiedere ad altre persone di apportare le modifiche e quindi provare a ripararlo da remoto alla loro estremità.

Una volta che lavori con quel tipo di modello, si applicano tutti i normali processi per evitare conflitti di unione. Alcuni dei più ovvi:

• Incoraggiare l'uso liberale di spazi dei nomi per intercettare i contenuti di un particolare autore / mod / team.
• Laddove il contenuto deve interagire, stabilire chiare convenzioni di chiamata / utilizzo, convenzioni di denominazione e altre "regole" sciolte che guidano lo sviluppo in modo che sia facile ricongiungersi. Fornire strumenti che consentano ai creatori di contenuti di sapere se stanno seguendo tali regole, idealmente integrati nella creazione stessa del contenuto.
• Fornire strumenti di reporting / analisi per individuare i probabili problemi di unione prima che si verifichino. Ripararlo dopo la fusione è probabilmente molto doloroso. Fai in modo che un determinato bit di contenuto possa essere controllato e dato tutto chiaro come pronto per l'unione, in modo che l'unione sia indolore
• Rendi robusta la tua fusione / integrazione. Consenti rollback facili. Esegui rigorosi test sui contenuti uniti: se falliscono i test, non unirli! Scorri i loro contenuti o i tuoi fino a quando l'unione procederà in modo pulito.
• Evita di utilizzare gli ID interi incrementali per qualsiasi cosa (non hai un modo affidabile di distribuirli ai creatori). Funziona solo in un DB perché il DB stesso è un provider canonico di ID in modo da non ottenere duplicati; tuttavia introduce anche un singolo punto di errore / carico nel sistema.
• Usa invece i GUID: costano di più per l'archiviazione, ma sono specifici della macchina e quindi non causeranno collisioni. In alternativa, utilizzare identificatori di stringhe, questo è molto più facile da debug / risolvere, ma più costoso per l'archiviazione e il confronto.

Conserva tutto come un attributo (o decoratore) - con punti di montaggio. Prendiamo una casa che il giocatore ha progettato come esempio:

o House: { Type = 105 } // Simple square cottage.
 o Mount point: South Wall:
  o Doodad: Chair { Displacement = 10cm }
   o Mount point: Seat:
    o Doodad: Pot Plant { Displacement = 0cm, Flower = Posies } // Work with me here :)
 o Mount point: North Wall:
  o Doodad: Table { Displacement = 1m }
    o Mount point: Left Edge:
     o Doodad: Food Bowl { Displacement = 20cm, Food = Meatballs}

Quindi ogni entità può avere uno o più punti di montaggio - ogni punto di montaggio può accettare zero o più altri componenti. Questi dati verrebbero archiviati con la versione in cui sono stati salvati, insieme a tutte le proprietà pertinenti (come Displacement ecc. Nel mio esempio) - NoSQL probabilmente si adatterebbe molto bene qui (Key = ID entità, Valore = Binario serializzato Dati).

Ogni componente dovrebbe quindi essere in grado di "aggiornare" i vecchi dati da una versione precedente (non rimuovere mai i campi dai dati serializzati - solo "null") - questo aggiornamento avviene nel momento in cui viene caricato (verrebbe quindi immediatamente archiviato nuovamente in l'ultima versione disponibile). Diciamo che la nostra casa ha cambiato le sue dimensioni. Il codice di aggiornamento determinerebbe relativamente la distanza tra le pareti nord e sud e altererebbe proporzionalmente gli spostamenti di tutte le entità contenute. Come altro esempio, la nostra ciotola di carne potrebbe aver rimosso il campo "Cibo" e ottenere invece una "Varietà" (Carne) e "Ricetta" (Palline). Lo script di aggiornamento trasformerebbe "Meat Balls" in "Meat", "Balls". Ogni componente dovrebbe inoltre sapere come gestire le modifiche ai punti di montaggio, ad es

Tutto ciò lascia esattamente un problema aperto: cosa succede se due oggetti si scontrano tra loro (non il loro contenitore - i punti di montaggio ti proteggono da quello)? Dopo un aggiornamento, dovresti controllare le collisioni e tentare di risolverle (spostando le cose a parte, un po 'come SAT). Se non riesci a capire come risolvere la collisione, rimuovi uno degli oggetti e mettilo in una riserva - dove possono acquistare questi oggetti rimossi (gratuitamente) o venderli (a prezzo pieno); e ovviamente avvisare il giocatore che l'aggiornamento ha interrotto parte del loro layout, possibilmente con una funzione di "zoom in" in modo che possano vedere il problema.

Alla fine dovresti lasciare cambiamenti complessi nelle mani dei giocatori (fallire velocemente) poiché nessun algoritmo può rendere conto dell'estetica - dovresti semplicemente essere in grado di fornire al giocatore il contesto di dove si trovava l'oggetto (in modo che possano ricordare, non solo atterrare con tutti questi oggetti nella loro scorta e non sapere dove fossero).

Sto cercando di associare questo a qualcosa che capisco, quindi sto pensando in termini di Minecraft in questo momento. Sto immaginando un server live con i giocatori che apportano modifiche in tempo reale mentre gli sviluppatori sono in esecuzione su un server di prova che corregge / crea nuovo contenuto.

La tua domanda sembra quasi 2 domande uniche:

1. Come assicurare che gli ID oggetto siano univoci
2. Come assicurarsi che gli spazi dei nomi degli script non si scontrino

Vorrei provare a risolvere il n. 1 attraverso un sistema di riferimento temporaneo. Ad esempio, quando un nuovo oggetto viene creato da qualcuno, potrebbe essere contrassegnato come volatile o temporaneo. Immagino che tutti i nuovi contenuti creati sul server di prova vengano contrassegnati come volatili (sebbene possa anche fare riferimento a contenuti non volatili).

Quando sei pronto a portare nuovi contenuti sul server live, il tuo processo di importazione trova gli oggetti volatili e assegna loro gli ID degli oggetti del server live che sono impostati su pietra. Ciò è diverso dall'importazione / unione diretta poiché è necessario poter fare riferimento a oggetti non volatili esistenti nel caso in cui sia necessario correggerli o aggiornarli.

Per il n. 2, sembra che tu abbia davvero bisogno di avere un certo livello di trasmutazione intermedia degli script che può eseguire l'hashing del nome della funzione in un unico spazio dei nomi. vale a dire

assignFrenchAccent

diventa

_Z11assignFrenchAccent

Se i file per i dati sono di testo anziché binari e designer e lettori stanno modificando aree diverse, è possibile provare a unire SVN.

Penso che un database / filesystem replicato in ambienti con una procedura di "check-out" sarebbe il migliore.

Pertanto, ogni volta che un designer desidera apportare alcune modifiche al mondo, verificherebbe / bloccherebbe tutte le risorse che desidera creare / modificare su tutte le copie del database (sviluppo e produzione), quindi nessun altro giocatore o designer potrebbe modificarlo . Avrebbe quindi lavorato sul database di sviluppo fino al completamento del nuovo progetto, e in quel momento le modifiche sarebbero state unite al database di produzione e tali risorse sarebbero state archiviate / sbloccate in tutti gli ambienti.

Le modifiche del lettore funzionerebbero più o meno allo stesso modo, tranne che i ruoli di database / filesystem sarebbero invertiti: funzionano sul database di produzione e tutti gli aggiornamenti vengono caricati su dev al termine.

Il blocco delle risorse può essere limitato alle proprietà in cui si desidera garantire l'assenza di conflitti: nell'esempio 1, si bloccherebbe ID 123456non appena il giocatore inizia a crearlo, quindi agli sviluppatori non verrà assegnato quell'ID. Nell'esempio 2 i tuoi sviluppatori avrebbero bloccato il nome dello scriptassignFrenchAccent durante lo sviluppo, quindi il giocatore avrebbe dovuto scegliere un nome diverso durante lo sviluppo della sua modifica (quel piccolo fastidio può essere ridotto con lo spazio dei nomi, ma che da solo non eviterà conflitti a meno che tu non dia utente / sviluppatore di uno spazio dei nomi specifico, quindi avrai lo stesso problema con la gestione degli spazi dei nomi). Ciò significa che tutto lo sviluppo dovrebbe leggere da un singolo database online, ma in questi esempi tutto ciò di cui hai bisogno da quel database sono i nomi degli oggetti, quindi le prestazioni non dovrebbero essere un problema.

In termini di implementazione, avere una sola tabella con tutte le chiavi e lo stato delle risorse (disponibile, bloccato da dev, bloccato da prod) sincronizzato / accessibile in tempo reale tra gli ambienti dovrebbe essere sufficiente. Una soluzione più complessa implementerebbe un sistema di controllo versione completo: puoi usare un sistema esistente come CVS o SVN se le tue risorse sono tutte in un filesystem.

Penso che il punto qui sia accettare chiaramente la tua responsabilità. 1) Il server dice ciò che è attualmente accettabile e l'API con cui accedere. Il database è in fase di modifica, secondo alcune regole. 2) I creatori possono creare contenuti, ma devono essere riproducibili dopo gli aggiornamenti. Questa è puramente una tua responsabilità: qualsiasi aggiornamento deve essere in grado di analizzare le vecchie strutture di dati preferibilmente il più semplice e pulito possibile.

L'idea del mount point ha dei vantaggi se sei interessato a tenere traccia di oggetti e posizioni unici all'interno di una struttura malleabile, specialmente se accettiamo che l'intera struttura "domestica" di un giocatore subirà un cambiamento drammatico, e vuoi mantenerlo piccoli oggetti decorativi nei rispettivi armadietti.

È un problema enormemente complicato, buona fortuna! Probabilmente non esiste una risposta.

Non penso che questo abbia un grosso problema mentre lo stai facendo.

Vorrei solo sovrascrivere le mod create dall'utente, con un avvertimento in cui si noti che "Mod X potrebbe non funzionare correttamente con questa versione", lasciando ai creatori di mod il compito di cambiare il loro lavoro. Non penso che questa sia un'aspettativa non realistica che gli aggiornamenti potrebbero disabilitare alcune mod.

Lo stesso vale per i contenuti creati dall'utente, basta fare un backup e sovrascrivere.

Non ho esperienza reale in questo, sto solo dando suggerimenti.