Beiträge von Annubis

Falls dir das noch helfen sollte, dann kannst du dir im neuen Blender (2.82 Alpha) das UDIM Feature anschauen. Mir erleichtert es sehr.

Bei Gebäuden solltest auch darauf achten, dass die Textur nur ein Teil der gesamten Fläche ist. Gerade Gebäude haben die Eigenart eine homogene Struktur zu haben. Ein Gebäudeseite ist nicht eine UV. Kacheln funktioniert hier super und spart ne Menge Rechenleistung und Speicher.

flip/flop sollte ne var erstparen und beim EventTick unbedingt nen delay einbauen, sonst hast bei 120 fps innerhalb von Sekunden ne riesige Zahl drinn stehen.

Zitat von Sleepy

Ich möchte nicht alles in den "FirstPersonCharacter" reinballern sondern in separaten Blueprints testen und dort brauche ich auch die Tastatur.

Nee, du nimmst den possesed Pawn und machst ein Interface. Im Pawn machst du noch einen Selector, damit du dein anzusprechendes TestBlueprint wählen kannst. Anschließend kannst soviele unabhängige BP machen wie du willst und alles seperat erledigen. Bsp: bei Drücken von "1" springt das Interface in deinem BP-A an und bei Drücken von "2" das BP-B. Über den Selektor im Pawn kannst du so auch an bereits "fertigen" Projekten arbeiten. Du kopierst den Funktionierenden BP und nennst ihn dann BP-Beta und wählst den im Selektor aus. wenn alles funktioniert, dann kopierst die Beta einfach über den Originalcode zurück und stellst den Selektor um. Dem Interface ist wurscht, wieviele BPs der anfunkt.

Bei Survival mag ich WeightBased. Da kommt Ark am besten drann. Durch das Gewicht lässt sich auch später noch Einfluss nehmen, sowohl bei den Gegenständen als auch beim Spieler.

Wenns ein Lootspiel ist, sagen wir PoE oder sowas, dann geschlossenes Inventar mit einer festen Anzahl an Slots und natürlich der Option mehr Slots freizuschalten. GrimDawn hat das relativ gut gemacht.

Die Option Stacks zu bilden, sollte immer da sein. Gerade bei "kleinen" Gegenständen ein "Muss".

Wenn Haltbarkeit eine Rolle spielt, dann kann man das entweder wie bei Minecraft lösen, was mehr Aufwand ist, oder wie bei Arc, jeden Gegenstand mit Haltbarkeit einzeln ablegen.

Du könntest dein Problem auch andersrum betrachten. In einem einzigen Level kannst du ein Universum verstecken. Der Spieler bewegt sich fast garnicht, immer wenn er sich von einem Objekt weg bewegt, dann schrumpfst du das Objekt. Dafür gibt es nun genug Möglichkeiten in der UE4. Bewegst sich der Spieler auf ein Objekt zu, skallierst du es größer.

Mars und Erde können so bspw. 2km auseinander liegen und trotzdem sind sie ewig weit getrennt. Das was du als Spieler wahrnimmst ist noch nicht das, was tatsächlich programmiert ist. Bestest Beispiel ist NoManSky. Da liegen die Planeten letztlich nebeneinander, die Immersion entsteht ausschließlich durch die Karte und die Entfernungsangaben.

Wenn es nur 3D wirken soll (Smartphone) dann definitiv mit einem Material. Wenn es tatsächlich 3D sein soll, dann auch mit einem Material

Du kannst das Material immer zur Kamera ausrichten. Die Füllmenge läuft über den Alphachannal. Ansonsten wie Sleepy schrieb, die Richtung über den Panner bestimmen.

Nimm ne Punktierte Alphamaske die du in Photoshop erstellst und leg sie über eine Sandtextur. Die Einfärbung kannst über den RGB Channel machen.

Such dir hier was aus, wandel es Graustufen um und dupliziere es in PS bis du deine Textur hast.

