View Full Version : Für alle Möchtegern-MMO-Entwickler
Hallo liebe Besserwisser, also alle Leute, die fordern, man möge ihnen den NC-SourceCode übergeben, weil sie ja sowieso alles besser können als KK. Hier ist eure Chance. Eine kostenlose MMO-Plattform, ohne Lizenzgebühren. Von alten Netscape-Industriehasen geschmiedet. Ladet euch das SDK runter und baut ein besseres Neocron: Multiverse (http://www.multiverse.net/)
Agrotóxico
10-08-07, 15:35
ich glaube fast du bist im falschen forum oder wer fordert hier sowas?
MrWeedster
10-08-07, 15:39
Muell.
Wenn dann wird alles von Grund auf Entwickelt inkl. Engine und Middleware.
greetz
Terror_Nonne
10-08-07, 16:02
Muell. - Wenn dann wird alles von Grund auf Entwickelt inkl. Engine und Middleware.
Mag ja sein, das dieser Weg noch besser ist, aber überhaupt mal angeschaut, bevor hier was von Abfall geredet wird?
Wird langsam mal Zeit fürn Open-MMO. :D SL ist net wirklich dolle.. :lol:
Make money through subscriptions, item sales, and/or advertising, and pay us only 10% of your gross revenue.
Das is ja mal echt clever! :cool:
Richtig Weedster, also.. okay.. engine geh ich noch mit. Das Ding selbst zu bauen braucht Zeit ;)
Aber der rest... wayne.
Naja, sagen wir so... Wenn die engine da is.. würd ich oberflächiger weise noch schnell nen Netcode zusammenstricken und fertig isn MMO (eher 3d chat) xD
Um nen NC nachzuempfinden.... mhm.. brauch schon etwas länger.
MrWeedster
10-08-07, 16:27
Wie jemand im Englischen Forum geschrieben hat: Das System ist nicht fuer FPS Style ausgelegt, sondern eher fuer Click'n'Wait Scheisse.
Also wenn ich persoenlich anfangen wuerde, wuerde ich erst mit der Q3 Engine experimentieren, und wenn die was taugt lizensieren. Netcode und FPS Orientierung brauchen wir glaube ich nicht zu diskutieren :>
Diese dann vernuenftig aufbohren (paar mehr Effekte, detailiertere Umgebung inkl. hoch Detailierten Models, sehr hohe Sichtweite), und danach mit Content fuellen.
Am besten waere dann natuerlich, DAS Shadowrun MMO zu machen. FPS Orientiert. Content waere bis zur Vergasung da.
Problem sind halt die Lizenzen, v.a. jetzt, wo MS selber anfaengt damit zu hantieren (Siehe den Crap SR MP Shooter). Der ist an und fuer sich zwar ganz nett, aber ohne tiefe ist das ganze SR Universum fuern Arsch.
greetz
Terror_Nonne
10-08-07, 16:39
Ich werds mir mal näher ansehen. Recht interessant, was auf der Site zu finden ist.
Wie jemand im Englischen Forum geschrieben hat: Das System ist nicht fuer FPS Style ausgelegt, sondern eher fuer Click'n'Wait Scheisse.
Also wenn ich persoenlich anfangen wuerde, wuerde ich erst mit der Q3 Engine experimentieren, und wenn die was taugt lizensieren. Netcode und FPS Orientierung brauchen wir glaube ich nicht zu diskutieren :>
Diese dann vernuenftig aufbohren (paar mehr Effekte, detailiertere Umgebung inkl. hoch Detailierten Models, sehr hohe Sichtweite), und danach mit Content fuellen.
Am besten waere dann natuerlich, DAS Shadowrun MMO zu machen. FPS Orientiert. Content waere bis zur Vergasung da.
Problem sind halt die Lizenzen, v.a. jetzt, wo MS selber anfaengt damit zu hantieren (Siehe den Crap SR MP Shooter). Der ist an und fuer sich zwar ganz nett, aber ohne tiefe ist das ganze SR Universum fuern Arsch.
greetz
Q3 ? Ne Teuer, nehmen wir doch einfach.. ööhm... ka TrueVision, TriBase (lol, mit der arbeite ich momentan... zum experimentieren), Irrlicht?! ;)
Im Grunde kannste solche Kits vergessen, ne Engine soll dir nen bissel Arbeitabnehmen beim Laden bzw. vorbereiten von D3D etc..
Bzw. Bisschen was an Matrizen und Vektoren anbieten, ohne das du selbst handanlegen musst. Noch ein schönes Texturemanagement und VFS,.. fertig :p
Terror_Nonne
10-08-07, 19:10
http://www.multiverse.net/videos/gdc_novoiceover.html
Mighty Max
10-08-07, 19:50
Cool, da braucht man nur nach Exploits im Framework suchen und kann gleich in allen diesen Games betrügen ...
Ala RPG-Maker-2000 "OnlineEdition": sicher 'ne nette Idee für den interessierten Hobbyisten. Ansonsten habe ich starke Zweifel an der Eignung für den Absatz der damit erstellten Welten.
Dr.Fallout
11-08-07, 00:27
Habs mir vor ein paar monaten schonmal angesehen... bin nicht so beeindruckt.
Graphisch ist das auf nem pre-SecondLife stand und auch sonst machts ein wenig verkorksten eindruck.
Das einzig interessante ist, dass die Entwickler sich die 'Firefly' Lizenz geschnappt haben, und wohl ein Firefly MMO auf multiverse entwickeln werden... eigendlich ist das aber auch eher schade, weil grade firefly was technisch besseres verdient hat!
Habs mir vor ein paar monaten schonmal angesehen... bin nicht so beeindruckt.
Graphisch ist das auf nem pre-SecondLife stand und auch sonst machts ein wenig verkorksten eindruck.
Das einzig interessante ist, dass die Entwickler sich die 'Firefly' Lizenz geschnappt haben, und wohl ein Firefly MMO auf multiverse entwickeln werden... eigendlich ist das aber auch eher schade, weil grade firefly was technisch besseres verdient hat!
Es kommt immer drauf an was die Entwickler daraus machen, seht eine Engine als eine riesengrosse Sammlung von Funktionen die einen helfen bzw. das entwickeln einfacher machen. Für die Art wie du sie nutzt... bist du selbst verantwortlich. Du kannst selbst mit so einer "Engine" Graphiken wie die von Crysis auf den Screen zaubern, blos musst du auch dafür entsprechen Hand anlegen. Siehe CryTek, wieviel Leute dahinter stecken ;)
Kurz: Eine Engine macht DX / OpenGL / Whatever einfach nur "bekömmlicher" auf Grund einfacher "Ansprechbarkeit".
Quanto Solo
12-08-07, 17:27
Im Prinzip finde ich die Idee gut. Durch die kostenfreie Verfuegbarkeit und, wie ich mal denke, komplett funktionierende MMOG-Rohplattform bietet sie gerade den kleinen Teams eine Moeglichkeit frische Ideen umzusetzen. Und wenn das mit der Vermarktung dann auch hinhaut, zB dank einem Zugpferd a la Firefly, ist das auch nicht schlecht.
Die Hoffnung das die grossen Entwickler mit Budget mal etwas anderes als den Mainstream bedienen habe ich aufgegeben, und wenn selbst Flying Labs mit dem eigenfinanzierten Pirates of the Burning Sea erst zeitaufwaendig verhandeln musste bis es einen Betreiber/Servicepartner gefunden hat der auf Entwicklungsmitsprache und Rechte am Spiel verzichtet dann will ich nicht wissen wie es da einem kleinen Team geht.
Nur leider habe ich auch so meine Zweifel an der Qualitaet, vor allem Graphik aber auch Netcode (Stichwort FPS-Faehigkeit) von Multiverse.
Ich will euch mal vom falschen Denken abbringen, also nochmal:
Eine Engine alleine bestimmt nicht letztenendes das aussehen der Graphik.
Allerdings rate ich von einigen Engines ab, da sie von den Lizenskosten in keiner relation zur Zeitersparnis stehen.
Quanto Solo
15-08-07, 06:00
Ich will euch mal vom falschen Denken abbringen, also nochmal:
Eine Engine alleine bestimmt nicht letztenendes das aussehen der Graphik.
Allerdings rate ich von einigen Engines ab, da sie von den Lizenskosten in keiner relation zur Zeitersparnis stehen.
Sie setzt aber doch Grenzen, ob die gezeigte Graphik aber jetzt die Grenzen der Engine oder der Faehigkeiten der Graphiker darstellen laesst sich so aber sicherlich nicht sagen.
Jo, Grenzen in der Geschwindigkeit / Verarbeitung.
Haben die Entwickler kein bisschen Plan von ASM, seh ich schonmal schwarz.
Jo, Grenzen in der Geschwindigkeit / Verarbeitung.
Haben die Entwickler kein bisschen Plan von ASM, seh ich schonmal schwarz.
ASM? Wie Assembler? Im Jahr 2007? SIMD Intrinsics sind da ratsamer.
ASM? Wie Assembler? Im Jahr 2007? SIMD Intrinsics sind da ratsamer.
Ne is eher Quatsch (keine Multimedia Berechnung) und ja ASM.
Da es "nur" Snippets im C / C++ Source sind, die auf LowLevel zugreifen (für eben die Geschwindigkeit) die dein Compiler sonst zu umständlich kompilieren würde, brauch ich kein SIMD Intrinsics.
Kurz: Wenn ich die ganze Zeit direkt so Hardwarenah programmieren will (also mit SIMD Technologie) wozu brauch ich dann noch Rasterizer wie DX, OpenGL, etc... ?
SIMD lässt sich hervorragend für Lineare Algebra nutzen, also Vektor/Matrix-Manipulation. Sprich die numerische Simulation die einem Spiel zu grundeliegt, und da ist ein Faktor 3-4 im durchsatz drin.
Klar können Moderne Graphikkarten da auch schon Teile von übernehmen, beispielseweise das Skinning, aber mit pre-DX10-Karten ist es problematisch(laaangsam) die Daten wieder aus dem V-Ram heraus zu bekommen.
Und zum Thema ASM vs. Complier Optimierung: Es gibt wenige Programmierer die es schaffen besser als in Compiler zu optimieren. Vorallem ist es meist die dafür verwendete Zeit nicht wert. Bevor man sich die Mühe mit ASM macht sollte man auf modernen Systemen eine gute nebenläufige Implementierung seiner Komponenten achten, da die CPU-Frequenzen langsam das stagnieren anfangen, hingegen die Kern zahl wohl stark wachsen wird. Dies ist jedoch für Spieleentwickler zum einen Neuland und zum anderen mit extra Hürden versehen da D3D und OpenGL inherent sequentiell sind.
Zumal C++ sich denkbar schlecht für Multi-Threading eignet und die alternativen den Ruf haben zu langsam zu sein.
Und DX und OpenGL benötigt man um die Sachen auf die Graphikkarte zu bekommen, da hat man auf Grund der Treiberarchitektur wenig andere Möglichkeiten.
Jo, Problem ist nur das hier wiederum nicht alle "älteren" Prozessoren SIMD unerstützen.
ASM in Quellcodes für Engines nutzen eine ganze reihe von Entwicklungstudios (alleine Schon wegen dem Geschwindigkeitsvorsprung gegenüber der Konkurrenz).
C++ und Multithreading? Möglich! Sogar einfacher als man sich es damals hätte vorstellen wollen. Problem bei Native C++ (unmanaged) sind Crosscalls etc,... Speicherüberschneidungen von fehlgemanagten Threads etc.
Managed C++ (.NET) hat den Nachteil langsam zu sein, weil die Manager "standarisiert" sind (also von allen Fehlerquellen ausgehen) und nicht spezifisch auf eine Anwedung.
Jedoch, gibt da auch wieder (begrenzte) Möglichkeiten, die .NET eigentlich fix laufen lassen.
Aber es soll ja sowieso bald eine neue C++ (C++ '09) kommen, da soll alles einfacher werden, gerade für Einsteiger.
Michael Corvin
15-08-07, 12:14
:wtf:
*kratz kratz*
:confused:
:p
Jo, Problem ist nur das hier wiederum nicht alle "älteren" Prozessoren SIMD unerstützen.
ASM in Quellcodes für Engines nutzen eine ganze reihe von Entwicklungstudios (alleine Schon wegen dem Geschwindigkeitsvorsprung gegenüber der Konkurrenz).
Die UE3.0 hat laut eines Interviews keine einzige Zeile Assembler. Wieso sollte sie? Damit sie die Sachen für PC/X-Box 360/PS3 jedes mal neu schreiben dürfen? Portablität ist wichtiger als 1-3% mehr Leistung.
Und SSE2 ist doch schon ne ganze weile verfügbar, sollte daher in den meisten Systemen vorhanden sein. Und wenn nicht, einfach ohne kompilieren.
C++ und Multithreading? Möglich! Sogar einfacher als man sich es damals hätte vorstellen wollen. Problem bei Native C++ (unmanaged) sind Crosscalls etc,... Speicherüberschneidungen von fehlgemanagten Threads etc.
Managed C++ (.NET) hat den Nachteil langsam zu sein, weil die Manager "standarisiert" sind (also von allen Fehlerquellen ausgehen) und nicht spezifisch auf eine Anwedung.
Und dann fangen die echten Probleme wie Deadlocks und Race-Conditions an.
Das hat man aber leider momentan bei den meisten Mainstreamsprachen, wenn man sich da im vergleich Erlang oder Stackless Python anschaut weiss man wie Nebenläufigkeit einfach zu erreichen ist.
Jedoch, gibt da auch wieder (begrenzte) Möglichkeiten, die .NET eigentlich fix laufen lassen.
Aber es soll ja sowieso bald eine neue C++ (C++ '09) kommen, da soll alles einfacher werden, gerade für Einsteiger.
Wenn .Net in der Performance in etwa mit aktuellen Java-Versionen vergleichbar ist, sollte es für 75%-85% der Gameengines reichen. Es ist bei vielen Anwendungen möglich weniger als 1% in der Garbage Collection zu verbringen. Bleibt noch der Overhead für Bounds-Checking bei Array usw. aber das ist eigentlich vernachlässigbar, da Arrays doch in vielen Fällen als Datenstukturen ausgedient haben.
Die UE3.0 hat laut eines Interviews keine einzige Zeile Assembler. Wieso sollte sie? Damit sie die Sachen für PC/X-Box 360/PS3 jedes mal neu schreiben dürfen? Portablität ist wichtiger als 1-3% mehr Leistung.
Und SSE2 ist doch schon ne ganze weile verfügbar, sollte daher in den meisten Systemen vorhanden sein. Und wenn nicht, einfach ohne kompilieren.
Ich bezieh mich nicht auf eine Engine, eines Herstellers -> JAIN
Es gibt genug sachen, die noch auf diesen alten kompatiblen Methoden gecodet werden, alle schon weil nicht jede Plattform SSE2 hat. (Das zum Thema Crossplatforming)
Und dann fangen die echten Probleme wie Deadlocks und Race-Conditions an.
Das hat man aber leider momentan bei den meisten Mainstreamsprachen, wenn man sich da im vergleich Erlang oder Stackless Python anschaut weiss man wie Nebenläufigkeit einfach zu erreichen ist.
JA
Wenn .Net in der Performance in etwa mit aktuellen Java-Versionen vergleichbar ist, sollte es für 75%-85% der Gameengines reichen. Es ist bei vielen Anwendungen möglich weniger als 1% in der Garbage Collection zu verbringen. Bleibt noch der Overhead für Bounds-Checking bei Array usw. aber das ist eigentlich vernachlässigbar, da Arrays doch in vielen Fällen als Datenstukturen ausgedient haben.
JA
JA
Ihhhgitt, Einverständniss in ner Forumsdiskussion is das überhaupt erlaubt?
Gute Frage :p
Warum sollte ich lügen? :p
Mighty Max
15-08-07, 17:55
Die UE3.0 hat laut eines Interviews keine einzige Zeile Assembler. Wieso sollte sie? Damit sie die Sachen für PC/X-Box 360/PS3 jedes mal neu schreiben dürfen? Portablität ist wichtiger als 1-3% mehr Leistung.
Und SSE2 ist doch schon ne ganze weile verfügbar, sollte daher in den meisten Systemen vorhanden sein. Und wenn nicht, einfach ohne kompilieren.
In Sachen Engine ohne physics, ist Assembler auch fehl am Platz. Neben der recht schwierigen händigen Optimierung (die Optimierungen vom Compiler und/oder Linker sind schon recht optimal), und die Performance wird an Stellen eingebüst, die nicht mehr der Kontrolle des Programms direkt unterliegen. Nen tree zu enumerieren erfordert nunmal den geringsten Aufwand, und bounding Box-Collisions sind nunmal auch keine Fleisaufgabe für die CPU mehr.
Für andere Bereiche allerdings ist Assembler Optimierung trotz der Portierungsprobleme gang und gebe. Schau dir mal den Source von mult-platform libs an.
Besonders SIMD oder die neuerdings schon in kleinen Anwendung moderne (dank Multicore) Parallelisierung (OpenMP, SMI) sorgt für die Wiederbelebung der HALs für spezifische Probleme, da hier durch Compileroptimierungen nichts zu gewinnen ist. (Die Semantische Analyse ist in diesem Bereich einfach nicht weit genug) Natürlich bleiben für die schnelle Portierung ein allgemeiner aber eben langsamer Code gepflegt.
Wir reden hier übrigends nicht über 1-3% sondern über wirklich markante Unterschiede. Wir reden hier über Vervielfachungen. Bestes Beispiel ist der Unterschied zwischen libmpeg2 auf nem ARM(1-9) mit und ohne asm-Optimierung. (Dank fehlendem nativen DIV)
Warum sollte ich lügen?
Das ist gar nicht nötig, hier hat sich als Standartstrategie in verschiedenen Messageboards das Aneinander-Vorbei-Reden als effektives Mittel der Konsensvermeidung erwiesen.
Wir reden hier übrigends nicht über 1-3% sondern über wirklich markante Unterschiede. Wir reden hier über Vervielfachungen. Bestes Beispiel ist der Unterschied zwischen libmpeg2 auf nem ARM(1-9) mit und ohne asm-Optimierung. (Dank fehlendem nativen DIV)
Meine Aussage klang zwar allgemein bezog sich aber eben auf Spieleengines wo praktisch nie mehr als 5% drin sein sollten.
Das aber in anderen Bereichen Optimierungen durch handgeschriebenes ASM möglich sind sollte auf der Hand liegen, da z.B. Annahmen getroffen werden können die ein optimiernder Compiler wegen fehlender Allgemeingültigkeit nicht treffen kann. Und die Situation auf dem ARM scheint ja auch eine ganz besondere zu sein.
Powered by vBulletin® Version 4.2.3 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved.