Gwiezdny kupiec

[Ister]

No cóż, mówiłem, że trzeba logikę przygotować
Pytanie na ile da się wykorzystać to co już zrobiłeś, bo szkoda by było części graficznej choćby

[lighting]

Grafike mogę udostępnić - jeżeli ktoś chciałby to pociągnąć w tej wersji dalej to proszę bardzo. Grafiki się przyda, kod uważam że jest do kosza.
Jeszcze raz powiem, że ta gra wymaga gruntownego projektu, tu się za dużo dzieje w logice.

[Ister]

Ok, moje plany na najbliższy czas wykluczają powrót do prac nad tą grą, ale myślę, że w okolicach września będę mógł usiąść do tego ponownie i rozpisać modele.
Skoro i tak będzie trzeba robić od zera to powróciłbym również do propozycji zbudowania tego w architekturze klient-serwer. Dzięki temu będzie można w przyszłości pomyśleć o różnych interfejsach, nie będzie problemu z grą sieciową...
Zaznaczam, sam prac programistycznych nie zrobię, będzie do tego potrzebna inna osoba. Ale przygotowanie modelu powinno programowanie ułatwić i pozwoli na skoncentrowanie prac na konkretnych wycinkach.

[lighting]

Porazka tego w obecnej wersji wynikla zarowno z braku projektu na wstepie, pisaniu tego z duzymi przerwami czasowymi i doborem zlej technologi (XNA nadaje sie glownie do malych gier).
Jezeli przygotowalbys do tego projekt, oferuje sie napisanie tego albo pomoc przy napisaniu z uzyciem inengo srodowika (np. Unity).
Przy projektowaniu wez prosze pod uwage fakt, ze w tej grze wiele rzeczy jest plynnych, tzn. w wersji planszowej gracze moga uczynic pewne ustalenia ustne, ktore musza miec odzwierciedlenie w wersji elektronicznej.

[Ister]

Tak pamiętam.
Łącznie z tym, że gracze mogą poczynić pewne ustalenia na zasadzie umowy, które mają odzwierciedlenie w stanie gry (np. sprzedaż statku czy magazynu, przekazanie kredytów), ale które mogą być obwarowane dodatkowymi warunkami. Złamanie takiej umowy przekłada się również na stan gry (np. gracze umawiają się, że nie będą się wzajemnie atakować przez 3 najbliższe kolejki i jeden z nich to postanowienie łamie) - odbywa się to kosztem któregoś z parametrów gracza łamiącego umowę - bodajże tych punktów na podstawie którego określa się co turę, czy gracz będzie kontrolowany lub dostanie kasę (sorki, nie mam w tej chwili czasu zaglądać w zasady).
Zbudowanie silnika choćby do tego to będzie dramat
Pozdrawiam

[lighting]

Tak. Twoje ostatnie zdanie mi uzmysławia, że albo to będzie wyjątkowo czasochłonny projekt, albo należy pozostać przy ZunTzu.

[zephyr]

Można zaprojektować coś pomiędzy. W sensie te reguły które daje się łatwo wklepać zapisać, a do dyplomacji itd założyć że gracze mają skype'a a w interfacie dodać tylko przycisk "gracz złamał zasady porozumienia" który aplikuje odpowiednie mechanizmy growe.

(choć samej gry nie znam, więc pewnie nie pomogę sensowniej)

Co do technologii. XNA jest takie złe? A Unity fajne? Kończą mi się studia inf i zastanawiałem się z jakich technologii korzysta się robiąc coś fajnego a nie projekt na zaliczenie kursu

[Ister]

