Fabrikklassenaufbau

Werbeanzeige

Paddy

Frischling

Beiträge: 15

Wohnort: Essen

21.11.2006, 02:37

Fabrikklassenaufbau

Hi,

ich will in meinem Game eine "Fabrikklasse" einfügen.
Diese soll quasi mit einem Rezept versehen werden und wenn in der Fabrik genügend Rohstoffe sind, dann kann man über eine Member, z.B.
Fabrik::createIdem(ItemID) das Item dann erstellen.

Mir erschließt sich aber grade nicht ganz wie ich die Rezepte aus ner sagen wir mal Skriptdatei in vererbbare Klassen konvertieren soll.

Meine Überlegung wäre, dass ich die Rezeptklasse etwa so aufbaue:
class Rezept
{
Zielprodukt; //Bezeichner Fertiges Produkt
BinäreListeZutaten; //Bezeichner der Zutaten, Menge
FähigkeitenEndprodukt;
minSkilllevel;
Herstellungszeit;
}
Diese könnte ich dann in die Fabriklasse laden und mit nem Fabrik::ZutatenTest() vor dem create vergleichen.

Was haltet ihr von dem Ansatz?
Hat einer einen besseren/dynamischeren Ansatz?

Zum Seitenanfang

rklaffehn

Treue Seele

Beiträge: 267

Wohnort: Braunschweig

21.11.2006, 07:00

Re: Fabrikklassenaufbau

Zitat von »"Paddy"«

ich will in meinem Game eine "Fabrikklasse" einfügen.

Oops. Für einen Moment dachte ich ans Factory Pattern, aber du meinst wohl eher etwas konkreteres.

Zitat

Diese soll quasi mit einem Rezept versehen werden und wenn in der Fabrik genügend Rohstoffe sind, dann kann man über eine Member, z.B.
Fabrik::createIdem(ItemID) das Item dann erstellen.

Klingt gut. ItemID wäre dann wohl eine festgelegte ID für ein zu produzierenedes Objekt (sowohl "physisch" als auch im Sinne eines Objektes einer Klasse). Du brauchst natürlich auch C++ Objekte zu deinen Zielprodukten.

"createItem" sollte ausserdem das erzeugte Objekt zurückliefern.

Zitat

Mir erschließt sich aber grade nicht ganz wie ich die Rezepte aus ner sagen wir mal Skriptdatei in vererbbare Klassen konvertieren soll.

Automatisch geht das auch nicht. Du brauchst in jedem Fall eine vorher definierte Klasse, die ein Interface mitbringt, das mit allen deinen Rezepten klarkommt und die dann den Inhalt aus deiner Skriptdatei lesen und für das Programm präsentieren kann.

Du musst ganz klar vorher definieren, welche Zutaten es überhaupt gibt und noch wichtiger, welche Zielprodukte (siehe oben).

Als Format für die Rezepte wäre XML sicher geeignet, weil du deinen Vorschlag damit gut realisieren kannst.

Zitat

Hat einer einen besseren/dynamischeren Ansatz?

Wenn die Interfaces deiner Rezept und Produkt Klasse gut sind, ist das schon ein ziemlich dynamischer Ansatz. Du solltest nur darauf achten, dass du nicht in die Bedrouille kommst, wenn du mal eine neue Zutat oder ein neues Zielprodukt einbauen willst. Ganz ohne programmieren kommt man da nicht aus, aber man kann versuchen, sich das Leben einfacher zu machen.

Gruss,
Rainer

God is real... unless declared integer.
http://www.boincstats.com/signature/user_967277_banner.gif

Zum Seitenanfang

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

21.11.2006, 09:58

Hmm warum sollte man nicht allgemeine Klassen programmieren können, die alle Zutaten und Rezepte dynamisch laden kann? Die Gesamte Menge aller Produkte und Zutaten (Produkte können ja wiederum Zutaten für andere Produkte sein Eisen->Schraube->Maschine) würde ich allgemein in einer Klasse lagern die folgende Sachen speichert:
-Name
-Wert
-Lagerplatzverbrauch

Die Fabrikation(Rezepte) können ja so aussehen:
-Name
-eine map die, die benötigen Zutaten der benötigen Menge zuordnet
-die Menge die an Produkten pro zyklus raus kommt
-Produktionszeit

Lagerklasse:
-Speichert die gesamte Menge aller Produkte/Zutaten(also nur welche Produkte/ Zutaten überhaupt existieren)
-Speichert zu jedem Produkt/Zutat die Lagermenge
- viell. noch die Lagergröße

Die Idee mit dem XML ist gut, jedoch muss man da ein wenig aufpassen, wegen der Zuordnungen:

eine mögliche korrekte Darstellung in einer XML Datei

Quellcode

<WiSi>
  <RES>
    <EISEN/>
    <KOHLE/>
    <STAHL/>
  </RES>
  <REZEPT>
    <STAHLFABRIK>
      <PRODUKT>STAHL</PRODUKT> //Man könnte auch mehrere Produkte mit einfacher Wiederholung des PRODUKT Tags realisieren
      <PRODUKTIONSMENGE> 1 </PRODUKTIONSMENGE>
      <PRODUKTIONSZEIT> 50 </PRODUKTIONSZEIT>
      <EISEN> 3 </EISEN> //Die verbrauchte Menge
      <KOHL> 10 </KOHL> //Hier sieht mein ein Problem von XML KOHL wird er nicht finden, da er nur KOHLE kennt
    </STAHLFABRIK>
  </REZEPT>

