Dies ist mal ein temporäres Thema über den SceneGraph und das Entity System.
(Dementsprechend hauptsächlich für die Leute, die daran mitbasteln.)

Erste Sache:
Ich wollte anfangen mal ne schematische Übersicht über das Entity zu erstellen. Jetzt viel mir ein, das das Entity ja komplett über Lua steuerbar sein muss. Da ich aber keine ahnung von Lua habe, würde mich mal intressieren wie das genau dann hinhaut. Werden per Lua jewals nur Funktionen wie "setPos" etc Aufgerufen, oder wie läuft das?? Ideal währe es meiner Meinung nach, wenn das Entity einen Pointer auf den Lua code hat, der dann vom SceneGraph beim updaten ausgeführt wird.(Weiß leider nicht ob das so möglich ist...) In C++ hätte ich jedem Entity einen Funktionspointer gegeben, der dann vom SceneGraph aufgerufen wird...
Andere sache:
Ich chat fanden wir, das eine Feste begrenzung auf eine bestimmte Anzahl Membervariablen unschön währe. Daher sollte ein void* userData benutzt werden. In wie weit zieht Lua da mit??
Und gibt das nicht eventuell probleme, wenn ein Entity (z.B. ein explodierendes Fass) bestimmte werte anderer Entitys ändern will(z.B. bei der Explosion die Lebensenergie runterregeln) und dieses Entity aber garkeine Lebensenergie hatt?? Das währe doch massiv Fehlerträchtig/viel arbeit, oder nicht??
greetz TGM
(sry das das jetzt erst kommt, aber mein inet hat zwischendrinnen mucken gemacht...)

Also ich wär ja immernoch dafür ein MemoryFile als userdata zu nehmen, aber gut ^^

Mit tolua++ kannst du ein ganz normales c++ interface schreiben und das drüberlaufen lassen. Dann kannst du die klasse und alle funktionen im lua script verwenden.

Hier mal ein beispiel:


in lua kann man dann, nachdem tolua++ drübergelaufen ist einfach schreiben


Zur zweiten Frage:
Wenn ein Entity keine Lebensenergie hat, dann kann man auch schlecht welche abziehn oder?

_________________
Phenom X4 9950 BE | 6144MB DDR2-800 | GeForce 8800GT 512MB | Asus M3A32-MVP Deluxe | 2TB HDD | 520W Seasonic NT | Soprano Tower | Samsung 22" TFT + Fujitsu-Siemens 17" TFT + Toshiba 42" FullHD LCD | Windows 7 Proessional x64
Behind the Brain

Eben. Du gehst einfach alle Objekte durch, die in deinem Umfeld liegen und Schaden nehmen sollten und wenn sie keinen Schaden nehmen können, dann wird eben nix abgezogen.
Wobei man vielleicht schon von Anfang an Objekte in verschiedene Kategorien unterteilen sollte (zerstörbar/nicht zerstörbar etc.), was die Sache noch einfacher machen würde.

In diesem Zusammenhang fällt mir übrigens folgendes ein: Wie wäre es, wenn wir die Landschaft komplett zerstörbar machen? Also Häuser, Bäume etc.
Ist Programmiertechnisch ja nicht unrealistisch...

Dürfte aber definitiv eine Gefahr fürs Gameplay darstellen, wenn sich der Spieler durch Gebäude/verschlossene Türen schießen kann...

EDIT: Irgendwo in der ODE MailingList war mal ne schöne Diskussion über komplett zerstörbare Welt/Gameplay, müsstet ihr mal bei Google suchen, da waren nachher schön die pros und cons aufgelistet.

Das wäre wieder eine Sache, die man diskutieren müsste...

also das mit dem tolua++ würde ich lassen, wir wollen das spiel doch nicht in lua schreiben. die scripte beschränken sich auf den bereich der dynamisch gehalten werden soll. man braucht keine scripte für dinge die immer wieder kommen und immer gleich sind. selbst wenn sie in bytecode sind ist das wie durch die brust ins auge: von der c++ funktion ins script und die ruft dann wieder eine c++funktion auf.. toll.
scripte steuern nur "verhalten" dass von der "norm" abweicht. eine tür ist eine tür, und man braucht nur ein script wenn die tür mehr tun soll als eine standard-tür, nämlich auf- und zugehen. zb einen zauber wirken, einen alarm auslösen (bei bestimmter bedingung), explodieren, was weiß ich.

arg stimmt.. falsch gedacht ^^

_________________
Phenom X4 9950 BE | 6144MB DDR2-800 | GeForce 8800GT 512MB | Asus M3A32-MVP Deluxe | 2TB HDD | 520W Seasonic NT | Soprano Tower | Samsung 22" TFT + Fujitsu-Siemens 17" TFT + Toshiba 42" FullHD LCD | Windows 7 Proessional x64
Behind the Brain

wie wärs mit 2 entity typen, solche die LuaScript ausführen, und soche die nen C++ Funktionspointer benutzen, und hardgecodete eigenschaften besitzen..??

genau... aber wenn man einfach von nem Pointer was abzieht, ohne vorher genaustens zu prüfen.. bye

ganz viel arbeit...

wir machen einfach einen pointer und für die scripts gibts ne wrapper-function...

Was wäre eigentluch mit XML, wo eben die Models geladen werden und positioniert werden. Die gegebenfalsl Eigenschaften besitzen und so...
So konnte man auch schnell Models laden ohne im Quellcode was zu ändern.
( oder wir schreiben uns ne eigene Pars Klasse )

Parsen muss man sowieso, da man bessere Ãœbersicht hat etc..

Z.B
BaumStadt01 = "tree01.3ds"
position = 3,20,35
collision = true

sry frür meion Deutsch (bin bissel besoffen).

kp
wenn wir ein eigenes xml-format nehmen müssen wir auch einen eigenen editor schreiben..