Banner left   Banner center   Banner right

Germanenglish Home · News · Diary · Screenshots · Documentation (Wiki) · Downloads · Guestbook · Forum

Home · Benutzer registrieren · Suchen · Statistik · FAQ · Benutzerliste

Zur Zeit online: keiner ausser dir

 X-Force - Fight For Destiny - Forum —› Quellcode / Programmierung —› Verbesserungsvorschlag Zufallseffekte

Autor Mitteilung
verfasst am: 23.10.2005, 14:06
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beitrge: 5596
Der Eintrag hier ist durch Natter's Verweis auf 518 nach meiner Frage ausgelst.

Die Zufallssteuerung in XForce ist sehr rudimentr - kein Spielsatzersteller hat Einfluss darauf, wie hufig ein UFO auftaucht (lediglich wie oft welches Modell bei einem Ufo ausgewhlt wird) oder wie hufig zufllige Scripts ausgelst werden.

Man kann in einem Spiel wie XForce aber auch nicht so einfach einen beliebigen Zufall unterbringen - das kollidiert dann an einigen Punkten in der Zeitsteuerung oder bringt kaum steuerbare Zufallsergebnisse, denn XForce rechnet mit Schritten von Minuten bzw. Stunden.

Man braucht allerdings auch keinen ganz freien Zufall um vernnftig einen Spielsatz steuern zu knnen. Ich wrde deshalb vorschlagen, einige Zufallstypen einzufhren und diese dann den jeweiligen Ereignissen zuordnenbar zu machen.

Es wird dann also im Spielsatz bei einem Script und bei allgemeinen Zuordnungen lediglich der Zufallstyp ausgewhlt und eine Funktion geschrieben, mit der man Zufallsereignisse im Spiel auch noch gescriptet einem anderen Zufallstyp zuweisen kann.

Diese Zufallstypen knnen dann fest in den passenden Zeitabstnden aufgerufen werden und haben jedesmal eine Liste wie oft und fr was sie berprft werden.

Typ 1: Prfung einmal pro Minute, Ereignis tritt mit 0,16% ein (msste die aktuelle Wahrscheinlichkeit fr UFOs sein, wenn ich mich richtig durch den Code gehangelt habe)
Typ 2: Prfung einmal pro Minute, 1% (UFO-Ansturm)
Typ 3: Prfung einmal pro Stunde, 0,16%
Typ 4: Prfung einmal pro Stunde, 1%
Typ 5: Prfung einmal pro Tag, 1%
Typ 6: Prfung einmal pro Tag, 5%
Typ 7: Prfung einmal pro Woche, 5%

Eventuell auch als Wertematrix, d.h. ein Wert ob pro Minute, pro Stunde, pro Tag oder pro Woche geprft wird und ein Wert fr die Wahrscheinlichkeit (0,16%, 1%, 5%). Hierbei wrde ich aber keine freie Wahrscheinlichkeitseingabe zulassen sondern nur die drei vorgegebenen Werte zur Auswahl.

Im Editor gibt es dann die Mglichkeit, als allgemeine Spielsatzeigenschaft die Ufo-Wahrscheinlichkeit einem Typen zuzuordnen sowie bei jedem Skript auer Zufllig auch den Zufallstyp festzulegen.

In der Zeitsteuerung wird in den entsprechenden Zeitabstnden die Zufallsroutine aufgerufen, die eine Liste mit allen Ereignissen enthlt die diesen Typ zugeordnet bekommen haben. Dann wird jedesmal ein Random gemacht und im Erfolgsfall die passende Funktion aufgerufen.
Das kann dann die UFO-Erzeugung oder ein beliebiges Script sein, z.B. fr Pseudo-Nachrichten oder Zufallsereignisse.

Und die Beschrnkung auf die fest definierten Zufallstypen verhindert das irgend ein Spielsatz oder Spiel aufgrund falscher freier Zufallswerte abstrzt etc.
verfasst am: 23.10.2005, 18:40
Registrierdatum: 03.01.2005, 16:26

 Beitrge: 12
Naja, ich hab mir den Code noch nicht so genau angeguckt, aber wenn das nicht zu Performance-Problemen fhrt sollten freie Zufallseingaben mglich sein, allerdings mssten die Werte selbstverstndlich geprft werden.
verfasst am: 23.10.2005, 19:05 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beitrge: 3186
Zitat: Bennily
sollten freie Zufallseingaben mglich sein,

