Ocena kodu C# [Monogame]

Question

Witam, zacząłem bawić się z w C# w Monogame i chciałbym sprawdzić, czy nie wyrobię sobie złych nawyków. Projekt jest nieduży i w bardzo wczesnej fazie, ale łatwiej się będzie czytało.

W szczególności martwi mnie, czy nie używam za dużo zmiennych publicznych i statycznych publicznych. Dzięki temu nie przekazuję zbyt wielu argumentów do funkcji co chwilę, ale nie wiem czy to najlepsze wyjście. Niedługo dojdzie pewnie do tego, że każda zmienna, związana z ewkipunkiem gracza będzie zmienną statyczną. Ale może to poprawny sposób?

https://github.com/Kodeman010/Monogame-game

Prosiłbym o jakiekolwiek rady, gdyż im wcześniej wyjdę ze złych nawyków, tym lepiej :)

Comments

Nigdy nie rób if`ów bez klamerek. Niby dla jendolinijkowych instrukcji można tak pisać lecz nie jest to zalecane i łatwiej o błędy. 

w gameObject masz 
public Texture2D _texture;

Podkreślnik przed nazwą to dość stara konwencja nazewnicza. Jest ona stosowana do wyróżnienia pól prywatnych nie publicznych.

GameObjects jest klasą trochę bez sensu bo wiele właściwości nie jest wykorzystywanych później przez obiekty potomne czemu zrobiłeś ta klase ?

---

Z GameObjects celowałem w coś w stylu w Unity, gdzie każdy obiekt ma własną funkcję Update, OnClick, dodałem jeszcze Draw. Każdy obiekt powinien być osobnym spritem, dlatego zawiera również kolizje. Kiedy rozszerzę program, to może obiekty potomne będą wykorzystywać więcej z rodzica.

Zastanawiałem się z obiektem MouseManager, gdyż on nie potrzebuje sprite'a, ale ma funkcję Update i Draw, które pasują i dzięki temu oszczędzam na kodzie (i być może czytelności). Czy teraz GameObjects ma sens, czy źle się całkowicie do tego zabrałem?

Dziękuję za resztę rad :)

---

Ja bym na twoim miejscu to rozdzielił bardziej. zrobił klase GameObject który zawiera tylko deklaracje funkcji update oraz draw (abstrakcyjne). Następnie zrobił klase GameVob która dziedziczy po GameObject która miała by dodatkowe pole z teksturą.

Następnie klasa
Player dziedziczy po GameVob który dziedziczy po GameObject
MouseManager dziedziczy tylko po GameObject

Fajniejszym rozwiązaniem było by użycie interfejsów i stworzenie interfejsu GameObject zamiast klasy ;)

 

Gdy pisałem swoją gierkę uzywałem tego kursy troche temu to juz było ale myśle ze i tak warto ;)

http://www.centrumxp.pl/dotNet/116,kategoria,Kurs-C-cz-II.aspx

Pierwszej części nie proponuje bo raczej byś się wynudził ale jeśli chcesz możesz spróbować poczytać obie ;)

---

Faktycznie, Twój pomysł jest lepszy, sprawdzę jak używać interfejsów, dziękuję również za link.

Jeśli można spytać jeszcze na koniec: Jakbyś rozwiązał problem z klasą camera? Mam w GameState jej publiczny statyczny obiekt, bo klasa MouseManager też potrzebuje tego obiektu. (Wielokrotnie w różnych postaciach się na ten problem natykam)

Czy właściwie użyłem public static, czy jest jakiś inny sposób, gdyż jakoś nie widzę przekazywania argumentów przez funkcję, bo zaraz się zrobi takich 1000. (I co znaczy Vob w GameVob? :p)

Napisz jeśli można w odpowiedzi, to będę mógł dać Ci najlepszą odpowiedź :)

Answer 1

GameVob wymyśliłem wzorując się na klasach gry Gothic. Kiedyś zajmowałem się modyfikowaniem tej gry.

Vob to - Visual Object. Obiekt w świecie który ma graficzną prezentacje.

jest jeszcze Mob który dziedziczy po Vob. Mob raczej już wiesz co to jest ;)

Co do staticów tez nigdy nie znalazłem idealnego rozwiązania problemów z nimi. Gry są na tyle specyficzne ze czesto potrzeba obiektów widocznych w wielu miejscach. Mam kilka pomysłów ale nigdy ich nie implementowałem w grach wiec nie wiem na ile się sprawdzą

1. singleton - jest to klasa z jedną funcją statyczną która zwraca jej instancje. Poczytasz na necie pełno jest przykładów

2. zrobić więcej funkcji update w jednej klasie. Rozdzielać wszystko na mniejsze funkcje do których będzie przekazywany jeden konkretny parametr.

3. Tworzyć klasy statyczne które mają wszystkie pola i funkcje jako statyczne. Taką klase np napisałem kiedyś do przechowywania tekstur uprzedzam ze było to prawie 5 lat temu

https://pastebin.com/Jpz9vhUH