Zaloguj się, aby móc dodać artykuł

Kategorie artykułów
Logowanie


Zapamietaj mnie
Facebook
22.07
22.07.2013 22:58 TKu
[PORADNIK] Mini poradnik: Jak stworzyć grę via WWW.
Tak więc idąc za prośbami z mojego poprzedniego tematu postanowiłem napisać coś mniejszego opisującego tylko najważniejsze zagadnienia z procesu tworzenia gry via WWW.

Rozdział 1: Koncepcja gry
Rozdział 2: Prezentacja wizualna :: pliki do rozdziału
Rozdział 3: Silnik MVC :: pliki do rozdziału
Rozdział 4: Projekt bazy danych :: pliki do rozdziału
Rozdział 5: Rejestracja i logowanie :: pliki do rozdziału
Rozdział 6: Karta Władcy
.
.
.
 
Komentarze
05.12.2015 20:42

Rafał Szostak
Bardzo fajny poradnik😊 Zaczełem naukę html PHP i CSS ponieważ bardzo mnie interesuje struktura tworzenia gier www. Po 3 latach zabawny nad Metin2 i nad edytowaniem jego kodu źródłowego zakończyłem projekt sprzedałem 2x (Kod źródłowy + Gotowe pliki + Client). Zarobiłem sporą sumę pięniędzy którą chcę przekazać na moją grę WWW.Z tego faktu mam łatwiej nauczyć się😊Ale poradnik bardzo pożądany pokazuje szczegółową organizację pracy i tworzenie kodu źródłowego 😊+++ Będzie kolejny poradnik jak stworzyć "fukcję walki" lub następna część poradnika
 
06.09.2015 17:28

Jouzef
Dla początkujących twórców może to być świetny poradnik, jednakże osoby trochę obeznane w temacie same sobie poradzą już ze wszystkim.
 
09.06.2015 09:45

daniel1302
Poradnik fajny, jednak pomylone jest pojęcie modelu i adaptera do obsługi bazy danych. Model powinien korzystać z adaptera który implementuje jeden interfejs, jednak nie powinien przejmowac jego roli. Wielu programistów to myli, ale w Javie w Spring Framework jest to super zrobione, encje w ORM oddzielone od modelu.
 
07.06.2015 12:33

writen
hehe. Może kiedyś, tak z ciekawości, postaram się to przeczytać.
 
06.06.2015 17:34

TKu
Trwało to bardzo długo ale napisałem kolejny rozdział poradnika.
Mama nadzieję, że jeszcze ktoś będzie miał ochotę zapoznać się z jego treścią
Tak jak zawsze proszę o ewentualne zgłaszanie literówek i wszelkich uwag.

Mam nadzieję, że na kolejny rozdział nie będziecie musieli czekać kolejnych 2 lat
 
18.03.2014 08:40

FrozenShade
Na polibudzie, na której ja studiowałem doktorzy, profesorowie itp mieli zupełnie inne podejście - o 180st. Oni bardzo chcieli swoją wiedzę przekazać, widać było że się do tego przykładali, magister od htmla i php miał nawet ambicje, żeby jego przedmiot był dla nas najważniejszy. Generalnie, im ktoś miał mniejszą wiedzę tym bardziej chciał ją przekazać
Byli to ludzie, którzy chyba całe swoje życie poświęcili uczelni - amatorzy z tytułami naukowymi. Trudno było by się czegoś od takich nauczyć, jeszcze trudniej żeby cię taki nakierował na właściwy tor. Reasumując - czy uczelnia dobra z fachową kadrą czy polibuda z pseudowykładowcami i tak musisz sam zapieprzać, różnica jest tylko taka, czy uczysz się tego co przewiduje materiał studiów, czy tego co ci jest faktycznie potrzebne.
 
18.03.2014 00:35

Zabusiaaa
Ja bylem na dniu otwartym mojego uniwerku i co jak co, ale na nauczycieli nie mam co narzekac, jeden pracowal nad zabezpieczeniami dla Barclays (taki bank ^^), jeden dla Apple, a poznej dla M$, ale moim zdaniem najlepszy nauczyciel pracowal w dawnym IBM i bedzie mnie uczyl OOP w C++. Porozmawialem troche z nimi, no i tak jak pisalem, wszyscy nauczyciele maja to w dupie jak sobie poradzisz, jak wiekszosc z nich mi wytlumaczyla to oni tylko przychodza na 2-3h wykladu (sama teoria), a ty dalej sam dzialasz, nie wazne czy rozmumiesz czy nie, to juz twoj wlasny biznes w tym, aby zrozumiec. Szczerze mowiac zgadzam sie z nimi. Jestem jeszcze z tej epoki kiedy nie bylo tutoriali, byla sama dokumentacja, male wprowadzenie do syntax i dalej metoda prob i bledow.
 
17.03.2014 12:17

Thoran
Froz zależy jak się trafi, też byłem na szkoleniu w tym towerze tylko, że z Active Directory. Źle nie było, komentarze innych osób też nie były jakieś mocno krytyczne. Studia są dobre o tyle, że uporządkują wiedzę na dany temat, pokażą czego się uczyć, bo wiadomo, że studiowanie to nie szkoła podstawowa czy liceum, trzeba samemu włożyć więcej wysiłku w drążenie tematu a nie czekać aż ci ktoś to wszystko wyłoży na wykładzie.
 
17.03.2014 12:05

FrozenShade
Do samoogarnięcia nie potrzeba studiów - przynajmniej mnie nie było potrzeba, bardziej mi te studia zawadzały (bo byłem, ale nie skończyłem), wymagali niepotrzebnych rzeczy, bo co mnie interere jakiś html, php czy css? Może to kwestia uczelni, miasta itp, ale poważnie, dziś z perspektywy czasu widzę jak mierny był poziom na tzw ćwiczeniach, jak mało przydatne były wykłady. Bardzo podobnie jest z kursami, które UE tak radośnie dotuje - jako zielony z javy zostałem wysłany przez firmę na 2 takie kursy, łącznie 10 dni. I to nie do jakiejś pipidówki tylko renomowanej firmy w Warszawie, Warsaw Trade Tower czy jakoś tak się budynek nazywał więc ja sobie cuda jakieś wyobrażałem... Tzw 'trener' szedł z materiałem chyba tą samą ścieżką co zawsze od lat, nie potrafił rozwinąć tematu wielowątkowości w servletach, na parę innych pytań też nie umiał odpowiedzieć. W firmie zapowiedziałem, że jeśli będą chcieli mnie wysłać na trzecie takie szkolenie to lepiej niech mi dadzą ekstra parę dni urlopu i kupią ze 2 książki to sobie w domu poczytam, efekt będzie dużo lepszy.
I znowu z perspektywy czasu, po 2 latach kodzenia w javie widzę, że tamten pan trener był najprawdopodobniej totalnym amatorem który w życiu żadnego działającego programu nie napisał a jego wiedza jest czysto teoretyczna. Myślicie, że na studiach jest inaczej?
 
17.03.2014 08:52

hobibit
Mam "wyższe wykształcenie chociaż studiów nie skończyłem".
Mi studia dały sporo, a konkretnie takiego ogólnego kopa. Uczyłem się wszystkiego po trochu (z informatyki). Przydatna rzecz moim zdaniem ale nie niezbędna.
Najwięcej nauczyłem się w pracy.

Jeśli chce jakiś temat liznąć i szybko coś zrobić to internetowe tutoriale są bardzo fajne do tego.
Jeśli chcesz jakiś temat poznać dobrze i dokładnie to książka.
 
16.03.2014 15:29

Zabusiaaa
Cytat Zamieszczone przez FrozenShade Zobacz posta
Informatyka w szkołach i na studiach to gówno. wiem, bo widze świeżaków, którzy przychodzą do firmy, w której pracuję. Owszem, mamy bardzo wysoką poprzeczkę, ale nawet traktując ludzi ulgowo po prostu sie nie da..... Gdybym ja miał np. pracować z takim nowym, zielonym , po studiach nad jakims projektem to bym sie chyba popłakał a zaraz potem zwolnił.

Moja rada: chcesz cos osiągnąć w informatyce to pracuj nad tym sam. czytaj książki, są dużo bardziej wartościowe niż stuff który znajdziesz na necie (z małymi wyjątkami).

