Ocena wątku:
  • 1 głosów - średnia: 5
  • 1
  • 2
  • 3
  • 4
  • 5
Nowy model płatności za transport
#1
Gdy wiele lat temu grałem w TTD, była to świetna i bardzo dobrze zbalansowana gra.
Obecnie jest jeszcze świetniejsza i ulepszana, ale wraz z ulepszeniami posypały się pewne sprawy.
Najważniejszą z nich są opłaty zależne od czasu transportu.
Przy mapach 256x256 działało to prawidłowo, ale przy większych mapach nawet przy dużej prędkości opłata za transport spada szybciej niż przyrasta dystans (po prostu z funkcji rosnącej robi się parabola), aby nie było ujemnych opłat, ktoś dosztukował linię prostą.
Więc teraz opłata za przewiezienie ze stałą prędkością raz jest duża, raz mała, to znowu duża:
[Obrazek: incomedistance256.png]
co gorsza potem nie zależy od prędkości. Na czerwono zaznaczone, jak to się zachowuje dla oryginalnej mapy - i podobnie powinno być dla większych.
Ten bug jest w grze od wersji 0.4.0 openttd gdy wprowadzono większe mapy, ale ludzie się tak przyzwyczaili, że myślą iż tak powinno być.
Jako osoba ze świeżym spojrzeniem ale pamiętająca stare czasy zapewniam, że nie powinno tak być i że nie jest to normalne.
Dlatego zaproponowałem nowy model, który:
  1. opiera się na prędkości średniej, a nie czasie transportu
  2. daje "gładką" zależność przychodu od odległości
  3. dla odległości ~200 pól daje b. podobny przychód jak stara wersja
  4. używa własności towaru Days1 i Days2 do modyfikacji krzywej przychodu zależnie od prędkości średniej

Obecnie wygląda to tak, przykład dla V=100km/h i pasażerów oraz ropy naftowej:
[Obrazek: pax100.png][Obrazek: oil100.png]
W przypadku mniejszych prędkości krzywa dla pasażerów idzie mocniej w dół dla większych dystansów, ale już nie wstaje.
W przypadku ropy również dla mniejszych prędkości krzywa się wysyca, tylko na mniejszym poziomie.
Z drugiej strony, zwiększanie prędkości ponad 200 km/h daje istotne rezultaty dla pasażerów, a nie towarów masowych - wszystko sterowanie przez oryginalne parametry Days1 i 2.

Szczegóły modelu oraz testowy kod źródłowy są tutaj:
http://www.tt-forums.net/viewtopic.php?f...3#p1113022
W powyższym wątku jest też link do arkusza kalkulacyjnego, gdzie można sobie porównać wykresy przychodu od odległości dla różnych prędkości i towarów.

Jeśli ktoś ma możliwość kompilowania, to zapraszam do testów i uwag,
zasadniczo zmieniłem tylko jedną funkcję w pliku economy.cpp
Na razie kod jest napisany w oparciu o liczby rzeczywiste, więc nie nadaje się do rozgrywki sieciowej.
Przeróbkę na integery zostawiam sobie na później, być może trzeba będzie jeszcze ulepszyć obecny model.
#2
Stary model (ten, który dawał parabolę) ze swoim gwałtownym spadkiem przychodu przy zbyt długich czasach przewozu wcale nie jest taki zły. Potencjalne ujemne przychody są dobrym "motywatorem" do budowania wydajniejszych magistral i szybszych pociągów na dłuższe odległości, ewentualnie do inwestowania w inne środki transportu (samoloty, Maglev), które pozwolą pokonać barierę odległości, wynikającą z modelu ekonomicznego.
Jedyne co należałoby ulepszyć w tym modelu, to uzależnić mechanizm obniżania stawki za tonę ładunku od rozmiaru mapy.

Twój model o tyle mi się nie podoba, że wyklucza praktycznie wszelkie ryzyko gospodarcze. Cokolwiek zrobisz, nawet największy absurd - np. pociąg jadący 10 lat naokoło planszy - to zawsze zarobisz na takim przewozie (pomijając koszty utrzymania taboru)...
#3
Moim zdaniem jest dokładnie odwrotnie niż piszesz.
Stary model pozwala na absurdy typu b. duży zarobek na b. dużych odległościach z b. małą prędkością, bo przychody są liniowe.
Jeśli tylko prosta kosztów (pomarańczowa) ma mniejsze nachylenie niż prosta przychodów,
to dochód będzie ciągle rósł z odległością i to niezależnie od prędkości.
W moim modelu krzywa dla dużych prędkości zaczyna się wysycać, a dla małych wręcz opadać, i już się nie podnosi.
Oto przykład dla 40 pasażerów, ale tego standardowego tendrzaka z v=64 km/h, pomarańczowa prosta to jego koszty całkowite razem z amortyzacją:
[Obrazek: pax40v64.png]
Jak widać, stary czerwony model daje gwałtowny spadek, ale potem rośnie i im dalej tym lepiej - gdzie tu sens gdzie logika,
w nowym powyżej 2000 przecina się przychód i koszt.
Oczywiście przychód z 40pax jest mały, dokładasz drugi wagon i w starym modelu kosisz kasę niezależnie od odległości, w moim modelu tylko przesuwasz punkt przecięcia dalej.

