Każda branża IT ma swoje rozwiązania, w tym GameDev. Jak ugryźć niektóre wzorce projektowe, żeby korzystać z nich w pełni i nie tracić czasu na boilerplate? Jaką stworzyć architekturę aplikacji, żeby inni członkowie zespołu się w niej odnaleźli? Przedstawię rozwiązania z którymi się spotkałem, z których korzystałem i które wymyśliłem na potrzeby małych i średnich projektów.

1. Walka z MVC i innymi
wzorcami projektowymi
w grach komputerowych z perspektywy
gameplayu
Kacper Kościeński
Senior Unity Developer
Playsoft

2. Licencja
/*
* ----------------------------------------------------------------------------
* "THE BEER-WARE LICENSE":
* <kkoscienski+4developers@gmail.com> wrote this file. As long as you retain this notice you
* can do whatever you want with this stuff. If we meet some day, and you think
* this stuff is worth it, you can buy me a beer in return.
* Kacper Kościeński
* ----------------------------------------------------------------------------
*/

3. Prezentacja - link
• Google drive folder
http://bit.ly/1RNSXWW

4. Spis treści
• O mnie
• Software development
• Gameplay
• MVC
• Inne wzorce
• Takeaway
• Pytania

5. Kacper Kościeński
Programista gier
kkoscienski+4developers@gmail.com

6. Disclaimer
● wszystkie prezentowane metody nie są uniwersalne:
ich zastosowanie zależy od projektu, teamu,
ograniczeń itp itd.
● skalowalne raczej do małych i średnich projektów
● część kodu uproszczona / zmieniona na cele
prezentacji

7. Software development
• Platformy (x86, Mobile, konsole, …)
• Technologie (Java, C#, C++, liby, Unity, …)
• Ludzie (skill, doświadczenie, nastrój…)
• Cel
• W zależności od branży różne narzędzia i
rozwiązania
• Wzorce projektowe

8. Gameplay
• Logika, AI, poruszanie, input, etc.
• Częsta zmian założeń
• Często brak dobrych wytycznych
• Nie ma testów jednostkowych
• Dużo profilowania
• Jesli masz Game Design Document -> WIN

9. • Model - parametry obiektów, wysokopoziomowa logika.
Game / Level Design
• View - art, wizualizacje
(kolor, tekstura, animacje …).
Artyści
• Controller - działania graczy / podsystemów,
niskopoziomowa logika.
Programiści
Model View Controller - Gameplay

10. MVC - Model
Dane:
public class BoatData
{
public readonly float Radius = 0.0f;
public readonly SailType SailType = SailType.Spinnaker;
}
Logika wysokopoziomowa - jeśli sztorm to płyń do portu

12. MVC - View
• Assety dostarczone przez artystów.
• Ustawianie parametrów (i.e. kolor)
• Wystartowanie efektu cząsteczkowego (wybuchy!)

13. MVC - Controller
• Input: gracze, podsystemy (i.e. AI)
• Sterowanie
• Wyszukiwanie ścieżki
• Zmiana stanów
• Animacje
• Logika niskopoziomowa - poruszanie, shoot
sequence etc.

14. MVC - typowe błędy
• Trzymanie się wzorca (“pure MVC”)
• Programista wymagany do wrzucania assetów
• Duża złożoność
• Language / library feature focus

15. Singleton
• “Antywzorzec”.
• Używany w każdej grze do jakiej miałem źródła.
• Wiele upraszcza.

16. public abstract class Singleton<T> : MonoBehaviour where T : Singleton<T> {
public static void Init(Transform parent) {
//load data and stuff, no lazy init
// Instance set
}
private void Awake() { //c-tor
if (Instance != null && Instance != this)
Destroy(gameObject);
else
OnAwake();
}
protected virtual void OnAwake() {}
public static T Instance { get; private set; }
}
Singleton

17. public class GameManager : Singleton<GameManager> {
protected override void OnAwake() {
Init(null);
ServiceManager.Init(transform);
NetworkManager.Init(transform);
UsersManager.Init(transform);
BoatStatesManager.Init(transform);
InterestManager.Init(transform);
DebugManager.Init(transform);
GameplayManager.Init(transform);
QualityManager.Init(transform);
WindManager.Init(transform);
InputManager.Init(transform);
LocalizationManager.Init(transform);
SpritesManager.Init(transform);
TranslationManager.Init(transform);
}
}
Singleton

18. Pozwala na:
LocalizationManager.Instance.Get(“ok”);
Typowe błędy:
• Lazy initialization
• Spam singletons
Hints:
• Instance nigdy null (init na starcie aplikacji / w
odpowiednim momencie).
• Nie inicjalizuj w get
Singleton

19. signal -> transmitter -> receiver
zazwyczaj implementacja i korzystanie - kilka linii kodu
BoatManager : Singleton<BoatManager> {
private UnityEvent onChanged = new UnityEvent();
public void Change() {
onChanged.Invoke();
}
// register / deregister event listeners
}
Observer

20. Typowe błędy:
• Trzymanie się wzorca
• Overcomplicated
• Language / library feature focus
Observer

21. • alokacja pamięci jest kosztowna
• Garbage Collector spikes
Object pool

23. I've seen things you people wouldn't believe.
• Trzymanie się wzorca (“pure XYZ”).
• Przekomplikowanie.
• Niemożność odejścia od wzorca.
Wzorce projektowe - błędy

24. • Twój kod nie powinien być maksymalnie uniwersalny.
• Lepiej zrobić coś prostego działającego w 1d i później
refactor niz super bibliotekę w 2mc i użyć jej raz.
• OOP jest przereklamowane! Może warto spróbować
trochę innego podejścia?
• Profiluj per platforma
Wzorce projektowe - hints

25. Takeaway
• Modyfikuj
• Upraszczaj
• Pamiętaj - nie piszesz biblioteki!
• KISS
Keep It Simple, Stupid

26. • Ta prezentacja
http://bit.ly/1RNSXWW
• Złudzenie ponownego wykorzystania
http://blog.codinghorror.com/rule-of-three/
• Joel on Software
http://joelonsoftware.com
Kacper Kościeński
kkoscienski+4developers@gmail.com
Pytania?