zephyr, problemem jest nie tyle "gracz złamał zasady", bo to rzeczywiście można obsłużyć tak jak mówisz (+jakiś arbitraż jeśli druga osoba się nie zgadza, nawet mam pomysł jaki). Problemem jest to, że w ramach umowy musi istnieć możliwość przekazania KAŻDEGO obiektu (a także kredytów). A to musi być możliwe do odwzorowania w systemie.
Do tego zasady różnicują złamanie umowy ustnej i pisemnej (!!!). Ale tu już powstaje pytanie czy warto to odwzorowywać
Poza tym podałem to tylko jako przykład problemu.
A skoro kończysz studia - może też włączysz się do projektu jak już ruszymy z nowym podejściem? Im więcej osób tym lepiej Nieznajomość gry przy dobrym modelu IMHO nie będzie miała wpływu

[lighting]

Można zaprojektować coś pomiędzy. W sensie te reguły które daje się łatwo wklepać zapisać, a do dyplomacji itd założyć że gracze mają skype'a a w interfacie dodać tylko przycisk "gracz złamał zasady porozumienia" który aplikuje odpowiednie mechanizmy growe.

(choć samej gry nie znam, więc pewnie nie pomogę sensowniej)

To jedna z naprawdę niewielu gier, gdzie można umówić sięna prawie wszystko. O ile tjest to fajne w wersji "analogowej", to jest koszmarne w wersji "cyfrowej". Jeżeli miałoby to pisać parę osób i ktoś podjąłby się wcześniej zaprojektować to, byłoby marzeniem. Niestety, gdy przyjmiemy uproszczenia w grze, czytaj "nie wszystko da się zrobić" to gra straci sporo uroku.

Co do technologii. XNA jest takie złe? A Unity fajne? Kończą mi się studia inf i zastanawiałem się z jakich technologii korzysta się robiąc coś fajnego a nie projekt na zaliczenie kursu

Jak ja to widzę: na początku chciałem napisać to w czystym DirectX + C# (po 10 latach obcowania z C++ i 2 latach C# nie chcę wracać już do C++). Po szukaniu w Internecie znalazłem XNA, w którym się zakochałem. Ale im bardziej Gwiezdny Kupiec się rozwijał, tym XNA stawał się gorsetem który utrudniał zrobienie dużego projektu (wszystkie projekty w XNA to bardzo proste gry i teraz wiem czemu). Postanowiłem poszukać czegoś innego i znalazłem najpierw GameMaker'a, od którego na szczęście szybko uciekłem i znalałem Unity. To framework, który jest konkurencją dla Unreal Development Kit jednak rozwija się wyjątkowo dynamicznie, a w bogatej wersji Standard jest dowolny dla każdego zastosowania. W tym frameworku na prawdę sięszybko pisze, więc Ci go polecam na zaliczenie kursu i nie tylko.

[yosz]

XNA jest w porządku, ale nie można bazować stricte na pętli draw-update bo wtedy rzeczywiście będzie robił się spaghetti kod.

Dla zainteresowanych, XNA działa na zasadzie że ekran jest rysowany przez metodę Draw, która jest wołana non stop. Metoda Update jest wołana raz na ileś wywołań Draw i ma za zadanie aktualizację danych, na podstawie których jest rysowany widok. Jeżeli nie zaprojektuje się tego porządnie, skutkuje to dopisywaniem non stop nowych if'ów do Draw np: if (State == JakisTamNowyStanKtoryPrzedChwilaMusialemDodac) { /* tu rysuję coś innego niż do tej pory, a potem i tak w środku dodam jakieś if'y */ } to kod będzie nie do ogarnięcia po kilku tygodniach pracy przy takiej skomplikowanej grze.

Robiąc Vicious Fishes natknąłem się dokładnie na ten problem - co rusz natrafiałem na na mur, który musiałem przeskakiwać. W końcu dałem sobie spokój i zacząłem od początku. W ciągu tygodnia napisałem sobie mały framework, do zarządzania animacjami i kod się stał bardzo czytelny i prosty w pisaniu (nie tykałem już metody Draw tylko pisałem jakisObiekt.Move(x, y, czasAnimacji));

