Forum CM: Projekt Casus -- część 1.

jiser [ generał-major Zajcef ]

Casus będzie pisany po angielsku (jest szansa na "eksport" programu na inne organizacje CM-owskie). Będzie złożony z modułów według podziału funkcjonalnego zagadnienia modelowania pola walki. Oto projektowany podział na moduły:

Moduł R : rules - zasady gry, sterowanie grą, koordynacja pozostałych modułów
Moduł T : terrain - reprezentacja terenu, mapa i jej obsługa
Moduł C : clock - synchronizacja czasu, zegar i jego obsługa
Moduł U : units - jednostki, stan osobowy i sprzętu
Moduł E : events - wydarzenia i ich obsługa
Moduł O : orders - rozkazy, obsługa wydawania rozkazów
Moduł L : logistics - logistyka - zaopatrzenie w amunicję, stopień powracalności żołnierzy WIA i MIA do walki, stopień przywracalności sprzętu bojowego, awaryjność sprzętu poza polem walki, sprawdzanie funkcjonowania linii zaopatrzeniowych
Moduł I : information - kontrola rozprzestrzeniania się informacji - FoW, przekazywanie dokumentów, łączność między dowódcami odgywanymi przez graczy, łączność między dowódcą a jednostami podległymi
Moduł A : actors - ewidencja dowódców (nietylko dowódców graczy), hierarchia dowodzenia, kontrola dwd-ców nad jednostkami
Moduł P : players - gracze
Moduł G : graphics - grafika, interface
Moduł AI : artificial intelligence - dla wprowadzania dowódców całkiem odgrywanych przez komputer (ECG for decisive systems)

Nie wszystkie moduły od razu mają mieć pełną (czy nawet częściową) funkcjonalność, postaramy się możliwie szybko składać proste wersje Casusa, by potem rozbudowywać o kolejne możliwości.

Poniżej znaleźć ma się opis problematyki poszczególnych modułów oraz omówienie różnych ich wariantów i możliwych do zastosowania modeli reprezentacji.

jiser [ generał-major Zajcef ]

Moduł Rules

jako spajający wszystkie inne, zostanie opisany na samym końcu

jiser [ generał-major Zajcef ]

Moduł Terrain -- modele

Najistotniejszymi częściami tego modułu są: określenie skali odwzorowania, reprezentacji i dyskretyzacji terenu.Skala odwzorowania wymusza ustalenie wielkości jednostek podstawowych (zbyt mała ilość wojska nie będzie w stanie skutecznie kontrolować pola, zbyt duża będzie miała problemy z zatłoczeniem) oraz czas potrzebny do przemieszczania się na inne pola. Reprezentacja terenu wyznacza ilość informacji podanych na mapie "strategicznej" o terenie potencjalnych pól bitewnych oraz z góry wyznacza ich cechy szczególne. Dyskretyzacja (podział na identyfikowalne kawałki) terenu wymusza szczegółowość podejścia do obliczania odległości między punktami oraz reprezentacji terenu w skali mapy "strategicznej". O co chodzi, widać na poniższych przykładach.

I. Model wydzielonych pól walki
Stosowany w BWB Pejotla. Z mapy topograficznej wybiera się miejsca, które w naturalny sposób stałyby się polami bitewnymi -- miasta, mosty, przełęcze, płaskie bezleśne teren graniczące z kompleksami leśnymi itp. Owe pola bitewne są względnie duże w porównaniu z rozmiarem mapy "strategicznej" - na mapie mieścić się może od 10 do 50 takich pól. Niewątpliwą zaletą jest możliwość projektowania map pól bitewnych w fazie organizacji początkowej kampanii. W danej turze, jednostka może przemieścić się zwykle najdalej trzy - cztery pola. Walczyć mogą jednostki tylko znajdujące się na tym samym polu bitewnym (nie dotyczy jednostek z dużym zasięgiem np. artylerii). Kolejną zaletą jest ograniczenie dziwacznych sposobów rozmieszczania jednostek przez graczy. Łatwo da się wyznaczyć obecną linię frontu, okrążenia, flankowanie pojawia się tylko w rozsądnych ilościach. Naturalne staje się wydzielanie pasów natarcia. Niezbędna staje się konstrukcja grafu przejść między polami (patrz problem 1) oraz posługiwanie się mapą topograficzną (patrz problem 2).

II. Model siatki heksagonalnej
Doskonale znany z gier planszowych, przeniósł się do komputerowych strategii turowych. Mapa podzielona jest na pola o kształcie sześciokątów foremnych. Zwykle tych pól jest od 50 do 1000. Używany w WB:BO i WB:BB. Oczywistą zaletą jest możliwość wprowadznia prostej reprezentacji terenu dzięki takiej dyskretyzacji mapy. Po prostu, uznaje się, że formacje powierzchniowe (wzgórza, lasy, jeziora, zabudowania) zajmują całe pole (w pewnym sensie - wioska nie zajmuje całego pola, ale jej obecność ma wpływ na całe to pole). Elementy "pozytywne" (drogi, mosty, linie kolejowe) zawsze łączą pola, elementy "negatywne" (przede wszystkim rzeki) - zawsze rozdzielają. Prostota takiego podejścia umożliwia "statystyczny" opis pól bitewnych (patrz problem 2). Także i tutaj (podobnie jak w modelu T.I) można stosować mapy zapisane jako statyczne obrazy. Jednostki walczą w taki sposób, że obrońca zawsze znajduje się na tylko jednym polu, atakujący może atakować z kilku (koniecznie innych) Zaletą jest prostota ustalania kontroli nad terenem oraz wyznaczania odległości między punktami. Niebanalnym problemem (od strony algorytmicznej) jest ustalanie, do którego pola należy dany punkt mapy. Czasem zdarzają się strategie "nierealistyczne" pod względem otoczenia "strategicznego" (tzn. gracze operują jednostkami tak, jakby nie były one częscią frontu).

III. Ciągły model mapy
Znany z gier typu RTS, choć lepszym przykładem jak działać może ciągły model mapy w grze strategicznej, jest klasyczna seria 'Harpoon'. Chodzi o mapę, której każdy punkt jest równie dobry jako miejsce docelowe (nie ma podziału na pola). Oczywiście, nic reprezentowane w komputrze nie ma postaci ciągłej, ponieważ jakikolwiek wybrany układ wspórzędnych na takiej mapie jest całkowitoliczbowy. Chodzi jednak o sytuację, w której rozmiar takiego punktu jest niezauważalny (co wymaga albo dużego marginesu rezerwy rozdzielczości mapy w stosunku do możliwych skal wyświetlania tej mapy, albo fraktalnego kodowania terenu). W tym modelu, niezbędna staje się pełna reprezentacja terenu (nie może być on zapisany jako statyczny obraz), jednak niesie to z sobą nieporównywalnie większą "realność" gry i dużo szerszą paletę możliwych zdarzeń. Trudne staje się określenie miejsca przebywania jednostki oraz jej kontroli terenu (kwestia reprezentacji obszarów jako kół? owali? wielokątów? figur Jordana?). Wszystkie reguły interakcji jednostek z otoczeniem wymagają procedur dla zakresowo liczonych odległości (tzn. między tymi dwoma jednostkami odległość wynosi 3170-3500m). Jest kilka metod radzenia sobie z takim modelem - wystarczy zerknąć na wymienione przykłady. Kiedy wreszcie przyjdzie pora na pojawienie się solidnej gry strategicznej z ciągłym modelem mapy <smutne westchnienie>? Jak się chce żeby coś zostało zrobione porządnie trzeba się samemu za to zabrać <smutny uśmiech>.

Są jeszcze inne ciekawe modele (w tym bardzo ciekawy - ciągły fraktalny o trójkątnym punkcie) lecz nie są one tak często używane.

jiser [ generał-major Zajcef ]

Moduł Terrain -- problematyka

a) Graf przejść
Chodzi o graf przejść między polami bitwy. Każde pole bitwy tworzy jeden węzeł, każda możliwa drogą przejścia - krawędź. Każda krawędź opisana jest przez jakość połączenia (przykłady na ilustracji). Graf przejść jest niezwykle ważny w modelu T.I (wydzielonych pól bitewnych). Dla modelu T.II, graf przejść jest jednorodny (każda krawędź ma długośc stałą dla mapy, możliwe są wszystkie połączaenia sąsiednich pól). Ujednolicone parametry przejść między polami stanowią "zasady ruchu jednostek".
W modelu T.III (nie ma na ilustracji) taki graf wyznaczają możliwe kierunki przejść między punktami - ponieważ zwykle punktem jest kwadrat więc tych kierunków dla każdego pola jest osiem (z przekątnymi) lub cztery (bez przekątnych); odległość punktów wynika ze skali rozdzielczości mapy.