Du kannst bei YT auch noch nach UE4 Transition suchen, da gibt es auch von Zeit zu Zeit immer mal wieder neue und gute Tuts.

Sowas?

Grundsätzlich hat des erstmal nix mit Copyright zu tun, sonder mit Markenrechten/Trademark.

Designs kannst du erstmal immer machen, wenn keine Marke draufsteht. Die Coladose selbst hat keinen Schutz, sondern der Schriftzug der drauf steht. Bei Autos ist es letztlich nichts anderes. Die Ähnlichkeit kann ein sehr hohes Maaß haben, wenn keine Marken auf dem Auto stehen. Auch bei Waffen ist das grundsätzlich so. Eine 1:1 Kopie zu machen ist eh schon schwer genug und einen Designabweichung einzubauen, ist immer eine gute Idee.

Bei Epic sollte alles kommerziell nutzbar sein, da musst du die Bedinungen vom Store lesen, wenn ich mich recht erinnere, dürfen da nur Sachen eingestellt werden, die auch kommerziell nutzbar sind, was ja auch schon Sinn und Zweck des Shops als Entwicklershop ist. Abweichende Lizensvereinbarungen wirst du halt nicht finden, würde mich zumindest wundern.

Die Dateien zu den jeweiligen Meshes sollten alle aufgehoben und gesichert werden, besonders zwischenschritte (Backups), damit ihr notfalls nachweisen könnt, das ihr selber kreativ wart.

Wenn ihr alles selbst erstellt, dann braucht ihr euch kaum Gedanken machen, sofern ihr nicht nachstellt, was Markenrechtsschutz unterstellt ist. Typischer Fall ist halt ne Coca Cola Dose nachbilden. Wobei die euch sicher auch für die Werbung dankbar sind.

Konzepte sind nicht vom Urheberrecht umfasst. Die Beispiele die du da bringst, funktionieren bei Software sowieso nicht, da nur Code geschützt werden kann. Also die Problemlösung in Form des Codes unterliegt dem Urheberrecht. Da ihr eigenen Code schreibt, gibt es da kein Problem. Sicherungskopien anfertigen, damit der Weg nachweisbar ist.

International solltet ihr euch von einem Fachanwalt beraten lassen, dass übersteigt meine übliche Tätigkeit. Generell bekommt ihr am schnellsten Probleme, wenn ihr euch den Spielnamen nicht schützen lasst. Ansonsten würd ich den Vertrieb einschränken.

Beim Thema Jugenschutz müsst ihr euer Spiel einfach nur einreichen und bekommt dann eine Einstufung hier in Deutschland zurück. Des ist auch nicht problematisch.

Kauft ihr Assets oder ähnliches ein, dann bewahrt zu Nachweiszwecken die Verträge auf, wonach geregelt ist, dass ihr sie kommerziell nutzen dürft. Selbstverständlich ohne Widerrufsmöglichkeit oder zeitliche Befristung.

Leute, des was er will ist das System von Neverwinternights Online. Da prüft der Client auch, ob geänderte Leveldaten vorhanden sind und läd immer den aktuellsten Level vom Spiel runter.

Eigentlich musst du nur schauen, ob du die Bestandteile deines Levels statt einer lokalen Speicheradresse auch mit einer Referenz auf einem Server hinterlegen kannst.

Wenn das geht, muss du dann eine Routine an deinen Button anknüpfen, der prüft, ob du das angeklickte Level schon rutnergeladen hast und ob es Updates gibt, also zweistufig. Entweder er läd erst das ganze Level an einen lokalen Speicherort oder er ändert nur die Dinge, die sich durch ein Update geändert haben.

Letztlich willst du einen Download und einen Patcher der @Runtime funktioniert.

Denke mal, dass das geht, aber sicher nur mit C++.

Satisfactory, Path of Exile, Factorio, Factory Town, Stationeers, Ark, Frostpunk, Raft, Space Engineers

