www.warsztatgames.fora.pl

Xirdus

Wsadzam dalszą część opisu mojego pomysłu, przedstawiającą bardziej sam gameplay. Skupiłem się głównie na mapach z tego względu, że zauważyłem, że prace pod tym względem już poszły. Anyway:

Przed rozpoczęciem walki mechy ustawiane są na miejscach startowych mapy. Dla pojedynków 1v1 brane są tylko miejsca nr 1 i 2, dla większej ilości graczy losowane są z całości puli. Dla walk drużynowych jest osobny zestaw miejsc startowych, a właściwie dwa: jeden dla jednej i drugi dla drugiej drużyny. Większej ilości drużyn nie przewiduję.

Kamera jest centralnie z góry, wysokość (tj. obszar, jaki pokazuje) zmienia się dynamicznie i jest uzależniony od pozycji mechów - kamera stara się uchwycić wszystkie mechy z małym marginesem, jednak nie zbliża się poniżej pewnego ustalonego poziomu by nie było zbyt dużego powiększenia.

Mapy będą niezbyt duże, jednak dokładna wielkość będzie zróżnicowana. Część map to będą otwarte place, część to labirynt korytarzy. Mapa zawsze będzie podłożem - nic nie będzie przykrywać mechów. Sam plik mapy powinien zawierać obrazek mapy oraz dane o obiektach:
-"niewidzialne ściany" w postaci prostokątów o dowolnych wymiarach i orientacji, przez które nie będzie nic przechodzić (zwykle będą w miejscach, gdzie narysowane są rzeczywiste ściany)
-"niewidzialne półścianki", przez które mechy nie mogą przechodzić, ale pociski tak
-obiekty fizyczne, np. skrzynki, które będą się przesuwać; każdy będzie miał określoną masę (masa równa 0 znaczy, że nie można przesuwać) oraz wytrzymałość (punkty obrażeń, po których obiekt zostaje zniszczony; 0 oznacza, że obiekt jest niezniszczalny); obiekty mogą być wysokie (blokują mechy i pociski) i niskie (blokują mechy, ale nie blokują pocisków); obiekty mogą być odporne lub częściowo odporne na niektóre typy broni
-obiekty niefizyczne, jako obrazki "wlepione" w mapę; na potrzeby skryptów
-triggery aktywujące skrypty; trigger aktywuje się, kiedy mech stanie w odpowiednim miejscu; obiekty fizyczne mogą pełnić rolę triggerów - wtedy skrypt aktywuje się po ich zniszczeniu

Walka kończy się, gdy spełni się jeden z dwóch warunków: wszystkie wrogie mechy zostaną wyeliminowane lub upłynie czas gry. Eliminacja następuje, gdy mech zostanie zniszczony lub unieruchomiony (nie będzie się poruszał przez określony czas). Przeciętna walka 1v1 powinna trwać do 1 minuty. Domyślne ustawienia dla części składowych mecha powinny być tak dobrane, by mniej więcej starczać na właśnie minutę.

Sory że tak rzadko i mało piszę, ale brakuje mi czasu i doświadczenia żeby więcej robić. Jak macie pytania lub uwagi odnośnie czegokolwiek albo prośby żebym jakiś element gry jeszcze opisał, to piszcie tutaj.

nobody

Parę rzeczy tutaj zmienia nieco mój pogląd na edytor. Ale nic. Nie napisałem na tyle dużo by strata paru rzeczy bolała.

PS. Niedługo napiszę do Ciebie listę pytań odnośnie gry, aby móc dokładniej zaprojektować edytor.

Will

Mam nadzieje, że z tej listy pytań zrobi się jakiś konkretny dokument tak aby nie trzeba było zbierać potem wszystkiego jak puzzle. Tak właściwie to trzeba opisać każdy z elementów, z tego podforum:
AI, skrypty, itd itd Napisz pod każdy opis ze strony designu czyli:
AI: opisz jaką inteligencje mają posiadać boty, jaka jest ich widoczność(radar?, wzrok? wykrywanie ruchu? itd), jakie mają być ich strategie walki(ich charaktery)?, itd
Rendering: Co to właściwie za świat? jakieś sf? mieszanka przeszłości z nowoczesną technologią? Jaki klimat całości(mroczny, same dynamiczne światła bez dziennego oświetlenia czy może mieszanka)?
Fizyka: Jak wygląda walka? latające elementy świata wpływają na przeciwników? podłoże wpływa na możliwości ruchu graczy? itd

Ogólnie najlepiej przygotuj opis dla każdej z sekcji tak aby każdy wiedział mniej więcej jak jego część roboty będzie wyglądać.

Xirdus