Nie ważne czego się użyje - czy to będzie kobyła a'la Unity, DirectX, Silverlight czy XNA - potrzebny jest projekt i świadomość że pierwsze podejście do robienia gry poskutkuje beznadziejnym kodem, który najlepiej by było przepisać (ale może działać). Jest takie powiedzenie że dopiero trzecia wersja software'u nadaje się do jakiegoś użytku

Problemem przy Gwiezdnym Kupcu nie jest skomplikowanie interfejsu - do tego spokojnie XNA wystarczy, tylko właśnie projekt graficzny i dobra implementacja zasad z gry.

[lighting]

Zgodzę się, że w XNA spokojnie da się to zrobić Chociaż nie jest to łatwe.
To czego nie rozumiem, to Właśnie zestawienie Draw() i Update(). W GK cała masa rzeczy w tzw. logice biznesowej jest ściśle powiązana z interfejsem. Stąd wystarczyłoby Initialize() lub Start() wykonywany na początku a potem Update().

Nie ważne, Unity mi odpowiada, bo koncepcja, gdzie instnieją obiekty na ekranie, a do nich podpięte skrypty bardzo mi pasuje i jest wygodna w użyciu. To tak w b. dużym uproszczeniu.
Co kto lubi

[blind99]

Lighting a to Twoja grafika - sam ja robiłeś? Jeśli chodzi o kod to ja raczej od nowa bym to pisał, bo muszę wszystko rozpisać zanim zacznę coś tworzyć bo tak to nie ma sensu inaczej projekt upadnie prędzej czy później... Tylko o co chodzi w tej grze/zasady? Bo jak nie to zrobię swoją wersję

[Ister]

Blind99 sięgnij gdzieś do 5-6 strony. Tam masz linki do zasad. Ze 2 strony dalej masz wykazane różnice między wersją polską a angielską. Uzgodniliśmy, że tam gdzie są rozbieżności bazujemy na wersji angielskiej. Wreszcie w wątku przewinęły się 2-3 tematy wątpliwe, gdzie uznaliśmy, że powinniśmy dać możliwość decyzji na poziomie konfiguracji gry.
Więc niestety lektura całego wątku Cię czeka

[lighting]

Lighting a to Twoja grafika - sam ja robiłeś? Jeśli chodzi o kod to ja raczej od nowa bym to pisał, bo muszę wszystko rozpisać zanim zacznę coś tworzyć bo tak to nie ma sensu inaczej projekt upadnie prędzej czy później... Tylko o co chodzi w tej grze/zasady? Bo jak nie to zrobię swoją wersję

Tak, 100% grafiki jest robione od zera przeze mnie.
A jak nie znasz zasad i potym jak je poznasz i nadal będziesz chciał to robić, to jesteś odważny. Twierdzę, że to najbardziej skomplikowany tytuł jaki stworzono.

A zasady online:
http://www.nest.republika.pl/kupiec1.html
http://www.nest.republika.pl/kupiec2.html

Brakuje tam niektórych tabel, które mogi Ci dosłać.

[blind99]

Lighting a to Twoja grafika - sam ja robiłeś? Jeśli chodzi o kod to ja raczej od nowa bym to pisał, bo muszę wszystko rozpisać zanim zacznę coś tworzyć bo tak to nie ma sensu inaczej projekt upadnie prędzej czy później... Tylko o co chodzi w tej grze/zasady? Bo jak nie to zrobię swoją wersję

Tak, 100% grafiki jest robione od zera przeze mnie.
A jak nie znasz zasad i potym jak je poznasz i nadal będziesz chciał to robić, to jesteś odważny. Twierdzę, że to najbardziej skomplikowany tytuł jaki stworzono.

A zasady online:
http://www.nest.republika.pl/kupiec1.html
http://www.nest.republika.pl/kupiec2.html

Brakuje tam niektórych tabel, które mogi Ci dosłać.

