Czy maszyna stanów powinna być niezależna od kierunku postaci ? Przykładowo
gdy mam tylko dwa stany IDLE, WALK. To czy powinno być

IDLE <---> WALK

Czy też

IDLE <---> WALK_LEFT
IDLE <---> WALK_RIGHT

Pytanie może naiwne, ale mnie to jakoś dręczy. Czy ma ktoś w tej kwestii jakieś przemyślenia albo mógłby mnie wspomóc jakimś linkiem (trochę już grzebałem w necie ale coś słabo )

PS: W grze są następujące stany: IDLE, WALK (możliwe kierunki LEFT,RIGHT), CLIMB (możliwe kierunki UP,DOWN), FALL, ECHANGE

"to zależy". ;) W AMInerze miałem takie stany:

typedef enum _tVehicleState {
	VEHICLE_STATE_MOVING,
	VEHICLE_STATE_DRILLING,
	VEHICLE_STATE_EXPLODING,
	VEHICLE_STATE_SMOKING,
	VEHICLE_STATE_TELEPORTING_OUT,
	VEHICLE_STATE_TELEPORTING_WAIT_FOR_CAMERA,
	VEHICLE_STATE_TELEPORTING_IN
} tVehicleState;

Bo ruch był co piksel, więc tak naprawdę nie był to proces który ma swój początek, środek i koniec, tylko trzeba było to obsługiwać co chwilę.

Jeśli rozważać to w kategoriach takich, że klikasz przycisk i postać idzie kafel w lewo lub w prawo lub wspina się w górę, to coś takiego miałem w VEHICLE_STATE_DRILLING. I jak widzisz jest od tego jeden stan, ale potem mam:

typedef enum _tDrillDir {
	DRILL_DIR_NONE = 0,
	DRILL_DIR_H,
	DRILL_DIR_V
} tDrillDir;

typedef enum _tDrillState {
	DRILL_STATE_VERT_ANIM_IN = 0,
	DRILL_STATE_DRILLING,
	DRILL_STATE_VERT_ANIM_OUT
} tDrillState;

To pierwsze rozróżnia wiercenie poziome i pionowe, to drugie rozróżnia fazę wiercenia przy wierceniu poziomym (wystaw gryzarkę, gryź, schowaj gryzarkę).

Taka hierarchiczna struktura pozwala Ci zawrzeć tyle informacji ile jest niezbędne w kodzie ogólnym (bo tam Ci wystarczy informacja że dany stan jest albo go nie ma), a wszelkie dodatkowe parametry robisz głębiej, już w samej implementacji stanu. Zaletą jest to że kod się robi modularny, bardziej poukładany, a wadą że masz więcej zmiennych niż przy pisaniu tego "na łopatę".

Jeśli zaś chodzi o przełożenie stanu na np. klatki animacji, to to jest kwestia czy wolisz to robić na bazie tylko jednej zmiennej (zmienna stan przyjmuje bardzo wiele wartości i załatwiasz to jednym switchem, ale gdzie indziej masz przez to w kodzie spaghetti) czy dodatkową ifologią (if drilling -> if drilling horizontally ... else if drilling vertically ...).

Jeśli miałbym stwierdzić które podejście jest lepsze, to chyba hierarchiczne. W małych grach nadmiar zmiennych aż tak nie boli, bo ramu masz w ciul i na ekranie pewnie też się mało dzieje więc parę cykli można na to poświęcić. A przedwcześnie optymalizować kosztem czytelności kodu to mi się nie chce. ;) Zresztą, odpal sobie źródła aminera i zobacz gdzie mnie takie podejście zaprowadziło. Jak Ci się nie spodoba to co zobaczysz to już wiesz, że trzeba iść w odwrotnym kierunku. ;d

Ostatnia aktualizacja: 26.07.2020 11:15:18 przez teh_KaiN

Dzięki za odpowiedź. Przyjrzę się żródłom Aminera.