|
|
|
|
Yeah. Noch nie in einem Spiel implementiert. GameJams sind dafür einfach nicht prädestiniert In Unity erstaunlich simpel. Zum Abspeichern braucht man in der regel recht wenig. Prefabname der statefull objekte, Vector/Rotation, relevante Script variablen.
Dann noch die Kunst die Prefabs "bootstrap" sicher zu gestalten. Hier haste deine gespeicherten Werte, jetzt benehm dich wie abgespeichert
Kann jetzt sowohl dynamisch neue TMX Maps + Objekt Layer importieren wie auch "fertige" Map-Prefabs samt Statefull Items laden.
|
|
|
|
|
|
|
Was genau ist das speicherformat?
|
|
|
|
|
|
|
|
|
|
|
Und auf die Antwort hab ich jetzt fast 24h gewartet.
|
|
|
|
|
|
|
Bin auch ein bisschen enttäuscht
|
|
|
|
|
|
|
| Zitat von freakadelle
Machst du alles nur in blueprint?
| |
| Zitat von Murica
Jop.
C++ fang ich immer erst an wenn es mit Blue Prints zu kompliziert wird / nicht mehr geht, oder die Performance zu schlecht wird
| |
Wobei mir jetzt im Moment die Bugs etwas auf die Eier gehen
Manchmal wechselt der Nodes nicht richtig aus.
Sie scheinen zwar ausgetauscht, aber nach dem compilen / blue print bzw projekt neu öffnen ist wieder das alte da.
Hier zum Beispiel:
Die Plasma Level Variablen sind falsch.
Ersetze (im Sinne von drüber ziehen, nicht löschen und neu setzen) ich sie nun durch die richtigen Repair Level Variablen, steht zwar repair da (bis zum neu öffnen), Plasma wird aber trotzdem noch genutzt.
Total banane.
|
|
|
|
|
|
|
| Zitat von freakadelle
Bin auch ein bisschen enttäuscht
| |
Sorry, hätte es JSON sein sollen? Oder meinst du die GameData Klasse welche ich via BinaryFormatter serializiere und in eine Datei speichere?
|
|
|
|
|
|
|
Speichern und laden hatte ich mir aber einfacher vorgestellt. Klar - wenn du nur einfache Objekte ohne verknüpfungen hast, ist es überschaubar. Aber komplette GameObjects abspeichern ist ein Ding für sich. Diskussionen darüber finden sich auch an vielen Stellen im Netz. Was ich nervig fand war die Tatsache, dass die Dokumentation von einem serializable Vector3 spricht, es im Endeffekt aber nie nativ funktioniert hat?!
Mein kleines Spielchen hängt derzeit an der Grafik... bin einfach kein Grafiker... So ein bissel von allem kann ich, aber bei einem einfachen Interface hört es schon auf.
|
|
|
|
|
|
|
| Zitat von [HDK+]BigBoss
Aber komplette GameObjects abspeichern ist ein Ding für sich. Diskussionen darüber finden sich auch an vielen Stellen im Netz. | |
Die Rede war von GameData und nicht ganzen GameObjects.
Zum Beispiel ein NPC:
|
Code: |
// --- NPC Build ---
// Active, prefab, position, rotation
[Serializable]
public class NPCData {
public bool active;
public SerialVector3 position;
public SerialQuaterion rotation;
public string prefabName;
public override string ToString () {
return String.Format("Player:( Active : {0}, position: {1}, rotation: {2}, prefab: {3})", active, position, rotation, prefabName);
}
} |
|
| Zitat von [HDK+]BigBoss
Was ich nervig fand war die Tatsache, dass die Dokumentation von einem serializable Vector3 spricht, es im Endeffekt aber nie nativ funktioniert hat?!
| |
Scheint so.
Deswegen auch:
|
Code: |
[Serializable]
public class SerialVector3 {
public float x;
public float y;
public float z;
public override string ToString () {
return "Vec3:( x: " + x +", y: "+y+", z: "+y+")";
}
} |
|
|
|
|
|
|
|
|
Klar, ich habe einfach den Gedanken weitergestrickt. Ich dachte das war durch das "Aber" ersichtlich Bei meinem Projekt mit der Generierung einer kleinen Stadt inkl. Verkehr hat mich das schon gewurmt. Sobald Objekte mit Scripts und generierten Texturen dazukommen, gleicht es einem Overkill für "nur speichern". Mich würde es ja interessieren, wie das bei der Konkurenz so ausschaut.
|
|
|
|
|
|
|
Speichern kann ganz schön kompliziert werden.
---
Im Moment komm ich nicht so wirklich vorwärts, scheiss Arbeit.
Aber - Pew pew!
|
|
|
|
|
|
|
pew pew.
|
|
|
|
|
|
|
Du bist ja schon relativ weit. Fängst du also bald was neues an?
|
|
|
|
|
|
|
Wird langsam Zeit
Wohl sobald alles fertig ist und ich es nur noch schön machen müsste /o\
|
|
|
|
|
|
|
| Zitat von Murica
Wird langsam Zeit
Wohl sobald alles fertig ist und ich es nur noch schön machen müsste /o\
| |
Die Engine proggen macht halt leider am meisten Spaß :P
|
|
|
|
|
|
|
| Zitat von anoX*
| Zitat von Murica
Wird langsam Zeit
Wohl sobald alles fertig ist und ich es nur noch schön machen müsste /o\
| |
Die Engine proggen macht halt leider am meisten Spaß :P
| |
Naja bei mir ist es oftmals so (zumindest bei Freizeit Projekten), dass ich irgendwann an einem Punkt ankomme, wo ich zwar weiss welche Baustellen noch offen sind, aber nicht so wirklich Lust hab sie anzugehen.
Dann denke ich mir "Kümmerst dich erstmal um die Visuals".
Nach 10 Minuten merke ich dass ich es nicht kann, schließe Photoshop / Maya und das Projekt ist tot
In diesem Sinne, fertig für heute. Danke Poxboxrox (wer auch immer du bist) für deinen Skriem Besuch, hätte mich gerne noch mehr über Kackschemel unterhalten!
|
|
|
|
|
|
|
| Zitat von Murica
Dann denke ich mir "Kümmerst dich erstmal um die Visuals".
Nach 10 Minuten merke ich dass ich es nicht kann, schließe Photoshop / Maya und das Projekt ist tot
| |
This. Mehrfach erlebt. Nur leider werden Peter Molyneux + ArtistCrew nicht spontan aushelfen.
Durchbeißen geht nicht?^
Die letzten "10 Prozent" sind bekanntlich die schwierigsten. Aber da muss man halt entscheiden ob man a) Spiele gerne entwickelt oder b) Spiele auch unbedingt veröffentlichen will.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von anoX* am 05.03.2016 16:40]
|
|
|
|
|
|
| Zitat von anoX*
Durchbeißen geht nicht?^
| |
Muss
Heute bis jetzt mal nur um die Bugs gekümmert.
Und wenigstens mal ein wenig "Planung" aufgeschrieben
|
|
|
|
|
|
|
| Zitat von Murica
Und wenigstens mal ein wenig "Planung" aufgeschrieben
| |
Top!
Hier unser derzeitiges Arma 3 Trello:
|
|
|
|
|
|
|
|
|
|
|
Heute ist mir endlich mal ne Idee gekommen wie ich die Health Anzeige bei Räumen (vorübergehend) machen kann. \o/
Gegner können nun endlich auch Räume zerstören. (Gegen Ende)
Sorry für die Musik, war nicht geplant.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Murica am 06.03.2016 19:56]
|
|
|
|
|
|
Wir haben Freezetime \o/
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Murica am 08.03.2016 6:03]
|
|
|
|
|
|
Was für ne NavMesh/Grid Solution benutzt du? Das inhouse navmeshin runtime generiert oder A* in deinem Raumgrid?
|
|
|
|
|
|
|
Eigentlich wollte ich A* nutzen, aber da es im Moment noch kein C++ Projekt ist, das inhouse.
Mit BluePrints A* nachbauen war mir dann doch zu doof
Wobei ich mit dem Inhouse keine Probleme (mehr) habe. Das Movement sieht noch nicht so gut aus, kann man aber relativ leicht verbessern. Solange sie ankommen wo sie sollen.
Der Bug beim selektieren der NPCs geht mir hart auf die Eier.
Habs letztens soweit gefixt bekommen dass man nun wenigstens von allen Kamera Ansichten selektiert bekommt.
Aber irgendwas spackt immernoch hart.
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Murica am 08.03.2016 4:03]
|
|
|
|
|
|
SOllte das nicht sowieso einfach die screen pos der units gegen ein rectangle im screenspace checken? ALso komplett Kameraunabhängig sein? Oder wie machst du das?
Hier hatte ich damals maln auswahlrahmen eingebaut. Ist wie gesagt komplett unabhängig von Kamerawinkel, weil er einfach die worldpos der units im screen space gegen die box im screenspace checkt. Und dann halt in nem array hält was gerade in der box ist und was nicht:
Ich hab vorn paar Tagen A* bei mir eingebaut. Das ist wesentlich weniger code als ich immer dachte.
Das eigentlich komplizierte ist eher die Generierung des Grids, was aber bei dir kein problem sein sollte. Sind halt einfach die Raumteile.
Bei mir können gegner an Wänden laufen UND ich muss das Grid direkt nach der procedural level generation bauen. Das geht momentan beides nicht mit Unitys recast navmesh, weshalb ich mir was eigenes bauen musste. Aber A* an sich sind erstmal nur zwei Klassen und ne kurze pathfinder-funktion. Das sollte in blueprint eigentlich machbar sein
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von freakadelle am 08.03.2016 11:17]
|
|
|
|
|
|
Naja für X / Y Winkel reicht ein normales Rechteck im Space, haste recht.
Bei mir kommt allerdings der Z Winkel der Cam dazu. D.h. das Rechteck muss sich noch drehen.
Allerdings ist das nichtmal das Problem, das funktioniert soweit glaube ich.
Das Problem ist eher die Half-Size, vermutlich weil BoxTrace ne Sphere zum Tracen nimmt (wtf?)
Sorry für den Kuddl Muddl in der Mitte. Bei der Half Size geht's um den Radius der Sphere.
Mouse Location Start (Worldspace) - Mouse Loc End, geteilt durch 2, Negativen Values zu Plus = Radius
Keine Ahnung was da falsch ist.
|
|
|
|
|
|
|
Das ist genau der Ansatz den ich eben nicht genommen hätte. Sondern für jede Unit die SCREENSPACE coords kalkulieren und gegen eine box im screen space (nicht world space) checken. Das wär dann nämlich nur sowas wie (pseudocode):
|
Code: |
foreach (UnitClass unit in unitsArray)
if(unit.worldToScreenpos.x > rect.xMin && unit.worldToScreenpos.x < rect.xMax)
if(unit.worldToScreenpos.y > rect.yMin && unit.worldToScreenpos.y < rect.yMax)
selectedUnits.Add(unit);
|
|
Brauchst weder RayCasts, noch dich um die KameraRotation kümmern. Du musst nur irgendwie die WorldPos der Units in Screenspace umwandeln. Unity hat da zB FUnktionen für, die dir einmal den Screenspace geben (Vector2 von 0 bis Auflösung in Pixeln) oder Viewport Space (Vector 2 von 0 bis 1).
Dein Rectangle sind natürlich auch nur 2-4 Punkte im gleichen Space
e: Die BoxTrace Funktion von Unreal ist ja anscheinend ein Physicstest. Ziemlicher overkill für einen selection frame
|
[Dieser Beitrag wurde 4 mal editiert; zum letzten Mal von freakadelle am 08.03.2016 17:40]
|
|
|
|
|
|
Ohhhh, ja das ist ein guter Ansatz.
Garnicht dran gedacht, top.
| Zitat von freakadelle
e: Die BoxTrace Funktion von Unreal ist ja anscheinend ein Physicstest. Ziemlicher overkill für einen selection frame
| |
Schon
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Murica am 08.03.2016 17:43]
|
|
|
|
|
|
|
|
|
Geilo \o/
|
|
|
|
|
|
|
Thema: Das pOT erstellt Spiele 3 ( code code durrrr ) |