pomysł na aplikację do gry planszowej

0

Grając ze znajomymi w planszówkę zauważyłem, że dosyć upierdliwe jest podliczanie punktów w tej grze. Co turę każdy graczy zdobywa kartę z "właściwościami", które po prostu się sumuje. Potem za to można zakupić jakieś "jednostki" itp. Może też zdarzyć się tak, że po turze gracz straci kartę. Wtedy przeliczamy punkty od nowa. Bo są tutaj jeszcze jakieś dodatkowe mnożniki itp. Trzeba też pilnować swojej tury czy kolejki (3 ruchy na turę).

Pomyślałem więc, że napiszę w C# aplikację okienkową. C# jest akurat tym językiem, w którym chce się rozwijać.

Myślę, że podejście obiektowe będzie tutaj idealne: każdy gracz to nowy obiekt klasy "gracz" z właściwościami określającymi ile punktów kto ma. Do tego jakaś metoda statyczna, która co turę przelicza liczbę punktów.

Pomysł jest taki:
1) odpalam program i wpisuję liczbę graczy
2) tworzę po kolei n obiektów
3) wyświetlam prostą tabelkę (siatkę textboxów)
3) jedna osoba na bieżąco zmienia liczbę punktów i każdy widzi, ile ma punktów do dyspozycji

O ile sama mechanika czy interfejs jeszcze jest do przemyślenia, to na poziomie "programistycznym" widzę już, że to nie takie proste. Zwłaszcza, że chcę po raz I zastosować podejście obiektowe w nieco większym projekcie. Ale inaczej się tego nie nauczę :)

Pytania:
1) Widzicie tutaj sens korzystania z bazy typu SQLite?
2) Mam do zadeklarowania nieokreśloną liczbę obiektów, dopiero po wpisaniu liczby graczy to będzie wiadomo. Jest jakiś prostszy sposób, niż tablica zawierająca n obiektów klasy "gracz"?
3) Skoro deklaruję dynamicznie, to też wypada pamięć zwalniać. W C++ faktycznie jest od tego operator delete. W C# teoretycznie jest GC, więc jeżeli dobrze rozumiem, to po zamknięciu aplikacji (X w okienku) zadeklarowana tablica/obiekty są usuwane i pamięć jest zwalniana?
4) Co będzie lepsze: deklaracja klas w osobnych plikach, czy wszystko w jednym pliku, "nad" klasą main?

1
  1. Jak chcesz trzymać jakieś archiwum to tak, ale równie dobrze możesz zapisywać do pliku.
  2. A co jest skomplikowanego w tablicy?
  3. Tak, jest zwalniana, nie musisz się tym martwić.
  4. Każda klasa w osobnym pliku.
0
kzkzg napisał(a):
  1. A co jest skomplikowanego w tablicy?

Chodzi mi o to, czy można to zrobić prościej. Przed napisaniem tematu zrobiłem research i wyszło mi, że właśnie tablica to najlepsza opcja. A fakt, że mamy GC ułatwia sprawę.

Mam wątpliwość odnośnie metod statycznych. Czy nie lepiej zadeklarować je w klasie main, zamiast deklarować osobną klasę na metody statyczne? Jedyna plus takiego rozwiązania jaki widzę, to czytelność kodu (co innego, jak deklaracje są w jednym pliku, a co innego jak wszystko jest rozbite na osobne pliki).

1
kosmonauta80 napisał(a):

W C# teoretycznie jest GC, więc jeżeli dobrze rozumiem, to po zamknięciu aplikacji (X w okienku) zadeklarowana tablica/obiekty są usuwane i pamięć jest zwalniana?

Tak, ale tak samo będzie z każdym programem, nawet napisanym w C i nawet gdy zapomnisz totalnie o zwalnianiu pamięci. System operacyjny "sprząta" po każdej zamkniętej aplikacji, gdyby tak nie było to bój się boga, pewnie co drugi dzień trzeba by było restartować komputer.
GC jest po to żeby nie przejmować się zarządzaniem pamięci PODCZAS działania programu, ale w grach i tak konstruuje się obiekty tak żeby były używane z puli, nie usuwa się niczego z pamięci tylko w miarę możliwości zwraca do puli i używa ponownie. Dzięki temu GC nie musi pracować zbyt ciężko co mogłoby spowodować lagi w grze.

2 - łatwiejsza od tablicy jest lista. Wewnętrznie operuje na zwykłej tablicy ale dostajesz dodatkowe metody do zarządzania nią - możliwość dodawania / usuwania elementów
Co do 4 - większość rzeczy w programowaniu robi się tylko dla czytelności i łatwiejszego zarządzania i rozwijania w przyszłości - nie ma lepszego powodu.

0

Aplikację napiszę w oparciu o WinForms. Gdzie najlepiej umieścić kod tworzący obiekt "gracz" dla każdego gracza? Pod button click? Deklaracja klasy będzie w osobnym pliku

0

Jak by ktoś się zastanawiał, czemu klasa Form nie widzi klasy zadeklarowanej w osobnym pliku *.cs, to sprawdźcie, czy tenże plik jest dodany do projektu ;) Samo wrzucenie go do katalogu dla VS nie wystarczy.

0

@kosmonauta80: Metody statyczne powinny być w osobnej klasie, ale nie wszystkie w jednej. A najlepiej gdyby ich było jak najmniej. Zależy co one robią.
Jak się uczysz to od razu zacznij się uczyć testowania. Nie pisz UI tylko używaj testów do uruchamiania poszczególnych metod obiektów.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0