Najbardziej prawdopodobne wydaje się implementacja najpierw modelu T.I, później T.II. Wystarczy zauważyć, że model II jest pewnym szczególnym kształtem grafu z modelu III z większą ilością węzłów. Inna reprezentacja, acz metodologia podobna. Realizacja modelu T.III pozostaje daleką przyszłością.

Zatem, do omawiania wybierzemy model I. Trzeba zauważyć, że przejścia między polami bitewnymi muszą być warunkowe. Oto dwa przykłady przejść warunkowych.

Przykład T.1
Fragment pola bitwy tworzy mała rzeczka o bagnistych brzegach, na rzeczce mostek o nośności jest 10 t. Piechota, lekkie wozy i lekkie działa przejdą dopóki jest mostek. Gdy mostek zostanie zniszczony, przeprawę będzie mogła podjąć jedynie piechota, z (być może) co lżejszą bronią wsparcia, ale na pewno bez dział i cięższych moździerzy. Gdyby jednakże wosjkom inżynieryjnym udało się zbudować przeprawę mostową, przejść mogłyby nawet czołgi. Od decyzji prowadzącego grę zależy czy teren na to pozwala.

Przykład T.2
dwa pola bitwy łączy linia kolejowa. Jeśli jest ona sprawna, a gracz dysponuje taborem kolejowym, może próbować transportować tym sposobem jednostki (podobnie jak w przypadku przydzielania jednostkom kolumn transportowych czy wozów piechoty) zamiast poruszać się "na piechotę". Przeciwnik może pokusić się o zniszczenie mostów kolejowych, taboru transportowego, kolumny przewożącej jednostki (w przypadku pociągu chodzi o zniszczenie go na trasie) czy nawet samych torów kolejowych. Prowadzący musi zdecydować czy któryś z tych wariantów jest możliwy.

W obu powyższych przypadkach zachodzi mnóstwo warunków, które muszą być spełnione aby dany sposób poruszania się mógł być wykonany. Wiążą się one z wiedzą posiadaną przez system (w tym przypadku Casus) o tym, co jest zapisane na mapie. Im więcej zatem informacji zostanie przeniesionych z mapy (jako obrazu statycznego) do systemu (jako informację dynamiczną), tym bardziej rozbudowane mogą być późniejsze wydarzenia zaplanowane w kampanii.

25.11.2003

04:26

[7]

Hanoverek [ Konsul ]

Powodzenia Jiser! Jesli Ci sie uda bedziesz wielki!

Llordus [ Generaďż˝ ]

A teraz troche praktycznego spojrzenia na problem:
przy ustalaniu modeli terenu i grafu przejsc wazna jest jeszcze jedna rzecz - mianowicie ktos te dane o mapach bedzie musial wprowadzic. Poza tym jak zostana wprowadzone, beda zajmowac mniej lub wiecej pamieci dyskowej - oznacza to zarówno większe obciążenie serwera, na którym projekt CaSuS miałby zostać udostępniony, jak i obciążenie łącz sieciowych użytkowników z niego korzystających (głównie myślę o modemowcach :) ). Z oczywistych wzgledow najprostszy do edycji bedzie model w stylu BWB Pejotla, najtrudniejszy (ale i najbardziej realistyczny) model ciągły.
Na plus modeli bardziej skomplikowanych jest fakt, że dana operacja będzie musiała być wyedytowana tylko raz, a rozgrywana tyle razy ilu będzie chętnych :).
To tyle moich dywagacji :)

jiser --> jestem pod wrazeniem Twoich opisow :D

adam [ Generaďż˝ ]

łojejku jestem pod wrażeniem:))

nie znam się zupełnie na problemach programistycznych jakie mogą wystąpić. Ale jestem za tym żeby w pierwszym ruchu poupraszczać ile da się. Skomplikowac chyba zawsze można bardziej:))

Np linia kolejowa.. nie będziemy sie bawić się w strategie , przrzuty armii pancernych, itd. Operujemy raczej na niewielkich mapach i niewielkich oddziałach. Nikt chyba na odległośc 20 km nie przesyłał oddziałów koleją szczególnie zaraz za linią frontu, bo samoloty bardzo ładnie tę możliwość mogły wyłączyć.

upraszczanie map - prosciej niz w cm tylko płasko i wzgórza, 2 szybkości przemieszczania na tej samej drodze
żadnych dodatkowych opcji, + teren gdzie wejśc nie można
2 drogi - szosa i polna droga
2 typy rzeczek - przekraczalna wczasie gry - czytaj most budujemy w 8-12 godzin
i nieprzekraczalna w czasie gry, o ile nie ma mostu)).
2 mosty - piechota i pojazdy typu HT - nie wiem czy mozna ustalic np 10T, i most dla całej reszty.
i to jest chyba maximum co trzeba z mapy do szybkosci przemieszczania wojsk

moduł Logistyczny - w operacjach CM jakos to jest zrobione, nie mozna się na tym oprzeć?
awaryjność sprzętu - uważam że nalezy sobie całkowicie podarować.
nie rozumiem po co moduł AI - mają grac ludzie a nie komp, chyba ze chodzi o jakies jednostki rozpoznawcze, w stylu 2 ludzi na rowerach zasuwa do najbliższej wioski:)), albo przyszedł dziadek z krową i powiedział ze za 3 brzózkami stoją 3 wielgachne czołgi:))

co więcej mozna uprościc? chyba nie mam pojęcia

25.11.2003

11:53

[10]

oskarm [ Future Combat System ]

jiser --> Niestety IMO model ciagły odpada:
1) ze względu na chyba najtrudniejszą formę realizacji,
2) ze względu na ograniczenia samego CM i wszystkich innych strategi w tej skali. O ile w Harpunie występowała mała ilość jednostek i nie trzeba było przechodzić do walki na inną skalę rozgrywki, to w CM jest to niemożliwe z wielu przyczyn:
a) zawsze będzie jakieś ograniczenie rozmiaru pola walki w CM,
b) percepcja graczy dowodzenie siłami wielkiści pół dywizji w tej skali jest bardzo pracochłonne,
c) trudnoby było oceniać jakie jednostki biorą jeszcze udział w walce na danej mapie a jakie nie.

IMO najlepszy byłby model heksagonalny.
1) umożliwia on łatwe zdyskretyzowanie właściwości terenowych, które jest czytelne i łatwe do zrobienia w CM (small, modest hils itd.)
2) mino swoich uproszczeń jest on chyab przez większość akceptowalny jako dosyć realne odwzorowanie pola bitwy w skali operacyjnej.
3) jeszcze nikt nadal nei wymyślił jak obejscproblem krawędzi mapy w tak obraniczonych obszarowo grach jaką jest CM

IMO jezeli chodzi o model Pejotla to jest on dobry w wypadku gdy gra jest obsługiwana przez człowieka, więc w wypadku programu chyba lepiej jest skoncentrować siean ambitniejszym rozwiazaniem heksagonalnym.

25.11.2003

11:53

[11]

NeoBerger [ Generaďż˝ ]

adam --> wszystko zalezy od tego w co sie chce zagrac.
Jezeli starcie dwoch batalionow na jakiejkolwiek mapce to mozna sobie podarowac wszelkie oprogramowanie i studia takie jakie podjal jiser. Wystarczy kartka papieru. I tu masz racje.

Ale wielu ma dosyc uproszczonych starc zaproponowanych przez CM.
Ja np. chce operacji, gdzie w walce uczestniczy po kazdej stronie co najmniej Armia z wzmocnieniami.

Wiec wtedy wchodzi w gre czas reakcji dowodztwa wyzszego szczebla, stopien umiejetnosci wspolpracy miedzy dowodcami, rozmieszczenie rezerw, zapasow, system drog, dojsc, czas przemieszczenia, zdolnosc do elastycznej reakcji, zdolnosc do improwizacji (sedzia gry moze wtedy zmienic tabele czy parametry - np. omawiana rzeczka moze byc przekroczona jednak przez dziala radzieckie, bo batalion piechoty przeniesie je na plecach :-)
W kilkudniowej walce ma znaczenie istnienie warsztatow remontowych, istnienie czesci zamiennych, zdolnosc do sciagania pojazdow z pola walki, szybkosc okopywania sie itp.
Naprawde jak wystarcza ci system operacji z CM to mozna w niego grac, ale tu jiser mial chyba na mysli to o czym napisalem powyzej :-)))

Zupelnie inna sprawa jest moment w ktorym trzeba zastosowac brzytwe bo istnienie projektu zostanie zagrozone w jego podstawach. Przeladowanie informacjami zalatwic moze nie tylko programistow, ale i pozniejszych dowodcow w grze :-)

Pzdr

Berger

jiser [ generał-major Zajcef ]

Llordus ~~>

1. o wprowadzaniu danych - za moment