No z miłą chęcią to zrobię. Zaciekawiła mnie nawet ta gra , dużo rzeczy jest do zrobienia ale... Ta planszowa gra jest na 6 osób, Ja bym tworzył w php więcej graczy by grało w tą gre, ale to nie byłby problem - chyba nie?

[Andy]

Ta planszowa gra jest na 6 osób, Ja bym tworzył w php więcej graczy by grało w tą gre, ale to nie byłby problem - chyba nie?

Gra jest dla 2-6 graczy i do takiej ich liczby dostosowana jest plansza.

[lighting]

No z miłą chęcią to zrobię. Zaciekawiła mnie nawet ta gra , dużo rzeczy jest do zrobienia ale... Ta planszowa gra jest na 6 osób, Ja bym tworzył w php więcej graczy by grało w tą gre, ale to nie byłby problem - chyba nie?

To znaczy tak: gra jest przewidziana dla 6 osób - plansza, ale myśle że także balans całej gry jest dopasowany dla tylu graczy. Myślałem żeby to zrobić w wersji wieloosobowej ale to przepisanie gry na nowo...
Co do PHP, chciałem uniknąć technologi webowych, żeby wesja komputerowa jak najbardziej przypominała oryginał ale gdybyś chciał to zrobić np. AJAX'em, to może coś sensownego osiągniesz.
Jednak zanim napiszesz chociaż linię kodu, przeczytaj proszę zasady i zobacz czy nadal chcesz to robić oraz zrób sobie dobry projekt. Bez tego dojdziesz z kodem do pewnego etapu, po czym polegniesz tak jak ja.

[Ister]

Ja bym optował za rozwiązaniem elastycznym. To znaczy - przygotowujemy to tak, żeby można było modyfikować liczbę planet, gospodarki, liczbę graczy, liczbę wiadomości itd. Przy pisaniu obiektowo to jest 0 problemu, a pozwoli w przyszłości pokombinować tak, aby można było poszukać rozwiązań dla większej liczby graczy.

Jeśli chodzi o technologie - dlatego sugeruję wersję w układzie klient-serwer, żeby móc tworzyć różne interfejsy. Stworzenie nie w oparciu o wygląd oryginału pozwoli uzyskać jakąś grywalność i napisać o wiele szybciej. A później będzie można rzeźbić piękne wersje a'la planszówka.
Poza tym przy zachowaniu oryginalnej grafiki ograniczamy się de facto do 6 planet, a więc w zasadzie maks gdzieś 8 graczy, właśnie z uwagi na balans gospodarczy (a i to już przy pewnych zmianach).

[lighting]

Ja bym optował za rozwiązaniem elastycznym. To znaczy - przygotowujemy to tak, żeby można było modyfikować liczbę planet, gospodarki, liczbę graczy, liczbę wiadomości itd. Przy pisaniu obiektowo to jest 0 problemu, a pozwoli w przyszłości pokombinować tak, aby można było poszukać rozwiązań dla większej liczby graczy.

Pomysł jest przedni, tylko odbiega już od oryginału. W przypadku rozszerzenia GK najtrudniej będzie zaimplementować zrównoważone wydarzenia.

Jeśli chodzi o technologie - dlatego sugeruję wersję w układzie klient-serwer, żeby móc tworzyć różne interfejsy. Stworzenie nie w oparciu o wygląd oryginału pozwoli uzyskać jakąś grywalność i napisać o wiele szybciej. A później będzie można rzeźbić piękne wersje a'la planszówka.
Poza tym przy zachowaniu oryginalnej grafiki ograniczamy się de facto do 6 planet, a więc w zasadzie maks gdzieś 8 graczy, właśnie z uwagi na balans gospodarczy (a i to już przy pewnych zmianach).

Klient - serwer ma sens, gdyż jest centralne miejsce, w któym wiadomo np. jakie gry aktualnie mają miejsce, ew. gdzie gracze oczekują na brakującego gracza. Jak zwykle sporo kłopotu w tej grze sprawi problem graczy, któze się rozłączą w trakcie...