Fnde ich auch besser. Auerdem sollte die Angabe (zumindest im Editor) nicht in der Form

0.xx % pro Stunde/Minute

gemacht werden, sondern eher in der Form:

Durchschnittlich XXX zufllige Ereignisse pro Tag

{...von Typ A, YYY pro Tag von Typ B usw., falls es denn verschiedene Zufallsereignisse gibt; sinnvoll wre z.B. eine Unterscheidung zwischen zufllig auftauchenden Ufos (Typ A) und zufllig gestarteten Skripten (Typ B)}
verfasst am: 23.10.2005, 19:42
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beitrge: 5596
Freie Zufallswerte wren mir auch lieber - den Vorschlag mit dem Festlegen hatte ich hauptschlich gemacht, weil man sonst eventuell mit den unterschiedlichen berprfungszeiten von Minute/Stunde/Tag durcheinander kommen knnte.

Das Problem weshalb ich diese Unterscheidung herein gebracht habe liegt zum Teil daran das es vom Programmcode her einfacher wre einzubauen.
Aber es liegt auch daran, dass folgende Angaben
Durchschnittlich 1 pro Tag
4,1% pro Stunde
0,07% pro Minute

halt nicht ganz das gleiche bewirken, obwohl alle zu demselben Durchschnitt von ca. 7 Ereignissen einer Woche fhren.

Eine berprfung von 0,07% pro Minute hat statistisch einen Treffer pro Tag. Abgesehen von einer leicht erhhten Performance durch Abfragen in jeder Minute kann es aber durchaus passieren, das zwischen zwei Treffern mal nur 2-3 Stunden liegen und dafr dann bis zum dritten 40 Stunden vergehen.
Dies ist aber je nach Ereignis nicht immer sinnvoll.

Wenn man dagegen ein selteneres Ereignis pro Tag berprft, dann wird es blicherweise um Mitternacht auftauchen, sobald halt der Tageszufall geprft wird...

Und die Ufo-Wahrscheinlichkeit von 0,16% pro Minute auf 10% pro Stunde zu wechseln hat auch so ein paar Probleme, denn dann wei der Spieler wann Ufos auftauchen knnen.

Die Aufteilung von Zufallstypen mit berprfungen pro Stunde oder pro Tag sollte hauptschlich dem Spielsatzersteller eine Mglichkeit geben, sinnvolle Zeitabstnde an das jeweilige Ereignis anzupassen.

Gerade bei Zufallsscripten mchte man unterschiedliche Wahrscheinlichkeiten besser steuern knnen - zwischen einem Bonus ber Naturereignisse und Alienstaffeln muss nicht alles gleich hufig auftreten.

Auerdem - wenn allgemein auf eine niedrige Wahrscheinlichkeit pro Minute umgerechnet wird, dann erfordert das auf Dauer merkbar mehr Resourcen - speziell bei vielen Zufallsscripten.
verfasst am: 23.10.2005, 19:57 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beitrge: 3186
Zitat: DirkF
halt nicht ganz das gleiche bewirken, obwohl alle zu demselben Durchschnitt von ca. 7 Ereignissen einer Woche fhren.

Ich meinte ja auch nicht die interne Codierung, sondern den eizugebenden Wert im Editor (der ja intern als Prozent pro Minute gespeichert werden knnte). Die berprfung muss natrlich immer bei fortlaufender Zeit erfolgen, je nach Geschwindigkeit pro Minute oder pro Stunde (bzw. entsprechende Zwischenstufen).

Zitat: DirkF
Gerade bei Zufallsscripten mchte man unterschiedliche Wahrscheinlichkeiten besser steuern knnen - zwischen einem Bonus ber Naturereignisse und Alienstaffeln muss nicht alles gleich hufig auftreten.

