Wegen winofis Beitrag kann ich mich gerne anbieten, zu versuchen eine Art Grundformel zu bauen, das würde ich aber daheim machen, hab da aber schon was in kopf. Ich weiß zwar nicht, ob das eine Ähnlichkeit mit dem realen Wirtschaftssystem zu tun hat und es wäre ziemlich einfach zu manipulieren, aber ne Formel bauen wäre kein problem
Sky Entwicklung der Preise im Adminshop
- Ersteller ixAkuma
- Erstellt am
Huhu,
habe den Thread jetzt ne weile beobachtet.
Als es das letzte mal eine Deflation auf den Server gab (Abschaffung der Automatischen Farmen ) hat sich dies nach spätestens einen halben Jahr wieder beruhigt. Im Moment ist nur der Kontrast noch extrem und für den ein oder Anderen ist es etwas ungewohnt das mann für sein Geld wieder etwas mehr schuften muss.
Das ein paar Preise so im Keller sind liegt ganz bei euch. Anscheinend ist z.b. bei Schwarzeiche manchen Spielern ein Preis von 0.14ct/Stack noch gut genug um von diesen 3k zu verkaufen. Die Restlichen Preisentwicklungen (bis auf ein paar solcher Ausnahmen) erscheinen mir relativ normal (genau wie Empty es beschrieben hat).
Das manchmal die Preise fallen obwohl am Vortag nichts verkauft wurde liegt daran das eben nicht nur der Vortag betrachtet wird.
Eine Untergrenze wie auf City lässt sich relativ schnell einbauen (das Plugin besitzt diese Funktion bereits) und erscheint mir auch als sinnvoll. Wir werden uns bei diesen Thema zusammensetzen und welche einbauen.
Einige Änderungen will ich an dieser Stelle gleich ausschließen
Begründet die Verschiedenen Elemente euer Funktion und nennt bitte Quellen falls ihr euch auf Funktionen von "Wirtschaftswissenschaftlern" stützt.
Wir werden uns Vorbehalten die Funktion dann gegebenen Falls noch einmal anzupassen.
Danke
habe den Thread jetzt ne weile beobachtet.
Als es das letzte mal eine Deflation auf den Server gab (Abschaffung der Automatischen Farmen ) hat sich dies nach spätestens einen halben Jahr wieder beruhigt. Im Moment ist nur der Kontrast noch extrem und für den ein oder Anderen ist es etwas ungewohnt das mann für sein Geld wieder etwas mehr schuften muss.
Das ein paar Preise so im Keller sind liegt ganz bei euch. Anscheinend ist z.b. bei Schwarzeiche manchen Spielern ein Preis von 0.14ct/Stack noch gut genug um von diesen 3k zu verkaufen. Die Restlichen Preisentwicklungen (bis auf ein paar solcher Ausnahmen) erscheinen mir relativ normal (genau wie Empty es beschrieben hat).
Das manchmal die Preise fallen obwohl am Vortag nichts verkauft wurde liegt daran das eben nicht nur der Vortag betrachtet wird.
Eine Untergrenze wie auf City lässt sich relativ schnell einbauen (das Plugin besitzt diese Funktion bereits) und erscheint mir auch als sinnvoll. Wir werden uns bei diesen Thema zusammensetzen und welche einbauen.
Einige Änderungen will ich an dieser Stelle gleich ausschließen
- Entfernung der Preis-Obergrenze
- Vincenzo's jeder bekommt fürs Däumchendrehen Geldgutgeschrieben System
- Reset des Geldes
- Absichtlicher Währungsverfall durch Multiplikation der AdminShop Preis um einen Faktor x > 1
- Reset des Servergeldes (Wenn so etwas mal zur Diskussion stehen wird wird vermutlich der komplette Server-teil neu aufgesetzt und neu gestaltet.)
- Verkaufszahlen + Datum
- Preise + Datum
- Obergrenzen werden weiterhin bestehen bleiben
- keine Immer an der Obergrenze Funktion
- möglichst eine normale Preisschwankung die sich zwischen Unter-/Obergrenze bewegt (keine untergrenze == 0.01ct) und diese möglichst nicht "berührt"
- keine so einfache Manipulation (wie zu der Zeit als nur der durchschnitt des vortages Tages benutzt wurde)
Begründet die Verschiedenen Elemente euer Funktion und nennt bitte Quellen falls ihr euch auf Funktionen von "Wirtschaftswissenschaftlern" stützt.
Wir werden uns Vorbehalten die Funktion dann gegebenen Falls noch einmal anzupassen.
Danke
Die punkte hatte ich auch bedacht, eine ganz grobe, nicht verfeinerte funktion, an die ich mich anlehnen würde, wäre:
V0 = Durchschnittsverkaufszahlen bzw. Verkaufszahlen der letzten 30/60/90 Tage im Durchschnitt
V1 = Verkaufszahlen des letzten Tages
P0 = Durchschnittspreis: (Obergrenze + Untergrenze) / 2
Neuer Preis = V0 / V1 × P0
Ich würde dann noch Faktoren hinzufügen im Abhängigkeit der letzten Tage bzw. Des kurses, damit es nicht stark sondern sehr langsam hin und herschwankt, mit Abhängigkeit auf den gestrigen Preis etc, aber an die Funktion würde ich mich eben anlehnen
V0 = Durchschnittsverkaufszahlen bzw. Verkaufszahlen der letzten 30/60/90 Tage im Durchschnitt
V1 = Verkaufszahlen des letzten Tages
P0 = Durchschnittspreis: (Obergrenze + Untergrenze) / 2
Neuer Preis = V0 / V1 × P0
Ich würde dann noch Faktoren hinzufügen im Abhängigkeit der letzten Tage bzw. Des kurses, damit es nicht stark sondern sehr langsam hin und herschwankt, mit Abhängigkeit auf den gestrigen Preis etc, aber an die Funktion würde ich mich eben anlehnen
Mal einige Zahlen damit ihr was zum Testen habt: (alles das gleiche im Tabellenformat deines Vertrauens)
https://craftstuebchen.de/assets/CsSky/sky_dynshop.ods
https://craftstuebchen.de/assets/CsSky/sky_dynshop.xls
https://craftstuebchen.de/assets/CsSky/sky_dynshop.xlsx
https://craftstuebchen.de/assets/CsSky/sky_dynshop.ods
https://craftstuebchen.de/assets/CsSky/sky_dynshop.xls
https://craftstuebchen.de/assets/CsSky/sky_dynshop.xlsx
also ich hätte jetzt einen sehr schlichten, leicht zu beeinflussen, aber funktionierende Funktion:
V0 = Durchschnittsverkaufszahlen bzw. Verkaufszahlen der letzten 30/60/90 Tage im Durchschnitt
V1 = Verkaufszahlen des letzten Tages
P0 = Durchschnittspreis: (Obergrenze + Untergrenze) / 2
P1 = Preis des letzten Tages
([{V0 / V1 x P0} - P1] / 5) + P1
Die 5 kann man alternativ auch Austauschen, um die Schritte noch etwas kleiner zu gestalten.
Auf Wunsch kann ich gerne auch versuchen, den hier jetzt noch nicht beachteten Kurs mit einzubringen (also, wenn der preis über 15 tage stetig fällt und dann nach der formel aufsteigen würde, er noch nicht aufsteigt sondern langsam erstmal "abflacht" bevor der preis wieder steigt)
V0 = Durchschnittsverkaufszahlen bzw. Verkaufszahlen der letzten 30/60/90 Tage im Durchschnitt
V1 = Verkaufszahlen des letzten Tages
P0 = Durchschnittspreis: (Obergrenze + Untergrenze) / 2
P1 = Preis des letzten Tages
([{V0 / V1 x P0} - P1] / 5) + P1
Die 5 kann man alternativ auch Austauschen, um die Schritte noch etwas kleiner zu gestalten.
Auf Wunsch kann ich gerne auch versuchen, den hier jetzt noch nicht beachteten Kurs mit einzubringen (also, wenn der preis über 15 tage stetig fällt und dann nach der formel aufsteigen würde, er noch nicht aufsteigt sondern langsam erstmal "abflacht" bevor der preis wieder steigt)
Ich bin mir nicht sicher ob man den Kurs noch einbauen muss, da die anzahl der verkauften Items bei immer schlechteren Preisen zurück gehen und der Preis somit wieder steigen sollte.
Sieht schon mal gut aus. Sehe aber als Gefahr den Faktor f=(V0/V1):
Pn+1=([{(V0 / V1) x P0} - P1] / 5) + P1;
sei f=(V0/V1)
lim f -> 0 (Pn+1)= ((0xP0)-P1/5)+P1 = P1-P1/5
lim f -> ∞ (Pn+1)= (('∞'*P0)-P1)/5+P1 = '∞'/5+P1= ∞
=> Preis kann explosionsartig steigen senken kann er sich aber maximal um P1/5
Sieht schon mal gut aus. Sehe aber als Gefahr den Faktor f=(V0/V1):
Pn+1=([{(V0 / V1) x P0} - P1] / 5) + P1;
sei f=(V0/V1)
lim f -> 0 (Pn+1)= ((0xP0)-P1/5)+P1 = P1-P1/5
lim f -> ∞ (Pn+1)= (('∞'*P0)-P1)/5+P1 = '∞'/5+P1= ∞
=> Preis kann explosionsartig steigen senken kann er sich aber maximal um P1/5
@Llewe vielleicht könnte man da in den java code an der dazugehörigen stelle ein elsefall reinhauen, dass falls V1 kleiner als 1/5 oder 1/8 oder so ist, dass genau dann dieser Ausdruck "V0/V1 x P0" = 0 sein soll. Somit käme auch eine maximale Steigerung von P1/5 zustande.
In Codeschrift könnte man das realisieren, indem man "V0/V1 x P0" als neue Variable deklariert und diese bei dem "Fall V1 < 1/5 bzw. 1/8 == true" gleich 0 gesetzt wird.
In Codeschrift könnte man das realisieren, indem man "V0/V1 x P0" als neue Variable deklariert und diese bei dem "Fall V1 < 1/5 bzw. 1/8 == true" gleich 0 gesetzt wird.
Mir gefällt der Ansatz für den Durchschnittspreis als einfaches Mittel zwischen Ober- und Untergrenze nicht.
Bin nun wahrlich kein Mathe-Genie, und BWL hat mich auch noch nie wirklich interessiert, aber ein fixer Durchschnittswerte wie aktuell vorgeschlagen setzt die Preise entweder viel zu hoch an oder aber lässt bei realistischen Werten kaum Platz für Schwankungen.
Wenn die Schwankungen jedoch so klein werden, dann lohnt sich der Aufwand kaum noch, da die Gewinnunterschiede sich über die Zeit ohnehin ausgleichen, man also quasi gar nicht auf die Preise gucken muss sondern einfach verkaufen kann, insbesondere wenn Anstiegs- und Abfallfaktoren auch noch gleich sind.
Im Mittel würde man somit immer zum Durchschnitt verkaufen.
Mein Vorschlag:
Variabler Erwartungspreis, welcher sich dynamisch aus den Erwartungspreisen der letzten Tage ergibt. Also quasi wie aktuell auch ein Kurswert, beeinflusst durch einen Leitindex.
Der nächste Kurswert ergibt sich dann aus den Verkaufszahlen der zurückliegenden Periode als Veränderungen auf die zurückliegenden Erwartungpreise.
Was sich ergeben müsste ist ein Konstrukt, welches halt nicht ständig und einfach um die Mitte zwischen Ober- und Untergrenze schwingt, sondern tatsächlich Leben zeigt.
Die Untergrenze sollte dabei durchaus in einem preisllich uninteressanten Bereich liegen, sonst greift wieder oben genanntes.
Gleiches gilt für die Obergrenze, diese sollte nicht inflationär, aber dennoch attraktiv sein.
Cobble für 5ct anstatt 4ct zu verkaufen ist genauso wenig attraktiv, wie ihn zu 3ct zu verkaufen schmerzhaft ist.
Bin nun wahrlich kein Mathe-Genie, und BWL hat mich auch noch nie wirklich interessiert, aber ein fixer Durchschnittswerte wie aktuell vorgeschlagen setzt die Preise entweder viel zu hoch an oder aber lässt bei realistischen Werten kaum Platz für Schwankungen.
Wenn die Schwankungen jedoch so klein werden, dann lohnt sich der Aufwand kaum noch, da die Gewinnunterschiede sich über die Zeit ohnehin ausgleichen, man also quasi gar nicht auf die Preise gucken muss sondern einfach verkaufen kann, insbesondere wenn Anstiegs- und Abfallfaktoren auch noch gleich sind.
Im Mittel würde man somit immer zum Durchschnitt verkaufen.
Mein Vorschlag:
Variabler Erwartungspreis, welcher sich dynamisch aus den Erwartungspreisen der letzten Tage ergibt. Also quasi wie aktuell auch ein Kurswert, beeinflusst durch einen Leitindex.
Der nächste Kurswert ergibt sich dann aus den Verkaufszahlen der zurückliegenden Periode als Veränderungen auf die zurückliegenden Erwartungpreise.
Was sich ergeben müsste ist ein Konstrukt, welches halt nicht ständig und einfach um die Mitte zwischen Ober- und Untergrenze schwingt, sondern tatsächlich Leben zeigt.
Die Untergrenze sollte dabei durchaus in einem preisllich uninteressanten Bereich liegen, sonst greift wieder oben genanntes.
Gleiches gilt für die Obergrenze, diese sollte nicht inflationär, aber dennoch attraktiv sein.
Cobble für 5ct anstatt 4ct zu verkaufen ist genauso wenig attraktiv, wie ihn zu 3ct zu verkaufen schmerzhaft ist.
Ah sry. Ich hatte deine Ergänzung ,einen Post über Mir ,übersehen ^^#.
Zuletzt bearbeitet:
Vielleicht könnte man das Ganze auch über ne Sinuskurve lösen.
Mit Maximal- und Minimalpreis als Amplituden und mittlere Preisdifferenz als Scheitel.(zb.: max: 15CT ,min: 5CT - Scheitel bei: min + (15 - 5) / 2)
Und temporäre Amplitudenwerte ,in Abhängigkeit vom Marktgeschehen ,drüber legen.
#Blah#Mathe#Blah
MfG
Mit Maximal- und Minimalpreis als Amplituden und mittlere Preisdifferenz als Scheitel.(zb.: max: 15CT ,min: 5CT - Scheitel bei: min + (15 - 5) / 2)
Und temporäre Amplitudenwerte ,in Abhängigkeit vom Marktgeschehen ,drüber legen.
#Blah#Mathe#Blah
MfG
Zuletzt bearbeitet:
so jetzt bin ich mal hier und kommentiere ^^ ok meine Meinung ist: mann sollte irgendwie schon ein unterpreis einfügen der unatraktiv ist aber grade so verkraftbar wie ich jetzt immer als Beispiel nehemen werde bei netherwarzen ca.6 während der Maximalpreis schon attraktiv sein sollte aber nicht inflaktioner (ka wies geschrieben wird) sein sollte wie scotty schon sagte mein Beispiel bei netherwarzen ca. 15 es soll halt lukrativ sein dann da zu verkaufen aber nicht so grass das man nur darauf hortet, was ich aber auch interesant finden und begrüßen würde ist wie timo gesagt hat ein durschnitspreis einzufügen worum der verkausfspreis dynamisch schwangt also nicht immer in ner welle von oben wieder unten und das sich wiederholend sondern auch mal unten bleibend oder oben bleibend. genauso ein kleiner randomeffekt hinzuzufügen wäre sehr interesant der dann die anfrage "auf der welt(also die Ankäufer von sky)" symbolisieren würde und die spieler hiermit sozusagen die macht aus den segeln nehmen würde den preis alleine selber zu stark zu beinflussen aber trozdem so beinflussbar machen das die Verkaufspreise was ausmachen
und nochmal an alle die es gelessen haben:sorry das ihr euch die mühe machen musstet und trotz der Rechtschreibfehler hoffentlich alles verstanden habt
meine Entschuldigung: ich komm grade von der schule und es ist montag .-. ich hoffe ihr versteht mich
und nochmal an alle die es gelessen haben:sorry das ihr euch die mühe machen musstet und trotz der Rechtschreibfehler hoffentlich alles verstanden habt
meine Entschuldigung: ich komm grade von der schule und es ist montag .-. ich hoffe ihr versteht mich
Also, ich hätte eine Idee. Zuallererst Möchte ich diese oben genannte Funktion als f1 betiteln, damit es im weiteren Kontext übersichtlich bleibt.
(Die 5 kann man wie gesagt noch variieren, um größere bzw. kleinere Schritte zu haben)
Ich versuche jetzt 2 Ansätze mit herein zu bringen, um sowohl mehr "Eigenleben" als auch einen "Kurswert" mit hineinzubringen, aber so, dass diese nicht ZU VIEL Einfluss haben.
Für den Kurswert hätte ich die Idee, einen Kurswert "V2 = Durchschnittswert der letzten 30 Tage" einzufügen, und diesen in der Formel folgendermaßen zu realisieren:
f2 = f1 + (V2 - f1) / 5
Auch hier kann man die 5 nach Wunsch anpassen, je nachdem wieviel einfluss dieser Kurswert haben soll.
Der Ansatz fürs "Eigenleben" kam in Inspiration von Admurai, dass man einen zufälligen Schwankungswert reinhaut. D.h., dass der preisunterschied durch Zufall mehr/weniger ausmachen kann. Hier in die Formel gepackt:
R = Zufälliger Wert zwischen 0 und 100 (in Javacode: zufälliger Wert zwischen 0 und 1 x 100)
f3 = f2 + f2 x ((R - 50) / 10)%
Somit würde der Wert zufälligerweise 95-105% Wertigkeit haben (kann man natürlich auch adjustieren => Statt der 10 eine 5 => 90-110%)
Beide Ansätze hab ich jetzt nach einem sehr simplen Prinzip geformt, somit natürlich keine Wunderleistung einer Funktion, auf Wunsch kann ich da versuchen, ein anderes Prinzip, die jeweilige Eigenschaft in die Funktion einzuarbeiten, zu suchen und anzuwenden.
Hallo Sky!
Ich habe mir jetzt einige Zeit genommen und diesen Thread fleißig verfolgt. Eigentlich würde ich gerne das aktuelle System beibehalten. Aber wer nichts beiträgt darf später nicht meckern, richtig?
Entschuldigt bitte gleich im Vorfeld den langen Post.
Ich habe ich mir also überlegt wie ich das selbst lösen würde und stimme da in einigen Punkten dem hier bereits gesagten zu. Die Fragen die ich mir hierbei gestellt habe sind:
Wie kann ich...
1. ... eine Nachfrage anhand der Verkaufszahlen simulieren?
2. ... eine Marktsättigung simulieren?
3. ... einen kontrollierbaren und nachvollziehbaren Preisverlauf generieren?
4. ... Manipulation vorbeugen?
5. ... den Preisverlauf "lebendig" halten
"Die Nachfrage bestimmt das Angebot" - Diesen Satz kennen sicher alle. D.h. das Angebot strebt immer der Nachfrage entgegen, egal in welche Richtung. Da wir aber leider nur das Angebot kennen bleibt uns nichts anderes übrig als das Pferd von hinten auf zu zäumen: "Das Angebot bestimmt die Nachfrage" nun gut, fast
Nehmen wir die Marktsättigung mit in unsere Überlegung. Der Preis eines Items wird auch bei steigendem Angebot solange steigen, solange die Nachfrage größer ist, also der Markt noch nicht gesättigt. Nehmen wir dazu an dass sich der Bedarf im System nur allmählich und nicht schlagartig ändert. Wir benötigen also einen Punkt ab welchem die Nachfrage gedeckt ist und der Markt gesättigt. Und das ganze in Abhängigkeit des Marktverlaufes.
Das brachte mich auf die Idee eines Schwellenwert - Systems in Abhängigkeit der Verkaufszahlen. Zu bestimmten Vielfachen der durchschnittlichen Verkaufsmengen im Zeitraum X eines Items wird der Preis um ein gewisses Maß angepasst. Da sich die durchschnittliche Verkaufsmenge ständig ändert tut dies auch unsere simulierte Nachfrage. Liegt das Angebot unter dem Durchschnitt, so steigt der Preis, da die Nachfrage nicht gedeckt werden kann. Liegt es darüber sinkt der Preis, denn der Markt ist gesättigt.
Durch definierbare Schwellenwerte und Preisänderungen entsteht so ein kontrollierbares und nachvollziehbares System. Leider reicht ein einfacher Durchschnittswert für diese Schwellenwerte nicht aus, da vereinzelte Massenverkäufe diesen ins unermessliche Steigern. Daher würde ich hier ein gestutztes Mittel verwenden.
Um Manipulationen vorzubeugen ist jeder Schwellenwert noch mit einer Zufallszahl zu multiplizieren um zu verhindern dass gezielte Mengen verkauft werden und um mehr Leben in das System zu bringen.
Desweiteren sollte nicht nur der aktuelle Tag, sondern auch der Zeitraum von ca. 1 Woche betrachtet werden um "Trends" zu ermöglichen und das ganze interessant zu halten (Danke an EmptySoul_Agony für diese Idee).
Leider sind meine Java-Kenntnisse stark eingerostet und ich konnte das gestutzte Mittel nach folgender Formel nicht in das Programmbeispiel integrieren:
http://prntscr.com/f99ore
Dennoch wollte ich zu Verdeutlichung ein erstes Beispiel für meinen Ansatz geben:
Die Werte sind selbstverständlich nur Beispielhaft und können gerne nach Belieben diskutiert und angepasst werden. Da Minimal- und Maximalpreise ja scheinbar erwünscht / gefordert sind, habe ich diese auch eingefügt.
Ich würde mich über reges Feedback zu diesem Ansatz freuen und bin mir sicher dass ich noch die ein oder andere Sache übersehen habe^^
MfG
_Pigdog_
Ich habe mir jetzt einige Zeit genommen und diesen Thread fleißig verfolgt. Eigentlich würde ich gerne das aktuelle System beibehalten. Aber wer nichts beiträgt darf später nicht meckern, richtig?
Entschuldigt bitte gleich im Vorfeld den langen Post.Ich habe ich mir also überlegt wie ich das selbst lösen würde und stimme da in einigen Punkten dem hier bereits gesagten zu. Die Fragen die ich mir hierbei gestellt habe sind:
Wie kann ich...
1. ... eine Nachfrage anhand der Verkaufszahlen simulieren?
2. ... eine Marktsättigung simulieren?
3. ... einen kontrollierbaren und nachvollziehbaren Preisverlauf generieren?
4. ... Manipulation vorbeugen?
5. ... den Preisverlauf "lebendig" halten
"Die Nachfrage bestimmt das Angebot" - Diesen Satz kennen sicher alle. D.h. das Angebot strebt immer der Nachfrage entgegen, egal in welche Richtung. Da wir aber leider nur das Angebot kennen bleibt uns nichts anderes übrig als das Pferd von hinten auf zu zäumen: "Das Angebot bestimmt die Nachfrage" nun gut, fast
Nehmen wir die Marktsättigung mit in unsere Überlegung. Der Preis eines Items wird auch bei steigendem Angebot solange steigen, solange die Nachfrage größer ist, also der Markt noch nicht gesättigt. Nehmen wir dazu an dass sich der Bedarf im System nur allmählich und nicht schlagartig ändert. Wir benötigen also einen Punkt ab welchem die Nachfrage gedeckt ist und der Markt gesättigt. Und das ganze in Abhängigkeit des Marktverlaufes.
Das brachte mich auf die Idee eines Schwellenwert - Systems in Abhängigkeit der Verkaufszahlen. Zu bestimmten Vielfachen der durchschnittlichen Verkaufsmengen im Zeitraum X eines Items wird der Preis um ein gewisses Maß angepasst. Da sich die durchschnittliche Verkaufsmenge ständig ändert tut dies auch unsere simulierte Nachfrage. Liegt das Angebot unter dem Durchschnitt, so steigt der Preis, da die Nachfrage nicht gedeckt werden kann. Liegt es darüber sinkt der Preis, denn der Markt ist gesättigt.
Durch definierbare Schwellenwerte und Preisänderungen entsteht so ein kontrollierbares und nachvollziehbares System. Leider reicht ein einfacher Durchschnittswert für diese Schwellenwerte nicht aus, da vereinzelte Massenverkäufe diesen ins unermessliche Steigern. Daher würde ich hier ein gestutztes Mittel verwenden.
Um Manipulationen vorzubeugen ist jeder Schwellenwert noch mit einer Zufallszahl zu multiplizieren um zu verhindern dass gezielte Mengen verkauft werden und um mehr Leben in das System zu bringen.
Desweiteren sollte nicht nur der aktuelle Tag, sondern auch der Zeitraum von ca. 1 Woche betrachtet werden um "Trends" zu ermöglichen und das ganze interessant zu halten (Danke an EmptySoul_Agony für diese Idee).
Leider sind meine Java-Kenntnisse stark eingerostet und ich konnte das gestutzte Mittel nach folgender Formel nicht in das Programmbeispiel integrieren:
http://prntscr.com/f99ore
Dennoch wollte ich zu Verdeutlichung ein erstes Beispiel für meinen Ansatz geben:
Code:
// M = Gestutztes Mittel der Verkaufszahlen der letzten 30 Tage (0,07 alpha) in Items
// V6= Summe der Verkaufszahlen der vorherigen 6 Tage in Items
// V = aktuelle Verkaufszahlen in Items
// RND = Zufallszahl zwischen 90 und 110
// P = Preis des Items in ct
// Pmax= Maximal möglicher Preis für Item in ct
// Pmin= Minimal möglicher Preis für Item in ct
// S = Schwellenwert
S := ((M*RND) / 100)
if (((V+V6) / 7) > (S*4)) {
P := P*0,91
} else {
if (((V+V6) / 7) > (S*3)) {
P := P*0,94
} else {
if (((V+V6) / 7) > (S*2)) {
P := P*0,97
} else {
if (((V+V6) / 7) > (S)) {
P := P
} else {
if (((V+V6) / 7) > (S*0,9)) {
P := P*1,03
} else {
if (((V+V6) / 7) > (S*0,75)) {
P := P*1,06
} else {
P := P*1,09
} // end of if-else
} // end of if
} // end of if-else
} // end of if
} // end of if-else
} // end of if
if (P > Pmax) {
P := Pmax
} else {
if (P < Pmin) {
P := Pmin
} // end of if
} // end of if-elseDie Werte sind selbstverständlich nur Beispielhaft und können gerne nach Belieben diskutiert und angepasst werden. Da Minimal- und Maximalpreise ja scheinbar erwünscht / gefordert sind, habe ich diese auch eingefügt.
Ich würde mich über reges Feedback zu diesem Ansatz freuen und bin mir sicher dass ich noch die ein oder andere Sache übersehen habe^^
MfG
_Pigdog_
Zuletzt bearbeitet von einem Moderator:
Hm, vorab muss Ich auch mal sagen das diese Formeln ,die eine reale Wirtschaft simulieren sollen, natürlich, Top sind.*Thumbs up*
Andererseits, je öfter Ich darüber nachdenke ,würde dann Realität auf Spiel treffen. -> Man verkauft viel -> Preise steigen -> man verkauft noch mehr und Preis stürzt ab.
Man verkauft nix -> Preis steigt -> man verkauft nochmehr nix und Preis ist "dauerhaft" im Keller. Im Realen würde das Item dann irgendwann aus dem Regal genommen werden.
Und das ist leider das Problem ,welches ich mit diesen Formeln habe.Auf kurz oder lang würden sich alle Preise im As kellern, bis Jeder nurnoch am jammern wäre und alle seine Items Horten und auf bessere Preise warten würde.
Deswegen war meine Idee weiter oben mit ner SinusKurve ,mit variablen Amplituden, und bei bedarf mit beweglichem Scheitel, eher auf eine "Spielwelt" ausgelegt ,in der eine stetige Bewegung von Nöten? ist.
MfG
PS: *P := P nehm und irgendwo versteck*
Andererseits, je öfter Ich darüber nachdenke ,würde dann Realität auf Spiel treffen. -> Man verkauft viel -> Preise steigen -> man verkauft noch mehr und Preis stürzt ab.
Man verkauft nix -> Preis steigt -> man verkauft nochmehr nix und Preis ist "dauerhaft" im Keller. Im Realen würde das Item dann irgendwann aus dem Regal genommen werden.
Und das ist leider das Problem ,welches ich mit diesen Formeln habe.Auf kurz oder lang würden sich alle Preise im As kellern, bis Jeder nurnoch am jammern wäre und alle seine Items Horten und auf bessere Preise warten würde.
Deswegen war meine Idee weiter oben mit ner SinusKurve ,mit variablen Amplituden, und bei bedarf mit beweglichem Scheitel, eher auf eine "Spielwelt" ausgelegt ,in der eine stetige Bewegung von Nöten? ist.
MfG
PS: *P := P nehm und irgendwo versteck*
Danke für den Hinweis Feuer_Fuchs, hatte es der Vollständigkeit halber mit rein genommen. Ist natürlich unnötig und hab ich wieder raus genommen. Dass der Preis "dauerhaft" im Keller bleibt, wenn nichts verkauft wird, ist bei meinem Ansatz zwar nicht möglich, ich versteh deinen Punkt aber. Andererseits ist eine ständige Bewegung der Preise ohne zutun der Spieler doch genauso wenig interessant. Schließlich geht es ja darum das System zu verstehen, es zu nutzen und dabei besser zu sein als der Rest, oder etwa nicht?
Ansonsten könnten wir ja auch gleich fixe Preise im Admin-shop festlegen und damit das Thema begraben
Ansonsten könnten wir ja auch gleich fixe Preise im Admin-shop festlegen und damit das Thema begraben