Każdy ma jakieś wady 
Witam,
chciałbym wyrazić swoje poparcie dla modelu open source w projekcie VCMI. Val-gaav przytoczył wiele argumentów za, w moim przypadku najważniejsze jest to, że mając źródła można powoli wdrożyć się w projekt bez dodatkowych deklaracji. Bardzo chętnie bym dołączył do Teamu programistów VCMI lecz niestety nie mogę w chwili obecnej obiecać, że zrobię to czy owo ponieważ nie mam zbyt dużo wolnego czasu i nie widziałem kodu (być może trzeba będzie coś doczytać, coś poznać od podstaw). A ‘wpraszanie się’ tylko po to aby przez kilka miesięcy oglądać kod i nic nie wnosić nie musi być mile widziane przez pozostałych deweloperów. Być może część programistów aspirujących do VCMI po przejrzeniu kodu źródłowego stwierdzi, że to ponad ich siły lub zrezygnuje z innych powodów.
Ja jestem zdecydowany pomóc, wnieść coś pożytecznego jako programista, bardzo chętnie porozmawiam z Tow czy w ogóle moja osoba jest tam potrzebna (umiejętności, czas, jakie taski czekają itp.) ale jak już wcześniej napisałem dostęp do kodów źródłowych byłby wielce pomocny w podejmowaniu decyzji i wysuwaniu swoich kandydatur.
pzdr
Witamy!
Z tym modelem open-source nie jest wcale tak prosto i różowo. Oczywiście, uprościłby nieco życie i nam i chętnym do współuczestniczenia w projekcie programistom. Nie przeceniałbym tu znaczenia otwarcia źródeł, ale przyznaję, że jest to sensowny argument.
Czemu więc ciągle ich nie otwieramy? W gruncie rzeczy decydujący jest tylko jeden powód - możliwości oszukiwania. Nawet średnio zdolny programista-amator mógłby sobie wtedy zbudować wersję VCMI z wyłączoną mgłą wojny (lub innymi “uprzyjemnieniami”). I wziąć udział w turnieju.
A trzeba pamiętać, że scena turniejowa jest spora i żywotna. Jeżeli VCMI ma być następcą H3 i WoG-a, to musi zapewniać niemniejsze bezpieczeństwo. Dopóki takie bezpieczeństwo nie będzie zapewnione, będę zwolennikiem rozwoju VCMI jako projektu zamkniętego.
Rozważamy dokonanie takich zmian w architekturze VCMI, które powinny uniemożliwić oszukiwanie poprzez manipulację klientem. Problem w tym, że jest tu zawsze coś za coś - generalnie gra będzie albo bezpieczna, albo sprawna i płynna. Nie zdecydowaliśmy jeszcze jak to zagadnienie rozstrzygniemy, sądzę jednak, iż do releasu 0.7 sytuacja się wyklaruje.
Choć - wnioskując po różnych opiniach, jakie przewinęły się przez to forum - niezależnie od tego, co zrobimy i tak jakaś grupa będzie bardzo niezadowolona. Taki już nasz los.
Co do ew. pomocy w programowaniu - w sumie dobra znajomość C++ jest wystarczająca. Korzystamy z SDL-a i kilku bibliotek z boosta, ale douczenie się ich w potrzebnym stopniu nie powinno być czasochłonne. Pomoc zawsze się nam przyda, choć już dawno straciłem wiarę w to, że jej doczekamy. Chyba nasz kod jest zbyt paskudny.
Mimo to sądzę, że warto spróbować swoich sił. Rozumiesz polski, więc ew. zadanie tłumaczenia czegokolwiek od razu mamy dalece ułatwione 
Jeśli podtrzymujesz swoje zainteresowanie, to TowDragon (zajmujący się rekrutacją i wdrożeniami) się powinien się wkrótce odezwać. Okazanie kodu źrodłowego nie jest takim dużym problemem, wystarczy, że założysz sobie konto na assembla.com a my dopiszemy Cię do odpowiedniej grupy.
Oczywiście swoją kandydaturę podtrzymuję 
Możliwości oszukiwania w H3 jest dostatecznie dużo. A kto chce oszukać, i tak oszuka. Niezbyt to badałem na multi, ale na singlu możliwości są wielkie.
EDIT: Wpadłam na pomysł, aby zrobić 3, lekko różniące się wersje VCMI. Jedna, byłaby do map singlowych i własnego modowania. Druga, miałaby własnoręcznie tworzoną sygnaturę, a twórca moda, rozsyłałby plik innym. Można by grać z innymi osobami, które mają VCMI z taką sama sygnaturą. I trzecia, wersja zamknięta, standardowa dla większości graczy.
Wysłałem ci maila z informacjami o kompilacji i otrzymaniu kodu.
Całymi godzinami już myśleliśmy, jaka architektura sieciowa będzie najlepsza. Po pierwsze, niemożliwe jest jednoczesne wypuszczanie wersji zamkniętej i otwartej - albo dałoby się i tak łątwo jedną w drugą zamienić, albo musielibyśmy de fact 2 projekty robić. Podobnie jest problem z sygnaturami - one dają niewielką ochronę przy zamkniętym kodzie (trzeba już się trochę pomęczyć, aby pozmieniać) i niemal żadną przy otwartym - można bez problemu wpisać odpowiednią w kod.
Generalnie, jeśli otworzymy kod VCMI, nie będzie możliwości ukrywania w kliencie jakichkolwiek informacji przed graczem - zawsze będzie można łatwo zmodyfikować kod i oszukiwać. Oczywiście, na kliencie tylko przez pozyskiwanie informacji, ale to i tak bywa dużo. A brak pewnych informacji będzie przeszkodą dla sprawnego wykonywania skryptów ERM. Co do serwera, to będzie trzeba po prostu ufać w uczciwość hosta - ma nieograniczone możliwosci oszukiwania.
Przy zamkniętym kodzie, sporo problemów znika - oszukiwanie staje się dużo trudniejsze przez sam fakt braku kodu. My możemy przygotować oszukującą wersje VCMI w 10 minut, a inni musieliby się męczyć bardzo długo.
Generalnie, otwieranie kodu jest kłopotliwe i ma pewne wady, dlatego nie chcemy być pochopni. Sądzę, że wszyscy przyznają, że lepiej mieć zamkniętą grę niż taką, w której każdego trzebaby podejrzewać o to, że może oszukiwać.
A jak będzie bezpieczna to będzie miał większe wymagania czy mniejszą szybkość
Ginden, witam na naszym forum!
Dlatego tym bardziej nie chciałbym ich poszerzać w VCMI.
Jeżeli oszukiwanie będzie dostatecznie utrudnione, to albo nie będzie umiał, albo uzna to za niewarte wysiłku. Absolutnego bezpieczeństwa nigdy się nie da zapewnić. Nie znaczy to jednak, że na tę kwestię winniśmy machnąć ręką.
Singiel się tu nie liczy, nikogo (poza sobą) w tym trybie nie oszukasz. Ba, oszukiwanie na singlu jest nawet wspierane przez twórców gier, chociażby przez udostępnione kody.
Jak dokładnie wygląda kwestia oszukiwania na multi nie bardzo wiem, nie wnikałem nigdy w te sprawy. Ale myślę, że jest trudne lub wykrywalne. Inaczej te wszystkie turnieje z nagrodami by były z miejsca spalone.
Wymagania sprzętowe wzrosną, ale to akurat żaden problem przy dzisiejszych komputerach.
Problemem będzie drastyczny wzrost użycia połączenia internetowego. Możemy zapewnić bezpieczeństwo, poprzez udostępnianie klientowi (niemal) wyłącznie tych informacji, które gracz ma prawo znać. Reszta pozostaje na serwerze. Sęk w tym, że w miarę jak gracz poznaje te wszystkie informacje, muszą one być przesyłane do klienta.
Obecnie skłaniamy się ku udostępnieniu obu tych rozwiązań, tj. możliwości gry zarówno w trybie “szybszym” jak i “bezpieczniejszym”. Z zaufanymi graczami będzie można grać normalnie, po staremu, a kluczowym rozgrywkom będzie można zapewnić praktycznie pełne bezpieczeństwo. Oczywiście, trzeba by było napisać wsparcie dla tego drugiego trybu i współpracę pomiędzy nimi.
Dodatkowo w takim wariancie możliwe też będzie otwarcie źródeł, bez pogrzebania projektu łatwością oszustw.
Jeśli wejdziesz między wrony musisz krakać …
Ekhem chodzi o to że używacie SDL, które to jest Wolnym Oprogramowaniem. Tak licencja LGPL zapewnia, że możecie linkować się do SDL i pozostać zamkniętymi, no ale grzecznościowo skoro użytkujecie kod otwarty wypadałoby i swój otworzyć.
To tak jak by sąsiad zaprosił Cię do siebie i poczęstował herbatą i ciastkami, kiedy Ty ugościsz swojego sąsiada wypadałoby też czymś go poczęstować. Oczywiście system wartości zależy od danej osoby i jest po prostu inny dla każdej jednostki.
Swoją drogą sądze, że lepiej jest podać techniczne zalety niż te moralne i tyle :). Są one przecież dośc przekonującę i kuszącę.
Jeśli zaś chodzi o oszukiwanie to wystarczy przy połączeniu porównywać exeki, pliki txt ze statsami jednostek itp. Powinno wystarczyć by jedna osoba miała niezmodyfikowaną wersję gry do wykrycia takiego oszustwa.
W h3 obecnie można oszukiwać bez żadnej wiedzy programistycznej, i nie sądzę by zamknięcie projektu znacznie utrudniło komuś kto chce stworzenie odpowiedniego programu oszukującego. Jest taki dla h3 to i dla VCMI powstanie, jesli tylko VCMI będzie popularne.
Po drugie obecnie na MP gra się z zaufanymi, a innych ma na oku. Dajce w standardzie autozapis w formacie :
autosave1
autosave2
autosave3
autosave4
I tak po rozgrywce można łatwo przejrzeć i sprawdzić czy ktoś oszukiwał czy nie. Obecnie w różnych rozgrywkach MP h3 tak się robi. Oczywiście ręczne zapisywanie gry po każdej turze nie jest zbyt przyjemne Ja ktoś zna gre to zauważy nieprawidłowości.
BTW przy okazji kodu sieciowego koniecznością jest dodanie tego co jest w h5 czyli symultanicznych tur + quick combat tak jak jest w h5 (czyli dostajemy wyniki quick comabat i możliwość rozegrania go(powtórzenia) w trybie normalnym). Te 2 rzeczy mają za zadanie przyśpieszyć rozgrywkę co na MP jest kluczowe.
Obecny system przesyłania kodu zainteresowanym jest IMHO niebezpieczny bo jak mniemam projekt nie jest jeszcze na żadnej licencji. Poza tym argument o zwiększeniu bezpieczeństwa multi przez zamkniętość nie jest prawdziwy. Jeśli będę chciał napisać trainer pokręce się tu trochę poproszę o kod i dostanę na pocztę po jakimś czasie.
No tak, otwieranie kodu linkującego do SDLa i innych bibliotek, które używamy jest czysto grzecznościowe. Ale jak sam widzisz, to słaby argument.
Wierz mi, to nie aż tak proste. Prowadziliśmy w teamie długie dyskusje, wymyślaliśmy najróżniejsze metody oszustw i zabezpieczeń, i lokalnie przechowywane statsy jesdnostek mają akurat najmniej do rzeczy, bo cała mechanika idzie i tak na serwerze (graczowi, który go odpala musimy niestety wierzyć, przynajmniej do pewnego stopnia). Kluczowe jest, aby na komputerze klienta nie były przechowywane żadne informacje, których nie może mieć gracz (obecnie robimy zmiany w VCMI, aby taki tryb umożliwić) oraz zrzucanie na każdym kliencie wszystkich wiadomości o zmianach stanu gry z serwera, które umożlwią sprawdzenie legalności każdej z wykonanych operacji. Wtedy serwer mógłby oszukiwać tylko w miejscach, gdzie nie musiałby informować o zmianach w stanie gry graczy, a klienci praktycznie w ogóle nie mogliby oszukiwać (nie widzę takiej możliwości). Wtedy groźne jest tylko oszukiwanie przez gracza mającego serwer (nie dałoby się wykryć, czy czasem nie dorzucił sobie jakichś jednostek) oraz zmowy gracza z serwerem z innymi graczami (może im dodawać jednostki np.)
Jednoczesne tury wymagałbyby pewnych zmian w mechanice rozgrywki i nie sądzę, aby były dostępne od momentu w którym będzie można grać przez sieć. Quick combat prędzej możnaby dorobić, to powina być tylko dość niewielka zmiana.
Obecnie VCMI jest na licencji freeware. Można się kłócić, czy to naprawdę jest licencja, ale na razie wystarcza. Mam nadzieję, że Tow nie będzie na mnie zły za wyciek, ale już skońćzyliśmy w teamie dyskusję nad zmianą licencji na GPL i doszliśmy do wniosku, że to najlepsza opcja. Otwarcie kodu jest obecnie tylko kwestią czasu (aż komuś zechce się zrobić kilka zmian i puścić newsa na forum).
Zmienne IP i znów oszukiwanie 
Z tym krakaniem trzeba jednak uważać, przyzwyczajenie bowiem drugą naturą człowieka.
Skoro autorzy SDL-a wypuścili go na licencji dopuszczającej linkowanie z zamkniętym kodem, to widać nie mają nic przeciw temu. Niegrzeczne z mojej strony by było przypuszczanie, iż zrobili co innego, niż chcieli.
Miło jest ze strony sąsiada, gdy mnie poczęstuje ciastkiem. Prawda.
Nie wiem natomiast, czy szczytem elegancji ze strony jego znajomych jest odwiedzanie mnie, wypominanie rzeczonej herbatki i naleganie, bym i ja się zrewanżował ciastkiem. A jeżeli nie oddam swojego ciastka jego grupie, to zorganizują protest (bojkot), albo mnie postraszą, iż usmażę się w piekle (niemoralność).
Nie mam pomysłu jak do tej analogii wepchać jeszcze głosy, które przestrzegały nas przed otwarciem źródeł, bo to “pogrzebie projekt” - a były.
Zresztą ta dyskusja i tak już jest pozbawiona sensu. Niemniej chcę zaznaczyć, że ta sprawa nie jest tak czarno-biała, jak niektórzy usiłują ją przedstawiać.
Prawda, na tyle nawet, że nas przekonały.
A jak sprawdzić, czy gość nie oszukuje przy porównywaniu?
Powtórzę jeszcze raz - albo mamy w grze bezpieczeństwo, albo płynność i reaktywność. Nie znam sposobu, by się dało osiągnąć i jedno i drugie.
Tury symultaniczne zamierzam zaimplementować, traktuję to jako jedną z ważniejszych funkcjonalności na etapie, gdy VCMI będzie grywalne.
Przy czym to też pociąga pewne trudności - nie ze wszystkimi koncepcjami kodu sieciowego współgra i samo w sobie tez kosztuje. Trzeba to wszystko ładnie zsynchronizować.
Trochę na wyrost ujęte, docelowo zamierzamy tryb ten udostępnić, lecz raczej nie w pierwszej kolejności.
Nie do końca, klient, nie dysponując kompletem informacji, nie może (a przynajmniej nie zawsze może) weryfikować informacje o wiadomych mu zmianach.
W ogóle wszystko to [sprawy kodu sieciowego i bezpieczeństwa] okazuje się dużo trudniejsze, niż pierwotnie sądziłem. Nawet przy założeniu, że serwer nie będzie oszukiwał, bezpieczeńśtwo ma wysoką cenę. Bez założenia - jest nieosiągalne.
No tak, chyba rzeczywiście lekko przesadziłem, ale i tak można wtedy dość sporo sprawdzić.
Oczywiście. Chciałem tylko przedstawić w nieco lepszym świetle czemu niektórzy uznają to za niemoralne. Tak żeby nie był to totalny fanatyzm ze strony tych ludzi 
Oczywiście bardzo słuszna uwaga.
Oznacza to, że pewne przejawy fanatyzmu istnieją po obu stronach.
Słuszna uwaga. Jednakże pewne zmiany by się przydały. IMHO nie może być np. tak jak jest w WoGu, że tzw opcje wogifikacji i skrypty idą tylko ze strony gracza-serwera (o ile wiem tak właśnie jest). Podobnie nie może być tak jak jest w oryginalnym h3, że pliki txt są niejako traktowane oddzielnie czyli jeden gracz może mieć u siebie impy z 10 hp a drugi z normalną wartością.
Przy ostatecznej walce zaś w takim wypadku dochodzi do zawieszenia gry bo jeden gracz ma inne statsy niż drugi. Stąd wział się popularny zwis ang wersja SoD vs pl wersja SoD, gdyż któraś z jednostek fortress miała inne staystyki w wersji polskiej.
Dwa tryby to pewne rozwiązanie problemu. Dla wielu osób płynność i reaktywność może być priorytetem z prostej przyczyny, ufają ludziom z którymi grają.
Kod sieciowy, AI i w przypadku herosów również generator map losowych to najtrudniejsze zadania ogólnie w prawie każdej grze.
Skoro projekt przechodzi na GPL, to może warto skorzystać z kolejnego plusa tej licencji. Mam na myśli wykorzystanie już istniejącego kodu. Battle for Wesnoth to też gra turowa i mimo pewnych różnic w rozgrywce jej kod sieciowy mógłby być dobrą podstawą dla VCMI. Battle for Wesnoth ma też swoje własne lobby, które też by można wykorzystać by VCMI miało coś w stylu własnego serwera.
Ponieważ trochę grałem w Battle for Wesnoth mogę zaświadczyć, że ich kod jest dobry. Ma bardzo niskie wymagania odnośnie łącza (sądzę, że i na modemie dałoby się grać spokojnie). Nie uświadczyłem też żadnych lagów ani rozłączeń itp.
Scena MP to nicki a nie IP . Raz przyłapana osoba na oszustwie traci wiele. Wszystkie jej osiągnięcia w turniejach itp. Zaczynanie zaś z nowym nickiem to zaczynanie od zera. Autosave to naprawdę dobry sposób na oszukiwaczy bo w turnieju doświadczony gracz jeśli będzie miał jakieś podejrzenia to przejrzy autozapisy drugiego gracza i rozpozna jeśli coś się nie będzie zgadzać. Przykładowo w polskiej lidze pojawił się kiedyś oszust który specjalistycznym programem dodawał sobie złoto i jednostki po walkach. Niestety w którejś z tur minimalnie się pomylił i dodał sobie za dużo. Biorąc pod uwagę limit czasu itp. bardzo ciężko się nie pomylić.
Tak, dokładnie. I ja się w tej sytuacji czułem trochę jak między młotem a kowadłem.
Mimo to wszystko zmierza już ku szczęśliwemu - miejmy nadzieję! - rozwiązaniu.
Masz tu rację, zdaję sobie z tego sprawę. Ludzie grają w Heroesy z różnych przyczyn, z których wynikają różne - w efekcie często sprzeczne ze sobą - priorytety.
Organizatorom i uczestnikom wszelakich lig i turniejów zdecydowanie bardziej zależy na zapewnieniu możliwie bezpiecznej i uczciwej rozgrywki, niż na maksymalnej możliwej reaktywności.
Osobom, które czysto rozrywkowo pogrywają z przyjaciółmi nie potrzeba wszystkich tych kosztownych zasieków, dla nich kluczowy jest komfort rozgrywki - żeby szło płynnie i bez bagów.
Jedno z drugim się wyklucza, toteż możemy najwyżej udostępnić oba tryby, co zadowoli obie grupy. Tylko, że jest to mnóstwo roboty dla nas. W najbliższej przyszłości raczej się jej nie podejmiemy, zbyt wiele kluczowych aspektów rozgrywki wciąż jest niedokończonych.
Obecny model sieciowy realizuje wariant pośredni. Wszystkie informacje są dostępne klientom, ale wydarzenia w rozgrywce (całą jej mechanikę) obsługuje serwer i informuje klienty o rezultatach.
Jeśli kogoś bliżej interesuje problem kodu sieciowego i oszukiwania w VCMI, to pozwolę sobie przytoczyć fragment mojego maila z dyskusji z kolegą z zespołu, w którym kreśliłem charakter tych problemów:
Chyba wszystkie istotniejsze kwestie zostały tam uwzględnione.
My już mamy własny kod sieciowy. Pewnie nie jest tak ładny jak Wesnothowy - aczkolwiek de gustibus non disputandum est - ale jest gotowy i działa. Nie wierzę, by dało się z korzyścią w tej chwili wykorzystać kod z projektu o tak odmiennej mechanice.
Zresztą szybkość i stabilność, to nie raczej kwestia samego kodu sieciowego; on na niższym poziomie pewnie i tak pewnie wygląda podobnie. To przede wszystkim jego użycie - ile informacji przesyłamy, jak bardzo oczekiwanie na nie jest dla użytkownika odczuwalne, jak reagujemy w sytuacjach kryzysowych. Są to rzeczy raczej związane z samą mechaniką gry niż kodem sieciowym. Choć zależy też jak szeroko to pojęcie interpretujemy.
PS. Ciekawe, ilu osobom uda się przebić przez ten post 
Ależ do tego nie potrzeba wcale wiedzy programistycznej. Wystarczą save’y gry i drugi komputer i można na bieżąco sprawdzać wszystkie te informacje w trakcie rozgrywki.
Do wzięcia pod uwagę jest też fakt, że te dane które chcecie ukryć powinny być i tak jakoś póżniej dostępne. Mam na myśli :
- Wygląd mapy - czy przeciwnik edytorem nie dodał sobie surowców. Swoją drogą mapy też powinny być porównywane i nie zezwalać na takie oszustwa . W przypadku map losowych gracze z jednej strony nie powinni móc jej podejrzeć w edytorze, a z drugiej strony popularne na MP są tak zwane restarty jeśli kopalnie ore i wood są nieosiągalne dla gracza lub zbytnio bronione. Bez podglądu mapy te restarty byłyby nadużywane. Alternatywa to na tyle dobry generator by te restarty nie były potrzebne.
Podobnie z autozapisem z jednej strony można wczytać na drugim PCi podejrzeć przeciwnika, a z drugiej jest on konieczny by ewentualnie udowodnić oszustwo.
Dlatego w trybie w pełni bezpiecznym tylko serwer mógłby zapisywać grę.
W trybie w pełni bezpiecznym klient nie wczytywałby mapy, tylko otrzymywał absoultnie niezbędne o niej informacje od serwera, czyli lokalna kopia mapy o takiej samej nazwie byłaby nawet nietknięta.
A kto ma mapy porównywać? Jeśli klient, to drobna zmiana w kodzie powoduje że VCMI przestaje na wynik porównania zwracać uwagę. Jeśli serwer, to klienta można zmodyfikować, żeby wysyłał to czego spodziewa się serwer a lokalnie odpalał co innego.
Najlepsze byłoby automatyczne sprawdzanie na serwerze, czy istotnie te kopalnie są zbyt bronione lub za daleko. No albo generator, który w powszechnym przekananiu generowałby mapy bez tej wady. Jeśli nie będzie ani jednego, ani drugiego to nie widzę dobrego rozwiązania.
Tu akurat jest troche inaczej. Autozapis na samym serwerze (jak już pisałem, w trybie w pełni bezpiecznym klient nie może zapisywać stanu gry) nie zmniejsza bezpieczeństwa (serwer i tak ma dużo większe możliwości oszustw), zaś udowadnianie oszustw byłoby albo za pomocą zapisu zmian stanu gry wysyłanych przez serwer, albo przez to co jest zapisywane na samym serwerze. Tak więc nie widzę tu żadnej nowej problematycznej kwestii.