2. o fizycznej ilości informacji - Zdaję sobię sprawę z kwestii przesyłania dużych ilości informacji siecią. Ale jest na to dość proste rozwiązanie. Casus niekoniecznie musi przybrać formę apletu WWW, może być uruchamialnym programem Javy w przeglądarkach internetowych, ale "do ściągnięcia" i uruchamialnym z dysku. Wtedy przez sieć przesyłane byłyby tylko pakiety informacji dotyczące zmian. Całość możliwych wcześniej do zaprojektowania (a przecież zdecydowanie większą część można wprowadzić "z góry") byłaby ściągana na początku. Zaś wersja w sieci działałaby jako serwer wymiany informacji.

3. właśnie - im więcej informacji zostanie zawartych w modelu, tym mniej (zdecydowanie) trzeba będzie się męczyć z jego obsługą.

adam & Berger ~~>

1. Nie rwę się od razu z motyką na słońce. Ale jeśli nie wezmę pod uwagę możliwie uniwersalnego kształtu możliwości Casusa, to będzie potem dużym problemem jego rozbudowa. Hmm, a jeśli chodzi o takie bardzo małe projekty o których mówi adam -- to nie trzeba do tego programu, wystarczy przecież dobrze napisany arkusz kalulacyjny, nawet exelowski. Przecież daje on naprawdę niezłe możliwości, nawet możnaby zrobić klikacz mapy (a nie wstukiwane ręczenie numery pól przy poruszaniu jednostek).

2. Po co są poszczególne moduły ? Powiem, jak wreszcie do nich dojdę :)

3. No właśnie, Berger, o to chodzi :) Może armia ze wzmocnieniami to trochę za dużo, ale dobrze byłoby gdyby sposób w jaki Casus zostanie zapisany nie załamał się przy wzięciu trochę większej skali (większa mapa, więcej jednostek, więcej dowódców). Komputerowi, jak już zostanie dobrze zaprogramowany, jest wszystko jedno czy ma tych dowódców 6 czy 20. A naprawdę małe kampanie należy grać nie przez Casusa, a przez "operacje" w CM.

Jedno jest na pewno ważne. CM "odwala za nas" najczarniejszą robotę. Czyli konstrukcję modelu pola bitwy na poziomie taktycznym. Kto ile widzi, jaka jest przebijalność tego działa, jaką balistykę mają takie pociski, jak daleko dobiegnie piechota, jak duży jest efekt jej ostrzelania przez kaemy. Przy tym, taki Casus, to pestka.

I jeszcze jedno. Mam świadomość, że czasem się zbyt dalce rozpędzam (w projektach). Ale potrafię się kontrolować. A do wielkości konieczna jest umiejętności spojrzenia daleko a nie tylko blisko (ale się pompatyczny zrobiłem ;)

4. Tak to jest, Bergerze. Dowódca sztabowy ma przed sobą, na wyciągnięcie ręki, duże ilości informacji .... tylko że większość z nich jest nieprawdziwa lub niedokładna :D A to dostarczyli mapę, ale można się nimi podetrzeć. A to mógłby pojechać do liniowych jednostek (a tam można się duuużo dowiedzieć), ale mu się nie chce ;)
W dobrej strategii potrzebna jest duża ilość informacji. Inna sprawa, że bardzo ważne jest aby były one czytelnie podane i w rozsądnych porcjach. A od tego będzie moduł interface&graphics (i może Ścibora da się namówić, aby został grafikiem zespołu ;)

oskarm ~~>
1. Model ciągły to dalekie plany. Ale jakoś mało firm produkujących strategie zdaje sobie sprawę, jak dobry mógłby być to produkt. A dobry produkt przebije się i znajdzie kupców. Poza tym, Casus jest (hie hie) uproszczeniem projektu systemu wspomagania dowódcy, nad którym pracuję od kilku lat. Profesjonalnego systemu wspomagania dowódcy, bo ten który widziałem na prezentacjach (na ten temat) w Wojskowej Akademii Technicznej jest raczej mierny. Ale wbrew temu co piszesz, taki model nie jest niemożliwy do zrealizowania. Bardzo trudny też nie. "Tylko" trudny ;)
2. Co do modelu heksagonalnego - owszem, tutaj będzie (zapewnie) ów "środek wagi" dla projektu. Ale zaczniemy od modelu pejotlowego, choć w ciut szerszym ujęciu. Więcej informacji na mapie (tych aktywnych) i więcej pól. Stanie się wtedy pewną hybrydą heksagonalnego - nie tak regularną, ale prostszą i zawierającą więcej informacji.

-=Dexter=- [ Konsul ]

Ogólnie -> zgadzam się z Adamem co do ogólnej koncepcji stopniowania skomplikowania projektu. Moją ulubioną metodą przy tworzeniu oprogramowania jest rozpoczynanie od możliwie uproszczonej wersji początkowej i ewolucyjny rozwój w pożądanym kierunku. Wadą takiego systemu pracy jest to, że pierwotna wersja musi nadawać się do rozwoju czyli musi zostać pod tym kątem szczegółowo przemyślana, a że nie wszystko da się na tym etapie przewidzieć, zdarza się że trzeba zaczynać rzecz od początku. Zaletą jest to, że nie grzęźniemy na etapie planowania, tylko szybko otrzymujemy coś realnego, co można wstępnie testować i co unaoczni nam wiele problemów niemożliwych do przewidzenia na sucho.

Dlatego moim zdaniem powiniśmy wyjść od rzeczy najprostszej i najłatwiejszej do stworzenia - interfejsu obsługi mapy, wyposażonemu w następujące możliwości:
- nanoszenie na mapę danych o jednostkach znajdujących się na poszczególnych węzłach - ręcznie, przez graczy lub przez sędziego w zależności od etapy gry
- graficzną reprezentację tych jednostek na mapie
- podgląd takiej mapy przez poszczególnych graczy logujących się na serwer z uwzględnieniem nadania im odpowiednich uprawnień do poszczególnych węzłów
- wymiana danych pomiędzy graczami i serwerem poprzez przesyłanie plików - e-mailem, lub online

Resztę funkji wykonywaliby na razie sędzia i gracze a program umożliwiałby tylko wymianę informacji między nimi w jednolitym, możliwym do kontrolowania formacie. W następnych etapach program przejmowałby od graczy i sędziego kolejne funkcje, oraz pozwalałby uwzględniać coraz wiecej czynników, zmierzając do docelowej postaci - kiedy możnaby za jego pomocą wykonywać wszystkie obliczenia pozostawiając graczom tylko czynności decyzyjne i eliminując potrzebę istnienia sędziego.

jiser -> to luźna propozycja, nie wiem jak by to się dało wkomponować w Twój system modułów

jeśli chodzi o reprezentację terenu to proponowałbym wyjść od prościutkiego modelu wydzielonych pól walki i stopniowo go komplikować,
model siatki heksagonalnej to moim zdaniem to samo co model wydzielonych pól walki tylko odpowiednio sparametryzowane
model ciągły pozostawiłbym do zaimplementowania w wersji 5.0 programu ;)

-=Dexter=- [ Konsul ]

jiser -> nie widziałem Twojego ostatniego posta (tyle czasu to pisałem? ;) ), widzę że ogólne przemyślenia mamy podobne ;)

jiser [ generał-major Zajcef ]

Dexter ~~>

Jak przedstawię zarys modułów, to się wszystko (mam nadzieję) wyjaśni z tą kompozycją. Nie jestem pewien czy sędziego da się (i czy potrzeba) wyeliminować z obiegu, w końcu to on dostarcza systemowi tych "ciekawych" pomysłów.
A co do pragmatycznego spojrzenia na tworzenia Casusa, widzę że się zgadzamy.

I jeszcze dwie uwagi natury ogólnej:
1. Co do tego 10-tonowego mostku. Widzice, tak na prawdę nic takiego być nie musi. Ale co chcecie mieć: grę planszową czy grę strategiczną ? Bo na dobrej mapie sztabowej zaznaczone są takie informacje jak nośność mostów, przepustowość dróg, gęstość i rodzaj zalesienia, trudność terenu. To ma gigantyczny wpływ na zadanie stojące przed dowódcą. A przecież kiedyś może wreszcie powstać tego rodzaju gra.

2. Co do modułu AI -- pojawił się on tutaj, ponieważ będzie tematem mojej pracy magisterskiej. Jak już Casus powstanie, będzie świetnym podłożem dla mojego projektu inteligentnych systemów informacyjnych. Jak widać, mam prywatny interes w tym aby Casus powstał ;)

Llordus [ Generaďż˝ ]