Btw, dla poparcia moich słów: samouk, bez studiów, 10 lat w zawodzie
W liceum uczysz sie ogolnie, a na studiach masz konkretny kierunek. Roznica jest taka ze liceum jest latwiej bo nauczyciel czuwa nad Toba i 'kieruje' Cie na poprawna droge. Na studiach jest na odwort, wyklady to nic, jesli nie poswiecisz wlasnego czasu na nauke i samemu nie pouczysz sie to nic studia Ci nie pomoga. Na studiach jedyne za co placisz to czas wykladowcow, ktorzy beda sprawdzac Twoje prace i ich nie interesuje kim jestes, co chcesz osiagnac.

To zostalo napisane tylko do dopelnienia tej wypowiedzi, gdyz zgadzam sie z wypowiedzia w 100%. Od kilku lat obracam sie przy ludziach, ktorzy maja firmy i zarabiaja powyzej 1mln GBP i wiem, ze bardziej wola przyjac osobe, ktora nie byla na studiach, niz ta co je skonczyla. Powod jest prosty, skoro nie poszedles na studia zanczy, ze zodbyles to wiedze sam, interesujesz sie tym co robisz, poswiecasz wlasny czas aby sie samodoskonalic w tym co robisz i dlatego ich bardziej cenia. W dzisiejszych czasach studia to jest nic, kazdy moze na nie isc, wiec to nie jest wielki wyczyn jak kiedys. Sam ide w tym roku na studia, ale nie po to zeby sie czegos nauczyc i zdobyc 'zajebiste' oceny, bo mam to gdzies (moze nie do konca, bo place 9k GBP za rok kursu xD), moj cel jest inny, szukam ludzi do firmy.
 
16.03.2014 14:36

clarioo
Ja nie mówię, że nie będę czytał ksiązek tylko będę się uczył z tego co mam pod ręką. Jeżeli znacie jakieś książki to podajcie nazwy. Będę wdzięczny:-)
 
16.03.2014 14:26

jenkins
Ja bym bardziej proponował zastosowanie się do rady FrozenShade:
Moja rada: chcesz cos osiągnąć w informatyce to pracuj nad tym sam. czytaj książki, są dużo bardziej wartościowe niż stuff który znajdziesz na necie (z małymi wyjątkami).
 
16.03.2014 13:32

clarioo
Wlasnie dlatego uczę się z internetu, bo wiem, że w szkole naucze się tylko jak zrobic obrazek w ,,żółwiku'', bo tak nazywa moj nauczyciel logomocję:-) . Takze dziekuję za informację i mam nadzieję, że poradnik będzie dalej rozwijany, bo jest naprawde interesujący
 
16.03.2014 10:47

jenkins
Syn mojego kolegi, chodzi do liceum profilowanego - 'zarządzanie informacją', ma 6 lekcji z komputerem tygodniowo. Pytam go kiedyś co tam się uczycie na tych informatykach - nic siedzimy na facebooku czasem jak coś trzeba to przepisują książki kawałek do zeszytu i tyle. W szkołach faktycznie jest tragedia.
 
15.03.2014 23:33

FrozenShade
Informatyka w szkołach i na studiach to gówno. wiem, bo widze świeżaków, którzy przychodzą do firmy, w której pracuję. Owszem, mamy bardzo wysoką poprzeczkę, ale nawet traktując ludzi ulgowo po prostu sie nie da..... Gdybym ja miał np. pracować z takim nowym, zielonym , po studiach nad jakims projektem to bym sie chyba popłakał a zaraz potem zwolnił.

Moja rada: chcesz cos osiągnąć w informatyce to pracuj nad tym sam. czytaj książki, są dużo bardziej wartościowe niż stuff który znajdziesz na necie (z małymi wyjątkami).

Btw, dla poparcia moich słów: samouk, bez studiów, 10 lat w zawodzie
 
15.03.2014 18:00

clarioo
Dzięki temu poradnikowi nauczyłem się w ciągu 3 dni tyle, ile w szkole nauczyłbym się w rok. Chodzę do 3 klasy gimnazjum i o pisaniu stron wiedzialem tyle co nic. Dowiedziałem się jak korzystać z arkusza stylów, oraz co nieco o PHP. Dziękuję i czekam na kolejną część.
 
28.01.2014 13:43

TKu
Ogólnie to prace zostały zawieszone ze względów studiów ale, że jest przerwa semestralna to postaram się przygotować kolejny rozdział czy kilka rozdziałów.
 
28.01.2014 12:46

Janekk
Kiedy rozdział 5?
 
24.09.2013 19:57

TKu
Wgrałem poprawki do rozdziału 4.

Trochę to trwało ale nie samym forum człowiek żyje.
 
15.09.2013 19:11

TKu
Na dniach postaram się dodań kolejny rozdział oraz poprawię rozdział 4, bo robiłem na szybkiego i jest masa niedociągnięć.
 
04.09.2013 16:47

TKu
dzięki za wyłapanie błędów, poprawione i wgrane.
 
04.09.2013 14:55

Srebrny
znalazłem jeszcze kilka błędów w rozdziale 3. nie skończyłem jeszcze czytać

Oczywiście w przypadku kiedy gar jest w podkatalogu należy dopisać do RewriteBase ścieżkę do katalogu.
- co to jest gar?
...stworzymy pliki silnika zaczynając od pliku inicjującego czyli ini.php.
a potem jest
Kod 3.4.1 Plik init.php
Na koniec czyścimy tablice $_REQUEST, $_POST, $_GET aby bo nie będą przez nas używane ...
Następnie tworzona jest nazwa jest nazwa akcji, ...
niestety nic z tego nie rozumiem chociaż obejrzałem kilka kursów video o obiektowym php. oj ciężko mi idzie nauka tego :-/
 
02.09.2013 16:44

TKu
McFly - dzięki, staram się. Taki komentarze motywują do działania
 
02.09.2013 15:46

McFly
Jak miesiąc temu zobaczyłem ten poradnik, to pomyślałem że to kolejne pieprzenie o szopenie i w 80% zgadzałem się z wypowiedzią adamsky'ego. Dzisiaj zasiadając przed mym kompanem życiowym - komputerem, otwarłem serwis społecznościowy, którego nazwy nie muszę wymieniać i... i zobaczyłem "Widzieliście już kolejną część poradnika TKu?", pomyślałem iż zobaczę, co za pierdoły znów wypisuje ten TKu. Klikam, klikam i patrzę 4 części już są :O Policzę na palcach jednej ręki osoby, które napisały więcej niż 2 części "poradników tworzenia gier", dlatego byłem w ogromnym szoku. Otwarłem drugą części i? Pierdoły jak dostosować "dizajn", ehh nudy... Ale tu nagle, wyłania się na oczojebny (białym) tle, napis "Silnik MVC". What?! Uderzam paluchem w LPM'a i czytam. Czytam. No i czytam. Cholera, naprawdę warty uwagi poradnik o MVC. Przeczytałem już trochę tekstów na ten temat, także popracowałem w tych standardach co nieco i rzeczywiście poziom merytoryczny, jest na dobrym poziomie, dla osoby która zaczyna przygodę z MVC.
Good job TKu! Jeśli będzie więcej poradników, pisanych na takim poziomie i takim językiem, to masz po co pisać, bo przyjemnie się czytało

P.S.
Specjalnie przypominałem hasło do konta, żeby to napisać!
 
30.08.2013 21:14

TKu
Lepiej późno niż wcale wgrałem 4-ty rozdział.

P.S. Sorry za źle podpięty link do 4'ego rozdziału poprawione i można czytać i zgłaszać ewentualne literówki czy błędy, które przeoczyłem.
 
30.08.2013 16:06

TKu
Cytat Zamieszczone przez Srebrny Zobacz posta
rozumiem, że chodzi też o APP_HOST?
jasne jasne

DODAŁEM POPRAWKI DO DOKUMENTU
 
30.08.2013 15:05

Srebrny
Ważne aby stałe APP_PATH oraz APP_PATH wskazywały na adres katalogu głównego z grą.
...
Ważne jest aby zmodyfikować stałe APP_PATH oraz APP_PATH jeśli chcemy...
rozumiem, że chodzi też o APP_HOST?
 
26.08.2013 17:52

TKu
Jak tylko skleję kod to rozdziału 4 to dodaje.
 
10.08.2013 16:58

