Come posso definire elementi nel mio gioco di ruolo come il gioco Java?

21

Sto lavorando casualmente su un gioco di tipo RPG in Java, ma ho difficoltà a capire come posso avere oggetti che possono fare molte cose diverse senza creare una classe diversa per ogni oggetto.

Ad esempio, come potrei creare un'ascia che potrebbe tagliare alberi e attaccare i mostri?

Se estendo la classe di taglio o di arma, non posso estendere l'altra classe.

Se dovessi tagliare e l'arma fosse un'interfaccia, avrò un sacco di codice duplicato quando un pugnale può anche attaccare i mostri e un'ascia diversa può tagliare gli alberi.

Spero che ci sia un modo per avere una singola classe di oggetti e caricare gli oggetti e le loro rispettive abilità da un file. Se ciò è possibile, come può essere fatto? In caso contrario, qual è il modo migliore per avere oggetti in un gioco?

java

— MESLewis
fonte

15

La risposta di Gregory Weir è la mia preferita per come strutturare le istanze degli oggetti al fine di svolgere più ruoli.

Per caricare da un file:

Innanzitutto, utilizzare YAML. YAML è un linguaggio di descrizione dei dati caratteristico; può essere analizzato relativamente rapidamente, letto e modificato dagli umani, supporta dati binari ed esistono librerie per la maggior parte dei linguaggi di programmazione, incluso Java. Questo risolve il "come posso ottenere i dati dai file negli oggetti?"

In secondo luogo, utilizzare il modello flyweight . La maggior parte dei dati letti da questi file è statica. Non cambierà per esempio ("l'ascia infligge 1d10 danno base e rompe il legno ma non la pietra" - questo è vero per tutti e cinque gli assi che un giocatore ha). Quello che in realtà leggi dai file YAML sono queste definizioni platoniche e le tue singole istanze di articoli hanno riferimenti sconosciuti (e costanti) a queste, insieme a dati per istanza come "Quante oscillazioni prima di spezzarmi?", "Il giocatore ha dato un nome personalizzato? ", e così via.

Condividendo i dati su più istanze in un singolo oggetto, si conserva molta memoria e si semplifica l'aggiornamento degli elementi senza stato di gioco persistente (salvataggio di giochi o database dei giocatori).

Quindi la struttura della tua classe è simile a:

class item - Un'istanza per articolo
- Possiede un'istanza di arma
- Possiede un'istanza di Tool
- Ha un nome personalizzato, ecc.
class Weapon - (Fino a) un'istanza per oggetto
- Is-a ItemComponent
- Si riferisce a WeaponDef
- Ha un livello di incantesimo bonus, ecc.
Strumento class - (fino a) un'istanza per articolo
- Is-a ItemComponent
- Si riferisce a ToolDef
- Ha una durata, ecc.
class WeaponDef - Un'istanza per tipo di arma
- Leggi da un file, i campi devono essere costanti.
- Ha un danno base, 1 o 2 mani, ecc.
class ToolDef - Un'istanza per tipo di strumento
- Leggi da un file, i campi devono essere costanti.
- Ha una resistenza di base, materiali che può rompersi, ecc.

— Marko Zajc
fonte

18

Il modello di progettazione Componente (non composito) è ottimo per questo scopo: http://gameprogrammingpatterns.com/component.html

Fondamentalmente, un'ascia sarebbe un'istanza della classe Item che conteneva un WeaponComponent e un ToolComponent (forse). Per verificare se qualcosa può essere usato come arma, controlla se ha un componente WeaponComponent, quindi parla con quell'istanza di WeaponComponent per ottenere le informazioni sull'arma dell'oggetto.

Il caricamento da un file è ovviamente un esercizio separato.

— Gregory Avery-Weir
fonte

E ovviamente, una volta che hai i componenti, puoi fare di nuovo buon uso delle interfacce. Il tuo tipo di ascia può implementare IChopper e IWeapon ma può quindi esporre il comportamento del componente per esso, permettendoti di riutilizzare sia il tipo che l'implementazione secondo necessità e di tagliare il test per i componenti. Se tutti gli assi hanno le stesse capacità ma statistiche diverse, allora sei d'oro. Se hai bisogno di oggetti con abilità uniche, potresti dover implementare una raccolta di componenti di gioco e fare in modo che le tue routine di aggiornamento interroghino gli oggetti per quello che possono fare attraverso quali componenti sono presenti.

— CodexArcanum,

6

@CodexArcanum: "Il tuo tipo di ascia può implementare IChopper e IWeapon ma può quindi esporre il comportamento del componente per questo" - Qual è il punto di questo? Gonfia semplicemente la tua gerarchia di classe. Il punto del modello del componente è che non hai bisogno di una classe Axe o di un'interfaccia IChopper o di un'interfaccia IWeapon, solo componenti di Chopper e Weapon concreti e un oggetto di livello superiore.

Attualmente sto lavorando a un sistema a componenti per i miei oggetti di gioco, e in realtà ho solo un grosso reclamo su come viene utilizzato il modello. Dati i componenti di Arma, Abbigliamento e Materiale di consumo, un oggetto potrebbe essere teoricamente "corrotto" in termini di oggetti che non possono essere sia armi che abbigliamento, o un abbigliamento che è anche consumabile. Logicamente un articolo può essere solo un "Componente principale", ma limitando i componenti si rompe la necessità di un sistema di componenti tutti insieme. Quindi, uno dei difetti fondamentali con un sistema altrimenti sorprendente

— Krythic,