Willkommen ~Gast!
Registrieren || Einloggen || Hilfe/FAQ || Staff
Probleme mit der Registrierung im Forum? Melde dich unter registerEin Bild.
Autor Beitrag
000
07.11.2009, 14:47
AlexS

Moin Leute,

ich code gerade ein wenig an der Critical Engine, eine Engine von mir geschrieben zum erstellen eines First Person Shooters, basierend auf DirectX 9c. Alles funktioniert wunderbar, sogar unser Hammer ähnlicher Map-Editor wurde bereits Einwandfrei implementiert.
Die Engine bietet Shader, KI (low level) und einen im Testlauf funktionierenden Multiplayer code.

Jedoch sitze ich gerade an der Waffen- und Munitionsverwaltung und wollte nachfragen, ob jemand eine bessere bzw. effektivere Idee zur implementierung hat.

Vorweg wird Waffe und Munition via Definitionsfile geladen.
Eine Waffe sieht z.b dann so aus:


-- Der Name, der im Spiel auch angezeigt wird
name = "M4"
sprite_name = "m4.png"

-- Das Verzeichnis indem die Modelle liegen
root = "m4"

-- Der Modellname inkl. Animation
object = "p_m4.dbo"

-- Sounds

shoot1 = "m4_shoot.wav"
shoot2 = "m4_glaunch.wav"
empty = "m4_empty.wav" -- Gilt für beide Feuermodi
reload = "m4_reload.wav" -- Gilt nur für das erste Feuermodi

-- Animationen

-- es gibt 4 verschiedene Animationsstufen (Schiessen1, Schiessen2, Idle, und Nachladen der primären Munition)

-- ani1 ist Idle
ani1_start=1380 -- gibt den Startpunkt der Animation an
ani1_end=1500 -- Endpunkt
ani1_speed=15 -- Geschwindigkeit

-- ani2 ist Feuermodus 1
ani2_start=0
ani2_end=300
ani2_speed=1000

-- ani3 ist Feuermodus 2
ani3_start=1500
ani3_end=1740
ani3_speed=500

-- ani4 ist Nachladen
ani4_start=300
ani4_end=1380
ani4_speed=150

-- Der Modus schaltet zwischen Einzelschuss (0) und Dauerfeuer (1)
wpn1_mode=0

wpn2_mode=1

prim_ammo="556"
sec_ammo="HE_grenade"

-- Maximal mögliche Munition im Magazin
-- bei "=0" gibt es unendlich viel Munition (z.B bei Stichwaffen)
prim_ammo_max=30
sec_ammo_max=8

-- Die "rate of fire" für primäres Feuer in msec
prim_rof=150

-- Die "rate of fire" für sekundäres Feuer in msec
sec_rof=1500

-- Die "rate of fire" für primäre Nachladen in msec
reload_rof=3000

Eine Munitionsdefinition folgendermaßen:

name="556"

-- als effect bezeichnet man die Art des Verschusses
-- 1= Patrone, 2= HE Granate, 3= Rakete

effect=1 --byte

-- größt möglichster Schaden
damage_max = 40 --byte

-- Schadenstolleranz
damage_tolerance = 20 --byte

-- Hier kommen die Startwerte, die der Spieler beim Enginestart erhält.
-- Dies ist kein muss, da je nach Level die Munition vergeben werden kann.

ammo=30 --byte
ammo_reserve=100 --byte

Jeweils Waffe und Munition wird in einem eigenen Array mit allen Daten abgespeichert.
Jedoch bin ich mir nicht sicher, ob es eine sauberere Möglichkeit gibt, den
ganzen Krams zu verwalten.
Kennt jemand eine bessere Lösung?

Für Interessierte, welche Ergebnisse die Engine liefert, gibt es hier einen, leider etwas veralteten, Screenshotbereich:
http://www.online-arts.de/Pics/sc.htm

--

____Maps____________________________
[fy_barpark] [aim_assault_oa] [sc_dojo]
[sc_buro_prologue]

Dieser Beitrag wurde am 07.11.2009 um 14:48 von AlexS bearbeitet.
zum Seitenanfang zum Seitenende Profil || Suche
001
08.11.2009, 10:38
Adrian_Broher
Admin

Zitat:
AlexS postete
Jeweils Waffe und Munition wird in einem eigenen Array mit allen Daten abgespeichert.
Jedoch bin ich mir nicht sicher, ob es eine sauberere Möglichkeit gibt, den
ganzen Krams zu verwalten.
Kennt jemand eine bessere Lösung?
Eine bessere Loesung fuer was?

--

