Metody i pola statyczne w kodzie gry

Witam,
jak to jest, czy powinno się tworzyć statyczne metody i pola, np. klasy głównej gry lub silnika i wywoływać je bez tworzenia obiektu, czy raczej stworzyć ten jeden obiekt, którego elementy będą używane przez cały czas programu? Jeśli weźmiemy pierwszy sposób, to de facto mamy pseudo zmienne globalne i nie musimy przesyłać tych zmiennych przez argumenty metodom z innych klas (gdy obce klasy mają do nich dostęp). Słyszałem, że w miarę możliwości powinno się przesyłać zmienne funkcją za pomocą argumentów, niż tworzyć litanie zmiennych globalnych. Ale i tak, i tak zmienne będą przechowywane przez cały czas gry, więc czy to jest tylko kwestia mojego upodobania?

Prawdopodobnie chodzi ci o Singleton'a. Aczkolwiek gdzieś czytałem, że nie powinno się go nadużywać (a taka jest tendencja właśnie do nadużywania).

Zmienne globalne to zło, ale zmienne pseudoglobalne właściwie używane mogą być przydatne. Na tej zasadzie działa na przykład zmienna . Możesz utworzyć zmienne pseudoglobalne zamknięte we własnej przestrzeni nazw, klasę ze statycznymi zmiennymi publicznymi lub cokolwiek sensownego, co będzie działało.

A czy ktoś mi wytłumaczy, jaką ma racje bytu ta zasada, żeby wszystko, w miarę możliwości, przesyłać do funkcji (metod) za pomocą argumentów oraz dlaczego zmienne globalne to zło?

1. Przekazujesz wszystko przez argumenty.
2. Lista argumentów funkcji robi się bardzo długa.
3. Część zmiennych zaczynasz pakować w struktury (lista argumentów się skraca).
4. Część kodu z takiej funkcji przenosisz do struktur jako ich metody (kod jest prostszy).
5. Dalsza ewolucja kodu...

W ten sposób unikasz zmiennych globalnych i problemów z ich używaniem. Jeśli trafisz na coś bardziej nietypowego, to możesz użyć zmiennych pseudoglobalnych.