Wenn es die Rechenleistung hergibt knnte man sicher jedes Skript extra abfragen, aber ich halte das fr wenig geeignet, bzw. auch fr unntig. Wenn man fr Zufallsskripte eine Hufigkeit (z.b. 1 pro Tag oder 1 pro 6 Tage) einfhrt, sollte das reichen. Wenn jemand dann seine Ereignisse irgendwie noch gewichten will, bitte, das ist ja jetzt schon mglich. Man legt einfach nur ein Zufallskript an. Dieses ruft dann per Zufallsgenerator mit fr jedes Skript gewichteten Wahrscheinlichkeiten ein Skript auf. Sobald die Skriptsprache um eine Datumsabfrage erweitert ist, kann man so auch leicht verschiedene Skripte zeitabhngig aktivieren/deaktivieren. Das drfte erstens Rechenleistung sparen (zumindest bei vielen Skripten), und auerdem ist es bersichtlicher.
verfasst am: 23.10.2005, 22:51
Registrierdatum: 03.01.2005, 16:26

 Beitrge: 12
Ich hatte schon gemeint das man pro tag/stunde/minute angeben kann, nur dass man den Zufallswert selbst whlt, also nicht unbeding 0,16% in der Minute sondern auch 0.17%...
verfasst am: 22.11.2023, 13:42
Registrierdatum: 22.11.2023, 07:10

 Beitrge: 69718
verfasst am: 01.12.2023, 15:19
Registrierdatum: 22.11.2023, 07:10

 Beitrge: 69718
audiobookkeeper.rucottagenet.rueyesvision.rueyesvisions.comfactoringfee.rufilmzones.rugadwall.rugaffertape.rugageboard.rugagrule.rugallduct.rugalvanometric.rugangforeman.rugangwayplatform.rugarbagechute.rugardeningleave.rugascautery.rugashbucket.rugasreturn.rugatedsweep.rugaugemodel.rugaussianfilter.rugearpitchdiameter.ru
geartreating.rugeneralizedanalysis.rugeneralprovisions.rugeophysicalprobe.rugeriatricnurse.rugetintoaflap.rugetthebounce.ruhabeascorpus.ruhabituate.ruhackedbolt.ruhackworker.ruhadronicannihilation.ruhaemagglutinin.ruhailsquall.ruhairysphere.ruhalforderfringe.ruhalfsiblings.ruhallofresidence.ruhaltstate.ruhandcoding.ruhandportedhead.ruhandradar.ruhandsfreetelephone.ru
hangonpart.ruhaphazardwinding.ruhardalloyteeth.ruhardasiron.ruhardenedconcrete.ruharmonicinteraction.ruhartlaubgoose.ruhatchholddown.ruhaveafinetime.ruhazardousatmosphere.ruheadregulator.ruheartofgold.ruheatageingresistance.ruheatinggas.ruheavydutymetalcutting.rujacketedwall.rujapanesecedar.rujibtypecrane.rujobabandonment.rujobstress.rujogformation.rujointcapsule.rujointsealingmaterial.ru
journallubricator.rujuicecatcher.rujunctionofchannels.rujusticiablehomicide.rujuxtapositiontwin.rukaposidisease.rukeepagoodoffing.rukeepsmthinhand.rukentishglory.rukerbweight.rukerrrotation.rukeymanassurance.rukeyserum.rukickplate.rukillthefattedcalf.rukilowattsecond.rukingweakfish.rukinozones.rukleinbottle.rukneejoint.ruknifesethouse.ruknockonatom.ruknowledgestate.ru
kondoferromagnet.rulabeledgraph.rulaborracket.rulabourearnings.rulabourleasing.rulaburnumtree.rulacingcourse.rulacrimalpoint.rulactogenicfactor.rulacunarycoefficient.ruladletreatediron.rulaggingload.rulaissezaller.rulambdatransition.rulaminatedmaterial.rulammasshoot.rulamphouse.rulancecorporal.rulancingdie.rulandingdoor.rulandmarksensor.rulandreform.rulanduseratio.ru
languagelaboratory.rulargeheart.rulasercalibration.rulaserlens.rulaserpulse.rulaterevent.rulatrinesergeant.rulayabout.ruleadcoating.ruleadingfirm.rulearningcurve.ruleaveword.rumachinesensible.rumagneticequator.rumagnetotelluricfield.rumailinghouse.rumajorconcern.rumammasdarling.ru



Du musst dich registrieren um auf dieses Thema zu antworten.
Login :: » Name » Passwort

Ladezeit (sec.): 0.011 · Powered by miniBB 1.6 with parts of 1.7 © 2001-2003