TKu
Dodałem 3'eci rozdział poradnika. Zapraszam do lektury i wyłapywania błędów lub też uwag, wszystko postaram się jak najszybciej poprawić, naprostować.
 
05.08.2013 14:28

TKu
Poszedłem za prośbą innych forumowiczów którzy stwierdzili że nie mam się bawić w podstawy tylko jechać z konkretami. Chciałem pisać od podstaw podstaw począwszy od HTML no ale jest jak jest. Kod HTML można w swoim zakresie edytować, nie jest to na sztywno zdeklarowane. Co do powtórki #menu_gorne to rzeczywiście jest pewnie pisałem już z automatu ale to nie ma znaczenia czy jest napisane tak:
Kod html:
#menu_gorne{
widht: ...;
height: ...;
.
.
.
}

#menu_gorne{
text-align: ....;
}
czy tak:
Kod html:
#menu_gorne{
widht: ...;
height: ...;
.
.
.
text-align: ....;
}
Co do section to racja nie ma ale to nie znaczy ze nie będzie, to jest tylko poglądowa wersja, section będzie dodane później podczas tworzenia widoków.
Jest to poradnik już dla trochę kumatych w temacie, jak pisałem we wstępie, zanim do niego przystąpisz to zapoznaj się z przynajmniej podstawami.
Oczywiście mogą się zdarzyć błędy ale sprawdzam kod zanim go wstawię do dokumentu i zapakuje w paczkę z gotowcem.
 
05.08.2013 13:22

Srebrny
chciałbym ale kod jest dość sporo chaotyczny. nie bardzo umiem się zorientować gdzie jest co do czego.
dlaczego div id="menu_gorne" nie jest nav?
div id="top" to chyba niezbyt udana nazwa całości strony.
dlaczego nie ma section?
style też, chaos. jest dwa razy #menu_gorne. nie można tego prościej i przejrzyściej napisać? ułatwiło by to naukę.

wiem, że się czepiam ale przy takim kodzie mi się ciężko uczy :-)
 
01.08.2013 23:18

TKu
W przygotowaniu jest kolejna część poradnika, powinna się ukazać w okolicach początku przyszłego tygodnia.

P.S. może się pochwalicie layout'ami jakie ułożyliście na podstawie 2'ego rozdziału?
 
30.07.2013 01:44

Karon94
Podoba mi się twoje podejście oraz zapał do tworzenia tego poradnika. Wiadomo dla osoby tworzącej już gry i mającej doświadczenie w tym treść zawarta w poradniku jest oczywista, lecz dla początkującego w sam raz. Plus dla ciebie, że nie zacząłeś od pisania kodu(PHP/SQL).

Jeśli mogę coś podpowiedzieć, to w HTMLu/CSS w przypadku kiedy powtarzając się znaczniki z intentyfikatorem (id="") zamień na class="". Lepiej kod wygląda, a poza tym z reguły id oznacza się tylko znaczniki nie powtarzające się. Zresztą wyjedzie to przy walidacji błędów W3.
 
29.07.2013 20:47

TKu
Na razie stawiam to tutaj, a jak uzyskam w jakikolwiek możliwość dodania tego do głównego wątku to wstawię.

Rozdział 2: Prezentacja wizualna :: pliki do rozdziału
 
24.07.2013 15:13

TKu
Poprawiłem temat rozdziału i mam nadzieję, że nie będzie wam przeszkadzał.

Ponadto to jest tylko przykład mający pokazać jak zakodzić grę a nie jak siedzieć miesiącami czy ataami nad rozmyślaniem wzorów i tworzeniem super wciągającej fabuły. Tym zajmie się już sam czytelnik. Ponadto jeśli napisze grę na tym poradniku to będzie posiadał możliwość jej rozbudowania czy też ZBALANSOWANIA ROZGRYWKI czy WYMYŚLANIA WZORÓW i WYKRESÓW. Nawet jeśli szarpnął bym się na opisanie wzorów czy wykresów to i tak mało kto by je ogarnął bo trzeba by było od podstaw tłumaczyć czemu tak, czemu to, i co to znaczy.

To że napomnieliście o tych faktach ma zmusić czytelników to zgłębienia tej tematyki jeśli chcą stworzyć coś naprawdę ŁAŁ!!!
 
24.07.2013 15:00

FrozenShade
Aha... czyli teraz dodatkowo wiesz lepiej jak przebiegały prace nad MH i co było potrzebne a co nie.
Nie wiem, opieram się na tym co napisałeś, z tego wyciągam wnioski.


Kończymy, mnie to już dawno temu znudziło.
 
24.07.2013 14:47

adamsky
Adamsky projektował (no, chyba, że ja przeceniam słowo 'projektować') jednostki i broń w momencie, gdy nie był jeszcze gotowy kod. Wykonał niepotrzebną, zbędną pracę.
Aha... czyli teraz dodatkowo wiesz lepiej jak przebiegały prace nad MH i co było potrzebne a co nie.

Dobra, to mój ostatni post w tym temacie bo już mi się to znudziło. Poza tym zmierza to w jakimś dziwnym kierunku...


Oczywiście wiele razy parametry broni były zmieniane, ale akurat w MH było to nie do uniknięcia ze względu na system gry. Jest 9 korpusów Mechów, ponad 40 typów wyposażenia które można na te Mechy zakładać i wiele schematów zachowania jednostek (trzyma się na dystans, idzie do przodu, ucieka jak zrobi się gorąco lub nie, koncentruje ogień na określonych jednostkach przeciwnika - masa możliwości). W efekcie zamiast 8 czy 12 predefiniowanych jednostek mamy bardzo dużą ilość możliwych konfiguracji, daleko wykraczającą poza to co można spotkać w typowych browserówkach. To oczywiście nie znaczy że te moje metody są użyteczne tylko przy tak złożonych systemach - wielokrotnie stosowałem je przy standardowych grach do rozpracowywania różnic między jednostkami, ich opłacalności, itp. Na różnym stopniu złożoności gry można sobie pomagać w ten sposób.

Nie mogę się zgodzić z tym że parametry wrzucone na pałę są równie dobre (czy raczej równie złe) jak wcześniej przeliczone. Balansowanie gry zazwyczaj odbywa się w kilku krokach, bo pierwsza czy druga poprawka niekoniecznie załatwia sprawę. Jeśli na starcie mamy wartości obiegające od prawidłowych o 20%, to dojdziemy do prawidłowych szybciej, niż startując od systemu rozregulowanego o 50%. Ponieważ szlifowanie tego na testach to są często miesiące pracy i wymaga to angażowania sporej liczby osób, to moim zdaniem zredukowanie tego nawet o jedną korektę to już jest spory zysk.

Nawet jeśli na starcie nie otrzymamy lepszych parametrów niż te wrzucone na pałę (z dowolnego powodu - na przykład przez błędne założenia czy brak doświadczenia) to wciąż pozostaje nam coś co pomaga w analizie wyników testów. Informacja od testerów też musi być analizowana. Po pierwsze gracze nie mówią jednym głosem: jeden będzie chciał zmniejszyć o 50%, drugi o 20%, trzeci będzie chciał zwiększyć a czwarty powie że jest ok i żeby nie ruszać. Po drugie istotna jest sieć relacji pomiędzy jednostkami - bardzo często zmieniając parametry jednej trzeba przy okazji dostroić dwie kolejne. Zgadzam się też z Dirkamem, że wrzucanie nowego contentu było znacznie prostsze jeśli były opracowane jakieś ramy i przeliczniki. Nawet jeśli nie wszystko od początku było dostrojone perfekcyjnie, to udawało się uniknąć mocno przestrzelonych wartości.


Na koniec jeszcze chcę zapewnić że nie jestem ani złośliwy ani upośledzony. Nie piszę tego żeby wam namieszać w głowie tylko być może pomóc komuś kto stanie przed zadaniem zaprojektowania i zabalansowania gry strategicznej PvP. Mi takie przeliczanie wartości w Excelu pomogło.
 
24.07.2013 12:37