[blind99]

Dzięki za rady, ale gier nie tworzę od dzisiaj i już dawno się nauczyłem, że kodowanie idzie na samym końcu wraz z grafiką. Jak najbardziej czytam aktualnie zasady. Jednak jeśli chodzi o mnie to niestety ja niedbałym rady robić gry dla 1-6 graczy, staram się aktualnie żyć z tego typu gier.

Wiem, że w nie których grach jeśli będzie więcej niż Np. 4 graczy rozgrywka może zupełnie inaczej wyglądać - ale może nie będzie tutaj problemu jak będzie w to grało więcej osób, trochę trzeba będzie na pewno zmodyfikować pewne rzeczy, gra planszowa a cyfrowa to niestety dwie inne rzeczy. To idę się brać do roboty.

PS. A opowiadanie dołączone do gry (Baranieckiego) to coś konkretnego na temat gry?

[lighting]

Opowiadanie jest jedynie przyjemnym wprowadzeniem w klimat rozgrywki. Jeszcze lepszym wprowadzeniem w sam klimat jest pograć w to parę razy, aczkolwiek zabiera to duuużo czasu.

Podziwiam Twój zapał
Jeżeli będziesz chciał jakiekolwiek pomocy/rady to służę.

[Ister]

blind99, można znaleźć gry, które są 2-6 osobowe również w sieci. Kwestia odpowiedniego zarządzania "pokojami gry".
Zauważ, że jakoś brydża w sieci da się znaleźć
Więc tu bym problemu nie widział.
Natomiast uważam, że trzeba będzie trochę poeksperymentować i spróbować zrobić (także) rozgrywkę powiedzmy z 20 planetami i 30-50 graczy.
Zresztą zobaczymy. Tak jak mówię - przy dobrym podejściu obiektowym ilość planet, graczy itd. będzie mogła być zmieniana dowolnie. Da się uruchomić grę na 6 i na 600 Pytanie czy będzie grywalna

[blind99]

Dzięki. Pewnie, że można ale ja też muszę z czegoś żyć , a pracy przy takich tego typu grach jest naprawdę dużo. Programowanie to cholernie żmudna robota. Oprócz tego grafika, testowanie ja czasami kilka godzin testuję jakieś błahostki... Więc tak jak mówię, gra na pewno nie będzie dla kilku osób, poza tym myślę że jak będzie więcej osób to lepiej się będzie grało. Dzięki za pomoc jak coś to będę pisał...

PS. W sumie nie potrzebnie pytałem o te opowiadanie bo już znalazłem - na pewno się przyda.

[lighting]

Jeżeli chodzi o to, żeby z tego żyć, to GK jest kiepskim wyborem z racji tego, że mała ilość osób będzie miała ochotę zapoznawać się z tak trudnymi zasadami. Pisząc GK automatycznie zawężasz sobie grono odbiorców. Patrząc na rynek, to najlepiej sprzedają się proste lecz pomysłowe gierki.

[bluesqad]

Szkoda że się nie udało, ale nie ma co. Kolejne doświadczenie jest

Mógłbyś wrzucić cały kod projektu i go udostępnić wraz z grafikami? Może by coś ktoś łatwiej wywnioskował dzięki temu?


Co do zarobieniu na GK to nie nastawiaj się na to. Jest to za trudna i zbyt mozolna gra dla ludzi którzy chcą sobie zagrać wieczorem do piwa. Tutaj będziesz miał raptem kilku(nastu) graczy.
Był już kiedyś GK online napisany w PHPie i grało w niego dosłownie parę osób. Ten projekt należy bardziej traktować hobbystycznie, niż zarobkowo - jedynie dla własnej satysfakcji.

A jeśli by go porównać do gier online to nie będzie miał takiej grywalności ze względów mało wartkiej akcji i tego że teraz gracze nastawieni są raczej na karabin w ręce i byle do przodu