civ.org.pl forums [http://forums.civ.org.pl]
Space 4X - Projekt gry - Strategia Kosmiczna 4x [http://forums.civ.org.pl/viewboard.php?BoardID=113]
Re: Rozdział II - Wstęp: Podstawy [http://forums.civ.org.pl/viewtopic.php?TopicID=10183]
[http://forums.civ.org.pl/viewtopic.php?TopicID=10183#244434]

HidN 
May 01, 2011 at 17:11
Re: Rozdział II - Wstęp: Podstawy

2.1. rodzaj gry
Zgadzam się z podejściem SE4, wydawanie rozkazów i przeliczenia na koniec tury to najlepsze rozwiązanie, głównie z powodu rozgrywki Multi, pozwala na grę dowolnej ilości osób bez spowalniania rozgrywki oraz rozgrywkę w czasie rzeczywistym. Można zauważyć, że skupiam się tutaj praktycznie tylko na trybie multiplayer i ma to swój oczywisty powód, gdyż przy grze tak skomplikowanej i rozbudowanej stworzenie dobrego AI będzie co najmniej bardzo trudne i niezwykle czasochłonne, a jednocześnie dziś net to normalka i rozgrywka MP jest możliwa praktycznie wszędzie więc dlaczego by nie uczynić jej misją całego projektu?
Zarazem odpowiada to na pytanie o taktyczne rozgrywanie bitew, która to opcja by miała zastosowanie tylko przy grze w czasie rzeczywistym, w dodatku utrudniałaby przejście z takiej rozgrywki w tryb mniej bezpośredni a taka konieczność zachodzić będzie na pewno bardzo często. Dlatego uważam, że ewentualna opcja taktycznej rozgrywki bitew powinna być elementem dodatkowym, nad którym można pracować po zakończeniu ważniejszych elementów programu, fazie testów i głównego patchowania gry.

2.2. Z tym punktem również się zgadzam, jedynymi grami które oferują naprawdę wysoki poziom komplikacji jest seria SE, która niestety spaliła się na 5tej części która miała być właśnie tą jedyną i wspaniałą, a SE4 ma niestety swoje ograniczenia i wady o których zapewne wszyscy dobrze wiedzą i nie ma sensu się na tym etapie rozwodzić.
Oczywiście wysoki poziom komplikacji rozgrywki wiąże ze sobą 3 poważne zagrożenia dla projektu, mianowicie:
- czasożerność mikrozarządzania dużym imperium
- łatwość wkradania się różnego rodzaju bugów
- nieczytelny i/lub niefunkcjonalny interfejs
Oczywiście nie są to problemy niemożliwe do pokonania, aczkolwiek koniecznością jest odpowiednie podejście do projektu od samego jego początku. Kluczem jest elastyczny engine gry, który wybaczy wiele błędów programistycznych i pozwoli na pisanie przejrzystego kodu w którym można łatwo nawigować i dokonywać zmian.

2.3. Moim zdaniem warto zainwestować we w pełni 3-wymiarową galaktykę, pomysł może wydawać się jednym mostem za daleko ale w moim przekonaniu nie jest. Należy zauważyć, że większość prawdziwych galaktyk jest płaska, możemy więc to wykorzystać i w ten sposób je generować. Dzięki temu posiadamy płaszczyznę galaktyki, która staje się fundamentem interfejsu, edge-scroll (względnie skróty klawiszowe etc) przewija widok galaktyki wzdłuż tej płaszczyzny (zupełnie tak jak w klasycznej 4X), przytrzymanie PPM obraca widok wokół punktu centralnego widoku, rolka go przybliża i oddala, a kliknięcie LPM centruje widok na danym obiekcie (np. system), przez co łatwo można jego widok przybliżać, oddalać i obracać. Takie rozwiązanie UI zapewnia wygodę użytkowania a przy tym pozwala na ogrom możliwości - np. tworzenie mgławic, trójwymiarowe tło dla galaktyki no i przede wszystkim - taktyka w 3D, tego jeszcze nie było! Oczywiście problemem jest czytelność odległości między poszczególnymi obiektami, można to rozwiązać dwojako, po pierwsze skalowanie rozmiaru gwiazd i innych obiektów / ikon zgodnie z ich odległością od kamery, a drugie to "mgła" co chyba nazywa się Field of coś tam, który sprawia że im dalsze obiekty od obserwowanego się widzi, tym wydają się bardziej niewyraźne, efekt stosowany z lubością w nowych grach 3D.
Jeśli chodzi o engine bitew, to oczywiście idealnym rozwiązaniem byłby również engine 3D, uwzględniający też grawitację itd., nie mam niestety pojęcia jak coś takiego zakodować, szczególnie że walki mają i tak odbywać się automatycznie. Oczywiście można tu łatwo pójść na ugodę i stworzyć klimatyczny widok bitwy, np. z planetą czy systemem w 3D w tle, natomiast samą bitwę umiejscowić w 2-wymiarowej płaszczyźnie orbitalnej. Można sobie wyobrazić taką bitwę z atakującą flotą wchodzącą na orbitę i rozpoczynającą bitwę z flotą defensywną. Oczywiście sama mechanika takiej walki to już raczej temat na osobną dyskusję.
Jeśli chodzi o bitwę planetarną, to proponowałbym ją zintegrować z bitwą na orbicie - tzn flota inwazyjna wchodzi na orbitę w identyczny sposób jak w tradycyjnej walce, bitwa na orbicie i desant mogą w tym przypadku zachodzić nawet jednocześnie zależnie od ustalonych taktyk dla flot. Do takiej bitwy mogą się także włączać planetarne systemy obronne (np. rakiety, myśliwce suborbitalne itp.), angażować desant próbując zmniejszyć liczebność atakującego wojska lub też zupełnie inaczej, flota osłaniająca desant przystępuje do neutralizacji obrony planetarnej a następnie dochodzi do desantu i walki na planecie wspieranej z orbity przez flotę.
Coś pięknego, a przy tym całkiem wykonalne i proste w swojej koncepcji (płaszczyzna równikowa jako pole walki w przestrzeni + płaszczyzna planety w strefie 0-60 st jako płaszczyzna walki lądowej o poszczególne strefy planety). Oczywiście wiele detali tej koncepcji pominąłem, ale chętnie o tym podyskutuję w razie potrzeby.

2.4. Zgadzam się, przydałyby się. Ale zawsze można mieć wymówkę, że w przestrzeni dźwięków nie słychać.

2.5. Interfejs to temat rzeka, jego struktura w 99% zależy od finalnej koncepcji mechaniki gry. Odważę się wręcz stwierdzić, że interfejs powinno się projektować jak już w/w koncepcja jest ustalona i wyryta w kamieniu.

2.6. Zdarzenia, tutaj proponuję genialną prostotę - informowanie o wydarzeniach w miejscu ich występowania. Powiedzmy że w danej turze miały miejsce 3 bitwy, na 4 planetach zakończono produkcję, na kolejną spadł meteor a do 1 systemu leci flota przeciwnika. Wszystkie te informacje umieszczane są na mapie galaktyki jako odpowiednie ikonki 3D, ich podświetlenie kursorem rozwija pełną informację o danym zdarzeniu a kliknięcie LPM pozwala na wycentrowanie na danym miejscu lub PPM usuwa zdarzenie i nie rusza kamery. Oczywiście jeśli zdarzenie znajduje się poza naszym widokiem, powinno być zakotwiczone na skraju ekranu. Zdarzenia globalne mogą mieć swoje własne wydzielone "terytorium" widoku, lecz poza tym funkcjonować w identyczny sposób. Ponadto każde zdarzenie może posiadać mini-ikonki przy nim pozwalające podjąć różne działania np. "wyświetl system" albo "zmień kolejkę budowy", możliwości takiego rozwiązania są dość bogate, w tym podział na rodzaj (np. kolor) i ważność (np. gwiazdka/gwiazdki w rogu eventu), wszystko razem da wygodny i ergonomiczny efekt, którego tak brakuje w grach tego typu.

2.7. No ba!

[Edited by HidN on May 01, 2011 at 17:46]




tForum version b0.94.1.2 (© 2003 tForumDevTeam)

The comments published here represent only the personal opinions of the respective users. civ.org.pl and it's staff is not held responsible for the contents of the posts.

Publikowane komentarze są prywatnymi opiniami użytkowników portalu. Portal civ.org.pl ani jego redakcja nie ponosi odpowiedzialności za treść opinii.


hosted by artserwis.pl - praca, konkursy, portfolia dla twórców.