FrozenShade
Wzorem nie opiszesz proporcji między broniami, więc i tak musisz je przetestować w boju, bo może się okazać, że ta 'naj naj' broń to już lekka przesada i sposób na łatwy win.
W poradniku jest tabela 1.6.3 a w niej są współczynniki. I jestem pewien, że autor już ma w głowie wzór na obliczenie damage a pojawi się on np w następnym rozdziale. Natomiast dlaczego pałkarz ma 15 pkt życia a paladyn 120 to mniej więcej taki sam problem jak bronie adamskyego, gdzie jedna jest 2x lepsza od drugiej. Tu paladyn ma 8x wiecej życia niż pałkarz. Czemu? nie wiem. Da się wyliczyć za pomocą wzorów, czy jest to prawidłowe podejście? nie. Jest tabelka z przykładowymi wartościami? Jest. Czy te wartości mają sens? Mają taki sam sens jak każde inne przepisane z sufitu lub 'zaprojektowane'. I o to mi cały czas chodzi. Adamsky projektował (no, chyba, że ja przeceniam słowo 'projektować') jednostki i broń w momencie, gdy nie był jeszcze gotowy kod. Wykonał niepotrzebną, zbędną pracę. I tak potem pewnie zmieniali to dziesiątki razy, bo na etapie projektu po prostu nie można pewnych rzeczy przewidzieć. Gdyby było inaczej, to pewnie napisał by o tym tak samo jak o poprawnie zaprojektowanym wydobyciu.
 
24.07.2013 12:11

Drikam
Mając jakiś przybliżony wzór łatwiej jest porównywać, a jaki jest współczynnik to bez różnicy.

Na pewno mając jakiś wzór do porównywania jest łatwiej wprowadzać nowości.

A co, jeżeli nagle chcesz dodać 10 nowych broni? Robisz osobny serwer i 3 miesiące je testujesz 'na czuja' żeby dopiero potem wprowadzić? Trochę bez sensu. A jak mamy jakiś wzór to łatwiej jest nam porównać cokolwiek.
 
24.07.2013 12:04

adamsky
OK, robisz bronie jedna 2x lepsza od drugiej. WHY? dlaczego nie 3x lepsza? albo 10x lepsza? czemu by nie zrobić, że 10-ta broń jest 200x lepsza od pierwszej?
To nie jest istotne w chwili budowania tych wzorów. Istotne jest to, że dzięki nim mogę potem łatwo modyfikować współczynniki. Jeśli w trakcie testów wyjdzie mi że broń nie ma być 2 razy lepsza, tylko 1,5 razy lepsza i o 20% lżejsza, to mam narzędzie które pozwoli mi łatwo wyznaczyć nowe parametry które to spełnią.

Jeszcze raz podkreślam: matematyka nie ma zastąpić projektowania czy balansowania gry tylko ułatwić cały proces.

Doskonale rozumiem że ty nie musisz sobie pomagać. Raz że cały system masz znacznie prostszy. Dwa że nawet jeśli jakaś roślinka jest przebalansowana lub niedoblansowana to to niczego nie zmienia. Gracz nie decyduje co mu się opłaca sadzić, tylko odpowiada na zapotrzebowanie narzucane przez klientów i zadania.
W strategii jeśli jednostka jest przebalansowana to zdominuje armie, a jak będzie niedobalansowana to nikt nie będzie jej budował (poza nieświadomym noobami). Na balans składa się cała masa parametrów.


Nie oczekuj że zacznę się tu teraz produkować na temat bardziej zaawansowanej analizy takiego systemu, gdzie w grę wchodzi na przykład analiza różnych typów graczy (przez pryzmat prowadzenia przez nich rozgrywki). To jest temat gdzie rzeczywiście bez doświadczenia ciężko ruszyć i jest to coś co silnie zależy od konkretnych rozwiązań w mechanice gry. To nie są tematy na prosty tutorial uczący podstaw. Do prostego tutoriala można wrzucić tylko to co pisałem, czyli strzelenie wykresiku, przeliczenie czy kolejny poziom kopalni zwróci się po tygodniu czy raczej po miesiącu i tym podobne. Z grubsza to samo co zrobi średnio rozgarnięty gracz.
 
24.07.2013 10:50

FrozenShade
Ale ja doskonale rozumiem te cyferki, ich znaczenie, rozumiem wzór. jest to dla mnie JASNE.
Tego typu cyferki mogę wziąć z sufitu i będą one równie dobre co twoje, po wyliczeniach.

tu nie ma co się zastanawiać nad matematyką, sam mówiłeś, że robisz 10 broni kierując się jakimś tam wzorem. OK, robisz bronie jedna 2x lepsza od drugiej. WHY? dlaczego nie 3x lepsza? albo 10x lepsza? czemu by nie zrobić, że 10-ta broń jest 200x lepsza od pierwszej? Twoje wartości ze wzorów i moje wartości 'na pałę' mogą okazać się takie same, chodzi o to, jak potoczy się rozgrywka przy różnicach 2-krotnych lub 10-krotnych. Jak duża ma być przepaść pomiędzy low a top? Czym uzasadnisz wielkość tej przepaści? Ceną? Poziomem gracza? Jakimiś technologiami? Cenę prędzej czy później się zapłaci, poziom osiągnie a technologię rozwinie.
Czy w pvp koleś na 80lvl powinien składać 'na 1 hita' postać na 10 lvlu? Jeśli tak, to dlaczego? Jeśli nie to dlaczego? Potrafisz mi odpowiedzieć na to pytanie wyprowadzając jakiś wzór? Bo ja jestem w stanie odpowiedzieć dopiero po tym, jak zobaczę, jak gracze zaczną się bawić na przykładowych wartościach i co będą próbowali zrobić z takiej gry. I jak to wygląda w podobnych grach.

W mojej farmie im wyższy poziom roślinki tym teoretycznie więcej doświadczenia można zyskać na jej hodowli. z małymi wyjątkami oczywiście. Tabela roślinek to jedyna rzecz, która została wyliczona wstępnie na etapie projektu. Czemu tych wartości nie wziąłem z sufitu? Ależ wziąłem, z sufitu wziąłem końcowe wartości, to co się na nie składa (exp, czas wzrostu, cena, ilość plonów) otrzymałem po przeliczeniach (tak, stosuję WZÓR!! ). Tylko co mi daje ten wzór? Nic, i tak na samym początku testów roślinki zostały zmodyfikowane.
Czemu pomiędzy doświadczeniem z uprawy ziemniaków a doświadczeniem z uprawy kalafiorów jest tak mała różnica? A czemu u ciebie druga broń jest dwa razy silniejsza niż pierwsza?

Kiedyś ilości roślinek na danej pozycji zamówienia klienta była funkcją poziomu (ilosc = level * 3). I była to zależność równie dobra co lvl^2 lub Lvl^3 + 4Lvl^2 + 234123552. Czemu? bo tak samo sztuczna jak wszystkie inne, jej sens nie był poparty niczym, równie dobrze mógłbym używać jakiegoś Random(1000000), miał bym wyniki o takiej samej użyteczności, czyli żadnej.
Teraz jest inaczej. Czemu? Obserwowałem i analizowałem zachowanie graczy, ilości obsłużonych/odrzuconych klientów, szybkość bogacenia się gracza, jego zasoby magazynowe.
Kiedyś losowałem 6 pozycji na zamówienie z tych, które dostępne były na danym poziomie. Teraz, do poziomu 4 włącznie losowane są tylko te, które gracz może wyprodukować na pierwszym polu, ilość pozycji na zamówieniu jest uzależniona od poziomu, jest maksymalnie jeden produkt.

Czy mógł bym opracować takie wzory kiedyś? Może by się udało, a może nie. Jednak były by to wzory syntetyczne, wzięte z powietrza, z mojego 'wydaje mi się'. Gra ma być dostosowana do graczy, gracz gra mniej więcej tak jak mu się podoba i spodziewa się tego, że lepiej lub gorzej, ale sobie będzie radził. Jeśli poziom trudności będzie zbyt niski - gra będzie nudna. Jeśli zbyt wysoki - gra będzie denerwująca. Pewne wartości, jeśli mają być sensowne, da się opracować TYLKO obserwując i analizując rozgrywkę. Gdyby było inaczej, to mądrzejsi od ciebie czy ode mnie nie wprowadzali by regularnych zmian w grach dodając coś nowego, nerfując coś istniejącego lub np likwidując kompletnie dany typ jednostki/broni/czegokolwiek.

Mam nadzieję, że wreszcie ogarnąłeś.
 
24.07.2013 09:36

adamsky
Wciąż mam wątpliwości czy w ogóle wiesz o czym ja piszę. Załóżmy że masz dwie bronie.

Pierwsza ma parametry:
damage: 205
range: 95
reload speed: 3 (ilość tur na przeładowanie)
accuracy: 75.0 %
weight 80

