LecramOS said:
Hi...
Ich wollte mal fragen wie Ihr so eure Levels, für eure in C++ Programmierten Spiele, gestaltet.
da gibt es quasi "unendlich" viele möglichkeiten ;-)
Es gibt keine einzig richtigen weg der immer für alles gut ist - das ist so äähnlich wie deine frage eingangs im OOP thread, in der art "wenn ich hier *so* OOP mache, dann hab ich immre gewonnen und es kann nix mehr schiefgehen, gell?".
So funktioniert das nicht ^^
Also ob Ihr "Tiles" benutzt oder jede Kollisionsabfrage einzeln schreibt. ?
Was meinst du mit tiles vs. "einzelne kollisionsabfrage schreiben" ?
Ich könnte einniges raten, aber das lass ich mal ^^
Wobei ich gern mal auf dieses letzte substantiv eingehen möchte.
Das nervt mich nämlich ein bisschen, dass sich das in deutschland so ausgebreitet hat.
Meiner theorie nach durch halbwissende zeitschriftenschreiber (spielezeitschriften), die damals die beim C64 (und sicher manchen konsolen mit hardware tiles/scrolling + sprites support) durchaus berechtigte bezeichnung "Kollisionsabfrage" einfach für alles andere, was mit kollision zu tun hat, übernahmen: So heisst es denn für die auch heute noch beim komplexesten 3D spiel einfach "die Kollisionsabfrage in spiel xyz ist nicht so gut".
Wenn es aber wirklich eine kollisions-
abfrage wäre, wie damals auf dem C64, wo man dank hardware support nur ein register abfragen musste, ob gerade ein sprite mit einem anderen oder dem hintergrund kollidiert, dann könnte in verschiedenen spielen die kollisions"abfrage" gar nicht verschieden gut oder schlecht sein, weil sie immer die gleiche wäre ^^
Sehr viel treffender wären ausdrücke wie "Kollisionsberechnung", "Kollisionserkennung", "Kollisionsfeststellung" o.ä. (englisch collision detection) - denn das muss man nämlich selbst machen, wie du scheinbar weisst (nur bin ich scheinbar einer der wenigen dem das wort auf den geist geht *g*), das kann man nicht einfach "abfragen" wie früher beim C64 ^^
Jaja. Is ja schon gut. Ich bin für's erste fertig mit mosern über unwesentliche details, aber sorry, wenn ich bei gamestar oä. mal wieder was von der "Kollisionsabfrage" lese, rollen sich mir die zehennägel auf
Habe gehört es soll auch Leveleditoren geben. Davon möchte ich jedoch die Finger lassen, weil ich von Grund auf alles selbst erstellen möchte.
Macht es vielleicht Sinn sich selber auch erst mal einen Leveleditor zu Programmieren ?
Klar, warum nicht. Da du dich ja in OOP üben willst - das wär doch gleich n gutes übungsprojekt ^^
Ich weiss nicht, wieviel erfahrung du ansonsten mit der programmierung hast.
Wenn du noch mit irgendwelchen C++ GUI libraries für linux oder windows, oder gar noch mit einer anderen sprache/umgebung/framework (es gibt wirklich nettere möglichkeiten der entwicklung von tools als in C++ mit altbewährten GUI toolkits) handtieren müsstest, mit denen du dich noch nicht auskennst, wäre das evtl. ein weiterer stein im weg (oder übung aus anderer perspektive. Wie man's nimmt)
Vielleicht reicht für die anfänge auch erstmal ein texteditor zum erstellen der levels.
Oder du könntest natürlich, wie in alten tagen, einfach das bisschen zeug. was du für nen einfachen tile basierten editor mit vielleicht ner handvoll einstellmöglichkeiten GUI-mäßig bräuchtest, auch selbst zeichnen, zB. in einer SDL basierten anwendung. Das habe ich früher gemacht, nach dem umstieg von DOS auf Windows programmierung, wo ich keinen nerv hatte, mich mit der grässlichen Win32 API zu schlagen: einfach nur 1 fenstre erzeugt undmir von ner grafik library nen pixel buffer dafür geben lassen, und dann meine alten DOS GUI routinen hübsch weiter verwendet, was dann in windows zwar etwas fremd aussah, aber was solls ^^
Also eine rudimentäre GUI library entwickeln für das gröbste - im spiel bräuchtest du letztendich auch irgendsoetwas, für menü's, einstellmöglichkeiten etc. Also warum nicht was mehrfachbenutzbares schaffen.
Naja,
ich schmeisse jetzt hier wild mit möglichkeiten, sorry für die überflutung ;-)
Ich weiss nicht genau um deinen stand, und wo du als nächstes hin möchtest auf deinem weg als entwickler, was dir am wichtigsten ist etc.
Wie machen die erfahrenen Spieleentwickler unter Euch das so ???
Alle tools selbst zu entwickeln, wäre sicher etwas zuviel zeitwaufwand. Bei 3D spielen soetwas wie modelling + animationsprogramme selbst zu machen, bei den guten programmen, die es gibt, wäre fast schon verrückt - ausser man will sowieso unbedingt so ein programm schreiben zum spaß ^^
Damit meine ich character / object modelling & animation..
Level editoren nehme ich davon aus, denn je nach engine können die bedürftnisse da doch so speziell sein, dass allemal ein fettes plugin für eine 3rd party lösung angesagt wäre, oder eben gleich eine flexiblere komplette eigenlösung.
Was deinen tiles editor betrifft - ich kann mir schon vorstellen, dass es da generische, standard lösungen gibt, mit denen man dann levels für durchschnitts tile-basierte spiele erstellen kann, da gibt es ja nun inzwischen doch etablierte standards und die gemeinsamkeiten, oder was bei den unterschieden zwischen genres berücksichtigt werden muss, sind bekannt.
Ich kenne da aber keine beispiele.
Da ein editor für so eine art spiel aber nicht soooo irrsinnig aufwendig sein sollte, seh ich keinen grund, warum man den nicht mal selbst basteln sollte.
Der kann dann nur das, was du brauchst, und zwingt dich nicht, dinge so zu machen, wie sie für deine zwecke eher umständlich wären - etwas, das man bei sehr allgemein gehaltenen lösungen schnell mal hat.
Ich selbst entwickle tools mit C# in .NET (ja .NET, auf dem pöööhsen windoofs! nicht Mono,
) (es ist witzig, dass hier tux für mich die zunge herausstreckt, haaahaa! *g* )
, bin bekennender liebhaber dieser sprache/framework ^^ Java = pfui, nach meinem persönlichen geschmack ^^ Aber das wäre sicher auch noch ne gute option statt nativem C++ kram für tool dev, wobei ich mich mit aktuellen Java GUI biliotheken gar nicht auskenne und daher dazu nix sagen kann.
Ich vertrete jedenfalls die ansicht, dass da, wo es performancemäßig nicht unbedingt nötig ist, man sich nicht mehr mit sowas wie nativer C++ entwicklung herumplagen sollte.