Das wäre nur eine Idee und jetzt nur so nebenher geschrieben, aber mit diesen Entwurf sollte man jederzeit neue Produkte und Rezepte hinzufügen können ohne was ändern zu müssen.

PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Zum Seitenanfang

Osram

Alter Hase

Beiträge: 889

Wohnort: Weissenthurm

Beruf: SW Entwickler

21.11.2006, 11:10

Sagen wir die Fabrik kann Konservendosen, Autos und natürlich :lol: auch Flugzeuge herstellen, dann ist die erste Frage willst Du eine Klasse pro Produkt oder eine einzige für die Herstellungsprozedur. Paddy scheint von mehreren auszugehen, Nox von einer.

Ich votiere auch für eine. Du kannst ja immer noch Dosen, Auto und Flugzeugklassen haben, die dann eben auf ein Herstellungsobjekt verweisen:

	C-/C++-Quelltext
1 2 3 4 5 6 7	class HerstellungsProzedur; class Flugzeug { Geschwindigkeit MaxGeschwindigkeit, StallGeschwindigkeit; [...] static class HerstellungsProzedur *Prozedur; }

etc. Du solltest auch ein Array mit allen HerstellungsProzeduren haben, sodass Du z.B. dem Spieler auswählen lassen kannst, was er machen will.

Die "class HerstellungsProzedur;" kannst Du im wesentlichen auf zwei Wegen machen, je nach Anforderungen:
- Du hast immer ein festes Verhältniss von der erzeugten Menge zur verbrauchten Menge an Rohstoffen. Z.B. ist das in Gothic 3 in der Alchemy so; ein Heiltrank kostet immer genau (ausm Kopf) eine Heilpflanze, ein "Vial" und 1 x Wasser. Das bedeutet verschiedene produkte unterscheiden sich nur in Zahlen (Daten), nicht im Algorithmus. Die "class HerstellungsProzedur" hat also eine Menge Membervariablen, es gibt für jedes produkt ein Objekt dieser Klasse und am Anfang liesst Du die Zahlen aus einer (z.B eben XML) Datei.
- Es muss die Möglichkeit geben verschiedene Algorithmen zu nehmen, z.B. ein Auto kann wenn keine Kugellager mehr da sind Walzenlager nehmen. Entweder machst Du für jeden möglichen Algorithmus eine C++ Klasse oder wenn Du es dem Level Designer etc offen halten willst, schlage ich vor Du baust einen vorhandenen Parser ein, z.B. muParser :
http://www.codeproject.com/cpp/FastMathParser.asp
Ist aber für ein kleines Projekt wahrscheinlich overkill.

"Games are algorithmic entertainment."

Zum Seitenanfang

Paddy

Frischling

Beiträge: 15

Wohnort: Essen

21.11.2006, 14:41

Wow...erst mal danke für die Antworten...hätte nicht mit so einer Resonanz gerechnet.

Also der Ansatz soll mehr sein, dass alle Objekte, die im Inventory oder vergleichbaren gelagert sind eigentlich nur als als Listeneintrag (ItemID, Pic, Menge,Anwendungsmöglichkeiten in der Inventory gespeichert werden. Die entsprechende Klasse wird erst bei Benutzung des Objektes erstellt.

So ähnlich kann dann in meinem Ansatz die Fabrikklasse auch aufgebaut werden.
Für jeden Fabriktyp gibt es also eine Skiptdatei/Liste in der die Rezepte stehen, die eine Fabrik annimmt. So wäre dann eine Klasse für die Produktion von allen Gegenständen da...quasi eine ACME-Klasse.

Auf diese Weise kann einer Fabrik nachträglich ein Gegenstand zur Produktion zugeordnet werden, der eigentlich für eine andere gedacht war.
(Flugzeugfabrik und Autofabrik bekommen beide ein "Flugauto" zur Herstellbarkeit zugewiesen).

Also die Liste der Items die verfügbar sind wird ein Binärer Baum. So sind die Dinger immer und schnell verfügbar. Wenn eine Fabrikklasse erstellt wird, dann werden über die ItemID alle Sachen aus dem Baum ausgelesen, die für die Fabrik verfügbar sein sollen und an die Fabrikliste angehängt.

Zu der Stahlklasse:
Das Rezept ist etwas umständlich
<rezepte>
<stahl>
<eisen>3</eisen>
<kohle>10</kohle>
<prodout>1</prodout>
<prodtime>50</prodtime>
<usages>
<schmiedbar>5</schmiedbar> //ab welchem level und dass schmiedbar
<korodiert>5</korodiert> //Geschwindigkeit des Rostens
</usages>
</stahl>
<Rosenstrauß>...
<usages>
<korodiert>100</korodiert>
<look>5</look> //Wie gut das aussieht oder auf Stimmung wirkt
....
</usages>
<Fahrradschlauch>...
usw
</rezepte>

So kann eine Fähigkeit/Benutzbarkeit etc per Designer gestaltet werden und nicht über Programmierung. Ob das aber ins XML-Format sollte, bin ich etwas unsicher. Der User sollte an dem System nicht herumfummeln können, also wahrscheinlich eher über ein Chunksystem aus ner Binärdatei...der Aufbau würde ja aber trotzdem gleich bleiben.