jiser --> zacznijmy od gry planszowej, skonczymy na strategicznej ;) Pamietaj, ze na dowolnej mapie bedziemy mogli sobie z czasem zwiekszac poziom szczegolowosci, w tym informacje o 10 tonowych mostach itd. Niemniej takiemu np. Pejotlowi latwiej bedzie w wersji 2.0 CaSuS-a wprowadzic informacje o mapie, podzielic na hexy i opisac czy sa lasy czy nie, po czym w wersji 3.0 CaSuS-a wprowadzic informacje o mostach 10 tonowych, 20 tonowych i megatonowych ;) niz gdyby mial to wprowadzic od reki. Wszystko co zostanie raz wprowadzone nie zginie nam!, zostanie dla potomnosci, bedzie to sobie mozna upgradowac, exportowac i co tylko dusza zapragnie :)
Do tego my bedziemy mieli poletko doswiadczalne - jak caly system sie zachowuje i obciaza serwer przy pewnej ilosci danych i jak sie to wszystko po prostu uzytkuje :)

P.S. Jezeli wszystko sie uda, to w wersji CaSuS 40.0 bedziemy sobie edytowac kolor barierek na mostach, stopien zielonosci drzew itd ;) a w wersji CaSuS 50.0 bedziemy miec mapy zgodne z GPS-em ;)
To byl tylko taki zart ;)

25.11.2003

15:25

[17]

NeoBerger [ Generaďż˝ ]

jiser --> nie daj sie nabierac podpowiadaczom. Albo robisz cos dobrego od ppoczatku, albo zabawke.
Z czasem straci sie sile i ochote - to raz.
Ale najwazniejsze i po drugie, to nie da sie zabawowego i falszywego z gruntu obrazu operacji przerobic na prawdziwy.
Celowo unikam tu slow planszowka i strategiczna bo nie wiem co to za okreslenia.
Ma powstac gra sztabowa z mozliwoscia uzywania jako podmodulu (nie wazne w jakiej relacji technicznej) gry CM.
Wiec trzeba zrobic to od poczatku profesjonalnie.
Jak maja byc dane o mostku to niech beda. Inaczej znowu cala rzeka bedzie do przekroczenia przez wojsko. A to brednia.
Po pierwsze do przeprawy musi dochodzic droga o odpowiedniej przepustowosci. Po drugie musi byc most o odpowiedniej nosnosci. Po trzecie musi byc odpowiedni brzeg z obu stron. Brak zalesienia gestego itp.
Tylko przy takich zalozeniach jest sens uzywac narzedzi informatycznych. Gdy wybierzemy planszowke to szkoda trudu bo... Jest juz odpowiedni program pod tytulem CYBERBOARD albo system operacyjny do CMBO COCAT 2.

Pzdr

Zajcew trzymaj sie i nie daj sie

Berger

jiser [ generał-major Zajcef ]

Dość łatwo pogodzić oba stanowiska przez zorganizowanie programu wokół systemu przetwarzania informacji. To jest rodzaj leibnicowskiej maszynki logiczne, przetwarzającej dostępne informacje. Takiemu systemowi jest wszystko jedno (z pewną dokładnością co do szybkości pracy ale to w symulowaniu strategii nie przeszkadza) czy ma tych informacji mało czy dużo, czy są one bardziej czy mniej szczegółowe. Po prostu łączy je w z góry zadany sposób.

Na tym polega zaleta zastosowania algebraicznej teorii informacji. I niech mi ktoś powie, że matematyka jest do dupy :D

PiotrMx [ Generaďż˝ ]

jiser-->To wszystko pieknie wyglada, tylko jeżeli mamy korzystać z CM jako podstawy rozgrywania bitew to wyglada, że Casus bedzie jak silnik mercedesa wrzucony do Syrenki. Przeciez CM to prymitywna gra z jeszcze prymitywniejszym edytorem. I jak wyedytujesz mosty o roznej nosnosci, drogi o roznej przepustowosci czy własciwosci dna rzeki w obrebie brodu?
Mysle , ze do rozgrywania kamapanii potrzebny jest ludziom Casusik a nie Casus.

Bergen--> rozumiem że to zupełnie inne uczucie prowadzic do boju armie niz głupia brygade ale jak ty sobie wyobrazasz rozegranie takiej bitwy korzystajac z CM.

Tak poza tym to pomysl mi sie podoba tylko ten mój cholerny sceptycyzm :-)

jiser [ generał-major Zajcef ]

PiotrMX ~~>

Trochę tak (fajne porównanie z syrenką i silnikiem, hieh, Ferrari, ktoś pamięta Nienackiego ;) Ale:
1. Casus nie jest/będzie przywiązany do CM. Tylko modeluje poziom operacyjny, nie zagłębiając się w poziom taktyczny. Ale, może kiedyś :)

2. Trzeba Ci zrozumieć, że wychowałem się na felietonach Bergera (hi :) o teorii wojen oraz na grach fabularnych (ale tych tradycyjnych, nie komputerowych). CM jest strasznie ubogie, ale pewne rzeczy da się wprowadzić. Jeśli posłuchasz dalej, zapoznasz się z kilkoma moimi pomysłami.

adam [ Generaďż˝ ]

ok, jak to jest fragment większej całości to rób jak uważasz:)),
małe pytanko, ile moze ci to zająć ??

Berger sądzę że dywizja ze wsparciem to jest wszystko co mozemy zrobic

adam [ Generaďż˝ ]

ok, jak to jest fragment większej całości to rób jak uważasz:)),
małe pytanko, ile moze ci to zająć ??

Berger sądzę że dywizja ze wsparciem to jest wszystko co mozemy zrobic

jiser [ generał-major Zajcef ]

Moduł Terrain -- problematyka

b) Organizacja map

Na razie rozważamy model T.I. Mapa kampanii dla Casusa (nazywajmy ją operacyjną) składa się z dwóch warstw. Podstawą jej konstrukcji jest mapa topograficzna z opisem wg schematu sztabowego. Jest ona traktowana przez Casusa (czy dokładniej, jego edytor) jako obraz statyczny. To znaczy, wszystkie informacje są zapisane w pliku graficznym, ale system jako taki nie umie ich odczytać. Posłuży ona jako warstwa spodnia. Twórca kampanii będzie edytował warstwę wierzchnią przez przenoszenie na nią z mapy topograficznej informacji, które będą przydatne w przebiegu kampanii. Takimi informacjami są na przykład wydzielone pola bitewne, drogi, mosty, itd.

W wersji minimalnej, konieczne jest tylko wyznaczenie pól bitewnych i prostego opisu co może którędy przechodzić (bez bajerów, jak przepustowość i odległości), jednak system umożliwia wprowadzenie większej ilości informacji przez nanoszenie na warstwę wierzchnią (edytowalną) większej ilości obiektów i ich własności. Opis obiektów jest opcjonalny i niejednorodny (o co chodzi, opiszę przy okazji modułu informacyjnego).

Niebanalnym problemem jest rozsądne wyznaczanie pól bitewnych. Wydaje się oczywiste, że będą one wszędzie tam, gdzie jest się o co bić (lecz nie tylko, patrz Lenino). Sposób w jaki należałoby to wykonać nie jest już taki oczywisty. Część obiektów na mapie jest stanowi naturalne rozgraniczenie (jak w przypadku rzek). Naturalne wydaje się aby stanowiły one rozgraniczenie pomiedzy polami bitewnymi (czy w przypadku siatki heksagonalnej, granicę heksów). Staje się wtedy jasne, kiedy takie rzeki muszą zostać przekroczone (gdy przechodzi się między polami bitewnymi między którymi jest rzeka). Wiadomo, pola bitewne nie mogą być za duże (1- obliczeniowość siada; 2 - dzieją się taktycznie dziwne rzeczy ze jak obchodzenie przeciwnika przy krawędzi mapy). Wróćmy jednak do przykładu T.1.

Przykład T.1
Wiadomo, że taka przeprawa byłaby dobrym miejscem do obrony. Należy zmusić napastnika, aby próbował przedrzeć się przez bagnistą okolicę pod ogniem naszej obrony. Więc gdy dojdzie do rozgrywania tego starcia w CM, rzeka będzie bliżej krawędzi obrońcy, więcej powinno pozostać miejsca od strony podejścia szturmującego. Zatem, ustawiamy pole bitewne aby rzeka stanowiła jej północną (dajmy na to) krawędź. Obrońca został odepchnięty od mostu ale zdążył go zniszczyć. Szturmujący zabiera się za budowanie przeprawy. I znów, naturalne wydaje się wykonanie przez obrońcę kontrataku na przebywające przy rzece wojska inżynieryjne. Zatem, rzeka z na wpół zbudowanym mostem oraz broniącymi się wojskami inżynieryjnymi, powinna się znaleźć na krawędzi południowej (przeciwnej do poprzednio wyznaczonej).

Mamy problem. Więc pole bitewne powinno być na południe czy na północ od mostu ? To most powinien być na jego środku ? Ale jeśli jest na środku to jak ocenić kiedy jednostka znajdująca się na tym polu bitewnym znajduje się po południowej czy po północnej stronie rzeki i w jakim stopniu ? :)

