Virtualisierung des Creatives

    Wir planen zum Release den Creative-Server zu "virtualisieren". Das bedeutet, dass jede "Baueinheit" ihren eigenen Server erhält, auf dem isoliert die entsprechenden Maps bearbeitet werden können. Dies bedeutet nicht nur eine Verbesserung der Performance sondern eröffnet auch neue Möglichkeiten und sichert das Konzept entsprechend ab. Für Bauteams besteht hier also kein Problem. Was ich hier aber zur Diskussion stellen möchte ist:

    • Wie sollen die Kriterien für die Gründung eines Bauteams aussehen?
    • Wo bauen einzelne Spieler?
    • Wie viele Maps haben Bauteams zur Verfügung?
    • Wie viele Maps haben einzelne Spieler zur Verfügung?
    • Wie lange sollen Maps geladen bleiben, nachdem der letzte Spieler offline gegangen ist/von der Map gegangen ist?

    Das soll es erst einmal gewesen sein. Ich freue mich auf Rückmeldungen! :D

    Wo bauen einzelne Spieler?
    Wie viele Maps haben einzelne Spieler zur Verfügung?


    Ich würde erst einmal sagen, dass einzelne Spieler grundsätzlich nur als Team Maps bauen sollten.
    Mir ist klar, dass es viele Spieler gibt, die in der Lage sind eine Map alleine zu gestalten, aber da dies nicht immer bzw. selten der Fall ist und die Maps auch recht zügig fertiggestellt werden sollten, wäre es besser in einem Team zu arbeiten.


    Was die Anzahl der Maps betrifft: Ich würde vorschlagen, dass sich die Anzahl im Allgemeinen an der Anzahl der Spieler definiert, die in einem Team bauen.


    Ich hoffe ihr versteht was ich meine ;)

    Moin Moin :thumbup:

    1. Bei den Kriterien würde ich mal sagen; mind. 4 Leute sollten für das Team bereit stehen und darunter sicher einer den man vom Server-Alltag etwas kennt.


    2. Ich find einzelne Spieler sollten keine Möglichkeit dazu haben. Dafür sollte man in einem [lexicon='Bauteam'][/lexicon] sein oder eine spezielle Genehmigung von Admin oder Supermod.


    3. Sage maximal 2. Damit nicht zu viele angefangen werden und dann schliesslich nichts fertig gestellt wird, da schon wieder neue ideen Spriessen.


    4. Das hat sich ja schon geklärt. :3


    5. Würde auf die 2 Monate schätzen. Da vielleicht der jenige Schulproblem oder etwas in der Art hat. Nach Nachfragen kann man die Zeit ja dan verlängern, wenn man später wider weiter bauen möchte, doch die Zeit zu diesem Zeitpunkt nicht findet.
    Und bis der Server down fährt würde ich 10 min machen, vieleicht giebt es ja Internet-Probleme. :thumbup:


    mfg Haimdall

    • Wie sollen die Kriterien für die Gründung eines Bauteams aussehen?
    • Ich denke, dass eine eher höhere mindest Anzahl von fünf Spieler nötig sein sollte, damit die Maps recht zügig fertig gestellt werden können.


    • Wo bauen einzelne Spieler?
    • Sie könnten ja kleinere Maps zur verfügung gestellt bekommen. Dann kann man Teile, mit dem Einverständnis des Erbauers, in andere Maps hinein kopieren.


    • Wie viele Maps haben Bauteams zur Verfügung?
    • Erstmal nur eine. Aber man kann sich für eine zweite Maps "bewerben", oder natürlich eine zweite geben, wenn die erste fast fertig ist.


    • Wie viele Maps haben einzelne Spieler zur Verfügung?
    • Eine kleinere.


    • Wie lange sollen Maps geladen bleiben, nachdem der letzte Spieler offline gegangen ist/von der Map gegangen ist?
    • Ich denke mal fünf Minuten sind eigentlich eine gute Zeit.

    Mal sehen wie es raus kommt :rank-[lexicon='bauteam'][/lexicon]:

    @Apenix


    1. bin ich etwa gleicher Meinung.


    2. Das würde zu viel Support aufwenden. :thumbdown::P


    3. Das ist widerum genau das Support Problem das der Server später einiges mehr Spieler haben wird und es wichtiger Sachen zu tun gibt.


    4. -


    5. Würde etwas mehr Zeit geben, da vielicht mal das Modem aussteigt. Weil der Servers nach dem herunterfahren mehr Leistung braucht, als wie wenn er noch ne weile laufen würde.

    • Wie sollen die Kriterien für die Gründung eines Bauteams aussehen?

    Meiner Meinung nach sollte die Gründung eines Bauteams nicht künstlich erschwert werden. Minimale Grundvorraussetzungen in die Richtung mindestens 3 Mitglieder und eine durchschnittliche JC-Activity von X wären dennoch sinnvoll.


    • Wo bauen einzelne Spieler?

    Für einzelne Spieler würde ich Shared-Server im einer Art Plot-System anbieten, da anders ein zu hoher Ressourcenverbrauch entstehen würde. Eventuell erstellt man aber auch einfach ein Bauteam mit dem Namen "JC-Community" und einzelne Spieler können dort mit entsprechender JC-Activity eine Map / einen Subserver erhalten.


    • Wie viele Maps haben Bauteams zur Verfügung?

    Das würde ich eventuell in Quadratblöcken bemessen, da Map ein sehr unklarer Begriff ist. Einen angemessenen Wert kann ich mir gerade nicht ausdenken - werden diesen aber zeitnah nachtragen.


    • Wie viele Maps haben einzelne Spieler zur Verfügung?

    Exakt eine, Premium Spieler, Promoter und der Gleichen Zwei und auf begründete Anfrage auch mehr.


    • Wie lange sollen Maps geladen bleiben, nachdem der letzte Spieler offline gegangen ist/von der Map gegangen ist?

    Standartmäßig 10-15 Minuten, jedoch denke ich das der Wert bei begründetem Nutzen für einzelne Bauteams von einem Moderator / dem Bereichsleiter für den Kreativ auf bis zu 60 Minuten ausgedehnt können werden sollte.

    You think focusing is about saying "Yes." No. Focusing is about saying "No." And when you say "No," you piss off people.

    Ehrlich gesagt bin ich wieder ähnlich irritiert, wie anfangs über den PvP-Server...


    Chunk! it! up!

    Guten Abend,


    hier (in teilweiser Zusammenarbeit mit @Scrayos) eine kleine Antwort für Dich:


    Limits sind durchaus ein extrem relevanter Part des Kreativ-Systems. Hauptsächlich liegt dies an den Kosten für entsprechende Hardware. Hier ist auch eher der RAM als die Festplatte zu bedenken, aber auch die gibt es leider nicht umsonst. Auch wollen wir das System von Anfang an skalierbar betreiben. Bei <= 20 Servern ist das Ressourcen-seitig sicherlich kein Problem, bei höherer Nachfrage steigen jedoch die Serverkosten deutlich an. Die Anzahl an Servern lässt sich an dieser Stelle letztendlich nur durch Vorteile für Spielergruppen gegenüber Einzelpersonen minimieren.


    JC als Bezahlung für Server oder Erweiterungen ist technisch zwar realisierbar, jedoch tauschen wir dann eine unendliche, digitale Währung gegen reale Produkte für die wir Geld bezahlen müssen.


    Hierzu ein Zitat vom Big Boss:

    Zitat von Scrayos

    Für JC verkaufen wir nur unerschöpfliche Ressourcen, wie z.B. Pets, Auren und Ingame-Items.


    Zur Unterscheidung einzelner "Map-Typen": Für uns ist nicht der Inhalt der Map, sondern deren pure Existenz relevant. Faktoren wie das Terrain kommen nur sehr kurzatmig zum Zug.


    Gruß
    Prof.Logout | Marco
    :rank-bauteam:

    You think focusing is about saying "Yes." No. Focusing is about saying "No." And when you say "No," you piss off people.

    Etwas konkreter: Die Dauer, in der es im Ram-liegt könnte mit der Teamgröße Skalieren. Man könnte dazu versuchen vorherzusagen, wie wahrscheinlich es ist, dass der Kreativ demnächst erneut genutzt wird. Etwa über die kürzlichen Spielzeiten.
    Eine einfache Variante wäre, die tägliche Nutzungsdauer einer Map festzuhalten (z.B. für 7 Tage). Die am stärksten genutzten Maps haben eine höhere Priorität als wenig genutzte, die zuerst aus dem Ram fliegen. Damit wären kleine Teams nicht benachteiligt, wenn sie die Map reichlicher nutzen als große Teams.


    Anhand eines Konzeptes sollten wir vielleicht versuchen zu prognostizieren, wie lukrativ ein Kreativ sein kann. Ich sehe natürlich vor Allem den Vorteil, dass er uns fertige Objekte bringen könnte, der den Bau der anderen Server beschleunigen kann. Diese können schneller expandieren und damit kann er indirekt Gewinne einfahren. Insofern würde ich bei der Konzeptionierung zumindest darauf achten, Gamification offen zu lassen.
    Zudem könnte es schon reichen, wenn er gelangweilte Spieler im Netzwerk ein paar Stündchen bei Laune hält, bis sie wieder Lust auf die Anderen Server haben (->bindung).



    Wenn dennoch die Vorteile nicht überwiegen dürften, dann sollte auch der Aufwand gering gehalten werden.
    z.B.:
    - Jeder hat eine Kreativwelt mit Worldboarder. Wächst ggf. durch Spielzeit
    - Man kann leute in seine Welt einladen, die dann dahin porten können und bestimmte Rechte haben (z.B. Bauen, Zeit Ändern, ??)= Bauteams
    - Nach x Tagen nicht-nutzung folgt eine Mailerinnerung, sowie im netzwerk
    - Wenn wir auf Gameification verzichten, wäre der Server entsprechend langweilig und wird nur von denen reichlich genutzt, die auch einfach nur Bauen wollen. Die geringe Entwicklungszeit ist vielleicht "billiger", als viel Zeit für komplexe teammechaniken zu verschwenden.



    Szenario 2: Mittlere- große Vorteile


    Meine Vorschläge:


    Opfersystem
    -----------
    - Man besitzt nur eine Lobby+ eine Welt. Will man eine neue, kann man sie /opfern. Man hat die Wahl, sie bewerten zu lassen.
    - Kuratoren werden dadurch informiert, können dort hin porten und eine Bewertung 0-100 angeben. Aus dem Score wird eine Belohnung generiert (z.B. JCs oder Kreativgeld*)
    - Sollten aktuell keine Builder im Kuratorenteam sein, weisen Koratoren die Builder auf besonders gelungene Objekte hin, damit diese vor dem löschen ggf. gesichert werden und an anderer Stelle verwendet (z.b. beim rpg oder dem citybuild).
    - Man kann andere Spieler anheuern und ihnen einen frei aushandelbaren Arbeitslohn geben. So kann man unternehmerisch tätig sein: mit den Einkünften z.B. mehr Terrains erwerben, größere Teams anheuern, bessere Sachen realisieren... Stufe 3: profit.


    Kreativgeld
    ----------
    Für verbrachte zeit, eingesendete Objekte, Events, Arbeit als Kurator, Videos gibt's Kreativgeld mit dem der Kreativshop bedient werden kann. Dort kann man Sachen machen wie:
    - bestehende Welten vergrößern
    - neue Themes freischalten (Nether, Ende, ...)
    - Weitere Welten hinzukaufen
    - Copy&Paste Presets (z.B. wenn man Straßenlaternen nicht immer Manuell bauen Möchte. Für Denizen gibts da sehr schicke Builder btw... die bauen einem eine Blueprint in Echtzeit nach und so so schonender als schnelles copy&pasten)
    - Npcs und Tiere
    - Permissions (Permaday, Zeit gezielt ändern
    - Lava/Wassereimer
    - Speedbuffs
    - Spielautomaten
    Wenn finanziell nötig: Nicht eingesendete, also offene Welten verursachen leichte Kosten


    Der Shop könnte in Form eines NPCs gestaltet sein, der als Buttler dient und in der Lobby wohnt.
    Extra: Die Lobby ist ein eigenes zu Hause im Stil der RPG-Void, dass man nur von innen sieht. Haustiere wie Katzen und Hunde können im KreativShop oder JCs erworben werden.



    Nur jetzt nicht im Just Chunks Fanshop:
    Chunk Wars Episode 2 - Die Rückkehr der Klotzkrieger

    Ein Update, weil es zunehmend Sinn macht, diese Diskussion wieder aufzunehmen. Mit dem Begriff "Team" sind immer auch Teammaps gemeint


    Unverifizierte Benutzer:

    - 1 Map

    - 1 Team

    - 1Gb Ram

    - 5 % CPU

    Maps werden nach 7 Tagen Inaktivität gelöscht


    Verifizierte Benutzer

    + 1 Map(2)

    + 2 Teams(3)

    + 1 GB Ram(2)

    + 1 GB Ram/aktivem Mitglied (max 10)

    + 5% CPU(10)

    Maps werden nach 32 Tagen gelöscht. Nach 29 Tagen erfolgt eine Warnung per Mail.


    Premium

    + 1 Gb Ram extra, wenn mind. 1 Premiumspieler im Team

    + 5 % CPU, wenn mind. ein Premiumspieler im Team(->15%)

    Maps werden trotz Inaktivität nicht gelöscht (32 Tage zählen erst nach Ablauf von Premium)


    Promoter

    + 2 Gb Ram/Promoter (wenn online) im Team

    + 10% CPU (->25%)

    + 2 Maps (4)

    + 1 Team (4)

    Maps werden nach 63 Tagen gelöscht.


    Bauteam+

    + 2 Maps (6)

    + 1 Team (5)

    Teammaps für JC-Projekte werden von einem Administrator angelegt


    Shopitems

    Einmalig:

    - Solomap

    - Teampass (+1 Team)

    - Schriftrolle der Permanenz (hält eine Map so lange vor, wie JC existiert|ggf.: Erlaubt den Download durch Außenstehende)

    - Poweruserpackage: +5Gb Ram, +5%CPU, +2 Maps, +2 Teampässe, +1 Schriftrolle d. Permanenz (Für Profis, bzw. Leute,die zu viel Geld haben)

    - Themes (default: Flat, normal=2k JCs, Large biomes=10k, Ende=25k, Nether=50k)


    Monatlich:

    - Ram

    - CPU Power (+10%, +20%, +40%, +70%) [Promoter+Poweruser+CPU70=95%]


    Am besten wäre es natürlich, wenn man schon die Scrolls als Währung hätte, die auch mit JCs gekauft werden können.


    Um Abschließend auf die Teamfrage einzugehen: In diesem Modell profitieren größere Team durch mehr Ram. Die Bonuseffekte von premiumspielern/promotern wirken sich nur dann aus, wenn diese online sind, wodurch ich genug Anreize sehe, große Teams zu bilden.

    Meine Kommentare/Ideen basieren alleine auf dem letzten Post von Aristos. Ich denke so viel Transparenz wie wir sie hier zu schau stellen könnte man sich auch mal von anderen Projekten wünschen:

    • Spieler haben ein Hauptteam, können aber unlimitiert vielen Teams beiwohnen. Das Hauptteam wird öffentlich angezeigt und ist das einzige Team dessen Limits sie anheben. Dadurch kann man bei beliebig vielen Projekten beiwohnen, ohne dabei mit dem System schindluder treiben zu können.
    • Lediglich Mitglieder können Teams gründen, Gäste Teams aber auch beiwohnen. Gäste erhöhen für kein Team die Limits um einen zusätzlichen Anreiz zur Verifikation zu schaffen/zu verhindern, das Personen mit .... drölfmilliarden Accounts (beispielsweise über Account-Dispenser) mit Leichtigkeit die Maxima erreichen können.
    • Solomaps halte ich nach wie vor für eine schlechte Idee, da sie das System völlig verkomplizieren. Stattdessen steht es ja jedem offen innerhalb eines Bauteams diese Maps so zu nutzen. Es ist einfach unheimlich wichtig die Maps einem Bauteam zuweisen zu können, da ich sonst nicht effektiv die Ressourcen managen/drossel kann und die Maps nicht einfach isolierbar sind (im Sinne von Command-Blocks, Zeit-Umstellung, Wetter-Umstellung, Chat, Teleport, Permissions, etc.).
    • Maps werden nur dann gelöscht, wenn keines der Mitglieder eines Bauteams (das dieses Team als Hauptteam ausgewählt hat) für X Tage online war. In diesem Fall wird das Bauteam dann auch aufgelöst. Hier würde ich allerdings mit den Limits nicht geizen, da dem Service sonst (gerechtfertiger-weise) eher mit Argwohn begegnet wird und Festplatten-Speicher spott-billig ist. (Wir haben über die Server verteilt aktuell etwa 20TB).
    • Poweruser-Package muss monatlich sein (und dringend einen anderen Namen kriegen :P), andernfalls lässt sich die zusätzliche Last nicht mit einem einmal-Betrag kompensieren. Außerdem können wir so flexibler die Leistungen verteilen/einteilen und müssen uns nicht unnötig Klötze an die beine Binden (durch Nutzer die vielleicht Monate nicht spielen und dann wieder kommen, wir aber gar nicht so viel Leistung zurückgehalten haben, weil sie in letzter Zeit nicht gebraucht wurde [Natürlich kann sowas nur bei mehreren Leuten gleichzeitig auftreten]).
    • Die Idee mit den Themes halte ich für völlig deplatziert, da es hier um das Entfalten von Kreativität geht und nicht darum Nutzer so gut wie möglich in ihrer Kreativität einzuschränken. JayCees können sicherlich in das System eingebunden werden (via JayCee-Shop) aber Themes sind sicherlich nicht der richtige Weg. Hier würde ich eher an "Kurzzeit-Boosts" der Leistung denken, oder aber an Map-Import-Credits (Export muss immer möglich sein) oder die Nutzung von Entitäten/NPCs.
    • Das Ressourcen nur dann erhöht sind, wenn die jeweiligen Spieler online sind halte ich für sinnvoll, da sich so weiter das Problem der Account-Dispenser angehen lässt, bzw. diese Ressourcen ja auch nur benötigt werden, wenn mehrere Spieler gleichzeitig an der Map arbeiten. Übrigens kleine technische Notiz für mich: Jeder Spieler hat eine eigene "Block-Modification-Queue" die die ausstehenden Block-Änderungen durch JCEdit beherbergt. An welcher Queue in einem Tick gearbeitet wird, wird per Round-Robin-Verfahren entschieden, so das effektiv und effizient an mehreren Aufgaben gleichzeitig gerechnet werden kann.
    • Unserem JC-Bauteam soll es auf keinen Fall an Ressourcen mangeln. Hier müssen wir sinnvolle Werte ermitteln (durch Tests) bei denen es (auch bei intensiver Last) zu keinen CPU-induzierten Verzögerungen kommt. Das Bauteam verrichtet einen wichtigen Teil der Server-Entwicklung und sollte ressourcen-technisch entsprechend bedacht werden. Außerdem gelten selbstverständlich keine Map-Limits sowie Team-Größen-Limits.
    • Ich halte ein gewisses over-commitment der zur Verfügung stehenden Ressourcen für sinnvoll. Ein Faktor von etwa 5-10% sollte hier ökonomisch gesehen vorteilhaft sein und sich nicht negativ auf die Performance auswirken. Denn es ist äußerst unwahrscheinlich, das alle Bauteams gleichzeitig alle die volle zugewiesene Last verbrauchen. Dadurch würden wieder Ressourcen brach liegen, die wir so ebenfalls benutzen können. Der Faktor sollte jedoch an Real-Beispielen/Test ermessen werden, da ein zu niedriger Faktor Verschwendung wäre und ein zu niedriger Faktor die Performance negativ beeinflussen würde.
    • Ich halte eine Unterscheidung von "aktiven Maps" und "archivierbaren Maps" für durchaus angebracht. Archivierbare Maps ist hierbei die Anzahl jener Karten, die überhaupt von uns aufbewahrt werden (aber nicht zwangsläufig gleichzeitig geladen werden können); aktive Maps ist dann die Anzahl der Karten, die gleichzeitig geladen und bebaut werden können. Hier ergibt eine Unterscheidung meines Erachtens nach Sinn, da nicht immer an allen Projekten gearbeitet wird, aber Projekte nach einer gewissen Zeit gerne wieder aufgenommen werden (beispielsweise wenn man eine neue Inspiration gewonnen hat).
    • Auf jeden Fall sollte es eine Art Client-Performance-Indikator geben, der einen universellen "Score" errechnet, wie angenehm die Karte für den Client zu rendern ist. Dabei spielen beispielsweise Lichtquellen, Entitäten, eingeschlossene Luft, Schilder, Tile-Entitäten und Größe eine Rolle. Dieser "Score" dient nicht dazu, die Erbauer zu limitieren, sondern ihnen einen sinnvollen Wert zu geben, der Aufschluss darüber gibt, inwiefern später beim Spielen Lags entstehen können. Hier könnten wir ggf. sogar genaue Werte mit einer "Headless"-Minecraft-Instanz machen, die die Maps tatsächlich austestet, um möglichst akkurate Werte zu erhalten. Dieser automatische Test würde so JayCees verbrauchen, andernfalls wird nur der "synthetische" Score angezeigt, der künstlich berechnet wird.

    Weitere Ideen folgen ggf. in Kürze.