Druga ma parametry:
damage: 48
range: 100
reload speed: 1
accuracy: 85.0 %
weight 36

Patrząc na sam zestaw liczb trudno określić jak się ma jedna do drugiej, ale jeśli zrobisz proste równanie:
atak * celność / ilość_tur_na_przeładowanie / waga
to dostaniesz prostą liczbę obrazującą uśrednioną siłę rażenia każdej broni. Analizując tą liczbę i zasięg strzału szybko określisz że druga broń jest około 2 razy silniejsza. Jak analizujesz nie 2 bronie tylko 10, to takie proste przeliczenie zaczyna być szalenie pomocne.

Nie trafia do mnie argument, że twórca gry tego nie ogranie, bo z takimi przeliczeniami doskonale radzą sobie nawet sami gracze. Nie minęło kilka miesięcy od startu naszej gry jak dostałem linki do googledocsów gdzie kluczowe elementy gracze rozpracowywali w ten sposób. Gdybym sam nie zrobił tego na początku, to byłbym kilka kroków za nimi.

Zresztą w twojej farmie też początkowo zacząłem się w to bawić. Bez problemu można wyliczyć, że nie funkcjonuje tu zasada że najefektywniej można expić na roślinach wymagających największej aktywności (co podpowiada zdrowy rozsądek). Jedyny powód dlaczego nie korzystam z tej wiedzy jest taki że jako gracz nie mam możliwości decydowania o tym co sadzę i zbieram, bo to mi narzuca sama gra.
 
24.07.2013 00:53

FrozenShade
Tak jak wspomniałeś, mamy kompletnie różne podejście do tego tematu, po prostu robimy co innego, mamy inne doświadczenie, inne gry piszemy.
Rozumiem twoje argumenty, ale czy mnie przekonują to zupełnie inna sprawa. Po prostu od lat pisałem tworząc najpierw 'obraz' wszystkiego z czym miałem mieć do czynienia, nie zagłębiając się jednak w parametry, szczegóły bo to przychodziło później. Sprawdziło się w systemie czasu rzeczywistego (od razu utworzona reprezentacja wszystkich urządzeń w sieci i jednocześnie kompletne olanie ich zachowania, aby były jako klasy w kodzie i w pierwszym rozdziale dokumentacji), sprawdziło się na farmie.
Czy się sprawdzi, jeśli kiedyś przyjdzie mi pisać strategię? Zobaczymy.

Z tej wymiany zdań autor tematu powinien teraz, dla dobra wszystkich swoich czytelników wyciągnąć odpowiednie wnioski i napisać jakiś dobry poradnik.

A ja przez to dzisiejsze pisanie na różnych forach spóźnię się z aktualizacją (zadania punktowane) ;p
 
24.07.2013 00:27

adamsky
Projektujesz grę, więc już na początku powinieneś mniej więcej wiedzieć jakie jednostki będą w niej występować, jakie będą mieć charakterystyki. To, czy potem się dorzuci lub wykasuje jakieś pojedyncze jednostki to tzw 'życie pokaże'. Charakterystyki wypełnione przykładowymi wartościami są też bardzo dobrym pomysłem - już coś jest, wiadomo, ze i tak się to jakoś dostosuje, ale jest pogląd - taka i taka jednostka ma być np 2x szybsza od innej.
Po ustaleniu listy parametrów i schematu algorytmów walki, uzupełniliśmy może z 30% i to parametrami kompletnie "na pałę". Programista miał na czym pracować i testować, a ja siedziałem z Excelem i projektowałem cały komplet (parametry, koszty, wymagania, opisy, itp.). Nic nie wybuchło przy takim trybie pracy.

W pewnych grach istnieje pojęcie 'zergu'. Nie zawsze 'mniej ale lepszych' jest podejściem preferowanym. J/w po zrobieniu przykładowych jednostek można zobaczyć indywidualne preferencje i strategie. Może ktoś woli puścić do walki zerg słabych jednostek niz mieć różnorodność. W takim razie jak przed takim zergiem obroni się przeciwnik, czym się będzie bronił, może trzeba będzie mu 'pomóc' dodajc do mocniejszych jednostek jakis dodatkowy skill.... Wzory wyprowadzane na początku raczej na to nie odpowiedzą a gracze chcą czasem grać tak jak na to mają ochotę a nie tak jak twórca przewidział.
Nie o tym piszę...
Jeśli masz powiedzmy 4 podstawowe parametry definiujące jednostkę, to możesz z tego zaprojektować 6-8 różnych jednostek, a możesz 20. Sporo graczy powie, że im więcej tym lepiej, bo wtedy jest różnorodność. W praktyce przy strategii PvP najczęściej lepiej zaprojektować 6-8 jednostek gdzie każda ma swój odmienny charakter, swoje mocne i słabe strony. Jak zrobisz 20 to zaczną "zlewać się ze sobą".

Oczywiście inaczej będzie przy PvE gdzie zainteresowanie gracza często rozbudza się ilością contentu.

Zobaczy wykresik. Ale czy zrozumie jego przekaz? mówimy tu o ludziach, którzy nic wcześniej nie pisali ani nie projektowali - gdyby bylo inaczej to nie potrzebowali by tego poradnika.
Dlatego trzeba to wytłumaczyć. Jak mu pokażesz sam kod to też nie zrozumie przekazu jeśli wcześniej nie programował - trzeba wyjaśnić.
Wszystko zależy czy tu powstaje poradnik robienia gier czy poradnik programowania. Zawsze powtarzam że tworzenie gier to coś co wykracza poza samo klepanie kodu.

Jak pisałem wyżej i w przykładzie z mojej własnej gry - wartości początkowe 'na czuja' nie są złe.
Mam dziwne wrażenie poziom złożoności tego typu problemów w prostej grze farmerskiej i w prostej strategii PvP to różnica o rząd wielkości.
Nie odbieraj tego jako umniejszanie twojej grze ani nic w tym stylu - po prostu klikając w nią nie widzę problemów które by się choćby zbliżały do zagadnień jakie się spotyka w strategiach.

Bardzo dobrym pomysłem, zwłaszcza przy pierwszym projekcie jest odnalezienie podobnej gry i przepisanie z niej pewnych początkowych wartości.
Pod warunkiem że sklonujesz też mechanikę.
Już lepiej wpisać wszędzie wartości na czuja niż nadmiernie inspirować się inną grą, bo czasem ciężko się od takiej inspiracji odkleić. To też już przerobiłem na własnej skórze. Do dziś w MH mamy niektóre mało istotne parametry identyczne jak w Travianie - zupełnie niezamierzone, ale trudno nie skojarzyć tego z faktem że i ja i programista sporo w Traviana graliśmy zaczynając własny projekt.

Żebyś się zakopał w całkach, wielomianach, wyprowadził setki wzorów i 'zbalansował' rozgrywkę to gracze i tak zrobią swoje, wynajdą coś, czego twoje wzory nie przewidzą. A potem jest nerfowanie (już takie 'na pałę') kolejnych postaci. Więc lepiej stworzyć podstawy na oko, dać to alpha testerom, obserwować rozgrywkę (lub samemu z kimś zagrać) i w trakcie takiej zabawy zacząć dostosowywać współczynniki.
kwestia doświadczenia, intuicji i znajomości gier
Cały czas chyba nie do końca rozumiesz co próbuję przekazać. Ja proponuję bardzo proste patenty które pozwalają oszczędzić czas. Nie ma tam żadnych całek tylko 4 podstawowe równania które odpowiednio zastosowane pozwalają widzieć więcej w systemie który często składa się z setek parametrów. To wciąż będzie przepuszczone przez testerów, ale feedback od ludzi to tylko początek drogi - normą jest że jeden będzie chciał tak, a drugi śmak. Rozpoczęcie testów w przypadku strategii PvP nie znaczy że nic już nie trzeba analizować bo wszystko samo się poukłada. Nie mówiąc już o tym, że danie testerom lepszego zestawu danych na początku przyspiesza cały proces.