Mimowolnie przyjęte zostało tu jedno założenie. Pola bitewne nie nakładają się. To może zrobić dwa pola bitewne, jedno raczej na północy, drugie raczej na południu od mostu, ale mające wspólną część z mostem ? Ale takie podejście sprawia, że odległość między tymi dwoma polami bitewnymi jest ... nnoo ... jakby to powiedzieć, ... nieduża :) Nieduża w porównaniu z długością dróg między innymi polami bitewnymi, czasem wręcz nieporównywalna. No i jeszcze jedno -- w takim przypadku oddziały stacjonujące na tym południowym polu bitewnym mogą atakować te na północnym. A przecież domyślnym założeniem metody Pejotla jest to, że walczą jednostki tylko z jednego pola.

A może jeszcze inaczej. Pole bitewne jest większe, natomiast do ataku w jedną stronę jest używany inny jego fragment niż w drugą stronę (coś podobnego do map "operacji" w CM) ? Tylko zadbać trzeba, aby któryś z przeciwników nie wykazał się nadmiernym sprytem obchodząc przeszkodę terenową "nie do przejścia" lub wychodząc poza pas natarcia.

Jak wrócę do domu, będę kontynuował rozważania.

jiser [ generał-major Zajcef ]

Do skutku, adamie, do skutku.

Planowałem ten projekt trzy ostatnie lata. Tylko był on za duży, abym mógł go udźwignąć sam. Teraz pomaga mi CM, Llordus, no i (mam nadzieję) Wy. W każdym razie oddaję się Casusowi bez reszty :]

25.11.2003

20:08

[25]

oskarm [ Future Combat System ]

Jiser --> ale ty robisz problem z tymi mapkami :-)... najprosciej jest zrobić tak że rzeka płynie mniej więcej przez środek heksu, nie trzeba wtedy przesówać terenu walki.

jiser [ generał-major Zajcef ]

Dobra jedziem dalej ;)

Moduł Terrain -- problematyka

Ad. b) Organizacja map

Nie zauważyłem, że nawet przy rozwiązaniu polegającym na konstruowaniu trochę większych pól bitewnych, nadal pozostaje problem: po której stronie rzeki bez mostu stoją czołgi ?

Efekt tych rozważań wydaje mi się taki, tam, gdzie będą pojawiać się przeszkody terenowe i miejsca umożliwiające ich przebrnięcie (na przykład teren górski i przełęcze), niezbędne będzie wprowadzenie podziału drobniejszego niż pole bitwy. Tzn. gdy pole bitwy jest przedzielone rzeką, i znajduje się na nim most, to jednostki, dla których ten most się nie nadają muszą mieć zadeklarowane z której strony rzeki się znajdują.

Jaki to ma wpływ na rozgrywanie w CM ? No cóż, nie można w CM zabronić części jednostek przekraczać mostu (czy ktoś próbował przechnąć Konigstigera lub Elephanta przez drewniany mostek ?), można jednakże nie pozwolić graczowi na przejście takich jednostek na pole po drugiej stronie rzeki. Jeśli gracze są obowiązkowi (znowu wkracza RPG), to nie będą tego robić także w trakcie pojedyczej bitwy w CM.

Przykład T.2

Pojawia się tam pomysł atakowania pociągu czy kolumny transportowej, czy też osłony takich szlaków. Ależ, jak to zrobić skoro one są "w ruchu" czyli pomiędzy polami, a walki odbywają się tylko na polach ?

Uogólniłbym trochę ten problem. Chodzi wogóle o możliwość prowadzenia bitew na polach o niezdefiniowanych granicach. Wyobraźmy to sobie tak. W przykładzie pierwszym chodziło o kontrolę nad mostem. Most ma bardzo konkretną lokalizację, i jest się o co bić (np. o wzgórze, które panuje nad okolicą tego mostu lub o przedmoście). Gdy zaś chodzi o szlak drogowy, trudno powiedzieć, o które miejsce na jego 10-kilometrowym odcinku chodzi. W pewnym sensie jest to problem ekstensywności i intenstywności pojęć (od ang. 'concept defined by extension or intention'). Pojęcie ekstensywne to takie, które można wskazać, namacalne (co nie oznacza, że fizyczne). Pojęcie intensywne to takie, które wymaga opisu. Przykład matematyczny ‹x1, x2, x3) to zbiór definiowany ekstensywnie, ‹x : x>5› to zbiór zdefiniowany intensywnie. W modelu Pejotla występują takie obszary nieokreślone, oznaczane są owalami (określone - prostokątami).

Pomysł jest następujący. Są dwa rodzaje pól - "określone" i "nieokreślone". Gdy dojść ma do bitwy na terenie "nieokreślonym" bierze w nim udział jedynie pewna (być może proporcjonalna) część sił. Gdy na przykład nacierający próbuje "przemycić" tędy kolumnę piechoty zapakowanej na ciężarówki, a obrońca wysyła w tamten rejon jednostkę zwiadu samochodowego, efekt zależeć będzie od wydanych przez graczy rozkazów. Jeśli ów obrońca, zdecyduje się "obstawić" całą drogę, ma pewność, że trafi na tą kolumnę, ale będzie walczył jedynie częścią swoich samochodów pancernych. Jeżeli postanowi zrobić pułapkę w jednym miejscu (nie rozdrabniając się), będzie walczył całością ... o ile zdąrzy ustawić pułapkę zanim kolumna nadjedzie :)

Pomysł nie wydaje się bardzo skomplikowany. W implementacji wyglądać będzie to tak, że obszary nieokreślone znajdować będą się na środku krawędzi, ale wyłapywać będą zdarzenia z całej krawędzi. Jak mi się będzie chciało, zrobię rysunek poglądowy.

jiser [ generał-major Zajcef ]

O żesz cholera
w przykładzie matematycznym powinno być:
‹x1, x2, x3› oraz ‹x : x>5›

oskarm ~~>
Ja Ci nie robię problemu z mapkami. A jeśli chcesz wiedzieć dlaczego rzeka na środku pola bitewnego sprawia kłopoty, czytaj dokładniej.

jiser [ generał-major Zajcef ]

A niech to ... GOL mnie nie lubi ;)
tam gdzie są te zbiory, na zewnątrz powinny być nawiasy zbiorów, czyli "wąsate", zamiast znaków < i >

jiser [ generał-major Zajcef ]

Aha .. jeszcze jedno:
poszukuję osoby, która odszuka mi (na sieci lub we własnych komputerowych szpargałach) możliwie zróżnicowaną (o różnorodnym terenie) mapę topograficzną ... najlepiej z opisem sztabowym (czyli z parametrami obiektów na mapie, jak wspomniana szerokość, nawierzchnia i przepustowość dróg, nośność mostów, gęstość zadrzewienia, itd).
Będę wdzięczny za pomoc.

PiotrMx [ Generaďż˝ ]

Adam--> dywizja z hakiem to max
Oskar--> te ataki przez rzeczki to rzeczywiscie kłopot

Jiser--> masz brzydki zwyczaj strofowania i ustawiania rozmowcow. Rozumiem ze ja prosty lamer co wie najwyzej gdzie jest wtyczka od mojego kompa nie bedzie dla Ciebie partnerem do rozmow na temat tworzenia symulatora strategiczno/operacyjnego pola walki. Dlatego postaram sie pohamowac z jakimis radami i jest to moj ostatni post na ten temat.
Chwała ci za to, ze podjałes sie tego ale stopien komplikacji jaki proponujesz wydaje mi sie zbyt duzy. Moze znajdzie sie dwoch GD ktorzy beda sie chcieli w to bawic ale reszta raczej chce rozgrywac szybkie bitwy. No poza tymi co graja tylko PBEMY.
Co do rzeki to IMO atakujacy ma waska strefe rozstawienia i zaraz przed nia rzeke. Obrona rozstawia sie w szerokiej strefie rozstawienie. Ale jak robilem mapki do WB to rzeczywiscie byl tu problem.
Nie zrozum ze Casus mi sie nie podoba. Jest OK ale nie dla CM i wiekszosci graczy ktorzy chcieliby pograc w WB.
Raczej sprobuj opchnac go Amerykanom. Niech potrenuja przed przyszlymi walkami w Iraku.
Oni maja cala mape swiata w wersji elektronicznej i jak chca sobie potrenowac jakas potyczke czy operacja wycinaja sobie potrzebny kawalek i graja. A my z naszym CM mamy problem z głupia rzeka. potem dojda problemy z okrazenie i atakiem z dwoch stron.

jiser [ generał-major Zajcef ]

PiotrMX ~~>

