Gioco di programmazione - la comunicazione tra oggetti di gioco in 2D

Question

Recentemente ho cercato la mia mano a codifica di un gioco in C #. Non sto usando XNA per questo, come ho pensato di imparare di più se ho codificato il gioco da zero (anche se sto usando un motore multimediale).

Sto cercando di progettare un gioco RPG in 2D - un po 'ambizioso, lo so, ma ho un ragionevolmente ben comprendere almeno delle parti fondamentali del gioco (cioè il codice 'piastra della caldaia'), e ho raggiunto una parte in cui non so dove andare da qui.

Nel gioco in 2D, si procede nel gioco tramite camminare 'aree' intorno diverse. Una volta che si colpisce un 'tegola portale', verrete trasportati alla prossima area ecc.

Non riesco a capire come questi oggetti zona dovrebbe essere istituito. Questa era la mia prima idea: Ogni zona ha alcune strutture di raccolta differenti (ad esempio, un quadtree visibilità, un quadtree collisione, un'entità AI List, ecc). Quindi, se dovessi aggiungere un entità nemica nel gioco, sarebbe messo in quadtree visibilità, il quadtree collisione (perché si può entrare in collisione con le entità) e la lista entità AI. Quando l'area riceve una richiesta di aggiornamento, racconta ciascuna di queste strutture per aggiornare se stessi, che a loro volta dicono le entità per aggiornare se stessi. Tutto bene, finora.

La mia domanda è questa: cosa succede se questo nemico ha bisogno di comunicare con gli altri oggetti? Ad esempio, potrebbe aver bisogno di sapere se il giocatore era in un certo intervallo di esso. O se era stato colpito dal giocatore. O dove tutti gli oggetti collidable sono nella zona (in modo che possa pathfind).

Il primo (e cattivi) soluzione a questo problema sarebbe semplicemente passare ciascuna entità un riferimento ad ogni collezione. Ma ciò incoraggia ovviamente oggetti strettamente accoppiati, che non è buono.

La seconda soluzione mi è venuta è stata per ogni entità di essere in grado di interrogare l'area, tramite strutture di messaggi. Così un nemico sarebbe in grado di dire "Dammi un elenco di ogni entità a breve distanza X della mia posizione" e la zona sarebbe tornato una risposta. Tuttavia, questo potrebbe ottenere sempre più difficile, come avrei dovuto codice più e più possibilità nella zona ( "Datemi un elenco degli enti che non sono facilmente raggiungibili a X di me stesso", "Datemi un elenco di tutte le entità con la salute inferiore X", ecc).

Quello che sto cercando è un tempo collaudato soluzione a questo problema di comunicazione tra l'oggetto, e in fondo come impostare una zona. Suppongo che avrebbe bisogno di un qualche tipo di sistema di messaggistica e, anche se non sono sicuro.

Grazie per la lettura.

Answer 1

Si potrebbe esaminare la mediatore modello . Sarebbe consentono di avere un accoppiamento basso, ma sì, è farebbe avere un sacco di codice nell'oggetto mediatore (s) per facilitare la comunicazione tra gli altri oggetti. Ma penso che sia l'uno o l'altro. E poi questo è preferibile. Sarebbe anche consentire una maggiore libertà di fare i trucchi, come fare la fila alcune richieste di aggiornamento e gestire le richieste a volte più opportuno, o per fare l'elaborazione in batch di un sacco di richieste invece fare uno per uno che sarebbe (ipoteticamente) imporre una sorta di spese generali.

Answer 2

Credo che la soluzione migliore per questo genere di cose è quello di utilizzare molto il pattern Observer ... creare eventi (decidere come generico o calcestruzzo è un altro decission progettazione) e fare i vostri oggetti di iscriversi a quelle di cui hanno bisogno.

Ad esempio, il motore può generare eventi collission o di prossimità quando 2 entità sono vicino, ma quelli saranno ricevuti solo dai soggetti che sono interessati. È possibile fare alcune ottimizzazioni per controllare solo quelle condizioni con gli osservatori suscribed.

Non so se questo è il posto comune nei giochi e non ho mai effettivamente utilizzato in qualsiasi gioco (ancora), ma ho pensato un sacco di volte su di esso ed è l'opzione che mi piace di più.

Answer 3

Bene un'aproach potrebbe essere quella di impostare un architettura client / server. Quindi il server potrebbe gestire tutti gli aggiornamenti mondo del gioco e logica interna e il cliente sarebbe solo chiedere al server se si può fare determinate azioni. Il server quindi rispondere e il client sarebbe solo allora disegnare e aggiornare la schermata di gioco. entità non giocatore avrebbe fatto lo stesso. L'unica differenza sarebbe il cliente è controllato umana e le altre entità sono controllati computer. Ciò a consentire di separare la configurazione mondo di gioco e gli eventi e gli aggiornamenti da logica entità.

Il "sistema di segnalazione" lei ha citato è chiamato il protocollo di applicazione e può essere un sistema complesso esoterica binario, o semplici stringhe leggibili che consiglio. Come il giocatore muove il server invierà un elenco degli enti che sono all'interno di vista del cliente. entità non giocatore avrebbe operare nello stesso modo. Cioè chiedendo al server per il permesso di fare le cose, o per informazioni su un altro soggetto che il server in precedenza inviato mentre si muoveva su e è entrato in vista dell'entità, e il server risponde con la risposta o informazioni appropriate.

Se si dovesse perseguire questo obiettivo con i socket si avrebbe la ovviamente vantaggio di gioco in rete intrinseca come il server non importa se il cliente fosse collega sulla stessa macchina server è in esecuzione o se il cliente è in tutto il continente. Questo può non aver risposto alla tua domanda in particolare con il codice ma spero che fosse almeno uno spunto di riflessione.

Answer 4

Questo è di solito molto più facile se si dispone di un oggetto sopra l'entità facendo la gestione. (Ad es. Il 'mondo' o il 'gioco'.) Si può vedere facilmente quali entità sono in prossimità di cui gli altri e inviare gli eventi e le notifiche di conseguenza.

Se le entità hanno bisogno di un po 'più di contesto per prendere le decisioni significative quando sono in fase di aggiornamento, si può sempre avere il pass mondo in quel contesto in qualche forma. Ma lasciare che il mondo a gestire il partizionamento e il posizionamento delle entità piuttosto che dover entità di cui preoccuparsi che direttamente.

(Inoltre, perché un quadtree? Per un 2D rpg una griglia grossolana sarebbe probabilmente molto più semplice da implementare e ugualmente utile.)