No i ostatnia sprawa... to nie tylko kwestia doszlifowania czy Mroczny Krasnolud ma mieć atak 16 czy może 18. O tym niżej.
Pojęcie tworzenia i wyważania gry to temat na inną książkę.
Ale ile było takich rzeczy, które od razu działały tak jak chciałeś i planowałeś?
Parametr parametrowi nie równy.
Są w grze pewne parametry de facto definiują charakter rozgrywki. Na przykład czy gracz może mieć kilka miast czy 100 miast. Czy drzewko technologii jest krótkie czy trzeba je rozpracowywać przez 2 lata. Wykracza to trochę poza zwykłe balansowanie gry i spokojnie można to podciągnąć pod projektowanie gameplaya. Przykład do którego się tu podczepiłem w zasadzie podpada pod tego typu parametr, bo produkcja surowców jest jednym z kluczowych zagadnień w strategiach. Takie parametry warto dość uważnie projektować, bo zmiana wydobycia surowców nagle zaczyna wpływać praktycznie na każdy aspekt gry.

Określenie jaka jest opłacalność kopalń i oszacowanie na tej podstawie dopływu surowców na różnych poziomach rozwoju jest pomocne w ustalaniu kosztu budynków, badań czy jednostek.

Wszystkie parametry które uznałem za kluczowe kontrolowałem dość dokładnie i działały tak jak chciałem. Zmian było bardzo niewiele i zazwyczaj wynikały z tego, że po jakimś czasie chciałem inaczej.



EDIT:
adamsky a czemu Ty nie napiszesz żadnego poradnika? Ja tam bym chciał porównać Twoją wersję z tu przedstawioną.
Mam grę, pracę, żonę i piwo do uwarzenia. Na pisanie poradników nie mam już czasu.
 
23.07.2013 23:26

Atverstyt
adamsky a czemu Ty nie napiszesz żadnego poradnika? Ja tam bym chciał porównać Twoją wersję z tu przedstawioną.
 
23.07.2013 19:48

Drikam
Pojęcie tworzenia i wyważania gry to temat na inną książkę. Swoją drogą bardzo ciekawą.

Ale nadal trzymam się tego, że tu nie chodzi o tworzenie jakieś super gry i żeby autor stworzył tekstowego Warcrafta tylko o naukę programistyczną, więc nie ma co się czepiać. Taki długi wstęp, czekam[y] na konkrety.
 
23.07.2013 19:32

FrozenShade
O proszę... mógłbyś rozwinąć temat?....
Projektujesz grę, więc już na początku powinieneś mniej więcej wiedzieć jakie jednostki będą w niej występować, jakie będą mieć charakterystyki. To, czy potem się dorzuci lub wykasuje jakieś pojedyncze jednostki to tzw 'życie pokaże'. Charakterystyki wypełnione przykładowymi wartościami są też bardzo dobrym pomysłem - już coś jest, wiadomo, ze i tak się to jakoś dostosuje, ale jest pogląd - taka i taka jednostka ma być np 2x szybsza od innej.

Ale to że nie ma uniwersalnego systemu wcale nie skazuje nas na wrzucanie wartości "na pałę" albo "na czuja".
Jak pisałem wyżej i w przykładzie z mojej własnej gry - wartości początkowe 'na czuja' nie są złe. Żebyś się zakopał w całkach, wielomianach, wyprowadził setki wzorów i 'zbalansował' rozgrywkę to gracze i tak zrobią swoje, wynajdą coś, czego twoje wzory nie przewidzą. A potem jest nerfowanie (już takie 'na pałę') kolejnych postaci. Więc lepiej stworzyć podstawy na oko, dać to alpha testerom, obserwować rozgrywkę (lub samemu z kimś zagrać) i w trakcie takiej zabawy zacząć dostosowywać współczynniki.

Trzymając się tego przykładu z kosztem i wydobyciem kopalń, łatwej jest balansować jeśli poza suchym kosztem i suchym wydobyciem masz wyliczone wskaźniki pokazujące opłacalność budowy kolejnych poziomów.
Nie twierdzę, że podejście 'na pałę' jest jedynym słusznym. Ale myślę, że ocena tego, co warto wyliczyć już na początku a co można sobie wziąć z sufitu to kwestia doświadczenia, intuicji i znajomości gier. Bardzo dobrym pomysłem, zwłaszcza przy pierwszym projekcie jest odnalezienie podobnej gry i przepisanie z niej pewnych początkowych wartości. W tym wypadku nie zdziwił bym się, gdyby TKu włączył jakiegoś warcrafta i spisał z niego połowę rzeczy

Tu mi chodzi o trochę co innego. O takie sprawy jak to że każda jednostka powinna mieć jakiś słaby punkt. O to że lepiej mieć mniej jednostek ale różniących się od siebie, niż dużo takich które w zasadzie zlewają się ze sobą. To jest szerszy temat i zapewniam że nie każdy kto tylko grał dostrzega w czym rzecz.
W pewnych grach istnieje pojęcie 'zergu'. Nie zawsze 'mniej ale lepszych' jest podejściem preferowanym. J/w po zrobieniu przykładowych jednostek można zobaczyć indywidualne preferencje i strategie. Może ktoś woli puścić do walki zerg słabych jednostek niz mieć różnorodność. W takim razie jak przed takim zergiem obroni się przeciwnik, czym się będzie bronił, może trzeba będzie mu 'pomóc' dodajc do mocniejszych jednostek jakis dodatkowy skill.... Wzory wyprowadzane na początku raczej na to nie odpowiedzą a gracze chcą czasem grać tak jak na to mają ochotę a nie tak jak twórca przewidział.
Jeśli chodzi ci o sprawy wydajnościowe przy zergu to ja osobiście nigdy nie wątpię we własnego skilla.

Zakładam że ktoś kto ma sobie poradzić z napisaniem gry, poradzi sobie również ze zrobieniem tabelki i paru formuł w Excelu.
Rozumiem że może nie wiedzieć jak się ma przebieg funkcji wykładniczej do liniowej, ale jak mu strzelisz wykresik i pokażesz że się powoli rozpędza i potem szybko rośnie to powinien zrozumieć w czym rzecz.
Zobaczy wykresik. Ale czy zrozumie jego przekaz? mówimy tu o ludziach, którzy nic wcześniej nie pisali ani nie projektowali - gdyby bylo inaczej to nie potrzebowali by tego poradnika. Imho (mogę się oczywiście mylić) bardziej trafi do takiego zwykle zobrazowanie:
mobek 1 - sila 10 pancerz 5
mobek 2 - sila 20 pancerz 10
mobek 3 - sila 15 pancerz 15
niż parabole i linie proste.
Wykresami można ich będzie pomęczyć później, nawet w praktyce, w postaci ćwiczenia dając dwa zestawy charakterystyk dla postaci w grze, jeden liniowy a drugi z bardziej złożonymi zależnościami i niech sobie sami sprawdzą rozgrywając partyjkę z kolegą. Na wszystko przyjdzie czas.

Baj de łej... Bez żadnego doświadczenia poustawiałem system w którym wydobycie rośnie jak funkcja kwadratowa, a koszt kopalni wykładniczo i do dziś działa to tak jak zaplanowałem parę lat temu, więc mi nie wmawiaj się nie da.
Coś wcześniej pisałem na temat intuicji i znajomości gier. Ale ile było takich rzeczy, które od razu działały tak jak chciałeś i planowałeś?

No ok, tylko nie piszmy tam że to poradnik jak projektować tylko że to gotowy uproszczony projekt na którym będziemy pracowali.
Jak dojdzie do nauki PHP to zakładam nie będzie wyłącznie wklejonego kodu, tylko wytłumaczone co jak napisać i dlaczego.
Nie wiem w jaka stronę pójdzie ten poradnik, mam nadzieje ze nasze tu gadanie pomoże autorowi tematu w przystępnym zaplanowaniu kolejnych części. To jeden z powodów, dla których się tutaj produkuję


Problem bierze się zapewne stąd, że wy jesteście głównie informatykami i dla was to są tylko jakieś wzory i jakieś współczynniki. Moja rola w projekcie jest natomiast taka żeby te wzory i współczynniki nie były jakieś, tylko żeby były sensowne. Ot, takie skrzywienie.
Nie wiem jak autor tematu, ale ja już dawno się przyzwyczaiłem do takiego 'projektowania na oko' bo albo się okaże, że klient chce jednak trochę inaczej, albo kierownik będzie miał jakiś genialny pomysł. Na zasadzie 'ja swoje, życie swoje'
 
23.07.2013 18:12