Piotrze, skąd te uwagi ?? Musiało zajść jakieś nieporozumienie. Nikogo nie strofuję i nie ustawiam. Jak już wielokrotnie pisałem, wątek ten i sąsiedni założyłem właśnie po to, abym mógł jes usłyszeć. Znacie się na CM i na realiach pola walki lepiej ode mnie. Chciałbym z Wami na ten temat podyskutować.

Doprawdy, czy kogoś ganię za wypowiedzi ? Chyba trudno mi przyjąć ton bardziej spokojny i otwarty, bo zupełnie sympatyczny słyszę ton w Waszych wypowiedziach. Aż do Twojej. Hmm ... mogło chodzić o moją odpowiedź skierowaną do Oskara, ale w takim razie jest to nieporozumienie. Nie wypowiedziałem tego chcąc jego lub kogoś innego zniechęcić. Przez Forum nie słychać w jaki sposób kto co mówi, i z jakim nastawieniem. Spróbuj wyobrazić sobie inne sposoby, a nie tylko takie jakie zapanowały między grdyką, PERem, Pejotlem Bergerem i Dw4rfem.

Cóż. Trudno mi zatrzymywać tu siłą kogoś, kto tu być nie chce. Ale wszystkie Wasze uwagi (na temat) są mile widziane. Dlatego nie podoba mi się Twoja wypowiedź, jako osoby trzaskającej drzwiami na odchodne. Zapewne na moją wypowiedź rzucił cień klimat utarczki na słowa między wyżej wymienionymi panami. Ale prosiłbym nie przynosić go tutaj.

To tyle co miałem do powiedzenia na ten temat. Oczekuję wyjaśnień z Twojej strony.
Pozdrawiam, Zajcef.

jiser [ generał-major Zajcef ]

Miało być:
Spróbuj wyobrazić sobie inne sposoby wypowiedzenia tego zdania, a nie tylko takie, jakie zapanowały między grdyką, PERem, Pejotlem Bergerem i Dw4rfem

PiotrMx [ Generaďż˝ ]

Zajcef--> fakt, że cos mnie dzisiaj nosi i zamiast sie napić musze czekać pod telefonem.

Powtorze sie ale uważam , ze probujesz do Syrenki wepchnac 2,5 litrowy silnik od merca. Ale to nie da rady. Albo syrenka sie rozpadnie albo bedziesz musial ograniczyc do jednego cylindra.
No ale ja zawsze ceniłem sobie prostotę i stawiam ja ponad realizm. I wydaje mi sie, ze graniczenia jakie narzuca CM sa zbyt duze a sama gra ma tyle umownosci ze nie ma potrzeby tworzyc do niej takiego symulatora jak Casus.

Szymon [ Konsul ]

To tyle co miałem do powiedzenia na ten temat. Oczekuję wyjaśnień z Twojej strony.

Ty chyba jesteś wojskowym? :)

Pomysł ogólnie robi bardzo pozytywne wrażenie.
Model wydzielonych pól walki wydaje mi się trochę dziwny, nie bardzo rozumiem dlaczego gracz miałby np. budować przeprawy przez rzeki tylko w zgóry określonych miejscach (tylko mni nie pisz że mam dokładniej poczytać)
Może powinienieś wykonac jedną przykładową mapę żeby rozwiać wątpliwości. Na przykład na bazie jednej z map WB.
Lepszy jest chyba model heksagonalny. Może dałoby się umieszcać jednostki na więcej niż jednym heksie, wtedy przy małych heksach uzyskałbyś efekt zbliżony do mapy ciągłej (jak bardzo to kwestia parametrów). A przy okazji możnaby uzyskać jendostki mniejsze, większe lub o roznych kształtach (np. Twoje ulubione pociągi ;) ).

Sam mam za sobą kilka projektów które planowałem z rozmachem z których nie zawsze wyszło to co miało wyjśc, więc mam pewne obawy czy uda Ci się to zrealizować. Ale trzymam kciuki.
Radzę skupić się na tym co sprawia największe problemy prowadzącym kampanie (to ich musiasz zapytać jakie mają problemy). Początkowo może byc tak że gracze sami pilnują przestrzegania reguł a system pozwoli im na wprowadzenie i wymianę danych, umieszczenie jednostek na mapie i zaplanowanie posunięć.
Wokól działającego rdzenia łatwiej będzie zgromadzić ludzi których ogarnie entuzjazm i zaczną tryskac pomysłami :)

PiotrMx [ Generaďż˝ ]

Szymon--> swiete słowa. Tylko odnosze wrażenie, że Zajcew robi Casusa i tak przy okazji wpadł na pomysł, że moze dałoby sie go zaimplantowac do WB. Obasadzanie jednostką kilku hexow mija sie z celem. W WBBO najmniejsze jednostki to kompanie piech i plutony czolgow. Jak chcesz takie jednostki dzielic na kilka hexow. Moze w realu czolg i pluton z mg42 osloni front o szerokosci 1,5-2km ale w grze to sie nie sprawdzi. Potrzebne jest odpowiednie nasycenie bitwy jednostkami. Co najmniej 1000-2000 punktow. I te punkty inaczej liczymy bo sporo przeznacza sie na pojazdy czy inne jednostki ktorych zwykle w QB nie stosujemy.
W WBBO zastosowalem odwrotna metode. Do skladu jednostek bioracych udzial w bitwie mozna dorzucic jednostki rezerwowe bedace w odpowiedniej odleglosci. Jezeli byly zachowane odpowiednie warunki to gracz mogl wybrac ktora bitwe wesprzec rezerwowymi jednostkami.

Nie wiem co Ty na to , ale pbema zachowalem. Wiedzialem ze wrocisz :-)

grdyka_ [ Pretorianin ]

Szymon --> pisze się "w z góry"

Szymon [ Konsul ]

Nie chcę dzielić jednostek tylko podzielić hexy na mniejsze. Jeden obecny hex odpowiadałby mniej więcej czterem nowym. Pole bitwy obejmowałoby kilka hexów

Szymon [ Konsul ]

grdyka_ -> 1:1

jiser [ generał-major Zajcef ]

PiotrMX & Szymon ~~>

1. Ja nie tworzę Casusa dla CM, tylko przy okazji CM. Jak pisałem, jest to efekt dłuższych prac nad tym tematem.

2. Rozumiem Waszą troskę o "sprowadzenie mnie na ziemie". Ale bez pewnej dozy odwagi nie uda się zrobić niczego. I jak tu pogodzić chęć wysłuchania innych oraz potrzebę odrzucenia sugestii ograniczenia skali ? Zgadzam się w tym przypadku z Bergerem -- zawsze trzeba stawiać poprzeczkę trochę wyżej niż przeciętność, ponieważ (po pierwsze) trzeba myśleć rozwojowo i nie można zamykać koncepcji zbyt wąską realizacją i (po drugie) z czasem rezygnuje się z pewnych rozwiązań i poprzeczka idzie w dół. Jeśli kogoś to nie bawi, ten projekt w żaden sposób go nie angażuje.
Chciałbym jednak znaleźć kilka osób, które nie uważają pomysłu za moją megalomanię i nieprzydatne komplikowanie WB.
Postaram się jednak jeszcze mocniej trzymać realiów (organizacji projektu programistycznego).


3. Może źle zostało to odebrane (zaraz zostanę znów posądzony o zbyt dalekie plany) ale to nie ma być wybór między modelem T.I a T.II, bo oba zostaną zaimplementowane. Przyczyna jest prosta -- oba są stosowane do WB. Ale wszystko w swoim czasie -- wybór ma polegać na tym, który zostanie zaimplementowany jako pierwszy.
Owszem, przyszedł mi dziś do głowy pomysł z siatką heksagonalną, w której pole jest mniejsze niż jednostka. Ale jak przed chwilą powiedziałem, na razie jest co innego do realizacji (konkretnie T.I)

4. Ci, którym nie podoba się rozmach, zdziwią się jak usłyszą moje plany dotyczące modułu information. Tam będzie dopiero cyrk ;)

jiser [ generał-major Zajcef ]

Szymon ~~>
Aha .. zapomniałem dodać, że nie da rady zrobić "dokładnego" (tzn. samopowielalnego) podziału siatki heksagonalnej ponieważ sześciokąt foremny nie jest rozkładalny na sześciokąty foremne. Jedynymi takimi figurami foremnymi są trójkąt i kwadrat.

PiotrMx [ Generaďż˝ ]

Zajcew-->jak to zrobisz i da sie tym grać będziesz wielki. I to bez picia mleka.
Problem tkwi w tym, ze Casus nie powstaje scisle dla CM.

Szymon [ Konsul ]

Aha .. zapomniałem dodać, że nie da rady zrobić "dokładnego" (tzn. samopowielalnego) podziału siatki heksagonalnej ponieważ sześciokąt foremny nie jest rozkładalny na sześciokąty foremne. Jedynymi takimi figurami foremnymi są trójkąt i kwadrat.

