Entity branch#1
Conversation
| TextureHandle* texture; | ||
| V3 render_color; |
There was a problem hiding this comment.
Das setzt vorraus, dass jeder EntityType genau eine Texture und eine Color haben wird. Was ist, wenn wir Tiling wandstuecke einbauen? Was ist wenn wir Blue, Gruene, Rote Vasen haben wollen? Braucht man dann jedes mal einen eigenen Typ?
There was a problem hiding this comment.
Ich gebe zu, dass es vielleicht Fälle gibt, in denen eine Texture unnötig ist,
aber die beiden Fälle die du erwähnst (tiling und verschiedene farben) sind eigentlich kein Problem.
Jeder EntityType hat einen function pointer zu einer render function,
und die render function kann mit der Textur und der Farbe vom entity type machen was sie will.
Du kannst also z.B. einen EntityType haben wo die Textur ein ganzes tileset ist,
und die render function so implementieren, dass sie den richtigen Teil vom tileset verwendet.
Du kannst auch eine render function haben die die render_color vom EntityType ignoriert,
und stattdessen rote, blaue oder grüne Farben abhängig von irgendwelcher extra data verwendet.
There was a problem hiding this comment.
Bedenke, wir werden spaeter auch Skeletal Animations / Poses anhaengen muessen. Wuerde man die in extra_data dann packen? Wenn du einen sprite atlas verwendest, brauchst du dann informationen ueber width und height? Falls ja, wo kommen die dann hin? Auch wieder in extra_data von jedem einzelnen Entity?
Fuer mich klingt das ein wenig nach einem hacky workaround.
| u32 load_tile_green; | ||
| u32 load_tile_blue; | ||
|
|
||
| ColliderType collider_type; |
There was a problem hiding this comment.
Geht davon aus, dass jeder Typ einen Collider haben wird. Was ist mit Cameras?
There was a problem hiding this comment.
Falls mit camera die enemies gemeint sind: Ich hätte enemies einen collider gegeben.
Falls die camera gemeint ist die das Spiel beobachtet: Das hätte ich nicht zu einem entity gemacht.
| EntityType* type; | ||
| V3 pos; | ||
| Collider collider; | ||
| V3 radius; |
There was a problem hiding this comment.
Wird jedes Entity einen Radius haben?
There was a problem hiding this comment.
Ich bin gerade hauptsächlich an collideable entities interessiert.
Vielleicht sollte ich meine Entities in CollideableEntities umbenennen.
Wir werden glaube ich mehr als genug collideable entities haben um diese Abstraktion zu rechtfertigen.
| V3 pos; | ||
| Collider collider; | ||
| V3 radius; | ||
| void* extra_data; |
There was a problem hiding this comment.
Warum hier eine Reference auf extra_data? Es ist bereits eine in EntityType. Ich denke wir sollten versuchen die Anzahl an References (vor allem void*) auf einem absoluten minimum zu halten, damit wir spaeter kein unverstaendliches Netz an Object References haben.
There was a problem hiding this comment.
Das ist eine gute Kritik. Ich werde die extra_data aus dem EntityType entfernen, weil das sonst nur verwirrend ist.
Nur einzelne Entities benötigen einen extra_data pointer.
Zum Beispiel jedes einzelnes Objective hat einen bool "broken" das sagt ob das objective schon zerbrochen wurde.
Aber der EntityType braucht das nicht. Ich werde das jetzt implementieren.
| // Update all entities | ||
| for (u32 i=0;i<game->entity_type_count;i++) { | ||
| for (u32 j=0;j<game->entity_types[i].count; j++) { | ||
| game->entity_types[i].update(&game->entity_types[i].entity_list[j], game); |
There was a problem hiding this comment.
Kontrolle ueber die update order geht verloren.
| // Render Entities | ||
| for (u32 i = 0; i < game->entity_type_count; i++){ | ||
| for (u32 j = 0; j < game->entity_types[i].count; j++){ | ||
| game->entity_types[i].render(&game->entity_types[i].entity_list[j], game, group, dbg); |
There was a problem hiding this comment.
Kontrolle ueber die render order geht verloren.
…ill a bit hacky. will be made more pretty soon.
2 participants
No description provided.