Also so sieht mein Code bisher aus, nun möchte ich wie in Pokemon einer nicht geringen Anzahl von "Monstern" Stats geben, zum Beispiel Lebenspunkte/Geschwindigkeit etc.

Nun möchte ich aber 1. so eine Art Grundstat-Datei haben und 2. eine Level-Up-Datei die jedes einzelne Viech anders erscheinen lässt.

Natürlich könnte ich aus einer Text-Datei lesen, möchte es gerne aber aus einer Resourcen-Datei(falls dies die richtige Art ist) machen.

Eine andere Lösung wäre vielleicht auch für jedes Viech eine einzelne Datei anzulegen, denn allein schon für ein Viech ist das vielleicht 10 Zeilen an Variablen.

Außerdem soll es möglich sein das selbe Viech mehrmals zu besitzen, und damit die dann nicht komplett gleich sind sollen die Daten Variabel sein.
Muss man hier bei der Speicherung der Eigenschaften noch einen rng dranbauen oder kann man diesen rng auch direkt in der Datendatei einbauen?

Danke schonmal!

funktioniert, aber in dem Fall greift man auf die switch-case-Anweisung zurück.

Zu deiner Frage, dass du ein "Viech" mehrmals allerdings mit varibalen Daten benutzen sind, leg dir eine Klasse "Viech" an. Deine verschiedenen Attribute packst du dann am besten noch in Strukturen.

Die Infos würde ich tabellarisch in einer .txt-Datei speichern, sodass du beim auslesen immer genau weißt, wo welches Attribut zu finden ist. Dementsprechend musst du einen eindeutigen "Spaltentrenner" benutzen, z. B. dieses Zeichen: "|"

MfG

Natürlich könnte ich aus einer Text-Datei lesen, möchte es gerne aber aus einer Resourcen-Datei(falls dies die richtige Art ist) machen.

...

Muss man hier bei der Speicherung der Eigenschaften noch einen rng dranbauen oder kann man diesen rng auch direkt in der Datendatei einbauen?

Was ist denn - Deiner Meinung nach - der Unterschied zwischen einer Text-Datei und einer Resourcen-Datei?
Und was ist ein 'rng'?

if         (choice == "a")
               {
                         cout << "Gut! Du besitzt nun Basic-Fire-Mon!\n";
                         xmon = 1;
               }
               else if (choice == "b")
               {
                         cout << "Gut! Du besitzt nun Basic-Water-Mon!\n";
                         xmon = 2;
               }
               else if (choice == "c")
               {
                         cout << "Gut! Du besitzt nun Basic-Plant-Mon!\n";
                         xmon = 3;
               }
               else
               {
                         cout << "Bitte benutze die richtige Taste!\n";
               }

funktioniert, aber in dem Fall greift man auf die switch-case-Anweisung zurück.

Dann aber nicht mit std::string

@sinnlos123: um Objekte eindeutig zu machen, greift man auf "Identität" zurück, d.h. man vergibt jedem Objekt einen eineindeutigen Identifier (z.B. ein laufender Zähler oder eine GUID)

Und ob du eine Textdatei oder Ressource benutzt oder sogar die Daten fest im Programm implementierst, ist ja ersteinmal egal - hauptsache du überlegst dir entsprechende Klassen und Strukturen, welche diese Daten dann speichern und bearbeiten können.

Und versuche gleich von Anfang an Ein-/Ausgabe und Spiellogik voneinander zu trennen, dann wird der Code übersichtlicher und besser wartbar.

um Objekte eindeutig zu machen, greift man auf "Identität" zurück, d.h. man vergibt jedem Objekt einen eineindeutigen Identifier (z.B. ein laufender Zähler oder eine GUID)

Oder man nimmt die Adresse.

@Th69: was wäre denn eine gute Trennung des i/o und der Spiellogik?(nur vom Konzept her mein ich)

Ich habe jetzt nur auf die schnelle das gefunden

It is important to cleanly separate input/output from (game) logic and from data.
Instead of having Scanners and System.out.println all over the place, put them in a separate package with separate classes and have the data and logic classes only return (method return values) and accept (method parameters) values.
This way you can easily switch from a text based interface to a graphical interface later on.

Ist es das warum ich diese Trennung lieber machen sollte oder gibt es noch andere Vorzüge?

Es ist einfach eines der Grundprinzipien der (objektorientierten) Programmierung: Single-Responsibility-Prinzip (d.h. Klassen und Funktionen sollten nur jeweils eine Aufgabe übernehmen - also keine Vermischung von Zuständigkeiten).

PS: Weitere Prinzipien finden sich unter dem Begriff SOLID