|
|
|
|
| Zitat von Armag3ddon
| Zitat von X-Tender
Finde ich gut. Nur blöd das das Thema dann jetzt schon feststehen würde.
| |
Das ist doch hier kein krasser Wettbewerb mit Sachpreisen. Wenn du betrügen willst, dann tu eben, sonst fang erst am Stichtag an :P
| |
Ich meine ja nur. Könnten dann den Start einfach eine Woche nach vorne verlegen.
Brettspiele finde ich blöd weil sowas nur mit mehreren spielen Spaß macht.
|
|
|
|
|
|
|
Solang das Ende nicht auch vorgezogen wird, sonst passt das mit meinem Urlaub nicht mehr
Meinte auch nicht zwingend das mehrspieler Brettspiel 1:1 nachzubauen, sondern sich nur Elemente aus dem Spiel anzunehmen. Wenn das gewählte Spiel Monopoly wäre, wären zB folgende Ideen möglich: Egoshooter durch die monopoly Welt oder monopoly Wirtschaftssimulation oder Puzzlespiel mit monopoly tiles. Aber war auch nur ne spontane Idee, mir sind auch 5 Rnd Titel oÄ recht
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von Aclebeth am 11.09.2014 9:08]
|
|
|
|
|
|
Ne nur den start. Dann hat man eben 4 Wochen.
|
|
|
|
|
|
|
Wäre der Start dann nicht schon morgen?
|
|
|
|
|
|
|
Oder halt heute, Thema haben wir ja schon
|
|
|
|
|
|
|
Also nehmen wir das nun?
|
|
|
|
|
|
|
Ich würde sagen ja, also "Generator".
d.h. ein essenzieller teil des spiels soll irgendwie "Generiert" werden. sei es die grafik, das level, die AI, was auch immer. je besser man diese "Generierung" um setzt desto länger ist der E-Penis!
Ich werde dann den jamThread vorbereiten da ich heute noch zeit habe.
IT'S ON!
http://forum.mods.de/bb/thread.php?TID=213001
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von X-Tender am 11.09.2014 14:20]
|
|
|
|
|
|
Ich habe keine Ahnung was mit dem Thema gemeint ist
|
|
|
|
|
|
|
Irgendwas in deinem Spiel muss über Code generiert werden. Wie zum Beispiel die Spielwelt in Minecraft, die wird ja auch generiert. Und so soll es auch in deinem Spiel sein. Nur, dass es nicht zwingend die Spielwelt sein muss, sondern alles was du willst.
|
|
|
|
|
|
|
Ahh Ok.
Ich könnte also theoretisch den code von letzter Seite nutzen und einen Zufall einbauen und das wäre dann Ok?
|
|
|
|
|
|
|
| Zitat von Black1900
Ahh Ok.
Ich könnte also theoretisch den code von letzter Seite nutzen und einen Zufall einbauen und das wäre dann Ok?
| |
Dann ist der 1. "Preis" dir sicher!
|
|
|
|
|
|
|
Kommt drauf an was der Zufall macht. Wäre dann aber auch "ein wenig" albern
|
|
|
|
|
|
|
Die Zufallsgenerierung sollte schon relevant für das Spiel sein. Sprich wenn du jetzt per Zufall Wolken im Hintergrund generieren lässt, die nichts weiter machen als hübsch auszusehen, dann bist du am Ziel vorbei.
|
|
|
|
|
|
|
Verdammt, das war mein erster Gedanke!
|
|
|
|
|
|
|
Okay hab eine gute Idee, bin schon ganz fickrig. Nacher gehts los, erstmal alles installieren \o/
|
|
|
|
|
|
|
Nein. Ich brauche das für die Welt. Es soll jedes mal ein anderes layout erstellt werden. Mit unterschiedlichen Geländefeldern.
Mal sehen...
|
|
|
|
|
|
|
Was geht eigentlich theoretisch schneller: Ein dynamisches Arry (List in c#) mit sagen wir mal immer so 10-30 entries oder ein fixed Array[64] oder so durchsuchen?
Hintergrund ist, dass ich dieses Array quasi durchgängig accessen muss. Es werden ständig Dinge hinzugefügt und entfernt. Ich könnte mich damit anfreunden, dass ich mit einer maximalanzahl an einträgen klarkommen und immer wenn ich was adden will einen leeren slot suchen muss, falls das schneller ist, als List.Add und List.Remove.
Wie gesagt, das Array wird ausserdem auch von mehreren objecten in runtime durchsucht.
|
|
|
|
|
|
|
Wenn List in c# wirklich nur ein dynamisches Array ist, dann wird es keinen großen Geschwindigkeitsunterschied beim hinzufügen/löschen am Ende geben.
Wenn du auch in der Mitte löschen möchtest und die Reihenfolge der Elemente keine Rolle spielt, kannst du immer den Index des letzten Elements speichern und beim löschen von einem Element das letzte Element in die neue freie Position bewegen. Vorrausgesetzt Bewegen ist günstig. Dadurch bleibt dir das freie Position suchen erspart. Löschen und Hinzufügen( am Ende) bleiben in O(1).
Wenn du auch in der Mitte hinzufügen möchtest, dann wäre für kleine Größen ein dynamisches Array und für größere Sachen eine linked list besser.
/e3 Gedanken geordnet
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Krypt0n am 11.09.2014 17:26]
|
|
|
|
|
|
Beim durchgehen wäre das dynamische sicher schneller. (Beim fixen muss er immer die komplette Größe durchgehen).
Beim Hinzufügen geh ich jetzt einfach mal von nem stl vector aus, da ist es so dass es wohl langsamer wäre durch das stetige neuzuweisen von Speicher. (Wobei das auch nicht bei jedem hinzufügen passiert).
Ich vermute ein fixes durchgehen ist schneller als Add / Remove.
e/
| Compared to the other dynamic sequence containers (deques, lists and forward_lists), vectors are very efficient accessing its elements (just like arrays) and relatively efficient adding or removing elements from its end. | |
Denke fixe sind schneller
Auch wenn das jetzt nicht c# ist
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von Murica am 11.09.2014 17:32]
|
|
|
|
|
|
Ich kenne es auch so, dass fixed Arrays wesentlich schneller sind als Dynamische. Zumindest hab ich das in der Unity Documentation oft gesehn.
Add/Remove würde ich jedesmal brauchen wenn ich einen gegner spawne oder destroye, also vielleicht 5 mal in der Sekunde, was irgendwas um die "alle 5-10 frames" bedeutet. Ein Arry hält ALLE Gegner.
Accessen muss ich das Array aber von ca 10 Missiles aus jeden frame, die aus ner Formel aus Distanz und nem anderen Faktor berechnen auf welchen gegner sie jetzt zufliegen (fire and forget) Alle Faktoren können sich auch zur runtime ändern, weshalb die Missile immer up to date sein muss.
Das Array Durchsuchen ist also ungleich wichtiger als das Bearbeiten
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von freakadelle am 11.09.2014 17:35]
|
|
|
|
|
|
Willst du innerhalb des Arrays löschen, oder nur am Ende? Denn wenn du bei einem fixen Array innerhalb löschen willst, also z.B. delete array[5] (mal pseudo-mäßig dargestellt), dann rücken alle nachfolgenden Einträge bei einem fixen Array nicht nach (oder ist das bei C# anders?), sprich du müsstest dich selbst darum kümmern zu wissen, welche Stellen im Array jetzt frei und welche belegt sind. Finde ich ziemlich umständlich.
|
|
|
|
|
|
|
Ja das muss ich und das weiß ich. Aber die Reihenfolge spielt keine Rolle. Müsste bei jedem hinzufügen erstmal von vorne solange gegen null checken bis ich einen leeren gefunden habe.
Aber das wär ja ok wenns durchsuchen dafür schneller geht, denn adden/removen muss ich wie gesagt nur einmal alle 5 frames machen. ALLE entries durchsuchen muss 10mal pro frame machen
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von freakadelle am 11.09.2014 17:49]
|
|
|
|
|
|
Müssen denn wirklich alle in einem Array sein? Kannst du deine Spielwelt nicht aufteilen oder so?
/¤dit: Und wieso muss es 10 mal pro Frame durchsucht werden? Kannst du da nichts optimieren?
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Roter Fuchs am 11.09.2014 17:51]
|
|
|
|
|
|
Das ist alles auf einem Screen, bringt also nichts kleinere Arrays zu machen. Und 10 (ode rhalt "oft") pro frame muss ich durchsuchen, weil jede Missile die das array durchsucht ihren flugpfad anhand der daten berechnen muss und kursänderungen macht, wenn ein gegner im array aufgrund von "faktoren" zu einer höheren priorität wird. Das muss jede Missile aber selbst machen, denn da Entfernung und Winkel ne spezielle rolle spielen kann ich da nichts verallgemeinern.
|
|
|
|
|
|
|
Wir reden hier von 10-30 Elementen.
Semi related:
|
|
|
|
|
|
|
| Zitat von Krypt0n
Wir reden hier von 10-30 Elementen.
| |
Willst du damit sagen, dass ich einen Unterschied erst merken werde wenn ich da noch 1-2 Nullen dranhänge?
|
|
|
|
|
|
|
Kein Wunder hatte ich immer nur drölf FPS.
|
|
|
|
|
|
|
Ja. Aber ich habe keine Ahnung von C# und viele der "klassischen C/C++" Optimierungstechniken sind in C#/Java nutzlos. Außerdem ist Optimieren ohne vorher gemessen zu haben böse (oder so ähnlich).
|
|
|
|
|
|
|
Wir reden hier von C#... ich glaube das garantiert nicht einmal, dass die Werte des Arrays im Speicher hintereinander hängen, so lange du es managen lässt...
|
|
|
|
|
|
|
|
|
|
Thema: Das pOT erstellt Spiele 3 ( code code durrrr ) |