Beiträge von Scrayos

    Heute konnten wir nun auch Marcel Reif bei uns als Developer willkommen heißen. Er wird fortan die Web-Entwicklung, vor allem durch Design und Gestaltung unterstützen und hat damit eine Schlüsselrolle in Bezug auf die neuen Verbindungen sowie unser Panel. Wir freuen uns auf die gemeinsame Zusammenarbeit!

    Wir haben CentrixDE Gestern (04.12.2017) als neuen Entwickler ins Team aufgenommen. Er wird sich fortan hauptsächlich mit dem Instandhalten der neuen Infrastruktur, dem optimieren der vorhandenen Infrastruktur und der Überwachung eben Jener befassen. Wir befinden uns ja immer noch in der Umstellung auf die vollständige Docker-Architektur, weshalb wir ihn genau zur richtigen Zeit für unser Team begeistern konnten.


    Darüber hinaus habe ich es leider verpasst, Moritz30 als neues Mitglied des Teams bei uns willkommen zu heißen. Er ist am 13.10.2017 unserem Team beigetreten und befasst sich mit der Weiterentwicklung von JCGuardian, unserer eigenen innovativen AntiCheat-Lösung. Sobald diese fertig ist, können wir damit die Vielzahl öffentlicher AntiCheat-Plugins, auf die wir leider aktuell angewiesen sind verbannen und damit wieder Performance sparen und nervige "False Positives" bekämpfen.


    Wir freuen uns auf eine gute Zusammenarbeit!

    Die JayCee-Belohnungen für Votes, die vor dem offiziellen Release (07.07.2017) getätigt wurden, wurden nun mit einem Umrechnungskurs von 1000 JayCee/Vote gutgeschrieben. Der niedrigere Kurs ergibt sich aus dem größeren Zeitraum und der enormen Summen die daraus resultieren.

    Dieser Thread dient als Ort für kleine Zwischen-News, die etwa im Umfang von Twitter-Posts sind und daher nun einen kleinen (aber oft wichtigen) Inhalt vermitteln sollen. Diese entsprechenden Nachrichten werden also chronologisch als Antworten hinzugefügt. Es lohnt sich also diesen Post im Blick zu behalten, sofern man nicht auf unsere sozialen Präsenzen schaut und dennoch auf dem Laufenden bleiben möchte.

    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.

    Das ging mir bei der "Frage" leider ähnlich. Tut mir leid das ich euch nicht behilflich sein konnte. Vielleicht hat ja ein anderes Team-Mitglied mehr Geduld mit euch. Ich supporte prinzipiell ebenfalls gerne, aber bei einer solch provokativen "Fragestellung" bin ich eher davon abgeneigt hier wirklich Hilfe zu leisten.

    Oh, da scheinst du dich in dem Teil der Website vertan zu haben. Das ist leicht zu erkennen daran, dass oben "FORUM" grün ist. Du suchst aber den "BUGTRACKER", der direkt daneben ist. Kein Problem, passiert selbst den Besten mal.


    Und wenn man einen Fehler im Singular meint, dann würde man schreiben "Fehler der das Spielerlebnis versaut". Aber kein Problem, habe dich trotzdem verstanden.

    Hui, du bist aber vorbildlich!


    Klar! Der PvP ist so etwas wie unser Pilotprojekt. Danach sind zahlreiche weitere Server vorgesehen. Aktuell arbeiten wir sogar schon an einer Vielzahl an Konzepten gleichzeitig. Konkret geplant sind bislang:


    Citybuild: Unser Citybuild-Server versteht sich als eine umfangreiche Wirtschaftssimulation mit Grundstücksbau, dem Handel als zentrales Element zum Fortschritt, damit verbunden die Firmen und Berufe. Spieler versuchen durch cleveren Handel und sinnvolles Investment ihren wirtschaftlichen Vorteil auszubauen. Dadurch sind dann auf verschiedensten Bauwelten wieder Grundstücke kaufbar, die nach Herzenslust gestaltet und bebaut werden könen.


    Besonderer Clou: Wir arbeiten mit "Shards" (Das sind Welten, die aus einer Kombination von Umwelt und Epoche/Thematik bestehen), die es einerseits ermöglichen extrem skalierbar zu bleiben was die maximale Spieleranzahl betrifft (eine einzelne Shard hält etwa 300 Spieler aus) als auch unseren Spielern mehr Vielfältigkeit zur Verfügung stellt. Mögliche Shard-Kombinationen sind zum Beispiel: Vorgebirge-Jetztzeit (Map), Winter-Mittelalter oder Strand-Steampunk. Diese Shards (4096*4096 Blocks groß) werden dann von unserem Bauteam erschlossen und es wird in der ohnehin schon aufwendig von uns terraformten Map eine Vielzahl von Gebäuden (Ruinen, Windmühlen, etc) errichtet, sowie bestimmte Gimmicks eingeflochten (Spielbares Schachbrett/4 Gewinnt/Aussichtsturm mit Zoom-Funktion/etc). Und in diese umfangreich gestaltete Karte werden dann Sockel für Grundstücksplätze eingefügt. Die kann man dann kaufen. Und weil so eine Shard ganz schön groß ist, kann sie auf Straßen und Wegen mit dem eigenen Auto (Verschiedene Modelle/Leistungsdaten) erkundet werden.



    RPG: Das RPG-Konzept ist wahnsinnig umfangreich und damit schwierig in ein paar Sätzen zu umreißen. Hilfreich zu wissen ist vielleicht: Wir verzichten auf feste Klassen und Berufe sondern setzen auf "Superskilling" -> Umso mehr du eine bestimmte Aktion machst, desto besser wirst du darin. Du wirst jedoch auch schlechter wenn du sie lange nicht mehr machst/viel anderes machst. Darüber hinaus besitzen die verschiedenen Fähigkeiten komplizierte Abhängigkeiten zueinander. So bringt dir das Schwertschwingen beispielsweise auch einen 10%-igen Lernfortschritt im Axtkämpfen weil ... naja es geht halt bei Beiden ums Schwingen!


    Besonderer Clou: Wir setzten erstmals im großen Stil "Phasing" ein. Gebiete verändern sich massiv mit dem Questfortschritt, du kannst die Welt individuell beeinflussen, die Quests basieren auf deinen Entscheidungen, kurz gefasst: Die volle Packung Einfluss aufs Spielgeschehen!



    Creative: Unsere Lösung für Bau-Teams und Kartenerstellung. Jedes Bauteam (Kann jeder erstellen) erhält einen eigenen Server der ganz normal über den Hub-Server erreicht werden kann, auf dem unlimitiertes WorldEdit/JCEditor zur Verfügung stehen und Karten direkt mit einem Prinzip ähnlich Steam-Greenlight in unseren Kartenpool der Minispiele aufgenommen werden können.



    Bloodline: Ein auf Elytren, Movement, Taktik und Übersicht basierendes rasantes Minispiel, bei dem nicht mit dem Inventar jongliert werden muss (Yay, Inventar-Legastheniker an die Macht!) und bei dem man mal so richtig der Blutlust nachgehen kann. Das Minispiel ist ganz nach der Devise "Einfach zu verstehen, Schwer zu meistern" aufgezogen. Genauere Details folgen in Zukunft.



    Ich hoffe ich konnte deine Frage schon einmal grob beantworten. Mit weiteren Infos werden wir zum gegebenen Zeitpunkt unser Wiki füllen.