adamsky
Najważniejsze, żeby takie tabelki się pojawiły w formie projektu przed napisaniem pierwszych linii kodu, żeby potem ad hoc nie wymyślać 'eeee....to teraz zróbmy jeszcze takiego ludzika'.
O proszę... mógłbyś rozwinąć temat? Większość contentu w naszej grze powstała już po napisaniu części kodu. Początkowo wrzuciliśmy cokolwiek żeby było na czym testować. Potem programista jechał z kodem a ja równolegle projektowałem docelowy zestaw jednostek i borni. Czemu to podejście było złe?

Nie ma i nie będzie uniwersalnego opisu 'jak stworzyć system i mechanikę gry oraz wszystkie współczynniki'.
Oczywiście że nie ma. Ale to że nie ma uniwersalnego systemu wcale nie skazuje nas na wrzucanie wartości "na pałę" albo "na czuja". Ja tylko próbuję wskazać pewne rozwiązania matematyczne które pomagają w doborze współczynników. Zwłaszcza że te same narzędzia mogą potem pomóc w szlifowaniu tych współczynników w trakcie testów.

Trzymając się tego przykładu z kosztem i wydobyciem kopalń, łatwej jest balansować jeśli poza suchym kosztem i suchym wydobyciem masz wyliczone wskaźniki pokazujące opłacalność budowy kolejnych poziomów. To daje lepszy wgląd w to jak zmiana danej wartości przełoży się na grę.

Jak takie współczynniki są zbudowane i jaką odgrywają to widać w wielu grach, przecież za pisanie gier nie bierze się osoba, która w życiu nie grała.
Tu mi chodzi o trochę co innego. O takie sprawy jak to że każda jednostka powinna mieć jakiś słaby punkt. O to że lepiej mieć mniej jednostek ale różniących się od siebie, niż dużo takich które w zasadzie zlewają się ze sobą. To jest szerszy temat i zapewniam że nie każdy kto tylko grał dostrzega w czym rzecz.

To co opisujesz, funkcje itp, jest chyba zbyt hardkorowym zagadnieniem dla przeciętnego gimnazjalisty (docelowego odbiorcy takich poradników).
Zakładam że ktoś kto ma sobie poradzić z napisaniem gry, poradzi sobie również ze zrobieniem tabelki i paru formuł w Excelu.
Rozumiem że może nie wiedzieć jak się ma przebieg funkcji wykładniczej do liniowej, ale jak mu strzelisz wykresik i pokażesz że się powoli rozpędza i potem szybko rośnie to powinien zrozumieć w czym rzecz.

Poza tym i tak, w większości przypadków teoria != praktyka. Bez doświadczenia zaprojektować można tylko 'na oko' jakiś wzór liniowy i z radością go używać. A potem przyjdą beta testy, testerzy zaczną grać i nadejdzie moment na ponowną weryfikację wzorów. Jestem pewien, że przechodziłeś przez coś takiego w swojej grze.
Kurcze... Nie piszę tego wszystkiego bo mi się nudzi, tylko dlatego że w ciągu tych kilku lat nauczyłem się że to bardzo pomaga w pracy. Gdyby mi ktoś na początku drogi podrzucił pomysły na to jak sobie pomóc, to bym zaoszczędził sporo czasu i pracy.

Baj de łej... Bez żadnego doświadczenia poustawiałem system w którym wydobycie rośnie jak funkcja kwadratowa, a koszt kopalni wykładniczo i do dziś działa to tak jak zaplanowałem parę lat temu, więc mi nie wmawiaj się nie da.

Myślę, że celem tego kursu jest raczej przeprowadzenie kompletnie zielonego 'entuzjasty' przez skrócony proces tworzenia gry, opisanie najważniejszych kroków i zwrócenie jego uwagi na pewne wybrane zagadnienia.
No ok, tylko nie piszmy tam że to poradnik jak projektować tylko że to gotowy uproszczony projekt na którym będziemy pracowali.
Jak dojdzie do nauki PHP to zakładam nie będzie wyłącznie wklejonego kodu, tylko wytłumaczone co jak napisać i dlaczego.



Problem bierze się zapewne stąd, że wy jesteście głównie informatykami i dla was to są tylko jakieś wzory i jakieś współczynniki. Moja rola w projekcie jest natomiast taka żeby te wzory i współczynniki nie były jakieś, tylko żeby były sensowne. Ot, takie skrzywienie.
 
23.07.2013 15:16

adamsky
No wiesz kolego adamsky od podstawo to ja chciałem opisywać w pierwotnej wersji poradnika, no ale stwierdziliście, że nie ma sensu tak więc założyłem bardzo prościutki scenariusz no bo jak ktoś chce się dowiedzieć więcej na ten temat to niech sobie doczyta w necie. Jakbym miał opisywać to zjawisko szczegółowo to nie wiem czy do końca wakacji zdarzyłbym napisać chociaż 10% tego co planuje.
Właśnie dlatego proponowałem odpuszczenie tych zagadnień które są już przerobione na necie 1000 razy - same tematy charakterystyczne dla gier to już jest bardzo obszerny materiał.

ja stworzyłem tylko przykładowy prosty przykład w wyniku którego każdy napisze prostą grę co ma zachęcić czytelników do dalszego zgłębiania wiedzy bo jak wiadomo w tym poradniku nie opiszę wszystkich zagadnień związanych z projektowaniem czy tworzeniem gry bo nie ma na to czasu
To co napisałeś można potraktować jako założenia do gry którą będziesz pisał w trakcie tutoriala, ale nie jako poradnik jak projektować grę. To co tam jest czyli parametry, koszty i jakieś wzory widzi każdy kto się zarejestruje żeby pograć w dowolną grę tego typu. Jak nie masz czasu / chęci / wiedzy (niepotrzebne skreślić) żeby opisać proces projektowania to zmień tytuł na "Założenia naszej gry" albo coś w tym stylu. Można to potraktować jako wprowadzenie kursanta w to co będzie robione w dalszej części poradnika.

No i od razu proponuję ograniczyć rozmach. 3 surowce zamiast 6 i 5 jednostek zamiast 11 wystarczy żeby wszystko pokazać. Zwłaszcza że temat mnożenia liczby surowców i jednostek też by pasowało ubrać w osobny rozdział, bo niekoniecznie więcej znaczy lepiej.

Jeśli posiadasz takową wiedzę to rozszerz mój poradnik opisz dokładnie co i jak tworzyć
Na dopisywanie rozdziałów zwyczajnie nie mam czasu - nawet tutaj nie powinienem teraz pisać, bo powinienem siedzieć nad własną grą.
Jak kiedyś zamkniemy albo sprzedamy MH to pomyślę nad spisaniem tego czego się przy tym projekcie nauczyłem.
 
23.07.2013 14:58

Drikam
Można by mówić o różnych wzorach, sposobach, testach, tutaj jest po prostu rzucony jakiś banalny projekt.

Wiadomo, że ta gra, gdyby była realnym projektem ot byłaby kompletnym niewypałem. Po pierwsze jest zbyt symetryczna. Ale tutaj chodzi o naukę tworzenia gier a nie jak robić dobre gry. To jednak jest coś innego. Jeżeli kogoś interesuje grywalizacja (nie jest to jakaś najlepsza nazwa) to niech o niej poczyta.

Ogólnie ciężko jest napisać coś, co zadowoli wszystkich. ; d
 
23.07.2013 14:05

FrozenShade
Żeby zbudować taką tabelkę to już trzeba trochę myśleć. Nie ma i nie będzie uniwersalnego opisu 'jak stworzyć system i mechanikę gry oraz wszystkie współczynniki'. Najważniejsze, żeby takie tabelki się pojawiły w formie projektu przed napisaniem pierwszych linii kodu, żeby potem ad hoc nie wymyślać 'eeee....to teraz zróbmy jeszcze takiego ludzika'. Jak takie współczynniki są zbudowane i jaką odgrywają to widać w wielu grach, przecież za pisanie gier nie bierze się osoba, która w życiu nie grała. A jak ktoś chce wiedzieć więcej to co najwyżej można mu poradzić zapoznanie się z jednym lub dwoma 'papierowymi' systemami rpg (i w sumie coś takiego powinno się znaleźć w tym pdf-ie).

