Na forum 4programmers.net korzystamy z plików cookies. Część z nich jest niezbędna do funkcjonowania
naszego forum, natomiast wykorzystanie pozostałych zależy od Twojej dobrowolnej zgody, którą możesz
wyrazić poniżej. Klikając „Zaakceptuj Wszystkie” zgadzasz się na wykorzystywanie przez nas plików cookies
analitycznych oraz reklamowych, jeżeli nie chcesz udzielić nam swojej zgody kliknij „Tylko niezbędne”.
Możesz także wyrazić swoją zgodę odrębnie dla plików cookies analitycznych lub reklamowych. W tym celu
ustaw odpowiednio pola wyboru i kliknij „Zaakceptuj Zaznaczone”. Więcej informacji o technologii cookie
znajduje się w naszej polityce prywatności.
Aktualnie w moim czasie wolnym pracuję nad grą logiczną na telefony komórkowe.
Gameplay mam już w 90% przemyślany, gra działa i jest grywalna.
Mój problem nie jest może do końca programistyczny, ale myślę że pasuje do tego działu na forum.
Jak ułożyć wzrastający poziom trudności w grze, tak aby gra nie była ani za łatwa ani za trudna?
Chodzi mi o to, żeby poziom trudności był tak zbalansowany, żeby gracz chciał grać dalej i nie zniechęcał się zbyt szybko.
Czy można to zrobić przy pomocy AI czy tylko najlepiej testów manualnych?
Jeżeli gra będzie się uczyć tego jak ktoś gra, to poziom trudności będzie rósł różnie dla róznych graczy, przez co np. ranking globalny graczy nie będzie sprawiedliwy.
Czy może znacie jakieś książki, w których są opisane tego typu rzeczy?
Aktualnie w moim czasie wolnym pracuję nad grą logiczną na telefony komórkowe.
Musisz napisać coś więcej na temat tej gry.
Jak ułożyć wzrastający poziom trudności w grze, tak aby gra nie była ani za łatwa ani za trudna?
Wszystko zależy od tego, co konkretnie robi się w tej grze, na czym gameplay polega. Dynamicznie dostosowujący się poziom trudności co prawda brzmi bardzo interesująco, ale trzeba pamiętać, że nie jest to standard, nie do każdej gry będzie pasować.
Chodzi mi o to, żeby poziom trudności był tak zbalansowany, żeby gracz chciał grać dalej i nie zniechęcał się zbyt szybko.
Tak czy siak każdą grę należy ręcznie zbalansować, bo to musi być fundament dla mechaniki zmieniającego się poziomu trudności, aby wiedziała, jakie są granice trudności — dolna, dla niedzielnych graczy (również dla dzieci) oraz górna, dla hardkorowców. Te granice musisz znaleźć samodzielnie, jako punkt startowy do dalszego balansowania.
Czy można to zrobić przy pomocy AI czy tylko najlepiej testów manualnych?
Zależy co masz na myśli pisząc o pomocy AI. IMO bez beta-testów się nie obejdzie, dlatego że żadne oprogramowanie nie zastąpi człowieka w tej kwestii. Powinieneś skorzystać z pomocy beta-testerów i finalnie zbalansować grę na podstawie ich feedbacku. Natomiast nic nie stoi na przeszkodzie, aby wersja beta przeznaczona do testów gromadziła dane telemetryczne.
Takie dane są bardzo cenne, bo nie tylko dostarczą mnóstwo dodatkowych informacji, których człowiek nie wyłapie i nie zgromadzi, ale i będą one zdecydowanie bardziej wiarygodne i bardziej precyzyjne, niż prosty feedback. Pamiętać trzeba, że człowiek to nie maszyna, nie zauważy mnóstwa szczegółów, może i będzie się mylić, ale też może mieć zły humor, być uprzedzonym czy po prostu kłamać dla własnych korzyści. A telemetria nie kłamie, nie myli się i niczego nie pomija.
Jeżeli gra będzie się uczyć tego jak ktoś gra, to poziom trudności będzie rósł różnie dla róznych graczy, przez co np. ranking globalny graczy nie będzie sprawiedliwy.
To zależy czym ta gra jest, jak istotny jest globalny ranking i czego w ogóle dotyczy. Ale nic nie stoi na przeszkodzie, aby użyty w trakcie gameplay'u poziom trudności wykorzystywać do obliczenia końcowego wyniku gracza (jeśli miałby to być wynik punktowy).
Aktualnie w moim czasie wolnym pracuję nad grą logiczną na telefony komórkowe.
Musisz napisać coś więcej na temat tej gry.
"Gra logiczna" trochę mówi o grze.
Trudność nie będzie taka jak w Snake, czy Tetrisie, gdzie wzrastający poziom trudności polega głównie skracaniu czasu na podjęcie decyzji.
Więc jeśli gra będzie podobna do tego:
To będzie trzeba poziom skomplikowania poziomów stopniowo zwiększać wraz z dodawaniem nowych elementów (typów przeszkód itp.).
Ale takie rzeczy to można wywnioskować grając w takie gry.
A potem odwzorować/skopiować z nich do swojej produkcji.
Np. pierwszy poziom pokazuje podstawową mechanikę. Potem jakiś trudniejszy poziom, który wymaga zastosowania tego co się gracz nauczył w pierwszym. Potem wprowadzenie następnej mechaniki i jakieś poziomy, które wymagają jej zastosowania, a potem łączenie poszczególnych mechanik, żeby rozwiązać łamigłówki itd.
2
Gier logicznych jest tyle, że nie mam za bardzo szans udzielić jednoznacznej odpowiedzi. W zależności od typu gry logicznej, poziom trudności może dotyczyć bardzo wielu różnych mechanik i elementów gameplay'u — upływ czasu to jeden z wielu elementów.
Dlatego dobrze by było wiedzieć na czym gameplay polega, czy jest to gra stricte logiczna (do klikania), czy logiczno-zręcznościowa, w której nie tylko liczy się inteligencja, ale też motoryka, koordynacja oko-ręka.
Co ciekawe, poziom trudności w Tetrisie też bez problemu mógłby być dynamicznie balansowany.
Pewne rzeczy byłyby z góry ustalone (im wyższy level tym wyższa prędkość opadania klocków), ale niektóre mogłyby się dostosowywać dynamicznie. Np. im wyższy stos (trudniejsza sytuacja), im więcej dziur w nim (bardziej problematyczne jego wypalenie) i im więcej palonych singli i doubli (większa panika i chęć uspokojenia się), tym mniej wymagające sekwencje kolejnych klocków (czyli tym bardziej przyjazne RNG).
Aktualnie w moim czasie wolnym pracuję nad grą logiczną na telefony komórkowe.
Tak czy siak każdą grę należy ręcznie zbalansować, bo to musi być fundament dla mechaniki zmieniającego się poziomu trudności, aby wiedziała, jakie są granice trudności — dolna, dla niedzielnych graczy (również dla dzieci) oraz górna, dla hardkorowców. Te granice musisz znaleźć samodzielnie, jako punkt startowy do dalszego balansowania.
Czy wystarczy jak ja sam będę ją balansować? Nie jestem w niej co prawda niedzielnym graczem, myślę że aktualnie najbardziej zaawansowanym graczem, ale jeżeli gra będzie miała jakieś chociaż minimalne zainteresowanie to myślę, że znajdą się więksi hardcorowcy niż ja.
Zależy co masz na myśli pisząc o pomocy AI. IMO bez beta-testów się nie obejdzie, dlatego że żadne oprogramowanie nie zastąpi człowieka w tej kwestii. Powinieneś skorzystać z pomocy beta-testerów i finalnie zbalansować grę na podstawie ich feedbacku. Natomiast nic nie stoi na przeszkodzie, aby wersja beta przeznaczona do testów gromadziła dane telemetryczne.
Tak, tyle że pracuję nad grą sam i nie mam budżetu na beta testerów, może nawet bym i miał ale widzę tutaj dwa problemy:
wydaje mi się, że mój pomysł jest dość oryginalny i nie chcę żeby ktoś inny zbyt szybko zrobił klona
nie wiem ile mogą kosztować beta testerzy
Jeżeli gra będzie się uczyć tego jak ktoś gra, to poziom trudności będzie rósł różnie dla róznych graczy, przez co np. ranking globalny graczy nie będzie sprawiedliwy.
To zależy czym ta gra jest, jak istotny jest globalny ranking i czego w ogóle dotyczy. Ale nic nie stoi na przeszkodzie, aby użyty w trakcie gameplay'u poziom trudności wykorzystywać do obliczenia końcowego wyniku gracza (jeśli miałby to być wynik punktowy).
Dzięki za odpowiedź, w sumie dobry punkt, tylko że AI nie programowałem do tej pory więc pewnie żeby to ogarnąć trochę czasu mi zajmie, pewnie zostane w takim razie jedynym testerem :(
Aktualnie w moim czasie wolnym pracuję nad grą logiczną na telefony komórkowe.
Musisz napisać coś więcej na temat tej gry.
"Gra logiczna" trochę mówi o grze.
Trudność nie będzie taka jak w Snake, czy Tetrisie, gdzie wzrastający poziom trudności polega głównie skracaniu czasu na podjęcie decyzji.
Jest to gra bardziej typu Tetris niż Snake. Mam problem tego typu, że jak na początku poziom jest za łatwy to gra jest nudna, ale na początku nie chcę też od razu dać wszystkich opcji, a w sumie wtedy gra jest najciekawsza.
W sumie to mam jeszcze kilka nierozstrzygniętych kwestii.
mogę robić levele i co kilka leveli wrzucać coś nowego
ciągła gra gdzie levele wskakują po uzyskaniu iluś tam punktów
Ostatecznie pewnie zdecyduję się na obydwa tryby jednak levele w trybie 1 będą inne niż te w trybie 2.
Więc jeśli gra będzie podobna do tego:
To będzie trzeba poziom skomplikowania poziomów stopniowo zwiększać wraz z dodawaniem nowych elementów (typów przeszkód itp.).
Ale takie rzeczy to można wywnioskować grając w takie gry.
A potem odwzorować/skopiować z nich do swojej produkcji.
Np. pierwszy poziom pokazuje podstawową mechanikę. Potem jakiś trudniejszy poziom, który wymaga zastosowania tego co się gracz nauczył w pierwszym. Potem wprowadzenie następnej mechaniki i jakieś poziomy, które wymagają jej zastosowania, a potem łączenie poszczególnych mechanik, żeby rozwiązać łamigłówki itd.
Tak, tak właśnie dokładnie nad takim mechanizmem myślę, dzięki.
Dlatego dobrze by było wiedzieć na czym gameplay polega, czy jest to gra stricte logiczna (do klikania), czy logiczno-zręcznościowa, w której nie tylko liczy się inteligencja, ale też motoryka, koordynacja oko-ręka.
Właśnie to jest dobre pytanie, bo mogę zrobić z tego zarówno grę loginczą jak i logiczno-zręcznościową w zależności od tego jak zaprojektuję levele, w sumie nie wiem cały czas w którą stronę ostatecznie pójść.
Co ciekawe, poziom trudności w Tetrisie też bez problemu mógłby być dynamicznie balansowany.
Pewne rzeczy byłyby z góry ustalone (im wyższy level tym wyższa prędkość opadania klocków), ale niektóre mogłyby się dostosowywać dynamicznie. Np. im wyższy stos (trudniejsza sytuacja), im więcej dziur w nim (bardziej problematyczne jego wypalenie) i im więcej palonych singli i doubli (większa panika i chęć uspokojenia się), tym mniej wymagające sekwencje kolejnych klocków (czyli tym bardziej przyjazne RNG).
Dzięki, w tej odpowiedzi mam kilka nowych pomysłów. Szczególnie to, że niektóre rzeczy mogą się dostosowywać dynamicznie a niektóre być zahardcodowanie. Nie wpadłem na to, myślałem, że wszystko muszę zahardcodować :)
Ogólnie miałem prosty pomysł, myślałem że po godzinach w pół roku zrobię a już tak ten projekt leży kilka lat i cały czas w toku
Oczywiście nie pracuję nad nim cały czas, mam okresy że siedzę nad tym i dużo dodaję a później takie że nic nie robię, ale w tym roku już chciałbym wydać bo żyję w niepewności i nie wiem czy to będzie hit czy kit :) Ogólnie stworzenie nawet takiej prostej gry jest dla mnie dużo trudniejsze niż myślałem, pomimo tego że już proste gry logiczne tego typu pisałem typu klon Tetrisa, Snake, Arkanoid itp.
3
Jeśli sam robisz grę i z obawy przed plagiatami nie chcesz jej nikomu pokazywać ani szczegółowo opisywać na czym gameplay polega, to masz trzy wyjścia:
Trzymać projekt nadal w tajemnicy i nauczyć się w tę grę grać po mistrzowsku. Wtedy będziesz wiedział co może w niej zrobić nie tylko początkujący (tę fazę masz już za sobą), ale i wymiatacz. Przy czym bierz pod uwagę to, że ludzie potrafią bardzo dużo, więc to co dla ciebie może być sufitem, dla absolutnych wymiataczy będzie zaledwie podłogą.
Znaleźć osoby chętne do testowania w wolnym czasie, czyli w formie wolontariatu, ale które potrafią trzymać gębę na kłódkę i nie zdradzać żadnych szczegółów absolutnie nikomu. Znalezienie takich ludzi będzie bardzo trudne.
Wynająć beta-testerów, którzy zgodzą się na podpisanie NDA, za określone wynagrodzenie. To jest opcja bezpieczna, ale może być droga, szczególnie, jeśli potrzebowałbyś dużej grupy takich testerów.
W przypadku prostego projektu i/lub braku odpowiedniego budżetu, raczej skupiłbym się na punkcie 1., czyli samodzielnym ogarnięciu wszystkiego. To się da zrobić, bo wiesz wszystko na temat tej gry — jedyne czego może brakować to skilla w samym graniu.
Jeśli chodzi o to co można dynamicznie balansować w grze, to spokojnie można powiedzieć, że niemal wszystko. Pytanie tylko czy dynamiczny balans poziomu trudności faktycznie do tej gry pasuje, czy wzbogaci gameplay, czy go zdewastuje (i statystyki globalne). Dynamicznie można balansować absolutnie każdy aspekt gameplay'u, od okien czasowych po procentowe prawdopodobieństwo wystąpienia konkretnych zdarzeń, w dodatku na podstawie mniejszej lub większej ilości różnych danych/telemetrii. Tak więc to raczej nie jest kwestia co można, a co powinno podlegać takiemu zmiennemu zachowaniu.
0
Dzięki za odpowiedź, niby można się trochę śmiać z tego, że nie chcę udostępniać pomysłu i pokazywać innym, ale ja nie zgadzam się z poglądem, że nikt pomysłu nie może ukraść i liczy się tylko realizacja.
Będę musiał pozostać przy punkcie 1, to nie jest aż na tyle skomplikowana gra, żeby korzystać z opcji 2 i 3.
Jeżeli chodzi o to dynamiczne balansowanie trudności to muszę jeszcze przemyśleć, trochę tego dużo jest.
W sumie zaczynając pisać grę nie zdawałem sobie sprawy z tego, że najtrudniejsze będzie zbalansowanie tego wszystkiego.
[…] niby można się trochę śmiać z tego, że nie chcę udostępniać pomysłu i pokazywać innym […]
Nie ma takiego obowiązku, nie musisz niczego i nikomu pokazywać aż do dnia publikacji. A jeśli ktoś tego nie rozumie, to jego problem.
Jeżeli chodzi o to dynamiczne balansowanie trudności to muszę jeszcze przemyśleć, trochę tego dużo jest.
Dobrze by było, gdybyś kod źródłowy miał napisany tak, aby bardzo łatwo zmieniać jej działanie. Np. zmieniasz wartość jednej stałej i reszta się do niej adaptuje.
W sumie zaczynając pisać grę nie zdawałem sobie sprawy z tego, że najtrudniejsze będzie zbalansowanie tego wszystkiego.
Odpowiednie zbalansowanie rozgrywki nie tylko jest trudne, ale i niezwykle istotne, dlatego nie można tego robić po łebkach. Jeśli gra będzie nudzić lub frustrować, to cała reszta nie będzie miała znaczenia, bo gracz nie będzie chciał grać. To tak samo jak ze sterowaniem — jeśli skopie się ten temat i zrobi sterowanie nieresponsywne lub skomplikowane, chęć do grania będzie mała.
Pamiętaj też, że to co wypuścisz na produkcję nie musi być wersją absolutnie ostateczną — w końcu nie będziesz tej gry tłoczył na CD (mam nadzieję). Balans, do którego dojdziesz sam, będzie punktem startowym. Jeśli skorzystasz z pomocy testerów, to będziesz miał nieco szerszą perspektywę. Natomiast po release nadal możesz zbierać feedback i jeśli wystarczająco dużo graczy będzie na coś narzekać, to ten element poprawiasz i dostarczasz nową wersję w aktualizacji.
Tak więc nie ma co panikować, w dowolnym momencie możesz zmienić każdy aspekt gry. Mimo wszystko dobrze jest dobrze ten temat przemyśleć, zanim puści się grę na produkcję, bo pierwsze wrażenie można zrobić tylko raz, stąd powinno być jak najlepsze.
W sumie zaczynając pisać grę nie zdawałem sobie sprawy z tego, że najtrudniejsze będzie zbalansowanie tego wszystkiego.
Odpowiednie zbalansowanie rozgrywki nie tylko jest trudne, ale i niezwykle istotne, dlatego nie można tego robić po łebkach. Jeśli gra będzie nudzić lub frustrować, to cała reszta nie będzie miała znaczenia, bo gracz nie będzie chciał grać. To tak samo jak ze sterowaniem — jeśli skopie się ten temat i zrobi sterowanie nieresponsywne lub skomplikowane, chęć do grania będzie mała.
To jest szczególnie istotne w grach mobilnych, gdzie gra musi angażować gracza jak najdłużej, żeby były zyski z reklam itd.
Bo w grach na Steamie Twoja gra musi wytrzymać przez 2 godziny, żeby nie dało się zrobić refund :]
Dzięki za odpowiedź, niby można się trochę śmiać z tego, że nie chcę udostępniać pomysłu i pokazywać innym, ale ja nie zgadzam się z poglądem, że nikt pomysłu nie może ukraść i liczy się tylko realizacja.
Oczywiście szansa, że ktoś ukradnie Twój pomysł i zrobi klona Twojej gry jest niezerowa.
Ale najbardziej na to mogą liczyć gry, które już odniosły sukces.
Dlatego, że popularna gra zostanie zauważona przez znacznie więcej osób,
a także dlatego, że jej statystyki zachęcają, aby spróbować powtórzyć ten sukces.
Gra, która jeszcze nie udowodniła swojej wartości ma niskie szanse, żeby kogoś zachęciła by ją sklonować.
Zwłaszcza na odpowiednim, komercyjnym poziomie.
To jest szczególnie istotne w grach mobilnych, gdzie gra musi angażować gracza jak najdłużej, żeby były zyski z reklam itd.
Właśnie tutaj się zastanawiam jak to rozwiązać. Idealnie chciałbym zrobić tak, żeby gra była płatna i bez żadnych reklam, ale pewnie wtedy nikt nie kupi albo bardzo mało osób.
Robienie in-app purchases wygląda mi na coś co spowoduje, że prace nad grą będą trwać dłużej, tj. dodatkowy development.
Z drugiej strony pewnie zysk z reklam jest bardziej stabilny długoterminowo, jeżeli ludzie grają w grę i ma się może ewentualnie wtedy jakieś fundusze na dalszy rozwój.
Oczywiście szansa, że ktoś ukradnie Twój pomysł i zrobi klona Twojej gry jest niezerowa.
Ale najbardziej na to mogą liczyć gry, które już odniosły sukces.
Tak, tylko głupio, żeby ktoś sklonował zanim ja wypuszczę, chociaż te kilka EUR/USD chciałoby się zarobić
Dlatego, że popularna gra zostanie zauważona przez znacznie więcej osób,
a także dlatego, że jej statystyki zachęcają, aby spróbować powtórzyć ten sukces.
Gra, która jeszcze nie udowodniła swojej wartości ma niskie szanse, żeby kogoś zachęciła by ją sklonować.
Zwłaszcza na odpowiednim, komercyjnym poziomie.
Dobrze by było, gdybyś kod źródłowy miał napisany tak, aby bardzo łatwo zmieniać jej działanie. Np. zmieniasz wartość jednej stałej i reszta się do niej adaptuje.
Tak właśnie robię, tylko nie podoba mi się sposób w jaki to mam zrobione.
Jest jedna główna klasa, która przetrzymuje te wszystkie parametry w postaci stałych.
Zastanawiam się nad rozproszeniem tego do klas poszczególnych leveli, ale wtedy jak np. będę mieć 100 leveli to klasa na level :/
Ewentualnie wczytywanie z pliku albo jakiejś bazy danych, ale nie wiem w sumie które podejście tutaj było by najlepsze.
Natomiast po release nadal możesz zbierać feedback i jeśli wystarczająco dużo graczy będzie na coś narzekać, to ten element poprawiasz i dostarczasz nową wersję w aktualizacji.
Dzięki, wezmę to pod uwagę.
Tak więc nie ma co panikować, w dowolnym momencie możesz zmienić każdy aspekt gry. Mimo wszystko dobrze jest dobrze ten temat przemyśleć, zanim puści się grę na produkcję, bo pierwsze wrażenie można zrobić tylko raz, stąd powinno być jak najlepsze.
Tak, właśnie dlatego jeszcze jej nie wypuściłem, chociaż mógłbym pewnie już dawno to zrobić to cały czas eksperymentuję z różnymi rzeczami.
Tak właśnie robię, tylko nie podoba mi się sposób w jaki to mam zrobione.
Jest jedna główna klasa, która przetrzymuje te wszystkie parametry w postaci stałych.
Co ta klasa reprezentuje? Pojedynczy level?
Zastanawiam się nad rozproszeniem tego do klas poszczególnych leveli, ale wtedy jak np. będę mieć 100 leveli to klasa na level :/
Nie brzmi to najlepiej.
Ewentualnie wczytywanie z pliku albo jakiejś bazy danych, ale nie wiem w sumie które podejście tutaj było by najlepsze.
Kod poziomu powinieneś mieć tak napisany, aby część jego funkcjonalności była hardkodowana, a inna dała się parametryzować. Jeśli poziom trudności ma być dynamiczny, względem aktualnego skilla gracza, nie tylko potrzebujesz parametryzacji, ale też możliwości dynamicznej zmiany niektórych elementów, aby zwiększyć lub zmniejszyć poziom trudności.
Jednak nadal pozostaje ten sam problem — nic nie wiemy o twojej grze, więc niczego konkretnego nie można zasugerować. Możemy się tylko przerzucać ogólnikami i wróżyć z fusów, a to może w niczym nie pomóc.
Natomiast po release nadal możesz zbierać feedback i jeśli wystarczająco dużo graczy będzie na coś narzekać, to ten element poprawiasz i dostarczasz nową wersję w aktualizacji.
Dzięki, wezmę to pod uwagę.
Pamiętaj, że jest to normalne w fazie utrzymywania oprogramowania. Deweloper, któremu zależy na dostarczeniu produktu jak najwyżej jakości, słucha feedbacku i na niego reaguje — naprawia błędy, balansuje rozgrywkę i dodaje nowe ficzery.
Tak, właśnie dlatego jeszcze jej nie wypuściłem, chociaż mógłbym pewnie już dawno to zrobić to cały czas eksperymentuję z różnymi rzeczami.
To brzmi jak klasyczna pułapka indie dewelopera — niekończące się szlifowanie przed pierwszym releasem, dążenie do ideału. To jest pułapka, w której jeśli utkniesz, to na bardzo długo i będziesz z tego powodu bardzo nieszczęśliwy. Postaraj się doszlifować produkt do takiej postaci, aby gra była grywalna i działała w miarę bezbłędnie. Nawet jeśli masz obawy, że coś nie jest najlepsze, to puść release i pracuj dalej, jednocześnie łapiąc feedback. Wszystkich problem i tak nie przewidzisz.
Przy czym jeśli jakość gry jest gówniana, zawiera wiele błędów i grywalność jest słaba, to czegoś takiego na produkcję nie wysyłaj. Nie bądź jak współcześni deweloperzy, którym się wydaje, że gracze to idioci, którzy łykną każdy syf, bo się produkt oznaczy jako wieczna alpha/beta. To są zakały gamedevu, sukcesywnie niszczące rynek gier i okradający graczy, wykorzystując ich fascynację i nierzadko naiwność.
Kod poziomu powinieneś mieć tak napisany, aby część jego funkcjonalności była hardkodowana, a inna dała się parametryzować. Jeśli poziom trudności ma być dynamiczny, względem aktualnego skilla gracza, nie tylko potrzebujesz parametryzacji, ale też możliwości dynamicznej zmiany niektórych elementów, aby zwiększyć lub zmniejszyć poziom trudności.
I żeby nie trzeba było dokonywać długotrwałej kompilacji czy wielu różnych kroków.
Bo np. chcesz sprawdzić, czy lepiej jest zrobić wroga o 10% szybszego albo czy może zrobić trochę większą planszę. Albo trochę większy bonus za wyczyszczenie rządka, cokolwiek.
Dobrze byłoby móc to sobie szybko gdzieś podmienić tak, żeby zmiana parametru zajęła ci np. 5 sekund, a nie minutę. Wtedy miałbyś szybszy feedback i mógłbyś mocniej kombinować. Ideałem byłaby też możliwość zmiany parametrów na żywo, bez konieczności odpalania od nowa gry.
Ew. jak masz możliwość szybkiej zmiany logiki w języku programowania (bo np. używasz języka skryptowego i możesz zrobić w nim live-reload), to też to może posłużyć do zrobienia szybkiego feedback loop.
1
Można znaleźć bardzo wiele w google na ten temat, np https://www.reddit.com/r/gamedev/comments/jm6lv9/how_do_you_balance_difficulty_for_your_game/
Natomiast logika i obserwacja innych gier podpowiada że nie da się tego zrobić inaczej niż testami manualnymi, zwłaszcza że większość gier idzie na łatwiznę i po prostu zwiększa ilość przeciwników, długość fali czy ilość razy którą trzeba zaatakować przeciwnika. W większości przypadków faktycznie zwiększa to trudność, ale gra robi się też bardziej monotonna, irytująca i nudna. Najgorszy przykład moim zdaniem to Dead Island gdzie postać levelowała i pojawiały się zombie zbliżone levelem do levela gracza, nagle pojawiają się przeciwnicy którzy wygląda tak samo jak na samym początku gry i których można było zabić jednym uderzeniem, a teraz wymagają uderzenia 50 razy nawet mimo tego że nasza broń jest 10 razy potężniejsza. Totalnie beznadziejne i leniwe rozwiązanie.
Zawsze mnie to zastanawiało w grach zręcznościowych gdzie niektóre dalsze poziomy wymagają zręczności które wymagają dziesiątek godzin w grze. I choć developerzy niewątpliwie podczas produkcji spędzili dziesiątki jeśli nie setki godzin grając w swoją produkcję to po drodze robili różne tweaki i zmieniali mechanikę gry co wymagało uczenia się niemal od nowa. Skąd wiedzieć że poziom w ogóle jest realny do ukończenia przez większość graczy? Znaczy wiem że można w sumie zakodować przejścia "tool assisted" np w zwolnionym tempie i częstymi checkpointami i sprawdzić wymagany czas reakcji gracza i przyjąć że poziom jest realny do ukończenia jeśli np nie wymaga reakcji gracza w czasie mniejszym niż np 200ms, ale czy robią to w ten sposób?
Dla małej produkcji wydaje mi się że najlepiej po prostu wypuśćić grę, poczekać na feedback i wypuścić poprawki poprawiające game balancing.
Nawet większe produkcje tak robią, przykładowo mapy w counter strike'u ciągle są zmieniane aktualizacjami tak żeby zrównoważyć rozgrywkę - jakieś przejścia są blokowane lub przesuwane, czasem przesuną lub zmienią rozmiar na przykład skrzyń żeby umożliwić lub uniemożliwić jakiś skok lub rzucenie smoke'a. Nawet na tym forum można zobaczyć że najlepiej się testuje na produkcji ;)
Dobrze byłoby móc to sobie szybko gdzieś podmienić tak, żeby zmiana parametru zajęła ci np. 5 sekund, a nie minutę. Wtedy miałbyś szybszy feedback i mógłbyś mocniej kombinować. Ideałem byłaby też możliwość zmiany parametrów na żywo, bez konieczności odpalania od nowa gry.
Idealnie by było mieć to przeniesione do skryptów, które można zmodyfikować i zapisać zmiany, a silnik wykryje zmianę zawartości pliku i ten skrypt przeładuje. Czyli możesz odpalić silnik i testować co chcesz, a kiedy trzeba coś skalibrować, to wystarczy edytować plik i po zapisie zmiany automatycznie są widoczne w oknie gry. Praca stanie się niezwykle wydajna.
To wcale nie muszą być tekstowe skrypty — wystarczy, że będzie to po prostu plik, którego modyfikacji silnik będzie nasłuchiwał (wykrywał zmianę zawartości lub po prostu datę ostatniej modyfikacji). Tak działał np. stary dobry Re-Volt — można było grę zminimalizować, zmienić model/teksturę, zapisać zmiany, przywrócić okno gry i nowa zawartość była od razu dostępna. Korzystałem z tego podczas modowania modeli — parametry modelu były w pliku tekstowym (w formacie INI), natomiast tekstury w plikach bitmap.
System operacyjny (np. Windows) pozwala obserwować plik czy nawet cały katalog i wysyłać notyfikacje do aplikacji, że plik został zmodyfikowany lub usunięty, albo nowy plik został dodany do obserwowanego katalogu. Coś takiego bardziej pasuje do aplikacji testowanych na PC, bo można mieć wiele okien otwartych i wygodnie obsługiwać wszystkie.
1
Słyszałeś o czymś takim jak A/B testy i model Lean?
Poeksperymentuj z różnymi podejściami, zbieraj staty z apki i analizuj dane.
To jedyna droga żeby ustalić co ludziom odpowiada, a może być tak że 7 latkom odpowiada coś innego niż znudzonym 20 letnim studentom na wykładzie.
Jak ułożyć wzrastający poziom trudności w grze, tak aby gra nie była ani za łatwa ani za trudna?
Chodzi mi o to, żeby poziom trudności był tak zbalansowany, żeby gracz chciał grać dalej i nie zniechęcał się zbyt szybko.
Zdradzę ci sekretny algorytm który jest powszechnie stosowany i działa na 99% casualowych homo-sapiens:
To mi przypomina sposób, który polega na niekończącym się wzroście poziomu trudności (brak górnej granicy), tak aby nikt nie był w stanie grać bez końca. Im lepszy gracz, tym dłużej będzie w stanie wytrzymać, ale prędzej czy później poziom trudności okaże się nie do ogarnięcia i trzeba będzie go obniżyć. Przeciwieństwem jest ustalenie górnej granicy, tak aby poziom trudności wzrastał i ostatecznie zatrzymywał się na takim poziomie, aby tylko najlepsi byli w stanie na nim grać, bez końca.
Cóż, wszystko zależy od gry i tego na czym gameplay polega.
Przeciwieństwem jest ustalenie górnej granicy, tak aby poziom trudności wzrastał i ostatecznie zatrzymywał się na takim poziomie, aby tylko najlepsi byli w stanie na nim grać, bez końca.
To się nazywa system ligowy ale tam nie wyznaczasz górnej granicy tylko dolną.
1
Jeśli to gra logiczna, to(być może) można oszacowac złożność obliczeniową problemów w notacji duzego O. Drugim trikiem jest zebranie listy parametów ktore sprawiają ze gra tak naprawde jest trudna. Presja czasy, limit ruchów, tolerancja błedów, ilośc podproblemów które trzeba rozwiązać na raz, brak cofania, losowość, ilość podpowiedzi/
Mając takie parametry możesz modelować, gre i levele, Np. Teraz zwiekszamy presje czasu, teraz, trudność zadań itp. itd. Dodatkowo mozesz robić levele bonusowe/specjalne, gdzie np. zamiast limitu ruchów bedzie limit czasu lub w drugą strone. Level bardzo trudne, uzyskać np. zbijajac toleracje błedów, dajac presje czasu pod limit, lub wymuszajac jedna iteracje problemu głębiej, lub mikro optymalizując jeden paramtr, np. dajesz średnio trudny level, ale żeby przejść gre, nie można stracić bonusu który dostajesz na poczatku, i normalnie jest nice to have.
Jeśli chcesz mieć auto dostosowywalny system. Możesz zrobić podobnie, np. liczysz średnią punktów kroczona z ostanich gier/prób, jeśli jest wysoka, utrudniasz rozgrywkę, np. zmieniając limit czasu, potrzebny czas reakcji itp. Jezli słabo robisz w drugą strone. O ile takie pomysł jest uniwersalny, to średnia kroczaca nie.
Ona szybko się wykrzacza, np. gdy gracz testuje nowe strategie, lub śrubuje rekordy. Troche można to zminiamalizowac mając więcej niz 1 punktacje , całkowita, per level, per sesja, kroczona ostatnie x-gier. I wyciągać z nich meta średnia.
Jeszcze innaczej można rozwinać ten system zebrać dane od użytkowników/testerów i używać tego jako punkt wyjścia.
0
Dziękuję bardzo wszystkim za odpowiedzi. Daliście mi dużo do myślenia i naprowadzili na kilka pomysłów, nad którymi muszę się zastanowić.
Jeśli to gra logiczna, to(być może) można oszacowac złożność obliczeniową problemów w notacji duzego O. Drugim trikiem jest zebranie listy parametów ktore sprawiają ze gra tak naprawde jest trudna. Presja czasy, limit ruchów, tolerancja błedów, ilośc podproblemów które trzeba rozwiązać na raz, brak cofania, losowość, ilość podpowiedzi/
Mając takie parametry możesz modelować, gre i levele, Np. Teraz zwiekszamy presje czasu, teraz, trudność zadań itp. itd. Dodatkowo mozesz robić levele bonusowe/specjalne, gdzie np. zamiast limitu ruchów bedzie limit czasu lub w drugą strone. Level bardzo trudne, uzyskać np. zbijajac toleracje błedów, dajac presje czasu pod limit, lub wymuszajac jedna iteracje problemu głębiej, lub mikro optymalizując jeden paramtr, np. dajesz średnio trudny level, ale żeby przejść gre, nie można stracić bonusu który dostajesz na poczatku, i normalnie jest nice to have.
Jeśli chcesz mieć auto dostosowywalny system. Możesz zrobić podobnie, np. liczysz średnią punktów kroczona z ostanich gier/prób, jeśli jest wysoka, utrudniasz rozgrywkę, np. zmieniając limit czasu, potrzebny czas reakcji itp. Jezli słabo robisz w drugą strone. O ile takie pomysł jest uniwersalny, to średnia kroczaca nie.
Ona szybko się wykrzacza, np. gdy gracz testuje nowe strategie, lub śrubuje rekordy. Troche można to zminiamalizowac mając więcej niz 1 punktacje , całkowita, per level, per sesja, kroczona ostatnie x-gier. I wyciągać z nich meta średnia.
Jeszcze innaczej można rozwinać ten system zebrać dane od użytkowników/testerów i używać tego jako punkt wyjścia.
Tak myślę o czymś takim, tylko to będzie dosyć czasochłonne, ale chyba nie ma wyjśćia. Dzięki.
0
Tak myślę o czymś takim, tylko to będzie dosyć czasochłonne, ale chyba nie ma wyjśćia. Dzięki.
Czemu będzie czasochłonne? Bardziej bym się bał że zrobione zbyt mechanicznie, doprowadzi do nudnej pewnej formy przewidywalności rozgrywki, lub nie mozliwie trudnych zadaniach.
1 użytkowników online, w tym zalogowanych: 0, gości: 1