There is nothing wrong with high standards. It's your problem that you don't meet them.
If you think it's simple, then you have misunderstood the problem.
When a customer says "nothing has changed", assume they're lying.
zum Seitenanfang zum Seitenende Profil || Suche
002
08.11.2009, 12:13
AlexS

Eine Lösung für einen schnelleren Zugriff.
Z.b werden im Array der Waffe Zahlen eingetragen, die immer konstant bleiben.
Andere jedoch ändern sich. Diese Information werden via Type in das Array eingebunden.
Gibt es Speedvorteile, wenn ich die Konstanten und Variablen jeweils in ein seperartes Array lege?

Leider bringt mit ein Test mit 1mio Abfragen nichts, da die Geschwindigkeit dieses Prozessors varriert, dass ich keine geeigneten Testergebnisse bekomme.

--

____Maps____________________________
[fy_barpark] [aim_assault_oa] [sc_dojo]
[sc_buro_prologue]
zum Seitenanfang zum Seitenende Profil || Suche
003
08.11.2009, 17:22
hausi

Du solltest ohnehin nie Code optimieren, ohne dass du dort Performance-Probleme hast. Also schreibst du ihn am besten so, dass er einfach verständlich ist und wenn du schlussendlich eine schlechte Performance hast, kannst du mit Profiling-Tools einmal durchgehen und die Flaschenhälse suchen. Ich denke nämlich nicht, dass eine Waffen-Definition, auf die vielleicht 2-3 mal pro Sekunde darauf zugegriffen wird auf die Gesamtgeschwindigkeit einen grossen Einfluss hat.

--
zum Seitenanfang zum Seitenende Profil || Suche
004
08.11.2009, 18:24
AlexS

Leider wird, und dass geht nicht anders, in jedem Schleifendurchlauf das Array aufgerufen um die Animationsdaten auszufragen.

--

____Maps____________________________
[fy_barpark] [aim_assault_oa] [sc_dojo]
[sc_buro_prologue]
zum Seitenanfang zum Seitenende Profil || Suche
005
08.11.2009, 18:53
Bluthund

Zitat:
effect=1
Warum hier kein sprechender Name, wie den ammo-Einträgen?

Zitat:
--byte
Warum nicht einfach (32Bit-)Integers für alles was Ganzzahl ist. So fällt dir der Datentyp wenigstens nicht auf die Füße wenn jemand ein MG mit 300 Schuss Ersatzmunition definieren will.

Vorweg: Ohne Messung hast du kein Performanceproblem. "Premature optimization is the root of all evil."
Die Anpassung der Prozessorgeschwindigkeit, kannst du afaik (meist über den entsprechenden Treiber) auch deaktivieren.

Ich verstehe auch deinen Ist-Zustand nicht so wirklich.
Unter anderem auch wegen so Aussagen wie:

Zitat:
Diese Information werden via Type in das Array eingebunden.
"Via Type etwas in ein Array einbinden"? Reden wir hier von einem Datentyp für Datentypen wie System.Type in .NET oder type_info in C++?
Ein normales Array speichert in vielen Sprachen nur Daten eines Datentyps ab. Damit kannst du ja schon erstmal nicht Zeichenketten und Ganzzahlen in das selbe Array packen (außer über Vergewohltätigungen wie union, was in vielen Fällen zu Code führt den niemand lesen/warten will). Wäre gut wenn du zu dem Punkt mal etwas mehr Input liefern könntest (e.g. Pseudocode für die Zieldatentypen; Oder packst du tatsächlich alle gelesenen Werte einfach nur in ein Array?!).

Die Daten, die du da einliest sehen mir alle nach wunderbaren Kandidaten für Konstruktionsparameter für eine Waffenklasse aus. Sprich: Alle Waffendefinitionsdateien parsen, anschließend Instanzen der Waffenklassen konstruieren und die Referenzen darauf dann in einen Container für den späteren Gebrauch im Spiel packen. Für alles was im Nachhinein änderbar sein soll (e.g. durch den Mapper), gibst du der Waffenklasse öffentliche Änderungsmethoden/Eigenschaften für die Membervariablen/Felder/Instanzvariablen - passende Termini je nach verwendeter Sprache selbst wählen ;)

Wenn du nicht immer iterieren möchtest, um zur entsprechenden Waffe zu kommen, kannst du ja einen Container benutzen der seine Inhalte über Keys direkt anspringt (e.g. std::map oder std::multimap [C++ STL], System.Collections.Generic.Dictionary [.NET]).

--

The C language combines all the power of assembly language with all the ease-of-use of assembly language.
"humorig is n blödwort :>" by -CarniGGeLjumpR-

Dieser Beitrag wurde am 08.11.2009 um 18:56 von Bluthund bearbeitet.
zum Seitenanfang zum Seitenende Profil || Suche