INNE Projekt: skrypt New World Disorder

[LaChupacabra]

Ostatnio przy okazji pojawienia się nowego przemysłu (FIRS) na Mapie Polski autorstwa pAtera, padła propozycja dodania do niej skryptu, który zmieniłby okrutnie prostą zasadę "sześciu stacji", która w grze decyduje o szybkości rozwoju miast (napisałem o niej już tutaj, tutaj, tutaj i tutaj), na taką, która dodawała by większego realizmu, nie była tak banalna i nadawałaby znaczenie dostawom żywności, towarów, czy materiałów budowlanych.
Jest już kilka skryptów, które zostały zbudowane na podobnych założeniach. Przetestowałem wszystkie te, które mogłyby być warte uwagi: Real Growth, City Controller, Renewed City Growth, Balanced City Growth, City Growth Limiter oraz City Buildier (ich opis pod kątem tego scenariusza znajdziecie >tutaj<). Wyszło jednak na to, że każdy z dostępnych miał jakieś mniejsze albo większe mankamenty. A to miasta rosły zbyt łatwo lub zbyt szybko, a to bezwzględnie domagały się dostarczania wszystkich produktów wymagając przez to od gracza, aby zajmował się wszystkim. Pojawiały się też inne problemy, ale już mniejsza o to.
Ostatnim ze skryptów, który zaprezentowałem w opisie był...

New World Disorder

O nim napiszę kiedy indziej Na razie mam po dziurki w nosie wszelkich skryptów...

Ten skrypt tak naprawdę nigdy nie istniał, zaś grafika panelu miasta jest tylko kolażem zrobionym w Paint'cie Liczby w nim ukazane nie są jednak przypadkowe. Ta grafika powstała z pomysłu, no i przede wszystkim po to, aby być może kogoś, kto potrafiłby napisać odpowiedni kod, nią zainspirować. U mnie niestety cienko w tej kwestii. Nie jest to jeszcze w 100% przemyślane, nawet nie wiem czy wszystkie z założeń są możliwe do zrealizowania. Zamieściłem to jednak ze względu na presję jaką zaczął wywierać na mnie Milek7, z którym poruszyłem wcześniej ten temat

Aby nie wyrywać postów z innego tematu (Mapa Polski pAtera):

A ten NWD, to prawdziwy czy tylko makieta?

Ten NWD to skrypt, o którym Ci mówiłem. To już jego trzecia lub czwarta wersja. Na razie jest zapisany w programie Paint w formacie PNG - wymagałby "jedynie" odpowiedniej konwersji do NUT'sa.
Mógłbym go dokładnie opisać, jak by miał działać, wszelkie zależności, co z czego wynika i dlaczego, ale już ktoś inny musiałby te wszystkie teorie przerobić na kod

Heh... miałem nadzieję odpocząć od tej całej skryptologii.

Zaczynam prace nad NWD
EDIT: Jest postęp
http://openttd-polska.pl/attachment.php?aid=745

Ponieważ ruszyły już pierwsze prace nad skryptem, a młody Frankenstein zaczął się niemrawo, ale jednak poruszać, postanowiłem założyć nowy wątek, który będzie poświęcony dalszym pracom nad nim. Kto wie, może urosną mu jeszcze ręce i nogi...

A więc...

