W każdej grze spotykamy się z menu, HUD-em, samym ekranem gry, menu in-game i innymi tego typu rzeczami. Sensowne zorganizowanie tego nie jest zbyt proste(a może jest, tylko trzeba to dobrze przemyśleć?) a jest to bardzo ważne. Jak to rozwiązać?
Sensownym i dość prostym rozwiązaniem jest maszyna stanowa. Każdy stan-klasa potrafi sam się odrysować i zaktualizować. W takim rozwiązaniu mamy np. stany Menu, Game, Loading, które robią, co mają robić i na koniec zmieniają na inny stan.
Lecz co zrobić, gdy chcemy mieć np. menu w trakcie gry, które tylko przysłania grę i zaprzestaje jej aktualizacji? Nie zmienimy stanu, bo w ten sposób stracimy to, co było na ekranie. Musimy wtedy wbudowywać to menu w stan gry, co rozbuduje nam, już dość dużą, klasę stanu.
Kolejnym rozwiązaniem, które znam jest manager tzw. ekranów. W moim przypadku są to bardziej stano-ekrany, niż same ekrany, bo oprócz możliwości odrysowania posiadaj możliwość aktualizacji. Każdy ekran może zostać przysłonięty przez inny jak i samemu może przysłaniać inne. Ja rozróżniam trzy stany:
Obecność dwóch stanów nieaktywny spowodowana jest tym, że rozgraniczam ekrany pełno i niepełno ekranowe(masło maślane… uwielbiam to
). Pełnoekranowe przysłaniają całkowicie ekrany „za” co oznacza, że nie są one ani odrysowywane ani aktualizowane, a niepełno ekranowe, mimo że mogą zajmować cały ekran(np. przysłaniając go półprzeźroczystym obrazkiem), pozwalają im się odrysować. Dzięki temu bez problemu możemy rozdzielić menu InGame od samej gry nadal pozwalając się jej odrysować!
PS. Na GitHubie dostępna jest prosta niegrywalna gierka, którą napisałem w ok. 2h, by sprawdzić jak sprawuje się to, co napisałem do tej pory. Wymagania: .NET 4.0, reszta dołączona do projektu(hint: uruchom msbuild w folderze z solucją i uruchom Kingdoms Clash.exe z GŁÓWNEGO katalogu solucji(nie z folderu Bin/Debug|Bin/Release)).