Des is halt die Grundlage, wie du die Variablen deiner einzelnen Objekte anlegst, hängt halt von dir ab, da gibts keine generelle Anleitung, weils halt jeder anders macht. Wenn dein Objekt selbst alles abspeichert, dann kannst du das gesamte Objekt als Variable abspeichern. Du kannst natürlich auch alles einzeln speichern. Hängt halt davon ab, wie du dein Spiel aufgebaut hast. Letztlich ist das SaveGame nur ein konsistenter Container.

Mach dir ein Makro. Füge das Makro ein deinen BP an und du kannst alles abspeichern, was dir wichtig ist.

Der Aufbau ist relativ simpel. Du nimst dein Objekt und leitest es an ein SavgameObjekt weiter. In dem Savegame ist ein Array, was sich selbstständig erweitert und die ID in den BP zurückgibt.

Am Ende prüft das BP nur, ob eine ID vorhanden ist oder nicht und ob eine Veränderung des Objekts eingetreten ist oder nicht. Ist keine ID vorhanden, dann wird es im SavegameObject ans Array gehängt und die ID wird ans BP gemeldet oder es hat eine ID bereits zugewiesen, dann wird im Array nur das Objekt mit den neuen Werten hinterlegt.

Im SavegameObject löschst du aber nicht aus dem jeweiligen Array dein Objekt per ID raus, sonder setzt es nur auf "nicht vorhanden". Die ID vermerkst du dann in einem extra Array als noch belegbar. Wenn dann ein neues Objekt anfragt, bekommt es die erste freie ID aus diesem Array.

Wenn du hingegegen aus dem Array ein Objekt ganz löschst, musst du sicherstellen, dass alle anderen Objekte die neue ID bekommen, was auf die Performance geht.

Die Anzahl der Arrays im SavegameObject, kannst du beliebig erweitern und deinen Übersichtlichkeitsbedürfnissen anpassen.

Die Grundlagen stehen alle in der Dokumentation. Stell dir das alles wie einen einzigen großen Container vor in dem nur maximale Ordnung herrschen muss.

Hey Leute, ich hab noch nen Xeon-Prozessor rumliegen und such jetzt ein gescheites Mainboard für das Ding. Ich kenn mich allerdings Null damit aus, da alle sonstigen Mainboards, die ich so aufm Schirm habe, keine Xeon unterstützen.

Das Board muss eigentlich nix weiter können. PCIe x16, Soundkarte und 64GB RAM sollte es unterstützen. Ansonsten ist der Rest ziehmlich egal. GLan-Anschluss unterstell ich mal als Standard.

Hat jemand nen Tip?

Du legst einfach einen Stencil in das Gebäude, so spielt es keine Rolle, wo oder wie das Gebäude steht, der macht automatisch ein Loch ins Gelände. Der Stencil ist natülich genauso groß wie die Gebäudeabmaße.

Das Prinzip ist das Selbe wie bei Schiffen und Wasser, nur das du dort eine vorgefertigten CustomStencil brauchst.

in dem Beispiel der Birne hat sie die gleiche ID, obwohl es zwei unterschiedliche Birnen sind. Bereits hier liegt der grundlegende Fehler. So etwas darf unter keinen Umständen passieren. Identifiziert wird hier die "richtige" Birne über den ArrayIndex.

wo auch immer die ID herkommt und wie dann der Gegenstand zugewiesen wird, da liegt in jedem Falle der Fehler. Nur tatsächlich identische Gegenstände dürfen die gleiche ID haben. ID=Identifikation. Bei zwei unterschiedlichen Objekten kann keine eindeutige Identifikation über die selbe ID erfolgen.

ItemDataBaseWaffen(Struct) ist ja letztlich schon begrifflich ein Widerspruch. Du kommst offensichtlich mit dem Aufbau nicht klar. Ein Struct ist eine benutzerdefinierte MultiVariable und keine DataBase.

Dein Post widerspricht auch deinem Ausgangspost. Dort beschreibst du drei Arrays. Ein Array kann Bestandteil eines Structs sein. Wenn du dann aber Gegenstände in einem Array ablegst, dann hast du eine Datenbank im technischen Sinne. Wie diese aufgebaut ist, regelt dein verwendetes Struct.