A czy ja mówię że można? Czytaj dokładnie :P

jiser [ generał-major Zajcef ]

Szymon ~~>

Pisałeś "podzielić heksy na mniejsze, jeden obecny odpowiadałby mniej więcej czterem nowym", a ja powtarzam, że nie da się tak podzielić heksu aby powstały mniejsze heksy.

Co do rozwiązań. Nie zmienię decyzji co do wyboru modelu Pejotla na pierwszy ogień. Z jednej strony mówicie, że Casus jest zbyt silny i zbyt drobiazgujący, z drugiej, że przeprawy musiałyby być tylko w zgóry określonych miejscach. Na siatce heksagonalnej też tak jest :)

Model ma być na tyle silny aby udźwignąć wszystkie pomysły, które stworzyłem dla CM RPG. A sposoby realizacji tych pomysłów mam w głowie ... ojej, może i CM jest ubogi, ale przecież do tego wystarczy odrobina inwencji.

Trzeba doceniać to co się ma. Myślę, że zbyt krytycznie podchodzicie (aby nie było znowu nieporozumień, nie krytykuję niczyjej wypowiedzi, nie próbuję nikogo uciszyć, myślę jednak, że trzeba Wam trochę optymizmu; nawet jak się Casus nie uda, to przecież nic Wam się nie stanie, bo niczym nie ryzykujecie; optymizmu trochę więcej, panowie ;)

PiotrMx [ Generaďż˝ ]

zajcew--> ale nam zalezy zeby Ci sie udalo. Bo jak nie to znaczy ze juz nigdy sie nie uda zrobic cos sensownego z CM.
Dlatego tak troszczymy sie o Ciebie.

26.11.2003

01:25

[45]

jiser [ generał-major Zajcef ]

PiotrMX ~~>

Taak, troszczycie się ;)
Czyli jednak się nie obraziłeś i nie zrezygnowałeś z zaglądania tutaj ?

Pozdrawiam z sympatią, Zajcef.

26.11.2003

01:37

[46]

Rah V. Gelert [ Generaďż˝ ]

jiser - jesli mialbym jakies watpliwosci wczesniej to teraz mi je rozwiales - jestes matematykiem ;)

Do tej pory pamietam jak mi przez pol roku walkowano co to jest widmo amplitudowe, potrafilem to policzyc, przytoczyc definicje itp. Ale dopiero jak na elektonice zobaczylem do czego sie to stosuje zrozumialem co to jest ;)

Dzielisz wlos na czworo, komplikujesz zalozenia bardzo - nie wiem jak inni ale ja juz sie potrochu w trym co piszesz gubie ( tu sa prosci zolnierze a nie matematycy ;) ) - ale moze tak trzeba.

Mam nadzije ze wiesz co robisz i licze ze to doprowadzisz do konca. :D

Llordus [ Generaďż˝ ]

jiser --> tak sobie mysle, ze moze troche ograniczmy wypowiedzi techniczne, taki np graf przejsc - chlopaki nie potrzebuja informacji technicznych o organizacji tego cuda :), im wystarczy wiedziec, ze chca przejsc z pola nr 2 na pole nr 15 i stoczyc tam bitwe z przeciwnikiem :) Natomiast to jest nasze zmartwienie jak im to umozliwic w aplikacji. To ze sobie zrobimy graf przejsc, do tego walniemy jakies wagi na poszczegolne polaczenia i zastosujemy pare algorytmow poszukiwania drogi w grafie zamknietym z wagami nikogo poza nami nie interesuje :)

do wszystkich --> nawet jak sie przewinie troche szczegolow technicznych to sie nie zrazajcie :) Matematycy tak czasem maja, ze ciezko im rozgraniczyc rzeczy trywialne od naprawde trudnych i skomplikowanych :)

Szymon [ Konsul ]

Mniej więcej, Zajcef, napisałem mniej więcej. Masz skłonności do skupiania się na nieistotnych szczegółach.

pozdrawiam, bez sympatii

jiser [ generał-major Zajcef ]

Cóż ...
widzę, że publikacja czegokolwiek na Forum mijała się z celem.

1. Wątek był tylko konstrukcyjny. Kogo to nie interesowało, nie musiał się wypowiadać. Kto nie rozumiał, nie musiał się wypowiadać. Kto nie miał nic konkretnego do powiedzenia (nie ogólną krytykę), też nie musiał się wypowiadać. Prosiłem, aby nie dawać off-topiców. Co prawda, sam zacząłem takie publikować licząc na to, że będzie można moderować ten wątek i zdejmować OT po 24h.

2. Biorąc pod uwagę powyższe, proszę nie mieć "tym porąbanym matematykom" za złe, że skoro wątek jest właśnie po to, to próbują coś na ten temat przedstawić. Skoro nie ma zainteresowanych, temat zamknięty.

3. Szymonie-bez-sympatii. Gdy piszesz, że heks da się podzielić na mniejsze heksy, jesteś w błędzie. Gdy zasłaniasz się zwrotem "mniej więcej" oznacza to tylko to, że nie umiesz precyzować swoich pomysłów. A jeśli uważasz, że "skupiam się na nieistotnych szczegółach", to przypomnij sobie, że ... (patrz punkt 1) oraz że zaproponowałeś to jako rozwiązanie. Rozwiązania mają to do siebie, że mają szczegóły, w któych zwykle siedzą diabły. Pozdrawiam bez sympatii.

4. Jeśli kogoś obraziłem swoją przemową, bo akurat był zainteresowany i nie robił głupich uwag, to przepraszam i zapraszam na stronę domową projektu. Niniejszym zamykam ten wątek, nie widzę sensu się tu dalej produkować.

26.11.2003

12:06

[50]

stary [ ZiP ]

Panowie,

Bardzo podoba mi się pomysł stworzenia narzędzia do WB, jednak obawiam się o jego losy.

Nie jestem matematykiem, ani programistą, ale wiem, że często ambitne projekty kończą się fiaskiem z powodu drobnych wydawałoby się nieporozumień. Często jest to zły przepływ informacji między ludźmi, czasami ludzie mają dość i chcą "tak czy siak" zakończyć projekt, a czasami kierownik projektu po prostu nie ogarnia całości i traci panowanie nad sytuacją.

Proponuję, abyście podzielili projekt nie tylko na obszary funkcjonalne, tak jak to zrobił jiser, ale także na etapy czasowe, w miarę kończenia których rosłaby funkcjonalność gry.

Przykładaowy (nie bijcie, nie jestem programistą!) podział na etapy dotyczące ruchu (dotyczy chyba obszarów funkcjonalnych T,U,E,O,L):
I każdy oddział może ruszać się tylko o 1 hex/turę
II oddziały poruszają się zgodnie z ich mobilnością (zmotoryzowane szybciej od piechoty)
III dodany wpływ terenu na ruch jednostek (np. zmotoryzowane nie mogą wejść w góry)
IV dodany wpływ warunków zewnętrznych na ruch (ostrzał, pogoda, korki drogowe)

W tej sposób:
1. dość szybko widać będzie efekty pracy
2. po zakończeniu etapu prac testerzy będą mogli wnosić uwagi/propozycje udoskonaleń do następnych etapów
3. projekt się nie znuży
4. mniejsze części będą łatwiejsze do zintegrowania z pozostałymi i wiadomo będzie gdzie coś nie trybi
5. głównodowodzący będzie miał lepsze rozeznanie w sytuacji i możliwościach poszczególnych ludzi (np. człowiek A skończył już III etap, a człowiek B ma nadal problemy z II etapem...)

26.11.2003

14:35

[51]

oskarm [ Future Combat System ]

Jiser --> w żaden sposób nie czuję się obrażony :-). Przeczytałem ponownie i ... jeszcze jeden twój post i teraz sprecyzuje. Ja myślę w mojej wypowiedzi o CM. Tam w WB sobie radziliśmy bez większych kłopotów z podziałem mapy. Co prawda trzeba było trocheto naginać, ale w skali CM rzadko zdarzają sią takie sytuacje (mi się to nigdy nie zdarzyło) żeby przesunięcie strefy o 100m powodowało jakieś perturbacje majacy wpływ na rozgrywkę. Dla precyzowania pewnych postanowień gracza była tabelka gdzie mógł on dokładnie opisać o co mu chodzi i przy wyznaczniu stref było to uwzględniane. IMo myślący sędzia z podziałem mapy sobie zawsze poradzi.

Co do zasadzek, to problem w wypadku CM został rozwiazany w zasadach WBBB:

"Zasadzka:
Gdy jeden z graczy poruszający się w kolumnie marszowej trafi na pole na którym znajduje się przeciwnik (który nie jest w kolumnie marszowej) wtedy organizowana jest zasadzka. Technicznie jest to rozgrywane w taki sposób: ST gra pierwsze tury z graczem organizującym zasadzkę. Wszystkim jednostką które wpadają w zasadzkę ST wydaje rozkaz move po drodze, po której się poruszają. Walka jest przekazywana graczowi, który wpadł w zasadzkę dopiero w chwili gdy AI kompa wykryje siły wrogie lub gdy padnie pierwszy strzał przeciwnika. Jeżeli wojska wpadające w zasadzkę składają się z kilku różnych rodzajów Sędzia pyta się wpadającego w zasadzkę (o ile będzie to technicznie możliwe) jakiej kolejności były ustawione w kolumnie."

W wypadku gdy kolumna jest długa, kolejne jednostki wchodzą na mapę jako posiłki.

CM jest w duzej mieże ograniczone, i z tego powodu nei trzeba zbytnio komplikowac samego programu. IMO lepiej jest poświęcic czas na przygotowanie możliwie dobrego heksagonalnego modelu ruchu (wpływ terenu, typu jednostki, przpustowości dróg itd.) niż bawić się w wyciaganie danych z plików z samej gry.
Mi najbardziej zależałoby własnei na systemie ruchu na mapie połaczonego z wyświetlaniem stanu liczbowego jednostki i rozkazów "nie ruchowych" jej wydanych.

Co do nadmiaru matematyki ...
To sporo jest tutaj inżynierów lub przyszłych inżynierów (3 rok automatyki i robotyki w toku), wiec chyba nie jest tak źle z tajemna wiedzą :-)
Dla humanistów i prawników mam małe motto jednego z moich kumpli: "Maszyny będą rządzić wami ...... a my maszynami" ;-)

26.11.2003

14:55

[52]

Rah V. Gelert [ Generaďż˝ ]

jiser - nigdzie nie napisalem "porabany matematyk", co wiecej zetknalem sie ciut z wysza matematyka i dzieki niej wiele spraw daje sie latwiej rozwiazac.
Niestety nie wszyscy potrafia myslec az tak bardzo abstrakcyjnie (np. ja) zeby wszystko w niej zrozumiec. Mi bardziej przemawiaja do wyobrazni konkretne zastosowania. Dlatego tez chyle czola przed ludzmi potrafiacymi dyskutowac o np rzutowaniu czegos w 11 wymiarach, dla mnie to jest magia.

Jako o.m.c. inzynier do problemu podchodze od strony praktycznej - robie cos prostego i patrze jak to dziala, ulepszam porawiam w miare potrzeb. Owszem czasem zdarzy sie sytuacja ze trzeba wszystko zaczac od poczatku bo to co zrobilem nie da sie juz rozbudowac.

To co opisujesz przeraza mie swim ogromem i zalozeniami stad moj post. Ale jesli Ty to potrafisz ogarnac to jesk OK.

26.11.2003

15:37

[53]

Da real Odi [ Konsul ]

zajcef ---> wybacz, ze sie wtracam, ale - na milosc Boska! - nie obrazaj sie!!! Skoncz ten projekt, bo to naprawde moze byc przelom! Zycze powodzenia, wytrwalosci i...mimo wszystko - wiekszego luzu w podchodzeniu do wypowiedzi innych. Pozdrawiam! (ja zawsze z sympatia...;)))

jiser [ generał-major Zajcef ]

I to, co zaprezentował stary zip, wydaje mi się właściwym sposobem dyskutowania. Dlatego proszę wziąć przykład z postów zamieszczonych tu przez Zipa, Bergera, czy Oskara.

Rah & Odi ~~>
Nie Ty mówiłeś o "porąbanych matematykach" więc nie bierz tego do siebie. To Berger pisał o "brudnych i śmierdzących matematykach", a jeszcze dwie osoby z politowaniem powiedziały mi, abym sobie "odpuścił". Nie obrażam się, ale ile można takich rzeczy wysłuchiwać, zanim się człowiek zdenerwuje.

Opisuję tu to wszystko, bo może ktoś mi powie w pewnym momencie: "słuchaj, ale w takim przypadku ten model się łamie" albo "a może by spróbować tak, wtedy dostajemy tu prostszy system, ale tu nam siada, co o tym myślisz?"

Uwaga: Chciałbym się dowiedzieć czy jest chociaż jedna taka osoba. Jeśli nie, to nie mam po co ciągnąć tego wątku.

klod & stary & Rah ~~>
W początkowych wersjach wiele części wprowadzających ciekawe rozwiązania, będzie miało "zaślepki". Będzie przewidziane miejsce na nie, ale nie będą działać.

To, co stary opisuje o wpływie czasu na ruch, to, przy tym podziale funkcjonalnym, współdziałanie modułu clock oraz rules. Sposób mierzenia czasu to clock, natomiast reguły dozwalające coś działać w określonym odcinku czasu to rules.

Ponadto, klod, w liście do mnie, zaproponował coś, co ja przewidywałem od początku. Chodzi o możliwość konstrukcji systemu zasad gry podczas kampanii wraz z jej konstrukcją. Po to jest ten cały podział funkcjonalny aby można było: albo dobierać odpowiednie wersje każdego z modułów (implementujące różne rozwiązania) albo przez moduł rules i zewnętrzne pliki skryptowe edytować owe zasady.

To all ~~> Czy moglibyśmy przejść do szczegółów ? Bo na razie obracamy się wokół tematu czy jest po co Casus tworzyć i jak dużo niebezpieczeństw czycha na koordynatora projektu. A te tematy uznałem (przynajmniej u siebie) za zamknięte wraz z otworzeniem tego wątku.

klod____ [ Generaďż˝ ]

jiser--> oczywiscie ze jest po co

co do szczegółów to ja także na nie czekam

jiser [ generał-major Zajcef ]

Wbrew pozorom, ostatnie 2 tygodnie ciszy w sprawie projektu 'Casus' nie oznaczają, że projekt upadł. Trzeba mi było jeno zająć się sprawami bliższymi serca i portfela. Zaiste ... dziwne połączenie.

Z przyjemnością mogę ogłosić, że potencjalny skład zespołu przy projekcie jest zarówno całkiem duży, jak i urozmaicony. Chęć aktywnej współpracy wyrazili:
- ja (projektant, programista modelu, koordynator)
- Llordus (projektant, programista sieciowo-bazodanowy)
- RM (programista środowiska, projektant własnego modelu środowiska grafikicznego)
- Rah V Gelert (programista?, recenzent)
- Jaskiniowiec (konsultant d/s systemów dowodzenia)
- klod (grafik, konsultant d/s praktyki WB)

liczę na współpracę, choć nie jestem pewien czy wyrażą zgodę:
- Ursus (konsultant d/s realiów historycznych)
- Ścibor (grafik/rysownik)

W przeciągu najbliższych dwóch-trzech dni postaram się powysyłać prośby o "obiecane" materiały, założę wreszcie stronę projektu Casus, i zacznę tam systematyzować posiadane informacje.

Lt Ursus [ Generaďż˝ ]

jiser--.Byłem długo poza domem więc uciekł mi ten wątek. Dobrze że powrócił na forum. Chętnie pomogę w pracach nad projektem w miarę posiadanych informacji. Lada moment będę miał trochę czasu myślę że póżniej zawsze uda się coś wygospodarować na współpracę w tworzeniu Casusa. Widzę że projekt jest naprawdę ambitny i uważam że jak już tworzyć to raczej coś złożonego. Chcąc mieć pewność że się skoczy na 3 m lepiej próbowac skakać na 3.5m. Nawet jak nie wszystko się uda w szczegółach to może powstać coś naprawdę wartościowego a rozgrywki wejdą na nowy strategiczny poziom..

RMATYSIAK [ Konsul ]

Posiadam teraz cos co jest zaczatkiem enginu 2D. Uruchamia sie w jedynej slusznej rodzielczosci 1024x768. Posiada meni, wczytuje mape mozna ja skalowac przesuwac, sa na niej jednostki ktore odpowiadaja nawet na to jak sie najedzie na nie myszka. Na wiecej nie mam czasu.
Poz R.
Ps jakby ktos chial pomoc to prosze o maila lub GG.

16.01.2004

22:06

[59]

sprezynka [ Pretorianin ]

~~> zajcef

Dotarłam, przeczytałam, zrozumiałam (sic!)

Nnooo.. może to ostatnie to nie w 100% <sapanie maszyny myślącej> ;), bo ze mnie ani matematyk, ani CM-owiec, ani znawca realiów. Ale da się to zrozumieć i podoba mi się. Czekam na następne moduły i na komentarze ludzi, którzy potrafią powiedzieć na ten temat coś więcej ode mnie :)

sprezynka [ Pretorianin ]

To all ~~>

Panowie, mam nadzieję, że ten wątek nie zaginął w Waszych umysłach? Może ktoś ma jeszcze jakieś komentarze po miesiącu przerwy? Ja chętnie poczytam ;)