Na razie jedynie z grubsza zarysuję założenia:
1. Głównym założeniem skryptu jest swoboda w sposobie rozwoju miast, aby nie było konieczności budowania całych wielkich sieci przemysłowych tylko po to, by miasta mogły się rozwijać.
2. "Wzrost miasta" byłby jedynie informacją o ile miasto zmieniło swoją populację. Ale! Wskaźnik lepiej aby był średnią z ostatnich 12, może nawet 24 miesięcy. W ciągu miesiąca populacja pomimo szybkiego wzrostu często się chwilowo kurczy - to byłoby niekiedy nawet bardzo mylące.
3. Bezrobocie wyznaczałoby tempo rozwoju miasta. Maksymalny jego poziom oznaczałby brak rozwoju miasta - byłby ustawialny i de facto oznaczał poziom trudności. Na poziom bezrobocia wpływ miałyby wszystkie pozostałe elementy. Ich znaczenie byłoby ustawialne.
A1. Komunikacja miejska - te 49% oznaczałoby, że właśnie taki procent spośród "wyprodukowanych" przez miasto pasażerów i poczty zostało przetransportowanych (liczone razem). Podobnie liczone jak w skrypcie CGL z tym, że tutaj jest to wpływ a nie blokada. Oczekiwany procent transportu byłby ustawialny w parametrach. Im bliżej wskaźnik byłby tej wartości tym większy wpływ na redukcję bezrobocia. Przekroczenie wyznaczonej wartości dalej zmniejszałoby bezrobocie, ale już w coraz mniejszym stopniu.
A2. Komunikacja międzymiastowa - 28 z 327, czyli 8,5% oznaczałoby ilość miast względem ich ogólnej liczby, z którymi dane miasto ma aktywne połączenia (ocena połączenia). Wszystkie niezbędne dane powinny być dostępne, pytanie tylko czy skrypt jest w stanie je odczytać.
A2'. Alternatywne rozwiązanie - jeśli powyższe okazałoby się niemożliwe lub zbyt trudne - aby podział na rodzaje komunikacji miał sens, wymagałoby określenia dla dostarczanych pasażerów/poczty faktu pochodzenia z innego miasta, albo odległości stacji z jakiej przybyli.
B1 i 2. Prąd - Byłyby dostępne cztery ustawienia. W pierwszych dwóch byłoby one dedykowane do konkretnych setów: istnieje WIRES, który transportuje prąd, i dobrze by było taką funkcję przypisać też Wired'owi. Automatycznie przestawiane do B3 jeśli dodatki nie są włączone.
B3. W tym ustawieniu produkcja prądu byłaby wirtualna. Jej poziom zależałby od dostaw węgla do najbliższej elektrowni oraz/lub tej przypisanej do miasta. Automatyczne przestawienie do B4 jeśli nie ma setów zawierających elektrownie.
B4. Produkcja prądu nie byłaby brana pod uwagę.
C. Przemysł - jego poziom zależałby od wielkości produkcji przedsiębiorstw przypisanych do miasta lub tych w określonym zasięgu. Produkty rolne miałyby obniżone znaczenie, zaś te przetworzone, zwłaszcza podwójnie miałyby odpowiednio wyższe.
D. Handel - zależałby od ilości dostaw towarów, żywności i materiałów budowlanych (ale tylko do sklepów przemysłowych).
E. Budownictwo - zależałoby od ilości dostaw materiałów budowlanych zwłaszcza do spółek budowlanych. Te dostarczane do sklepów miałyby obniżone znaczenie.
4. Miasta nie powinny w ogóle wymierać, albo mieć opcję zamrożenia tej funkcji. Gdyby miały wymierać, najlepiej aby odbywało się to na zasadzie podmiany większego budynku na mniejszy.
5. Skrypt powinien być możliwie jak najbardziej przejrzysty i zrozumiały - dobór odpowiedniego układu, kolorów, stworzenie opisu w oknie opowieści. Przy okazji, jeśli jest to możliwe, dobrze by było dodać "na wierzchu" widok oceny firmy w mieście.
6. Można pomyśleć o dodaniu funkcji podatku - coś podobnego funkcjonuje w zmodyfikowanym skrypcie RCG na serwerze ttdistas.es
7. Okres "rozliczeniowy" powinien być dłuższy niż jeden miesiąc. Te zielone wartości (jedna czerwona) powinny być średnią miesięcznych dostaw z dłuższego okresu np. 3 lub 6 miesięcy, aby pojedyncza kumulacja dostaw lub ich brak w jednym miesiącu nie stanowiły od razu oceny dla całego elementu. Ten okres dobrze gdyby był ustawialny w parametrach np.1-24.
W przypadku Handlu i Budownictwa zamiast okresu rozliczeniowego, ocena mogła by bazować nie na ilościach dostarczonych, ale zmagazynowanych (ustalone byłoby ich zużycie) - tutaj takie rozwiązanie chyba byłoby nawet bardziej adekwatne.