To co opisujesz, funkcje itp, jest chyba zbyt hardkorowym zagadnieniem dla przeciętnego gimnazjalisty (docelowego odbiorcy takich poradników). Poza tym i tak, w większości przypadków teoria != praktyka. Bez doświadczenia zaprojektować można tylko 'na oko' jakiś wzór liniowy i z radością go używać. A potem przyjdą beta testy, testerzy zaczną grać i nadejdzie moment na ponowną weryfikację wzorów. Jestem pewien, że przechodziłeś przez coś takiego w swojej grze. Ja to miałem u siebie dwa-trzy miesiące temu. Pierwotna wersja wzoru na ilości roślin w zamówieniu klienta była funkcją liniową, ilość = f(level). Proste, napisane bez większego zastanowienia, otoczone wykomentowanymi wykrzyknikami i słowami TODO Już po tygodniu testów funkcja ewoluowała, aktualnie, po trzech miesiącach ilość jest zależna od kilkunastu czynników. Po prostu pewne rzeczy lepiej sprawdzić w boju.

Identycznie będzie pewnie w tym projekcie, taki proces na pewno powinien zostać opisany w jednej z części poradnika.

Jeśli chcieć opisać to wszystko o czym wspominasz to zamiast prostego poradnika powstała by książka. Myślę, że celem tego kursu jest raczej przeprowadzenie kompletnie zielonego 'entuzjasty' przez skrócony proces tworzenia gry, opisanie najważniejszych kroków i zwrócenie jego uwagi na pewne wybrane zagadnienia. Potem taki ktoś może zacząć grzebać się na własną rękę w takim kodzie, rozwijać projekt lub spróbować powtórzyć wszystkie kroki z czymś nowym, własnym. Możesz ludziom wytłumaczyć pewne rzeczy, pokazać pewne procesy, ale nigdy nie nauczysz ich myśleć. To powinni umieć sami, zwłaszcza przy tak barwnym zagadnieniu jak pisanie gier.

Pozdrawiam.
 
23.07.2013 13:42

TKu
Ok, zacznę może od tego że jeśli to co zaraz napiszę uważacie za bezsensowny hejting to dajcie znać. Przestanę czytać te wątki poradnikowe i nie będę więcej przeszkadzał.
Osobiście nie odbieram tego jako hejting ale uzupełnienie.

No wiesz kolego adamsky od podstawo to ja chciałem opisywać w pierwotnej wersji poradnika, no ale stwierdziliście, że nie ma sensu tak więc założyłem bardzo prościutki scenariusz no bo jak ktoś chce się dowiedzieć więcej na ten temat to niech sobie doczyta w necie. Jakbym miał opisywać to zjawisko szczegółowo to nie wiem czy do końca wakacji zdarzyłbym napisać chociaż 10% tego co planuje.

Jeśli posiadasz takową wiedzę to rozszerz mój poradnik opisz dokładnie co i jak tworzyć, ja stworzyłem tylko przykładowy prosty przykład w wyniku którego każdy napisze prostą grę co ma zachęcić czytelników do dalszego zgłębiania wiedzy bo jak wiadomo w tym poradniku nie opiszę wszystkich zagadnień związanych z projektowaniem czy tworzeniem gry bo nie ma na to czasu.
 
23.07.2013 13:25

adamsky
Ok, zacznę może od tego że jeśli to co zaraz napiszę uważacie za bezsensowny hejting to dajcie znać. Przestanę czytać te wątki poradnikowe i nie będę więcej przeszkadzał.


To nie jest poradnik projektowania ani "opis procesu projektowania gry" (jak piszesz we wstępie). To jest jakiś uproszczony opis gry, ale nie ma tam praktycznie nic o tym jak coś takiego budować na własną rękę. Zamiast wkleić tabelkę z gotowymi parametrami jednostek jak bym tam raczej widział opis tego jak taką tabelkę tworzyć. Jaką logiką się kierować projektując jednostki i jaką matematyką się wspierać dobierając im wstępne parametry (wiadomo że to jest potem szlifowane na etapie testów).

Weźmy na przykład te wzory na koszt i produkcję kopalń. Podałeś dwa wzory liniowe i tylko napisałeś że każdy może sobie wymyślić własny. No kurde... przecież w projektowaniu takich elementów nie chodzi o wymyślenie sobie jakiegoś wzoru, tylko o to żeby dzięki matematyce modelować rozgrywkę. Tu aż się prosi o porównanie 3 najpopularniejszych funkcji (liniowa, wykładnicza, potęgowa). Pokazać przebiegi, pokazać gdzie się przecinają i jak to można wykorzystać. Pokazać jak parametryzować funkcje (można na 2 przykładach: niski koszt początkowy i szybki wzrost vs wysoki koszt początkowy i niski wzrost). Jeśli już jesteśmy przy koszcie kopalń i wydobyciu, to pokazać dwa podstawowe wskaźniki pomagające w analizie: stosunek produkcji do kosztu kopalni i stosunek wzrostu produkcji do kosztu kopalni. Pokazać że jeden określa jak długo gracz musi zbierać na kolejny poziom, a drugi określa czas po jakim inwestycja w kopalnię się zwraca.

Pasowałoby coś napomknąć o tematach bardziej złożonych. O różnych rodzajach graczy i jak właściwie targetować grę, o skalowaniu tempa rozgrywki w czasie, o rozbieżnościach między aktywnymi i mało aktywnymi graczami i jak sobie z tym radzić jeśli gra jest nastawiona na PvP, o balansie między atakującym i obrońcą, o aktywnym i pasywnym pozyskiwaniu surowców...

Temat-rzeka, ale jak już uczyć kogoś projektowania gier, to przynajmniej podstawy trzeba zarysować.
 
23.07.2013 12:34

TKu
unix89
P.S. Taki offtop: Całość tworzysz w OpenOffice? Nie myślałeś nad jakimś porządnym narzędziem do składania tekstu?
To znaczy co konkretnie? Wydaje mi się, że OpenOffice wystarcza w zupełności. Ponadto kod wklejany do poradnika będzie posiadał kolorowaną składnię i myślę, że to jest najważniejsze żeby nie zanudzić czytelnika szarością.
 
23.07.2013 12:29

unix89
Zapowiada się interesująco

P.S. Taki offtop: Całość tworzysz w OpenOffice? Nie myślałeś nad jakimś porządnym narzędziem do składania tekstu?
 
23.07.2013 10:03

TKu
Tak jak pisałem wcześniej napisaniem gry mmo w JavaScript przewiduje dopiero po tym poradniku. Jednak rozmiary poradnika z grą mmo mogą być spore bo napisanie tego rodzaju gry jest bardziej skomplikowane niż gry tekstowej.
 
23.07.2013 07:34

adacho26
Weslug mnie bardzo dobrze napisane tylko kurcze szkoda że opisujesz gry tekstowe :/ coraz mniej ludzi gra w takie gry .. Opisałbyś też może jakies mmorpg
 
22.07.2013 23:47

TKu
Co do pisowni to też zauważyłem błąd w pierwszym zdaniu, najwidoczniej mój openoffice ma w swoim słowniku takie słowo i pewnie będzie więcej literówek poprawię błędy i wgram poprawioną wersję. Do tego będę musiał jeszcze dopisać coś o projekcie graficznym strony. Chyba, że opisze go w części następnej w której zbuduje szablon pod stronę i przygotuje kilka formularzy czy okienek.
 
22.07.2013 23:35

FrozenShade
Przepuść tekst przez jakiegoś worda ze sprawdzaniem pisowni.
A tak poza tym to wygląda fajnie i przyjemnie. Zobaczymy co dalej.

Na końcu każdego rozdziału mógł byś wrzucać takie podsumowanie, zbiór nowych terminów, które się pojawiły. Coś, o czym każdy już powinien poczytać na własną rękę, ty zaznaczasz, że jest to ważne i trzeba to umieć. My wiemy, co to jest np sql, ale takich skrótów pojawiło się tam sporo, znajomość wybranych zagadnień na pewno będzie konieczna, żeby w pełni zrozumieć kolejne części (no i żebyś nie musiał przepisywać manuala).

Powodzenia.
 
22.07.2013 23:33

TKu
"błoto" wydaje mi się bardzo oryginalnym surowcem. : )
Musiałem coś wymyślić
 
22.07.2013 23:21

Drikam
"błoto" wydaje mi się bardzo oryginalnym surowcem. : )

Dość prosto opisane jak wygląda przykładowy projekt gry. Fajna sprawa, nie przydało mi się, zerknąłem tylko, ale zapowiada się ciekawie.