tBane Temat założony przez niniejszego użytkownika |
Przetwarzanie obiektów w grze » 2024-02-10 19:33:54 Witam. Wymyśliłem sobie wygodny sposób na przetwarzanie obiektów w grze. Czy jest to dobra praktyka czy nie. A jeżeli nie, to jaka byłaby lepsza. std::vector < GameObject * > gameObjects;
std::vector < Unit * > units;
std::vector < Building * > buildings;
std::vector < Nature * > natures;
enum class type { none, unit, building, nature };
class GameObject
{
public:
float x, y, radius;
GameObject( float, float, float );
~GameObject();
};
class Unit
: public GameObject
{
public:
Unit( float, float, float, type );
~Unit();
};
class Building
: public GameObject
{
public:
Building( float, float, float, type );
~Building();
};
class Nature
: public GameObject
{
public:
Nature( float, float, float, type );
~Nature();
};
|
|
pekfos |
» 2024-02-10 20:01:01 Może lepiej byłoby trzymać jedną kolekcję elementów na bazie GameObject. Wtedy aktualizacja, renderowanie, itp to jedna pętla a nie kilka. Ale jak to co wymyśliłeś jest wygodne to rób tak, jak najbardziej. |
|
DejaVu |
» 2024-02-10 20:17:05 Moim zdaniem najwygodniej mieć klasę bazową GameObject, która posiada wszystkie możliwe metody, których implementacja jest pusta (np. GetWeapon() zwraca null). Następnie gdy implementujesz jednostkę, która ma broń, to po prostu przeciążasz metodę GetWeapon() i zwracasz właściwą broń. Jeżeli jest to budynek to nic nie robisz i zwrócone zostanie null (brak broni).
W ten sposób pozbędziesz się problemu rzutowania na typ szczegółowy, więc wszędzie będziesz sobie pracował z GameObject i jedyne co będziesz musiał sprawdzać to czy "GetWeapon()" zwróciło null czy nie. |
|
tBane Temat założony przez niniejszego użytkownika |
» 2024-02-10 21:04:35 Właśnie to próbuję osiągnąć - stworzyć "podstawkę" dla jednostek kilku typów : unit, building, natureObject, by potem móc w wygodny sposób chociażby je sortować co w renderingu jest istotne.
W grze sterowalne mają być tylko jednostki.
Budynki i natureObject'y (kamienie, drzewa) są statyczne, ale osobne listy są wygodne w póżniejszym przetwarzaniu.
( np. drzewa rosną, budynki są zaznaczane lub animowane ) |
|
DejaVu |
» 2024-02-10 21:08:09 Jeżeli potrzebujesz sortowania 'pod rendering' to albo robisz grę 2D (good enough), albo masz modele 3d i nigdy nie zadziała Ci poprawnie rozwiązanie dopóki nie włączysz bufora Z-index w OpenGL-u. |
|
tBane Temat założony przez niniejszego użytkownika |
» 2024-02-10 21:31:12 Teraz robię grę 2D "Village". Ma to być gra strategiczna RTS. Gra będzie polegała na tworzeniu robotników oraz przydzielaniu im zadań takich jak wycinka drzew, pozyskiwanie kamienia. Robotnicy oprócz wydobywania tych surowców będą je także dostarczać do siedziby głównej gracza po zebraniu. Gracz wygrywa gdy stworzy odpowiednią ilość robotników.
Jestem newbie w programowaniu, obecnie przerabiam tutoriale z Unity, by lepiej zrozumieć mechanikę RTS. |
|
DejaVu |
» 2024-02-11 10:41:33 Jeżeli masz grę stricte 2D, to obiekty nie powinny na siebie nachodzić, więc sortowanie nie powinno być Ci w ogóle potrzebne. Chyba, że chcesz mieć warstwy, to wówczas możesz dodać z-index do każdego obiektu i sortować cały kontener po Z-index. Dopiero jak stwierdzisz, że to rozwiązanie jest 'za wolne' to możesz myśleć jak optymalizować kod. Przedwczesna optymalizacja zwiększa istotnie złożoność kodu, a ta szybko komplikuje wytwarzanie oprogramowania i wykonywanie zmian w konceptach. Im mniej kodu tym łatwiej robić adaptacje. |
|
tBane Temat założony przez niniejszego użytkownika |
» 2024-02-11 17:34:45 Dziękuję za rady :-) |
|
| « 1 » |