Dein Inventar wiederrum hat, wie ich dir gezeigt habe, einen Index für jedes Item was in deinem Inventar liegt. Wählst du ein Item aus dem Inventar aus, so steht über den Index eindeutig identifizierbar fest, welches Item zu ausgewählt hast, weil auf einem Index nur ein Item liegen kann.

Was du mit dem Item machen kannst, muss sich also aus deinem Inventar ergeben. Es muss ja irgendwo hinterlegt sein, um was für ein Item es sich handelt. Aus welcher Eigenschaft leitest du ab, was du mit dem Item alles machen kannst? Ich verwende in einem Struct ein TagArray. Hier werden Tags vergeben, die bestimmen, was für Interaktionen das Item erlaubt. Tags: Delete, Use, Build, Equip.

Eine Logik fragt dann diese Tags ab und ein Widget gibt mir dann aus, was ich machen will.

Im Lexikon habe ich Videos zum Inventar. Die sind zwar nur grundsätzlicher Natur, sollen aber eine mögliche Lösung näher bringen.

Die Empfehlung bei Spielen, die eine große Anzahl an Gegenständen verwalten sollen, ist immer ein DataTable. Auch diesen Aspekt versuche ich in den Videos näher zu bringen.

Deine Herangehensweise vermengt Programmierlogik mit dem BenutzerOverlay (HUD). Du weißt, dass du 3 Datenbanken für verschiedene Items haben willst (Waffen, Bauzeug, Essen).

Lege dir also 3 Structs an und füge alle Variablen ein, die die Eigenschaften dieser 3 Kategorien abdecken.

Beispiel:Waffen (Struct)

Name, Mesh, Thumbnail, SchadenMin, SchadenMax, Haltbarkeit, stabelbar?, Stabelgröße, DropChance, Unique?, handelbar?

Aus diesem Struct erstellst du einen DataTable. Jetzt kannst du alle deine Waffen in diesen Datatable integrieren.

Anschließend erstellst du dir dein Inventar. Dein Inventar ist ein Array mit beispielsweise 10 Slots. Dieses Array besteht wieder aus einem Struct also einem InventoryStruct. Die Bestandteile dieses Structs: Name, Thumbnail, Anzahl, DataTable

Wenn du jetzt aus einer Quelle (Boden, Kiste, Crafting) einen Gegenstand bekommst, ziehst du die Werte des Gegenstandes Aus dem DataTable und legst dein unter Berücksichtigung im Inventar ab. Wenn du jetzt ein Widget erstellst, dann nimmst du das Index des InventarArray und überdrägst es an das Widget. Dann kann das Widget den DataTable abfragen, was mit dem Gegenstand möglich ist und gibt dir die entsprechenden Optionen grafisch aus. Drückst du jetzt auf Löschen oder Ablegen, hast du im Widget die Position des Inventararrays und gibst diese Position an das Inventar zurück und löschst den Eintrag im Array.

Array:Inventar

Die Erstellung des Inventars erfolgt automatisch durch die gewählte Routine. Du prüfst, was auf Index 0 liegt und wo es herkommt. Wenn du ein Item ins Inventar verschiebst, speichert die Logik, wo das Item herkommt und welchen Index es dort hat.

Als zusätzlicher Hinweis: ein Widget gehört zu den Frontends. Es dient der Bedienung. Widgets bilden etwas ab. Die Logik erfolgt aber nie im Widget. Es geht nicht darum was du siehst, sondern was im Hintergrund abläuft. Das Widget dient nur dem Benutzer dein Spiel zu bedienen. Den Fehler hab ich am Anfang so häufig gemacht. Widgets empfangen Befehle und leiten sie weiter, berechnen aber nichts. Wenn du in deinem Widget eine Gamplaylogik hast, läuft schon was schief.

in deinem BP sehe ich garkein Sound. Der müsste doch am Ende der beiden Logiken angeschlossen sein?