Neue ideen für das spiel

  • Wie wäre es wenn man neben dem Aussehen auch das geschlecht ändern könnte.

    Oder man ein spezieles item in denn shop einführt wo einem ermöglicht seine 3 Klasse auf 100 zu ziehen(so fern man Main/Sek klasse auf 100 hat)


    Ein Item(wird bisschen teurer als andere im shop) mit dem man zmb waffen+rüstung auf +25-+30 direkt machen kann (Preisvorschlag zwischen 3000-4000 dias)


    Man einen NPC ins spiel einbringt bei dem man Waffen und Rüstungsteile eintauschen kann wenn man mal das falsche bekommen hat z. B. Kette gegen Leder oder Stoff gegen Kette.



    Was haltet ihr davon ? dieser post ist für noch mehr neue ideen also nur her damit :D


    Gesegnet von Fossilo <3

  • Wie wäre es wenn man neben dem Aussehen auch das geschlecht ändern könnte.

    Gibt es glaube sogar schon in der Datenbank - müsste es dann nur auch mal erwerbbar irgendwo geben.

    Quote

    Oder man ein spezieles item in denn shop einführt wo einem ermöglicht seine 3 Klasse auf 100 zu ziehen(so fern man Main/Sek klasse auf 100 hat)

    Da bin ich persönlich kein großer Fan von... mit Sonne grinden bekommt man bei nem EP Event eine Klasse von 0 auf 100 in 6-10h (je nach Event) und das ist mMn schon viel zu schnell bzw zu wenig Arbeit. Würde es da noch ein Item im IS geben, würde das den pay2win faktor nur erhöhen.


    Quote

    Ein Item(wird bisschen teurer als andere im shop) mit dem man zmb waffen+rüstung auf +25-+30 direkt machen kann (Preisvorschlag zwischen 3000-4000 dias)

    Solche Steine gibt es für bis +20 und da kostet einer für Waffen schon 3k Dias. bis +25 würde ich dann mal grob 6k Dias vermuten (bis +25 bekommt man ein Item noch gut) und bis +30 sowas wie 40k Dias (was günsitger sein sollte, als eine Waffe auf normalem wege auf +30 zu bringen).

    Zusätzlich hat man das Problem, dass man die Leute viel zu OP macht. Nicht mehr lang und die Leute laufen Grab solo. (ja, es sind immer weniger leute auf den servern da und man muss die inis auch mit weniger leuten packen, aber sowas wäre mMn der falsche weg)


    Quote

    Man einen NPC ins spiel einbringt bei dem man Waffen und Rüstungsteile eintauschen kann wenn man mal das falsche bekommen hat z. B. Kette gegen Leder oder Stoff gegen Kette.

    Das einzige was aktuell im pve noch etwas abwechslung bringt, ist inis laufen.. eine der größten motivationen ist da oft, dass dem gildie xy noch ein teil fehlt. Wenn man dann die 20 Platten-Equips die man rumliegen hat, gegen kette/leder/stoff tauschen könnte, würde dieser motivator wegbrechen. Dazu kommt noch, dass damit der Handel mit Equip wohl lahmgelegt würde, weil dann jeder der die inis laufen kann, einfach die teile, die er bekommt, gegen das tauscht, was er braucht. kleinere Spieler, die die inis nicht laufen können, sich aber gold sparen, um das zeug im AH zu kaufen, würden dann nichts mehr bekommen.

  • finde ich toll die ganzen antworten ihr könnt hier drunter auch gerne mal eure ideen schreiben die würden mich auch interessieren

  • Meine persönliche Prio-Liste:

    1. neuer, anspruchsvoller Content (bzw. Pantheon laufbar machen und maximal 6 Monate danach eine neue Ini)
    2. Servermerge (da es je server, außer auf Baldr, maximal noch je eine gilde gibt, die überhaupt eine neue, anspruchsvolle Ini clearen könnte)
    3. BK aus der Beta holen (performantere Server ODER Spieler je Seite einschränken, Türme einnehmen wieder erschweren, Tortwinks einschränken,...)
    4. 64 Bit Client
    5. Klassenbalancing (ja, es sind schon viele Klassen gut spielbar, aber ~80% der kombis sind trotzdem useless, was nicht sein müsste)
    6. Plussteine mit Abwertungschance entfernen
    7. Itemshop performanter gestalten

    generell wird aber nichtmal die Hälfte der Sachen bis zum Ende von RoM umgesetzt. Ich würde mich aber schon freuen, wenn von oben herein wenigstens 3 Punkte abgearbeit würden.


    Wenn alle Punkte abgearbeitet sind und dann noch Kapazitäten sind, kann man sich über andere Sachen gedanken machen.

  • Die letzte Performance-Änderung hat schonmal ein großes Problem von RoM scheinbar behoben/etwas verbessert: der temporäre Speicher leert sich mit der Zeit und läuft nicht einfach voll.

    Allerdings kann man unter gewissen Umständen trotzdem eine Überlastung des Clients erzeugen, indem die, für den jeweiligen Prozess reservierten Bereiche so schnell gefüllt werden, dass der Speicher nicht rechtzeitig wieder freigegeben werden kann (z.B. Hexer mit seinen Effekten und Speedbuff, um dann in kürzester zeit noch möglichst viele Umgebungs-Effekte in den RAM zu laden - siehe Noris video).


    Der derzeitige Client nimmt eine statische Aufteilung des für ihn reservierten RAMs vor. 32 Bit Systeme haben maximal 2 GB RAM zur Verfügung (2³² Byte = 4GB - 2GB für OS). Diese 2GB werden dann intern noch einmal aufgeteilt, wodurch für Effekte von Skills, Pets, Mounts, Skins,... noch ca 500mb übrig bleiben. Wenn man sich dann mal die Größe der jeweiligen Effekte/Skins anschaut (je nach Effekt bis zu 200kb und Skin bis zu 350kb/item) und man dann mal grob hochrechnet, dass pro Spieler damit gut und gern 3mb an Skins und je nach Anzahl der verwendeten Skills nochmal mehr daten in den Ram fließen kann man sich gut vorstellen, dass die 500mb recht schnell voll sind.

    Würde man die RAM-Verwaltung dynamisch gestalten, könnte das wohl auch noch mal eine Verringerung der krits bewirken, da dann potentiell mehr (bis zu 1,5GB) zur Verfügung stünde.

    Nichtsdestotrotz sollte eine Anpassung auf einen 64 Bit Client wohl auch von Entwickler-Seite ähnlich aufwendig sein, wie die interne Verwaltung des RAMs zu überarbeiten, mit dem unterschied, dass ein 64 Bit Client nur mit der Hardware limitiert wäre. Die durchschnittliche RAM-Nutzung sollte durch den 64 Bit Client nicht einmal nennenswert nach oben gehen.



    So oder so... ein performantes/nicht krittendes Game bringt einem auch nichts, wenn man sich einloggt und langweilt^^ (deswegen auch nur auf meiner persönlichen Wunschliste prio 4)

  • Der derzeitige Client nimmt eine statische Aufteilung des für ihn reservierten RAMs vor. 32 Bit Systeme haben maximal 2 GB RAM zur Verfügung (2³² Byte = 4GB - 2GB für OS). Diese 2GB werden dann intern noch einmal aufgeteilt, wodurch für Effekte von Skills, Pets, Mounts, Skins,... noch ca 500mb übrig bleiben.

    Spannend, aber leider falsch. Ein Adresszeiger ist ein "unsigned long", der kann als 32bit auch 3 oder 4 GB adressieren. Das Dein OS für sich soviel RAM zieht, ist Deinem OS sein Problem und kann zudem durch Abschalten von unnützen Autostartdiensten noch leicht verkleinert werden.


    Außerdem ist nur ROM 32Bit, nicht mehr das OS, was meint, daß ROM bequem 4 GB nutzen könnte, weil in dem reservierten Speichersegment kein OS vorhanden ist. Möglich macht das die MMU in der CPU, die Physikalisch verteilte Speicherblöcke zu virtuell zusammenhängenden Blöcken mappt.


    ROM in allllllll seiner Ausdehnung kommt übrigen mit allem an GFX was geht, grade mal auf 1.2 GB .. auch für 32Bit nichts besonderes. Das mag in der Ini poder bei Gruppeneffekten etwas steigen, aber viel wirds nicht sein. Ein Blick ins TOP zeigt das deutlich. (Linux rulz ; )


    Fest steht aber leider weiterhin, daß der letzte Patch in der Sache zwar eine deutliche Verbesserung brachte, aber irgendwo noch DoubleFree oder Nullpointerexceptions lauern, die auf Fehler in der Implementierung des MemoryPoolings hindeuten.

  • Da ich grad am Handy bin, fasse ich mich kurz.

    Zu dem max-Ram-Thema:

    https://www.technologyblog.de/…amme-unter-64bit-windows/



    Zum Thema der Maximalen Ram-Auslastung kann ich dir gern heut abend mal nen Screenshot schicken. Die Maximale Ram-Ausdehnung bei Rom auf max-grafik liegt bei knapp über 2 GB. Wenn man den Shop-Client abzieht (der gesondert adressiert wird), sinds bis zu 2GB, wobei der Client bei einer Überschreitung crittet.




  • Wenn Deine Beobachtung ist:


    "Das Spiel läuft ok bis es 2 GB Ram braucht, dann stürtzt es ab."


    Dann ist der Fehler vermutlich, daß im Programm kein "(unsigned) long" sondern ein "signed int" verwendet wird. Der würde bei 2 G einen Überlauf produzieren und das Spiel könnte sich (durch dummheit) selbst terminieren, indem auf Bereich zugreift, die gar nicht gemeint sind.


    Ein Bug, der oft vorkommt in C Programmen, aber gleichzeitig auch extrem leicht zu beheben wäre.

  • Ein Bug, der oft vorkommt in C Programmen, aber gleichzeitig auch extrem leicht zu beheben wäre.

    den dann auch nur der Entwickler beheben darf.


    Wenn Deine Beobachtung ist:


    "Das Spiel läuft ok bis es 2 GB Ram braucht, dann stürtzt es ab."


    Dann ist der Fehler vermutlich, daß im Programm kein "(unsigned) long" sondern ein "signed int" verwendet wird. Der würde bei 2 G einen Überlauf produzieren und das Spiel könnte sich (durch dummheit) selbst terminieren, indem auf Bereich zugreift, die gar nicht gemeint sind.

    nicht mein das jetzt nicht böse. aber ich schätze mal 98% den Spielern ist es vollkommen egal, woran das liegt. und selbst wenn es ein Fehler in der


    Matrix wäre. macht einfach das es nicht mehr ein Fehler ist. so denke ich mal gehen die meisten Spieler an die Sache ran. vorallem weil wir alle hier


    keinen Einfluss draufhaben.