Na razie problemow jeszcze nie ma, bo nie zaczalem nic pisac ;), ale mam za wczasu pare pytan.
Jesli napisze najpierw podstawe, czyli gre ktora bedzie dzialac w konsoli, chodzi glownie o sprawdzenie poprawnosci, to czy potem stworzenie GUI sprowadzi sie do przerobienia samego wyswietlania?
Mysle o tworzeniu tego w Qt.
Moze znacie jakies bardziej przystepne poradniki do qt gui, jakies wstawianie wlasnej grafiki, odswiezanie planszy itd.(oprocz dokumentacji). Nie to, zeby mi sie nie chcialo szukac, ale chcialbym sie troche przygotowac i moze ktos zna jakies dobre sprawdzone strony. Youtube tez srednio mi odpowiada.
- Rejestracja:prawie 14 lat
- Ostatnio:prawie 3 lata
- Postów:353
0
- Rejestracja:prawie 14 lat
- Ostatnio:około 6 godzin
0
Nie tylko wyświetlania ale również wprowadzania danych, na pewno będziesz musiał zrezygnować ze wszystkich cin-ów oraz cout-ów. Generalnie lepiej jest tworzyć program od razu jako graficzny, dużo mniej problematyczne.
ps sama "część obliczeniowa" czyli przetwarzanie danych zostanie naturalnie ta sama.
- Rejestracja:ponad 13 lat
- Ostatnio:ponad 11 lat
- Postów:26
0
Odnośnie książki to ja korzystam z tego http://developer.qt.nokia.com/books/view/c_gui_programming_with_qt_4_2nd_edition_the_official_c_qt_book
Do dostania w internecie.
- Rejestracja:prawie 14 lat
- Ostatnio:prawie 3 lata
- Postów:353
0
Gra jako tako bedzie prosta, bo to taki eurobiznes, wiec raczej wprowadzania danych nie bedzie, jedynie moze wybor ilosci graczy z menu. Reszta to tylko kolejne rzuty kostka i ewentualnie kupno/sprzedaz posiadlosci. Zaczniemy robic to zobacze co z tego bedzie wychodzilo ;) W razie problemow bede pytal.
Ogolnie sama obsluga gry i wprowadzaniem danych zajmie sie klasa nadrzedna, wiec mysle ze jedynie przerobka bedzie w tej klasie w razie czego.
edytowany 1x, ostatnio: Krycho
- Rejestracja:prawie 19 lat
- Ostatnio:ponad 13 lat
0
Zadbaj o dobrą architekturę, modułowość. Rozdziel wyraźnie warstwę związaną z prezentacją (wypisywaniem) od logiki gry, danych itp. (np. tradycyjny schemat model-widok-kontroler). No i jak będziesz pisał klasy to miej cały czas w głowie, żeby zachować modułowość tzn. im mniej zależności między warstawą prezentacji a innymi tym lepiej.
Jak tak zrobisz, to zmiana interfejsu nie powinna potem nieść ze sobą wielu problemów (oczywiście tych niezwiązanych z tworzeniem samego GUI).
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
0
Jeśli ładnie podzielisz to według wzorca MVC to zmiana View nie powinna być specjalnie bolesna :)
- Rejestracja:prawie 14 lat
- Ostatnio:prawie 3 lata
- Postów:353
0
Mozecie powiedziec czy ten szablon jest zgodny z tym modelem? Mam takie klasy
Widok - zadnych zmiennych jedynie operuje na danych przekazanych przez gre i wyswietla(na razie bedzie konsolowo potem GUI)
Gra - kontroler calej gry ma informacje o planszy i graczach
Gracz - informacje o graczu i akcje kupowania sprzedawania itd.
pole -klasa abstrakcyjna, przechowuje podstawowe informacje jak nr pola i do kogo nalezy
posiadlosc - dziedziczy po polu i przechowuje odpowiednie dla siebie informacje
akcje - tez dziedziczy po polu nie ma zadnych danych jedynie wykonuje pewne akcje na graczach
edytowany 1x, ostatnio: Krycho
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
0
Wygląda ok, oprócz tego akcje, bo nie rozumiem czemu jest szczególnym przypadkiem pola. Chyba że to jest takie magiczne pole które coś robi jak ktoś na nim stanie?
Tylko jeśli używasz MVC to musisz tu gdzieś wcisnąc Observera. To znaczy View musi skądś wiedzieć ze zaszła zmiana w modelu. Jeśli model sam go o tym poinformuje za pomocą jakiegoś Listenera to będziesz mial MVC. Jeśli to kontroler gry będzie jednocześnie wykonywał akcje na modelu i informował Widok że coś się zmieniło, to będziesz mial MVP.
edytowany 1x, ostatnio: Shalom
- Rejestracja:prawie 14 lat
- Ostatnio:prawie 3 lata
- Postów:353
0
Akcje to sa wlasnie takie magiczne pola na planszy, ze jak gracz na nim stanie to cos tam sie dzieje. Zabiera mu kase, daje, stoi kolejke itd. Ogolnie Klasa gry ma w sobie 2 vectory graczy i planszy, i odpowiada za odpowiedni ruch graczy po planszy. Teraz myslalem zeby po prostu ona zwracala pewne dane potrzebne do wyswietlenia danymi funkcjami, z ktorych moglby korzystac widok. On by sobie co kazdy ruch pobieral(dostawal żądanie od kontrolera na odswiezenie) nowe informacje i wyswietlal je. Swoich danych nie ma jedynie operuje na tym co dostanie z zewnatrz.
edytowany 1x, ostatnio: Krycho
- Rejestracja:około 21 lat
- Ostatnio:prawie 3 lata
- Lokalizacja:Space: the final frontier
- Postów:26433
0
No tak, póki ta gra jest turowa to możesz tak zrobić. Ale myśl szerzej ;) Gdyby gra nie była turowa to nie byłoby wiadomo kiedy Widok powinien się aktualizować. Dlatego wyzwalaczem powinna być informacja albo od Prezentera albo od Modelu.