Zdaję sobie sprawę, że ten bug jest od tak dawna, że się ludzie przyzwyczaili i dorobili do tego jakieś teorie które to tłumaczą.
Jeszcze raz powtarzam, mój model odtwarza praktycznie te same wartości, które były w klasycznym TTD na mapach do 256t, a poprawka jest dla dużych map.

PS. ta prędkość jest oczywiście średnia, w rzeczywistości dla v=64 km/h i ruchu podmiejskiego wychodzi 2x mniej.
#4
(04-03-2014, 15:38)McZapkie napisał(a): Moim zdaniem jest dokładnie odwrotnie niż piszesz.
Jak widać, stary czerwony model daje gwałtowny spadek, ale potem rośnie...

O tym dziwnym patch'u nie mówię. Dla mnie to też jakieś kuriozum. Sad
A wracając do modeli przychodów, to zauważ, że obecny model jest wpisany nie tylko w OTTD, ale i w specyfikację NewGRF. O parametrach krzywej "starzenia się" ładunku decydują GRF-y przemysłowe:
http://newgrf-specs.tt-wiki.net/wiki/Act...11.2C12.29
Nie możesz więc tak zupełnie bezkarnie zastąpić tego mechanizmu innym.

Dla mnie zupełnie wystarczającą poprawką w obecnym modelu ekonomii byłoby dynamiczne dopasowanie przedziału czasu, w którym następuje starzenie towaru, do rozmiaru mapy. Np. można by obecny interwał naliczania czasu przejazdu (zwykle co 185 tick'ów) odpowiednio wydłużać, np. 1,5x na każdy 2x rozmiaru mapy powyżej 512kratek. Przy okazji - te 185 tick'ów to nic innego, jak cargo_age_period z GRF-ów pojazdów... Wink
Tak więc niewielkim kosztem można by pożenić ze sobą wszystkie obecne parametry NewGRF oraz historyczny model TTD.

Cytat:...ludzie przyzwyczaili i dorobili do tego jakieś teorie które to tłumaczą.

Żadnej teorii nie trzeba dorabiać. 'Penalty' znaczy 'kara', w tym wypadku - kara za niedotrzymanie terminu dostarczenia towaru. Terminy dostawy są ustalane właśnie przez GRF-y przemysłowe.
#5
(04-03-2014, 17:49)TadeuszD napisał(a): Moim zdaniem jest dokładnie odwrotnie niż piszesz.
Jak widać, stary czerwony model daje gwałtowny spadek, ale potem rośnie...
O tym dziwnym patch'u nie mówię. Dla mnie to też jakieś kuriozum. Sad
Ale to przecież nie jest patch, tylko standard -w każdym openttd tak jest: http://docs.openttd.org/economy_8cpp_source.html linia 970.

Ale zgadzam się, jest to kuriozum i stąd mój model Smile

Dziwię się że w ogóle bronisz tego kuriozum, skoro powodu tego buga większość pracy wsadzonej w pkp-set, a także inne newgrf, jest po prostu wsadzona na marne.
3xPt31 z węglarkami i wyłączonym limitem wagonów - czy to jest to, do czego warto było dążyć?

(04-03-2014, 17:49)TadeuszD napisał(a): A wracając do modeli przychodów, to zauważ, że obecny model jest wpisany nie tylko w OTTD, ale i w specyfikację NewGRF. O parametrach krzywej "starzenia się" ładunku decydują GRF-y przemysłowe
Halo, przecież mój model korzysta z tych samych parametrów i jak pisałem, rezultaty są zasadniczo te same na odległościach takich jak w standardowym TTD.
Standardowy TTD był bardzo dobrze zbalansowany ze względu na odległości, prędkości i ładunki. Przykładowo, OIL ma najdłuższy czas ochrony przed czasem dlatego, by dało się wozić tankowcami na duże odległości.
Rudowęglowców nie było, stąd mniejsze czasy.
Ale teraz są newgrf ze statkami do innych towarów i trochę problem - dlatego w FIRS przedłużono też czasy dla innych masowców.
Ale to wszystko i tak się sypie na większych mapach.
Nie można bezkarnie zmieniać gry bez odpowiednich poprawek.
Tak to wyglądało na standardowej mapie dla ropy i pasażerów:
[Obrazek: oilpax-oldgood.png]
i to ma sens - a na większej mapie mamy garba, spadek, znowu wzrost - to nie jest tak, że "gra tak ma", to zwykły błąd jak się zmienia coś, co dobrze działało.
Moja zmiana naprawia ten błąd.
Pokazane krzywe w oryginalnej grze są podobne do rzeczywistych krzywych płatności, przykład z Przewozów Regionalnych:
[Obrazek: passpaymentgraph_regio.png]
jak widać jest to odwrotność funkcji wykładniczej plus jakaś prosta.
W TTD dla małych prędkości była dodana dodatkowo kara czasowa, stad krzywa się zakrzywiała w dół.
I ta właśnie działa mój model.
PRAKTYCZNIE TO SAMO CO BYŁO do 200 pól:
[Obrazek: paxcomp64.png]
przerywane duża prędkość - oba modele się pokrywają, ciągłe mała prędkość - oba modele się pokrywają w obrębie czarnego kwadratu.
Ja nie robię żadnej rewolucji, tylko poprawkę w zakresie, w którym to źle działa.

Natomiast kombinowanie w newgrf aby wydłużyć czas, to nie jest dobry pomysł.
Zrobiłem tak w FIRS (zwiększyłem days1), ale to rozwala balans z kolei na małych odległościach. To samo ze starzeniem.

Wieczorkiem wrzucę plik z patchem, jak ktoś chce, to sobie skompiluje i oceni, czy rozwaliłem grę czy ja poprawiłem.
#6
(04-03-2014, 18:25)McZapkie napisał(a): Ale to przecież nie jest patch, tylko standard...
Dziwię się że w ogóle bronisz tego kuriozum...

Nie bronię "kuriozum" - wręcz przeciwnie - uważam, że ta dziwna stała = 31 powinna zniknąć!
Bronię jednak ogólnej idei, wg której wożenie towarów klasycznymi środkami transportu na coraz większe odległości staje się całkiem nieopłacalne, a nie tylko trochę mniej opłacalne. Wymusza to inwestowanie w coraz lepsze (i droższe) technologie - samoloty, pociągi MagLev, vacuum-tube, itp. OTTD zdecydowanie NIE JEST grą realistyczną, więc nie ma tu sensu skupiać się na rzeczywistych stawkach przewozowych, np. PKP... Wink

Cytat:Natomiast kombinowanie w newgrf aby wydłużyć czas, to nie jest dobry pomysł.

A to się chyba źle zrozumieliśmy. Nie chodziło mi, że trzeba coś zmieniać w GRF-ach. Chodziło mi o to, że OTTD mógłby sztucznie "spowalniać czas" na dużych mapach, aby uzyskać na nich model przychodu zbliżony do uzyskiwanego na małych mapach. Efekt byłby identyczny z tym, jakby wszystkim pojazdom jednocześnie przemnożyć cargo_age_period o współczynnik, wynikający z wielkości mapy.

EDIT
I jeszcze jedna sprawa, która przyszła mi do głowy już w łóżku... W swoim wzorze wykorzystujesz dwa razy funkcję exp(). Przy włączonym CargoDist i wielu pojazdach na mapie wywołanie tej funkcji może następować nawet kilkaset razy na sekundę - każdy przeładunek/wyładunek dla każdej partii towarów podróżujących inną trasą jest wyliczany osobno.
Nie wiem, ile trwa wyliczenie exp() na nowych procesorach - ostatnio zajmowałem się tymi kwestiami jak królowały procesory 486 - ale na pewno dłużej niż kilka prostych operacji na integerach. OTTD jest programem jednowątkowym, więc wydłużenie choć jednego bloku operacji wpłynie negatywnie na całkowitą wydajność aplikacji. Nie jestem więc pewny, czy pójście w zaawansowany model zmiennoprzecinkowy to najlepszy pomysł. Może lepiej popracować nad jakimś uproszczonym algorytmem, operującym na integer'ach?
#7
(05-03-2014, 00:22)TadeuszD napisał(a): Bronię jednak ogólnej idei, wg której wożenie towarów klasycznymi środkami transportu na coraz większe odległości staje się całkiem nieopłacalne, a nie tylko trochę mniej opłacalne. Wymusza to inwestowanie w coraz lepsze (i droższe) technologie - samoloty, pociągi MagLev, vacuum-tube, itp. OTTD zdecydowanie NIE JEST grą realistyczną, więc nie ma tu sensu skupiać się na rzeczywistych stawkach przewozowych, np. PKP... Wink
Gdybym się skupiał na rzeczywistych stawkach PKP Cargo, to bym przywalił linię prostą PLN(km), niezależną od prędkości Smile
Ja tylko realizuję to, co napisano na głównej stronie openttd: "It attempts to mimic the original game as closely as possible while extending it with new features."
i poprawiam rzeczy, które są skopane. W oryginalnej grze stawki za transport towarów bardzo mało zależały od czasu i podobnie powinno być na dużych mapach.
Przecież różnica między modyfikatorami dla szybkich i wolnych towarów jest nawet 10-krotna!
Wcale nie jest tak, że jeśli coś nie zależy od prędkości, to się nie opłaca inwestować w szybszy transport.
Nawet, gdyby stawki zupełnie nie zależały od prędkości, opłacałoby się inwestować w szybszy transport z 2 trywialnych powodów: większa przepustowość linii i więcej razy można obrócić tym samym pojazdem w danym czasie.

Tym niemniej uwzględniam postulaty, aby przewozy na duże odległości małymi prędkościami były całkiem nieopłacalne (spada do zera albo poniżej running cost) - ale to zależy od rodzaju towaru.

Cytat: Nie chodziło mi, że trzeba coś zmieniać w GRF-ach. Chodziło mi o to, że OTTD mógłby sztucznie "spowalniać czas" na dużych mapach
Jest chyba takie coś - Daylenght patch - ale z tego co mi się obiło o oczy, to są duże problemy ze zbalansowaniem produktywności przemysłu, kompatybilnością ze skryptami i innymi poprawkami - dlatego ciągle nie ma tego patcha w głównej wersji.

Co do funkcji exp() to oczywiście że nie będzie używana w takiej formie, to jest tylko dla testów,
jak pisałem, liczby zmiennoprzecinkowe w ogóle są zabronione w openttd bo rozwalają rozgrywkę sieciową.
Zrobię to na int, a zamiast e^-x będzie 2^-n, co można trywialnie załatwić przesuwem o bit w prawo.
#8
(07-03-2014, 01:35)McZapkie napisał(a): Jest chyba takie coś - Daylenght patch - ale z tego co mi się obiło o oczy, to są duże problemy ze zbalansowaniem...

Nie, nie... Wszelkie patch'e typu Daylength to zupełnie inna para kaloszy. Nie chodzi o globalne spowolnienie czasu, lecz jedynie o "rozciągnięcie" krzywej opadania stawki tak, aby bardziej pasowała do rozmiaru mapy.
#9
Niestety to spowolnienie czasu poprzez rzadsze naliczanie cargo days dawałoby nieproporcjonalnie wielkie przychody na dużych odległościach:
[Obrazek: Pt31comp.png]
na niebiesko zaznaczyłem 6x rzadsze naliczanie tak, aby prawie nie było tej "hopki" - jak widać, w porównaniu z pomarańczową krzywą oryginalnej płatności, jest o wiele za dużo, np. w porównaniu z running cost (czerwona prosta).
Oczywiście można by obniżyć mnożnik bazowy, ale wtedy z kolei byłoby za mało przychodu na małych odległościach (zbyt płaski wykres).
Nie tędy droga.

Głównym problemem jest to, że jest jeden mechanizm służący do dwóch rzeczy:
1. spłaszczania krzywej przychodu z odległością
2. kary za opóźnione transporty.
I na większych mapach to nie działa właściwie.

Najlepszym rozwiązaniem jest rozdzielenie tych rzeczy, właśnie pracuję nad nowym modelem.
Płatność w zależności od odległości wyglądała by tak jak ta zielona krzywa
(jej początkowy charakter identyczny ze starym openttd dla każdej prędkości i towaru, potem mniej lub bardziej płaska zależnie od towaru).
Ale ponadto odejmowane byłyby punkty karne za zbyt późny dowóz,
a kryterium spóźnienia byłaby różnica między czasem transportu a spodziewanym czasem transportu liczonym z prędkości maksymalnej i odległości (plus jakiś mały offset na czas potrzebny na ładowanie/rozładunek i przyspieszanie/hamowanie).
Punkty karne naliczane byłyby, tak jak teraz, czyli w mniejszej ilości, jeśli różnica
jest większa niż cargo.days1 ale mniejsza niz cargo.days2, w większej ilości gdy różnica jest większa niż cargo.days2.
Czyli transport pasażerów byłby znacznie bardziej uczulony na spóźnienia niż np. węgla.
To dawałoby możliwość ciekawych strategii, które są obecne również teraz, ale nie tak wyraźnie.
Np. mało opłacalne byłoby czekanie na pełny załadunek pasażerów, ale w przypadku węgla mogłoby być już opłacalne (zależnie od długości składu),
trzeba by też, w przypadku wspólnej linii, pomyśleć o takim ustawianiu semaforów, aby pasażerskie miały priorytet - jak towarowy poczeka, to nie straci nic lub mało.
#10
(12-03-2014, 11:45)McZapkie napisał(a): Niestety to spowolnienie czasu poprzez rzadsze naliczanie cargo days dawałoby nieproporcjonalnie wielkie przychody na dużych odległościach...

Bo moim zdaniem użyłeś zbyt dużego przelicznika czasu. Nie wiem, dla jakiej prędkości to liczyłeś, ale na podstawie wykresu można założyć, że 'oryginalny' model przychodu sprawdza się z powodzeniem na mapach o wielkości do 512. Dla skrajnej odległości spadek dochodowości jest już mocno odczuwalny - zmusza to gracza do inwestowania w nowsze technologie - ale wykres jeszcze nie obejmuje obszaru tych dziwnych fluktuacji.
Gdzieś wcześniej proponowałem, żeby wraz ze 2x wzrostem mapy zwiększać przelicznik czasu 1,5x. Dla ułatwienia można przyjąć SQRT(2)=1,41. Czyli dla mapy 4096 trzeba by spowolnić czas 2,83x a nie 6x, jak przyjąłeś. Wykres będzie wtedy przebiegał znacznie niżej oraz pojawi się próg, powyżej którego nie opłaca się już wozić towarów 'tradycyjnymi' środkami. Z małą poprawką, że dalej powinno być już "0", a nie prosta wznosząca się.
Co do nieproporcjonalności przychodów, to bym się tym aż tak bardzo nie przejmował. Zauważ, że środki transportu, poruszające się z prędkościami >>500 km/h (są takie GRF-y) będą generowały przychód praktycznie liniowy, bez żadnego załamania krzywej stawki. Wzrost przychodów dla 'tradycyjnych', powolniejszych środków transportu po prostu tylko wyrówna nieco ich szanse. Zmniejszy parcie na prędkość za 'wszelką cenę'.

Cytat:...kryterium spóźnienia byłaby różnica między czasem transportu a spodziewanym czasem transportu liczonym z prędkości maksymalnej i odległości (plus jakiś mały offset na czas potrzebny na ładowanie/rozładunek i przyspieszanie/hamowanie).

Wyczuwam wiele problemów w przypadku transportu towarów/pasażerów różnymi środkami, z różnymi prędkościami. Jak rozwiążesz problem pasażera, który wsiada do autobusu, potem przesiada się do samolotu a na koniec dojeżdża do celu tramwajem, w dodatku każdy z tych środków transportu ma inne cargo_age_period? Co, gdy CargoDist przeliczy w międzyczasie trasy i skieruje pasażera inną trasą? Jak rozwiążesz absurd, polegający na wysłaniu pasażera wozem konnym na drugi koniec mapy o rozmiarze 4k (spodziewany czas transportu na poziomie 100 lat...) - algorytm uzna to za normalne i zacznie naliczać kary dopiero po 100 latach???

Mnie ciągle niepokoi, że w swoich rozważaniach myślisz wyłącznie o zwykłych pociągach. Tymczasem już sama gra w wersji 'standard' dostarcza rozwiązanie Twoich problemów - wożenie węgla koleją MagLev przełamuje barierę braku opłacalności. A jak to nie pomoże, to są dodatkowe GRF-y: sety samolotów lub futurystyczne pociągi Vacuum Tube Train (V max = 4100 km/h). Wink
OTTD to prosta gra ekonomiczna, której celem jest wozić więcej i szybciej. A Ty za wszelką cenę chcesz zrobić z niej super-realistyczny symulator kolei. Wink
#11
(12-03-2014, 13:52)TadeuszD napisał(a): Wyczuwam wiele problemów w przypadku transportu towarów/pasażerów różnymi środkami, z różnymi prędkościami. Jak rozwiążesz problem pasażera, który wsiada do autobusu, potem przesiada się do samolotu a na koniec dojeżdża do celu tramwajem, w dodatku każdy z tych środków transportu ma inne cargo_age_period? Co, gdy CargoDist przeliczy w międzyczasie trasy i skieruje pasażera inną trasą? Jak rozwiążesz absurd, polegający na wysłaniu pasażera wozem konnym na drugi koniec mapy o rozmiarze 4k (spodziewany czas transportu na poziomie 100 lat...) - algorytm uzna to za normalne i zacznie naliczać kary dopiero po 100 latach???
1. to właśnie obecnie jest problem przy naliczaniu "transfer credits", które są naliczanie nieprawidłowo gdy są różne prędkości.
W efekcie wyskakują irytujące okienka o ujemnym proficie, mimo iż summa summarum całkowity dochód z transportu z "przesiadką" jest dodatni.
Mój model powinien przy okazji rozwiązać ten problem.

2. to właśnie obecnie można całkiem spory zarobek mieć, transportując pasażerów powozem na drugi koniec mapy, patrz różnica między czerwonymi kosztami a pomarańczową linią (liczone dla 1-konnej 10pax dorożki z eGRVTS):
[Obrazek: horse1.png]
Zaproponowany model ze spłaszczoną krzywą ucina opłacalność na długich dystansach (szczególnie gdy włączone są awarie).

(12-03-2014, 13:52)TadeuszD napisał(a): ...już sama gra w wersji 'standard' dostarcza rozwiązanie Twoich problemów - wożenie węgla koleją MagLev przełamuje barierę braku opłacalności
...
OTTD to prosta gra ekonomiczna, której celem jest wozić więcej i szybciej. A Ty za wszelką cenę chcesz zrobić z niej super-realistyczny symulator kolei. Wink
I napisał to Ten, Który stworzył realistyczny grf, z możliwością wyłączenia maglev Smile
#12
(12-03-2014, 16:45)McZapkie napisał(a): I napisał to Ten, Który stworzył realistyczny grf, z możliwością wyłączenia maglev Smile

Tak. Tyle, że PKP Set jest zaledwie jednym z wielu opcjonalnych dodatków, natomiast Ty chcesz zmienić core'ową cechę gry, która dotknie każdego bez wyjątku... Smiley33

Pokaż proszę, jakby się rozkładał przychód w przypadku zastosowania współczynnika czasu 2,83 zamiast 6. Oczywiście przy założeniu, że dalej jest już tylko stawka zerowa. Bo tu chyba żaden z nas nie ma wątpliwości, że to wymaga poprawy.

BTW - bawiąc sie w 'tuningowanie' PKP Setu zauważyłem, że w większości przypadków precyzyjne wyliczanie parametrów nie dawało oczekiwanych rezultatów. Niewielkie zmiany ginęły wśród wpływu innych czynników. Zamierzony efekt stawał się widoczny dopiero wtedy, gdy parametry były nieco 'przesterowane'.
I podejrzewam, że podobnie będzie w przypadku 'tuningowania' stawek za przewóz. Jak nie walniesz graczowi na czerwono po oczach zerowym lub ujemnym przychodem za rozładunek/transfer, to nie zauważy on, że coś jest nie tak. Szczególnie jak ma wiele dochodowych linii, a tylko jedna mu kuleje.
Dlatego krzywa, gwałtownie ucinająca dochód po przekroczeniu pewnej umownej granicy, wydaje mi się lepsza niż model, który generuje przychód nawet w teoretycznie nieskończenie długim czasie.
#13
Proszę, oto zestawienie przy współczynniku x1, x2.83 (czyli mniej więcej tyle co ma WARS) i x6:
[Obrazek: Pt31cargoaging.png]

Niestety to nie działa jak powinno - przy większych dystansach dalej jest hopka w dół, a przy średnich są nieproporcjonalnie duże przychody.
Gdyby to było takie proste, to by już takie coś zrobiono.

(12-03-2014, 18:02)TadeuszD napisał(a): chcesz zmienić core'ową cechę gry, która dotknie każdego bez wyjątku...
Ej, dlaczego piszesz "dotknie" - czy ja kogoś krzywdzę?
Stawki na odległościach takich jak w oryginalnym TTD są takie same, poprawiam tylko to, co jest skopane na większych odległościach.
Jak ktoś chce zarabiać więcej na lewitacji węgla, to przecież dalej może.
Ale skoro są realistyczne sety, takie jak PKP albo xUSSR, to dlaczego nie można z nich w pełni korzystać?
#14
Nieco poprawiłem wykres. Wg mnie tak powinien on wyglądać po zmianach:

[Obrazek: 676Pt31cargoaging.png]

(12-03-2014, 22:05)McZapkie napisał(a): Niestety to nie działa jak powinno - przy większych dystansach dalej jest hopka w dół...

Ale dlaczego tak Ci przeszkadza ta "hopka", czyli gwałtowny spadek przychodów na większe odległości? Dla mnie takie zjawisko jest OK. To utrudnienie, które skutecznie eliminuje absurdy typu wożenie towarów ciężarówką (60 km/h) przez cała planszę. Zjawisko to można pokonać jedynie stosując szybsze (a co za tym idzie - droższe) środki lokomocji lub bardziej 'komfortowe' (wyższe cargo_age_period). Gdybyś chciał w tych realiach umieścić PKP Set, to byłaby to doskonała okazja do zastosowania wagonów 1 klasy oraz sypialnych.

No i pisałem - te "nieproporcjonalnie duże przychody" nie są żadnym problemem. Wręcz też są OK. Jeśli taki gigantyczny przychód, uzyskany za przewóz na odległość 4k kratek (wierzchołek granatowego wykresu) podzielisz przez czas, który trwał ten przewóz, to wcale nie wyjdzie tak dużo. Podobny, a nawet większy przychód jest w stanie 'wyjeździć' pociąg na krótszej trasie (początek wykresu), ale pokonując tę trasę wielokrotnie w tym samym czasie...
#15
Przeszkadza mi hopka oraz ten ogon.
Uciąłeś ogon, OK, ale on był po to, żeby jednak się dało transportować towary na dalekie odległości z małą prędkością. Jak sobie teraz wyobrażasz grę w 1800 gdy są tylko furmanki, a odległości są duże?
Przed XIXw 2-tygodniowa podróż dyliżansem uważana była za szybką (stąd nazwa, od francuskiego dilligence), po wprowadzeniu pociągów przewóz konny miał już tylko lokalne znaczenie.
Przed powszechnym wprowadzeniem samolotów, podróż transatlantykiem była na porządku dziennym. itp.
Potrzeba więc mechanizmu, który w miarę nowych środków transportu zwiększa "ciśnienie" na używanie szybszych pojazdów.
Jest pomysł, aby dla danego towaru liczyć średnią prędkość z dostępnych dla tego towaru pojazdów.
Wtedy ujemne punkty naliczane byłyby, jeśli różnica między faktycznym czasem jazdy a oczekiwanym z prędkości średniej dla danego towaru jest większa niż marginesy late/early delivery dla danego towaru.
Oczywiście zbyt wolne dla danego towaru pojazdy nadal można używać, ale na małych dystansach.

Średnia prędkość może być wyliczana co jakiś czas, np. raz do roku.
Pytanie tylko, jak ją liczyć.
Czy jako średnią prędkość dostępnych do kupienia pojazdów?
Czy jako średnią prędkość wszystkich istniejących na mapie pojazdów?

Pierwsza opcja jest bardziej drastyczna i wymusza ciągłą presję na unowocześnianie parku maszyn. Presja ta zależy od konkretnych zestawów pojazdów, które sobie załadujemy.

Druga opcja jest mniej restrykcyjna, ale jest ciekawa z punktu widzenia multiplayera/AI - jak konkurencja kupi sobie nowoczesny tabor, to jesteśmy bici.
#16
(14-03-2014, 13:18)McZapkie napisał(a): Uciąłeś ogon, OK, ale on był po to, żeby jednak się dało transportować towary na dalekie odległości z małą prędkością. Jak sobie teraz wyobrażasz grę w 1800 gdy są tylko furmanki, a odległości są duże?

Nikt w tamtych czasach nie jeździł na wakacje do Egiptu, ani na staże do Stanów... Już wyprawa do najbliższego miasta była zjawiskiem raczej wyjątkowym. Większość towarów również była wytwarzana i sprzedawana lokalnie. Nikt nie sprowadzał wtedy odzieży i elektroniki z Chin. Wink
Dlatego wciąż uważam, że obecny algorytm (ale z uciętym "ogonem") słusznie uniemożliwia takie "wybryki", jak transport towarów furmanką przez całą mapę. Wymusza on na graczu logiczne planowanie - najpierw rozbudowa lokalnych rynków, a dopiero potem (w miarę postępu technicznego) łączenie ich w kompleksową sieć.
Przy czym to już mocno zależy od tego, co kto lubi i jakie ma wyobrażenie na temat 'poprawnego' zachowania gry.

McZapkie napisał(a):Potrzeba więc mechanizmu, który w miarę nowych środków transportu zwiększa "ciśnienie" na używanie szybszych pojazdów...
Oczywiście zbyt wolne dla danego towaru pojazdy nadal można używać, ale na małych dystansach...
Średnia prędkość może być wyliczana co jakiś czas, np. raz do roku.
Pytanie tylko, jak ją liczyć.

Jeżeli chcesz uzyskać następujący efekt, że w 1918r transport węgla na nawet dalsze odległości za pomocą Tp4 jest opłacalny, a z czasem staje się reliktem przeszłości, to mam bardzo proste rozwiązanie.
Obecnie "oczekiwany czas transportu" każdego z towarów zależy wyłącznie od T1. Nie zależy on ani od wielkości mapy, ani od możliwości technicznych używanych pojazdów. I to jest rzeczywiście słabe...
Ale może zamiast projektować super-hiper skomplikowany mechanizm, wyliczający rentowność przewozów na podstawie wielu czynników, spróbuj zastosować proste skalowanie krzywej naliczania kar (zależnej od T1 i T2) w dwóch wymiarach, niech T1 i T2:
- rosną liniowo w zależności od wielkości mapy,
- spadają wraz z upływem czasu kalendarzowego w grze.
Zależność od czasu najlepiej żeby była odwrotnie proporcjonalna lub wykładnicza, np:
1800r.: 4x
1900r.: 2x
2000r.: 1x
2100r.: 0,5x
Wtedy np. podróż parowcem w XIX w będzie wysoce opłacalna, bo jego przychód będzie odpowiadał szczytowi paraboli na wykresie, ale już 100 lat później ten sam parowiec na tej samej trasie zacznie przynosić straty, bo wykres przychodów zmieni swą charakterystykę ("skurczy" się w lewo).
#17
Cytat:- rosną liniowo w zależności od wielkości mapy,
- spadają wraz z upływem czasu kalendarzowego w grze.
Zależność od czasu najlepiej żeby była odwrotnie proporcjonalna lub wykładnicza, np:
1800r.: 4x
1900r.: 2x
2000r.: 1x
2100r.: 0,5x
Wtedy np. podróż parowcem w XIX w będzie wysoce opłacalna, bo jego przychód będzie odpowiadał szczytowi paraboli na wykresie, ale już 100 lat później ten sam parowiec na tej samej trasie zacznie przynosić straty, bo wykres przychodów zmieni swą charakterystykę ("skurczy" się w lewo).
Jeśli takie coś jest możliwe to jestem jak najbardziej za Smiley42
#18
(14-03-2014, 15:57)TadeuszD napisał(a): Nikt w tamtych czasach nie jeździł na wakacje do Egiptu, ani na staże do Stanów... Już wyprawa do najbliższego miasta była zjawiskiem raczej wyjątkowym. Większość towarów również była wytwarzana i sprzedawana lokalnie. Nikt nie sprowadzał wtedy odzieży i elektroniki z Chin. Wink
Ależ jak to, przecież podróżowano na bardzo duże odległości, tyle że nie każdego było na to stać.
Były regularne międzynarodowe linie dyliżansów w Europie, w USA osadnicy przemierzali cały kontynent,
z Polski do Anglii wysyłano zboże, z Chin sprowadzano jedwab i korzenie przypraw - your argument is invalid Smile
McZapkie napisał(a):Potrzeba więc mechanizmu, który w miarę nowych środków transportu zwiększa "ciśnienie" na używanie szybszych pojazdów...
Oczywiście zbyt wolne dla danego towaru pojazdy nadal można używać, ale na małych dystansach...
Średnia prędkość może być wyliczana co jakiś czas, np. raz do roku.

Cytat:spróbuj zastosować proste skalowanie krzywej naliczania kar (zależnej od T1 i T2) w dwóch wymiarach, niech T1 i T2:
- rosną liniowo w zależności od wielkości mapy,
- spadają wraz z upływem czasu kalendarzowego w grze.
No popatrz, podobnie myślałem w przypadku tego pierwszego modelu z wykładniczą funkcją - aby stała "czasowa" odpowiedzialna za kształt krzywej, zależała od daty.
Cieszę się, że istnieje jakaś wspólna asymptota naszych poglądów.

Z tym że pomysł z uzależnieniem od daty został skrytykowany przez niektórych twórców newgrf - nie podobało im się, że balansują swoje sety a potem się jakiś parametr zmienia w czasie i ten balans zaburza.
Stąd teraz pomysł, aby T1 i T2 były naliczane od różnicy czasu jaki był przebyty i czasu jaki powinien być przebyty przy danej prędkości średniej.
A ta prędkość średnia zależy od tego, jakie w danej chwili są dostępne pojazdy,
tak więc twórca newgrf ma nad tym pełną kontrolę (chyba że się załaduje dodatkowo jakieś bardzo inne dziwne newgrf).
Uważam że pomysł nie jest skomplikowany, aczkolwiek mam mały problem z wagonami które nie mają limitu prędkości (np. te standardowe) albo mają jakiś dziko duży (np. 2cc).
Tak więc trzeba też lokomotywy brać do średniej i być może liczyć średnią ważoną z małą wagą największych i najmniejszych prędkości.
#19
(16-03-2014, 19:19)McZapkie napisał(a): ...z Chin sprowadzano jedwab i korzenie przypraw...

Byłem na 100% przekonany, że użyjesz tego argumentu Smile
Ale karawany z przyprawami i jedwabiem nie stanowiły wtedy trzonu gospodarki, decydując o rozwoju całego regionu. Było raczej odwrotnie - to ogólny rozwój i dobrobyt generował w efekcie zapotrzebowanie na te towary luksusowe. Zupełnie inaczej niż dziś, gdzie bez Chin przestałyby działać wszelkie lokalne rynki... W OTTD jest to raczej nie do odtworzenia.
Aczkolwiek można sobie wyobrazić sytuację, w której brak jakiegoś surowca blokuje rozwój całego regionu, więc za wszelką cenę sprowadza się go z odległego krańca mapy. Transport tego surowca będzie przynosił same straty, ale suma summarum - zyski z przewozu w kolejnych etapach łańcucha przetwarzania zniwelują te straty.

McZapkie napisał(a):Z tym że pomysł z uzależnieniem od daty został skrytykowany przez niektórych twórców newgrf - nie podobało im się, że balansują swoje sety a potem się jakiś parametr zmienia w czasie i ten balans zaburza.

Trochę mają rację, choć nie do końca. W końcu inflacji nikt się nie czepia, a to też parametr, który zmienia się w czasie...
Mi pomysł na "balansowanie" parametrów T1 i T2 w zależności od średnich prędkości pojazdów też się nie podoba, i to z powodów, które sam wymieniłeś. Wyniki będą nieprzewidywalne. Inne rezultaty osiągniesz, gdy wyłączysz wycofywanie starych pojazdów, a inne, gdy wgrasz dodatkowo kilka setów samolotów, albo jeszcze gorzej - wspomniany set Vacuum trains...
Mechanizm "zmian oczekiwań klientów" powinien być stabilny w czasie i raczej wolno zmienny, żeby dało się za nim nadążyć. W rzeczywistości oczekiwania i przyzwyczajenia ludzi nie zmieniają się szybko. Zauważ, że samoloty latają od 80 lat. Ale ludzie nie przesiedli się do nich jednego dnia. Proces kształtowania się klienteli był procesem powolnym i dopiero w ostatnich latach samoloty zyskały status "normalnego" środka lokomocji, a nie tylko kaprysem VIPów.
Powinno to też działać w drugą stronę - "oczekiwania klientów" powinny rosnąć w ciągu gry pomimo dostępności w tej grze np. wyłącznie samych dorożek.

A może wyznaczać taki parametr na podstawie poziomu rozwoju miast?
#20
(16-03-2014, 22:31)TadeuszD napisał(a): W końcu inflacji nikt się nie czepia, a to też parametr, który zmienia się w czasie...
Oj bardzo się czepiają:
http://www.tt-forums.net/viewtopic.php?f...4&start=13
a konkretnie tego, że running cost rosną szybciej niż przychody. W efekcie ten sam newgrf, w zależności od tego czy grę wystartujemy w XIX czy w XXw, może dawać ujemne dochody lub wprost przeciwnie.
W sumie jakby zrobili start inflacji zawsze w 1950 zależny od daty a nie od czasu od początku gry.

Cytat:Mechanizm "zmian oczekiwań klientów" powinien być stabilny w czasie i raczej wolno zmienny, żeby dało się za nim nadążyć.
...
Powinno to też działać w drugą stronę - "oczekiwania klientów" powinny rosnąć w ciągu gry pomimo dostępności w tej grze np. wyłącznie samych dorożek.
No wiadomo, toteż liczę średnią kroczącą (rolling average), kwestia dobrania wagi wartości z poprzedniego roku.
Co do kwestii oczekiwań klientów, to "byt kształtuje świadomość" - mało kto na początku XIX marzył o podróżowaniu z prędkością większą niż koń, wprost przeciwnie, wiele ludzi bało się tego, patrz słynne opinie "powyżej 40mph pęd pociągu wyssie mózg pasażerom".
Generalnie ludzie boją się zmian.
Dopiero jak te zmiany zostaną wprowadzone przez jakiegoś wizjonera, ludzie się przyzwyczajają i nie wyobrażają sobie bez tego żyć.


Skocz do:


Użytkownicy przeglądający ten wątek: 1 gości