Will, postaram się zrobić to, o czym mówisz, na tyle na ile mogę. Problem w tym, że... sam nie wiem jak to będzie wyglądać Razz

Nie da się zaprojektować każdego pojedynczego skrawka gry "na sucho". Po pierwsze nie mam doświadczenia, po drugie niektórych rzeczy nie da się odgórnie zaprojektować, tylko trzeba je sprawdzić w praktyce. A część rzeczy to się po prostu rozumie sama przez się Wink

Will

No tak, ja nie twierdzę, że da się wszystko zaprojektować od początku do końca ale potrzeba tyle informacji aby każda z sekcji mogła ruszyć do przodu. Do tego potrzebne są informacje np: takie, które podałem w poprzednim poście. Najlepszy byłby opis jednego pojedynku ogólny+ taki opis osobny dla każdej sekcji. Najbardziej sensowym rozwiązaniem jest stworzenie dynamicznego design doc'a, który byłby uzupełniany wraz z rozwojem projektu. Wtedy całość jest w jednym miejscu i każdy ma dostęp zawsze do najnowszych danych. Możesz zrobić coś na zasadzie wiki.

p2rkw

Może na początek skupmy się na tym jak byśmy widzieli prototyp gry. Mi w prototypie wystarczy mapa, pare mechów i możliwość strzelania czymkolwiek.

nobody

Mam wrażenie, że to wszystko zmierza trochę nie w tym kierunku co trzeba. Trzeba zrobić solidny zarys ogólnego projektu, albo inaczej zrobi nam się niezły burdel z kodu oraz współpracy.

Oto co ja Wam proponuje:
- skontaktuje się z Xirdusem na GG w celu dopytania o pewne szczegóły gry, jak on to widzi
- na podstawie tych oraz poprzednich informacji zaprojektuje odgórnie CAŁY kod (nie mam tu na myśl jakiś wewnętrznych mechanizmów, tylko schemat jak to ma być zbudowane oraz jak to ma działać). Będę tu wykorzystywał głównie wiedzę jak czegoś nie robić (patrz dział "Projekty" na moim blogu)
- postaram się to zrobić w ciągu kilku dni

Po pokazaniu projektu stwierdzicie, czy według Was ma on sens i czy warto go wykorzystać. Odpowiada Wam ta propozycja?

p2rkw

Skoro czujesz się na siłach zaprojektować cały kod, to mi jak najbardziej pasuje.

kkalisz

Xirdus

Will

Pomysł ok ale nawet do prototypu potrzebne są te wszystkie dane, o których pisałem plus moim zdaniem nawet prototyp powinien oferować grę po sieci.

nobody

Fail z mojej strony. Jako, że jutro jadę na wycieczkę i okazało się, że nie mogę wziąć laptopa z projektowania kodu nici (a raczej będę mógł to zrobić na kartce, ale nie będę miał możliwości przeniesienia na komputer i wysłania wam). Dostęp do internetu będę miał tak właściwie jedynie z czytnika e-booków.

Więc albo możecie poczekać na projekt (wracam 09.02.12, w weekend pewnie bym się wyrobił z przeniesieniem), albo po prostu inaczej to zorganizować i zacząć kodzić. Nie chcę wstrzymywać prac.

kkalisz

sory ale ja dalej nie wiem co to kodzić !? nie mamy nawet dokładnie opisanego konceptu całej mechaniki. nie mamy zbudowanego żadnego podstawowego diagramu co aktualnie jest podstawą przy Tworzeniu oprogramowania. Minął prawie miesiąc... a dalej stoimy w miejscu.... i skończy się tak że zacznie powstawać kod który nie był przemyślany zaprojektowany nawet, pojawią się kłopoty braki nagłe zmiany konceptu i wyjdzie chuj w dupe Razz

Will

Ja też nie mam pojęcia co kodzić Wink

ale bez opisu nie można się za nic zabrać. Xirdus co z opisem? Jeśli nie masz czasu a nikt inny nie widzi tego pomysłu na tyle aby móc to dobrze spisać to trzeba będzie podjąć jakieś sensowne decyzje. Daj znać co i jak i najpóźniej w weekend trzeba będzie podjąć konkretne decyzje.

Xirdus

Ale ja nie bardzo wiem co mam opisać Sad

No po prostu nie wiem jak wyrazić w słowach zwykłą naparzankę. Bardzo bym chciał, żeby inni członkowie zespołu też wzięli udział w projektowaniu, szczególnie projektowaniu kodu - bo takie coś wykracza poza moje umiejętności.

@kkalisz: czego konkretnie opis ci potrzeba? Jaka kwestia jeszcze nie została na tyle dobrze przedstawiona, by nie móc chociaż zacząć prac? Czy chodzi tylko o zebranie wszystkiego do kupy?