FORUM PTT - :: Napisz odpowiedź

Napisz odpowiedź

Użytkownik

Temat

Treść wiadomości

Ikony Emocji

µ	Ω	Π	φ	Δ	Θ	Λ	Σ	Φ	Ψ	α
β	χ	τ	γ	δ	ε	ζ	η	ψ	θ	λ
ξ	ρ	σ	ω	κ	Γ	♣	♥	ø	§	©
®	•	™	°	«	»	≤	≥	³	²	½
¼	¾	±	÷	×	√	∞	∫	≈	≠	≡
≈	←	→	↑	↓	↔	€	£	¥	¢	ƒ

[quote="zyxist"]Dzięki za komentarz. Wiele z tego co napisałeś, już widziałem w dyskusjach przewijających się na tym forum, albo biernie śledziłem (wróciłem do Trainz w połowie 2020, 1,5 roku przed rejestracją tutaj). Tak więc wiele z tych spraw jest mi znanych, tyle że z racji zawodu (programista/architekt oprogramowania) patrzę na nie inaczej. Nie mówię, że efekty widoczne dla graczy są fajne, bo nie są. Po prostu z kilkoma łudząco podobnymi sytuacjami spotkałem się w pracy, tyle że będąc "po drugiej stronie" barykady. Wiem, że robi się tu trochę dyskusja nie na temat, bo miało być o Geodecie, ale ew. gdyby to przeszkadzało, to moglibyśmy to do osobnego wątku wydzielić. Osobno przedstawię mój punkt widzenia na kwestie finansowe i programistyczne, do tego dorzucę parę kwestii kulturowych. Ogólnie też mam nadzieję, że nie potraktujesz tego jako ataku, bo nie mam takiego zamiaru. Masz prawo nie znać pewnych realiów branży i ja nie traktuję Twojej wypowiedzi jako jeżdżenia bez sensu po kimś - piszesz o swoich odczuciach i frustracjach, co jest jak najbardziej OK. Jedynie w jednym miejscu dostajesz delikatnego prztyczka z podstaw ekonomii, ale to spojlerów nie będę dawał :). Ogólnie nie jest moim celem przekonywanie Cię, zwłaszcza na siłę. Raczej ciekaw jestem dyskusji i tego, co się z niej zrodzi.

Strona finansowa

Czytałem coś tam o historii Trainza, Aurana i N3V Games. Oryginalna firma zbankrutowała, zaś obecny N3V Games żyje wyłącznie z Trainza. Dokopałem się jakiś czas temu do informacji w jakichś katalogach firm, że N3V należy do kategorii małych firm zatrudniających 11-50 ludzi. To jest małe, niezależne studio robiące niszową grę, które musi się tylko z niej utrzymać. Nie wiem czy wiesz, jakie są koszty utrzymania zespołu programistów. 5-osobowy zespół składający się z dwóch sensownych junior developerów, jednego mid developera i dwóch doświadczonych seniorów w polskich realiach to roczny koszt samych tylko wynagrodzeń w wysokości nawet 700 tys. złotych i może być wyższy, jeśli chcesz przyciągnąć lepszych developerów.  Do tego dochodzi koszt zakupu sprzętu do pracy, licencji na oprogramowanie, subskrypcji potrzebnych narzędzi, które trzeba co jakiś czas odnawiać. Koszt serwerów i łączy internetowych, albo wirtualnych serwerów w chmurze. Wynajem biura, administracja. Jeśli sprzedajesz swój produkt dajmy na to za 150 złotych, to abyś zarobił na same tylko roczne pensje, musisz rocznie sprzedać 4 666 egzemplarzy. Jeśli wydajesz nową wersję co 3 lata, musisz sprzedać 14 000 egzemplarzy, by wystarczyło pieniędzy na płacenie im pensji przez 3 lata. Do stworzenia i utrzymania gry z 20-letnią historią potrzebujesz zazwyczaj więcej niż 5 osób.

Jeśli chcesz mieć dobrych programistów, musisz wyłożyć konkretne pieniądze. Osób z wysokimi umiejętnościami jest mało, o wiele za mało w stosunku do potrzeb i albo masz odpowiednio dużo $$$, albo takie osoby pójdą pracować do kogoś innego, kto te $$$ ma. Takie są realia tej branży. Mam znajomych oraz osoby w rodzinie pracujące w start-upach, tam naprawdę jest konkretna walka o przekonanie inwestorów do sfinansowania Twojego produktu, byś miał w ogóle za co go skończyć. Byś miał za co zatrudnić wystarczająco dużo osób na wystarczająco długo czasu, by produkt zdążył się przebić, "spłacił się" i zaczął przynosić jakikolwiek dochód. Nie masz $$$ i do tego masz kijowy produkt = programiści idą gdzie indziej, ew. musisz zatrudnić tańszych i gorszych programistów i zgodzić się na gorszą jakość. Dla małej firmy utrata nawet jednej doświadczonej osoby znającej produkt to niezły cios w plecy. Bardzo bym się zdziwił, gdyby N3V Games rozwijające jeden niszowy produkt (i mające ludzi, którzy mają za sobą doświadczenie bankructwa) leżało na walizkach pełnych dolarów. To nie jest EA Games.

Ten Twój przykład ze stażem trochę nie do końca pasuje do sytuacji, bo nie mówimy tu o zatrudnianiu kogoś, a o sprzedawaniu produktu, a to dwie różne kwestie. Choćby przez to, że zatrudnianie kogoś jest obwarowane przepisami prawa nakładającymi na pracodawcę obowiązek zapewnienia narzędzi potrzebnych do pracy. Niemniej jest taka firma, i to nawet dość znana, która za moich czasów studenckich (nie wiem, jak teraz) oferowała bezpłatne staże i to w takich ilościach, że w zasadzie tam studenci odwalali niemałą część roboty. Nawet krążył dowcip o tym, że "prezes tej firmy wyznawał zasadę, że każdego doświadczonego developera można zastąpić skończoną liczbą studentów" :). Do finansowania rozwoju produktu jeszcze nawiążę przy okazji kwestii programistycznych.

Natomiast ostatnia kwestia: firma z założenia służy do tego, aby przynosiła zysk. Jeśli chcesz tylko koordynacji projektu rozwijanego przez hobbystów, to zakładasz organizację pożytku publicznego (znaną też jako "fundacja" albo "organizacja non-profit"). W świecie IT istnieją takie fundacje, o jakich piszesz (np. The Linux Foundation). N3V Games jest firmą, a nie fundacją. Jeśli Ci nie odpowiada model biznesowy jakiejś firmy, to nie kupujesz jej produktu. Ale krytykować za to, że ktoś założył firmę i chce osiągnąć zysk?

Strona programistyczna

Pracowałem przez jakiś czas przy monolitycznym produkcie mającym za sobą - podobnie jak Trainz - 20 lat historii i sprzedawanym klientom. Taki projekt ma za sobą ogromny bagaż tzw. "długu technicznego" - nietrafionych decyzji, pójścia na skróty, zmian podejścia i nadchodzi zawsze moment, kiedy albo ten dług techniczny spłacisz, albo grzęźniesz.

Wspomniałeś o dwóch kwestiach: wewnętrznych beta-testerach oraz pauzy w Geodecie. Z lektury oficjalnego forum wiem, że w TRS2019 twórcy postanowili przejść z utrzymywania dwóch różnych linii kodu (A: utrzymywanie TRS2019, B: nowa funkcjonalność dla TRS2022) na jedną, wspólną linię kodu, gdzie po prostu nowe funkcjonalności są poblokowane. Z punktu widzenia utrzymania programisty to bardzo ważna i pożądana zmiana, pośrednio też przekładająca się na graczy. Pracowałem zarówno w firmach, gdzie produkt miał jedną linię kodu (teraz też zresztą w takiej pracuję) i takich, gdzie trzeba było utrzymywać X wersji wstecz.

Gdy masz dwie linie kodu, pojawia się problem, że poprawki znalezionych bugów musisz przeportować do tej drugiej linii kodu. Są automatyczne narzędzia wspomagające ten proces, ale działają one dobrze tylko wtedy, kiedy zmieniany kawałek kodu nie różni się w obu wersjach. Im więcej różnic, tym więcej trzeba dostosowywać ręcznie, a to zajmuje czas. Jeśli na jednej gałęzi rozwijasz nową funkcjonalność, na której w dodatku przerabiasz wewnętrzną architekturę gry, może wręcz okazać się, że poprawki musisz robić dwukrotnie, bo różnic jest tak dużo. Do tego dochodzą testy poprawek, dwukrotna recenzja kodu przez innego programistę. Takie działanie potrafi skonsumować sporą część mocy przerobowej zespołu. W jednej z firm zdarzyło mi się, że podejmowaliśmy decyzję, aby np. nie porządkować jakiegoś zasyfionego kawałka kodu - choć porządek znacząco poprawiłby czytelność i uprościł utrzymanie, to utrudniłby portowanie ewentualnych poprawek w tym miejscu i to drugie przeważyło. Mi porotwanie zajmowało kilka godzin, czasem cały dzień. Mniej doświadczonej - tydzień. W 5-osobowym zespole nagle zostają Ci 3, 4 osoby, bo ostatnia przenosi już poprawione zmiany. To duża strata produktywności. Gdy masz jedną linię kodu, ten problem znika.

Jednak z drugiej strony jeśli ta sama linia kodu obsługuje dwie wersje: "starą" i "nową-rozwojową", to musisz w kodzie gry zaszyć mechanizmy, które ukrywają nieukończoną funkcjonalność przed światem. I niestety czasem zdarza się, że mimo Twoich starań, niektóre rzeczy wyciekają, albo generują jakieś efekty uboczne w "starej wersji". Funkcjonalność, którą dodano w TRS2022 (czyli dawny TRS2019 + Trainz Plus) dość mocno zmienia fundamentalną cechę gry, tj. podział na tryb Geodety i Maszynisty. To musiała być dla nich gruba zmiana wymagająca przeorania sporej części silnika, mimo iż Ty widzisz to po prostu jako błyskawiczne przełączenie się między jednym trybem, a drugim. Nie da się przy takim przeoraniu uniknąć przeoczenia czegoś. Czasami stajesz przed dylematem: "albo tu to zmienię i coś się może zepsuć, albo się zablokujemy, bo A i B się wzajemnie wykluczają". Jeśli masz starą bazę kodu, pisaną w dodatku przez kogoś innego, to możesz nawet nie być świadomy, że Twoja zmiana coś zepsuje, bo jest to taki dziwny ciąg przyczynowo-skutkowy, że prawie niemożliwe jest wykminienie, że coś takiego może zajść. Robiłem takie przebudowy funkcjonalności używanej przez klientów i to są rzeczy znane mi z autopsji. A jeśli w dodatku dopiero wdrażasz mechanizm spearacji niegotowych funkcjonalności, to musisz też zdobyć doświadczenie w jego stosowaniu. To niestety przychodzi z czasem. O pauzie w Geodecie pisali, dlaczego musieli takie coś wprowadzić.

Co z tymi beta-testerami? Tak, to była charakterystyczna cecha takiego stylu wytwarzania oprogramowania znanego jako "waterfall" lub "model kaskadowy", którego początki datuje się na lata 50. XX wieku. I wiesz co? Prawie cała branża już się z niego wycofała, bo w zdecydowanej większości projektów on się kompletnie nie sprawdza. A te firmy, które jakimś cudem to przespały, teraz borykają się z gigantycznym długiem technicznym i problemami z jakością (+ developerzy nie chcą tam pracować). W testowaniu i nowoczesnym wytwarzaniu oprogramowania chodzi o to, aby skrócić pętlę informacji zwrotnej między developerem, a odbiorcą. Perskeptywa developera mocno różni się od perspektywy końcowego użytkownika. Jak miałeś waterfall, to aż za często traciłeś X lat i ogromne pieniądze, inwestując w coś, a na koniec dowiadywałeś się, że klient chciał czegoś kompletnie innego. Co więcej, perspektywa testera też różni się od perspektywy developera i użytkownika - też zajmowałem się takim testowaniem. W waterfallu tester dostawał specyfikację i opracowywał testy pod tę specyfikację, a niekoniecznie zajmował się rozkminianiem czy dana funkcjonalność z punktu widzenia użytkownika ma sens. Do tego większość programistów jest słabymi testerami. Testy manualne są niesamowicie kosztowne - albo robisz je na samym końcu, kiedy projekt jest gotowy, a wtedy programiści nie mają wczesnej informacji zwrotnej, albo toniesz w powtarzaniu w kółko tych samych scenariuszy z powodu liczby zmian. Tak się NIE DA.

Obecnie dominują różne metodologie agile, których cechą jest dostarczanie nowej funkcjonalności w mniejszych kawałkach i skracanie dystansu między odbiorcą, a twórcą. Dlatego patrząc na TRS2019 widzę po prostu wersję przejściową, gdzie twórcy musieli uporządkować mocno wewnętrzną architekturę i metodologię pracy. Gdzie wzięli się za przemyślenie fundamentalnych elementów gry. Musieli się nauczyć pracować w nowym modelu (każdy projekt ma inną specyfikę, nawet jeśli masz doświadczenie w jakimś stylu pracy), mieli kilkunastoletnią bazę kodu i ograniczone zasoby. I to było bolesne, bo wyciekały różne rzeczy, ale ze znajomości branży wiem, że potrzebne. Takie zmiany nawet dla doświadczonych osób są mega-ciężkie tak, by nic nie popsuć. Mało jest też osób, które potrafią to skoordynować i technicznie poprowadzić zespół. A żeby je mieć w swojej firmie, to albo masz szczęście i przypadkiem na kogoś takiego trafiasz, albo... wykładasz $$$. Firmy, które potrafią to robić, dochodziły do tego często latami, również poprzez popełnianie błędów.

Brutalność, lekceważenie... powiem tak. Na pewno lekceważenie jest wtedy, kiedy dyrektor w firmie wymusza na programistach jakieś decyzje techniczne mimo, iż to nie on nad tym kodem pracuje i nie on będzie później musiał podczas rozwoju/utrzymywania ponosić konsekwencje tej decyzji. Lekceważenie jest wtedy, kiedy dyrektor/menedżer wymusza na programistach, aby porzucali dobre praktyki typu pisanie testów automatycznych, np. by zatuszować powstałe z jego winy opóźnienia. Lekceważenie jest wtedy, kiedy dyrektor oszukuje stakeholderów co do postępów, albo gdy programiści celowo oszukują i fałszują wyniki testów, postępy prac. Na pewno słyszałeś o CD Projekt RED i Cyberpunku 2077, gdzie przy okazji premiery i rozmaitych błędów w tej grze wyszły na jaw różne wewnątrzfirmowe brudy, które odbiły się na jakości gry, a także pełnoprawne oszustwa (pokazywanie wyreżyserowanego filmu jako dema z prawdziwej rozgrywki). To było lekceważenie graczy. Czy masz wgląd w wewnętrzne procesy N3V Games? Ja nie mam. Widzę, że są problemy w kilku obszarach i TRS2019, ale nie widzę, by płynęły one ze złej woli, lekceważenia czy oszustwa. Raczej ambitne wyzwanie po to, by móc dalej rozwijać grę, tylko po drodze podwinęła im się noga, co może wynikać choćby z tak prozaicznej rzeczy, jak niedoszacowanie stopnia trudności.
Dlatego unikam takich sformułowań.

Kompatybilność wsteczna

To jest ciężki temat. Mam kilka gier z aktywnymi społecznościami moderskimi i wg mnie Trainz się swoją stabilnością (przynajmniej jeśli chodzi o język programowania TrainzScript) wyróżnia. Cities: Skylines, Stellaris, Crusader Kings, Valheim... kurde, no po prostu w każdej z tych gier podbicie minor wersji to mały dramat z modami. Collosal Order (twórcy Cities: Skylines) dopiero za trzecim czy czwartym dodatkiem dali radę wypracować ze społecznością moderską jakiś model współpracy, który gwarantowałby, że przynajmniej te największe i najpopularniejsze mody będą zaktualizowane na czas. W Trainz widzę, że we wczesnych latach popełniono kilka brzmiennych w skutki decyzji projektowych, jak choćby bardzo luźne podejście do poprawności plików config.txt. To się zawsze później mści na programistach, którzy później muszą utrzymywać kod do czytania takich plików i absolutnie się nie dziwię, że w najnowszych wersjach zaostrzyli mocno walidację. I tak, wymusza to na autorach dodatków, by przestali bezmyślnie kopiować configi, tylko poczytali co do czego służy. Fajnie by było, gdyby to tak od razu działało, ale cóż...

Poruszyłeś kwestię skrytów do lokomotyw. Pamiętam tę akcję na forum Auranu :mrgreen:, patrzyłem też wtedy w kod, co się zepsuło i dlaczego. Od razu mi się wtedy nasunęły dwie myśli. Jedno to trochę wybrakowana dokumentacja do API (interfejsy programistyczne = zestawy dostępnych funkcji oraz opis ich działania/zachowania) oraz brak jakichś notek ostrzegających o zmianach w zachowaniu. To zdecydowanie odpowiedzialność N3V Games, gdzie mogliby i w sumie powinni się poprawić, skoro dają taki język programowania. ALE wy jako społeczność Trainza też sobie strzeliliście tu epicko w stopę. Tamten błąd, jeśli dobrze pamiętam, to była kwestia zmiany paru linijek, a cały problem polegał na tym, że skrypt był kopiowany metodą Copy'ego-Paste'a między poszczególnymi lokomotywami. Takie kopiowanie kodu to samobójstwo, jeśli chodzi o utrzymanie. Zdążyłem już nieco poznać TrainzScripta. Tam da się tworzyć współdzielone biblioteki kodu, sam język programowania jest miejscami niewygodny, ale posiada wszystko co trzeba, by stworzyć współdzielony, modułowy skrypt z możliwością dodawania specyficznych personalizacji. Gdybyście coś takiego mieli, to poprawilibyście to w 10 minut, wydali nową wersję współdzielonego skrytku i git.

To prawda, jesteście graczami i nie musicie znać się aż tak na programowaniu. Ale jeśli napiszecie choć jedną linijkę kodu, to Wasz kod i Wasza praca zaczyna podlegać tym samym prawom, zasadom i dobrym praktykom utrzymywalności, których muszą przestrzegać wszyscy programiści, bo tak po prostu działa wszechświat. Utrrzymanie 100% wstecznej kompatybilności API to mega-trudne zadanie, mało teżjest programistów, którzy wiedzą, co warto dokumentować, a co nie (i ponownie - chcesz takich mieć w zespole, to albo trafisz na nich przypadkiem, albo wyłóż $$$ na ich zatrudnienie). Sam się tego uczyłem latami. W IT nikt nie wymaga od bibliotek programistycznych trzymania kompatybilności za wszelką cenę. Niektóre projekty podejmują wyzwanie i dają określone gwarancje stabilności, ale muszą się do tego przygotować i jest pewna cena. W innych developerzy oczekują jasnej rozpiski, co się zmienia i czy wersja zrywa wsteczną kompatybilność czy nie. Jest taki język programowania Java. Od powstania w 1995 roku aż do wydania wersji 8 (2014-2017), ściśle trzymano tam wsteczną kompatybilność, tj. każda funkcja, każda funkcjonalność jaką kiedykolwiek dodano do języka, miała gwarancję bycia wspieraną. No i wszystko fajnie, tylko w pewnym momencie narósł im już taki dług nietrafionych rozwiązań, że zaczęło to się negatywnie odbijać na możliwościach dalszego rozwoju. I od wersji 9 (2017) wprowadzono politykę wycofywania i kasowania takich funkcjonalności. I tak, czasem to sprawiało, że komuś coś się jednak zepsuło. Po to właśnie pisze się kod tak, by w razie czego dało się go łatwo podbić do nowej wersji. N3V tego nie wymyśliło. Tak po prostu jest; możecie się oburzać, ale to nic nie da.

W temacie beta-testów jeszcze, od strony wstecznej kompatybilności:

- ależ jak najbardziej masz wersje beta za darmo. Wszystkie Service Packi, przed oficjalnym ukazaniem się, mają przynajmniej jedno publiczne wydanie "Release Candidate"; w ustawieniach Trainza da się przełączyć źródło z kanału stabilnego na kanał beta. N3V zadbało tutaj, byś mógł sprawdzić swoje dodatki i dać im feedback czy ich zmiany nic nie zepsuły. TRS2019 SP5 zaliczył kilka RC i twórcy poprawiali bugi do skutku. Nie da się wymagać od firmy liczącej mniej niż 50 osób, by sprawdziła kompatybilność X tysięcy dodatków, z czego część znajduje się poza Download Station i wymaga znajomości polskiego, by w ogóle rozkminić, że istnieją. Ile osób tutaj testuje swoje dodatki na wersjach RC?

- Trainz Plus, jak już wspominałem, to pomysł na skrócenie feedbacku i pętli zwrotnej. Dostęp do wersji beta nowej funkcjonalności to forma nagrody za wsparcie. Czy tracisz coś na tym, że nowa funkcjonalność jest udostępniona w tej formie? Nie. Mogli tego nie udostępniać, wszyscy czekaliby 3 lata po równo. No spoko, ale mi Geodeta 2.0 nawet w takiej niedokończonej wersji ułatwia pracę, więc dlaczego mam twórców nie wesprzeć? Popatrz sobie na Steamie, ile gier jest wydawanych obecnie w formule "Early Access", gdzie płacisz za... nieukończoną, dość wczesną wersję gry z błędami? Jeśli nie chcesz - nie wspieraj, po sprawie. Zauważ też, że nie mogą akurat tego udostępnić do testów za darmo, bo... no kto by wtedy kupił nową wersję, skoro wszystko już wyszło za darmo w ramach beta-testów? I z czego byś wtedy sfinansował dalszy rozwój gry? Dla mnie to całkowicie uczciwa oferta.

Kwestie kulturowe

Różne narodowości inaczej odbierają taki marketing, jaki widzisz. Jeśli mówimy o rynku amerykańskim, to takie promowanie jest tam koniecznością. Jest to styl prowadzenia biznesu, autoprezentacji, bez którego nigdy nie trafisz do ludzi. Miałem kiedyś całe dwudniowe szkolenie o tym. Tam po prostu jak się jakiekolwiek przedsięwzięcie zaczyna, trzeba ludziom rozdawać czapeczki, robić konkursy piosenek, opowiadać, jakie wszystko jest wspaniałe i piękne, i wiele innych rzeczy, które nam się wydają totalnym absurdem, kiczem i stratą czasu lub wręcz kojarzą się niemiło z totalitarną propagandą. N3V Games to firma australijska - nie wiem, jakie podejście mają do tego Australijczycy, ale powiedziałbym, że raczej zależy im bardziej na rynku amerykańskim niż polskim . Jeśli nawet nie jest to "ich" styl, to wtedy dostosowują się do realiów tamtego rynku. Jeśli będziesz chciał dotrzeć do Amerykanów, to polskim podejściem w czystej postaci kompletnie do nich nie trafisz tak, jak oni swoim nie bardzo trafią do Polaków.

Tak zwijając wątki...

No właśnie, polska społeczność Trainza jest aktywna i ma ideały. Ale też popatrz sobie na stan polskiej sceny. Multum dodatków, N tras i żadna nie nadaje się do zabawy po pewnym czasie. Autorzy porzucają swoje dodatki i strony, na których były hostowane. Dodatków nie da się już nigdzie znaleźć poza dyskami twardymi paru szczęśliwców, którzy rozsyłają "na prośbę", bo oficjalnie im nie wolno wrzucić tego na żadną stronę. Nie ma nawet dżentelmeńskiej praktyki, którą znam ze społeczności innych gier, że jak porzucam moje dodatki, to udostępniam źródła i pozwalam przynajmniej innymi przejąć nad nimi opiekę, by nie psuć zabawy. Próbowałem chyba z 5 czy 6 polskich tras uruchomić - dopiero w "Korsze-Ełk" udało mi się skompletować wszystkie potrzebne dodatki. Ale to tylko sama trasa, bez sesji. Reszta ma braki i jest przez to  niegrywalna. Czym to się różni od porzucenia dodatku przez N3V?

A teraz popatrz na to z takiej strony. Ile jesteś w stanie zapłacić za porządnie przygotowaną i utrzymywaną przez autora mapę, by wynagrodzić mu poświęcony czas liczony w miesiącach czy latach? Z tego co mi wiadomo, możliwość wykorzystania w płatnych dodatkach pozwala również niezależnym twórcom płatnych map taki dodatek wykorzystać, a nie tylko N3V. Co mi przeszkadza, że ktoś np. wykorzysta mój domek w komercyjnej trasie, dopóki sam domek nadal jest dostępny za darmo? Połowa IT stoi na takich darmowych narzędziach dopuszczonych do użytku komercyjnego i w świecie IT nikt nie robi problemu z tego, że ludzie, którzy te narzędzia rozwijają, albo budują wokół tego dodatkowe biznesy, albo powstaje jakaś fundacja, albo są dotacje. Dla mnie to norma. Ja tak po zastanowieniu właśnie widzę w tym zachętę ze strony twórców do tego, by ludzie tworzyli nowe trasy, poprzez możliwość ich spieniężenia. Budowa takiej mapy to zadanie na miesiące lub lata. Niby wypuściłem moje pierwsze dodatki na PTT Open Content, ale szczerze już się od co najmniej dwóch tygodni zastanawiam czy by nie dać luźniejszej licencji. Dodatków może nie opublikowałem jakoś dużo, ale rozwijałem różne darmowe i niekoniecznie darmowe projekty poza światem Trainz. Stąd też moje inne doświadczenia i stosunek do pewnych spraw.

I do czego zmierzam... czy nie byłaby zdrowsza taka scena, gdzie np. tory, sieć trakcyjna, wskaźniki itd. są dostępne za darmo z dopuszczeniem komercyjnego użytku, a ich autorzy dodatkowo angażują się w budowę płatnych polskich tras? Do tego kilka mniejszych np. darmowych, z jakąś trasą-samouczkiem wprowadzającym w świat polskich kolei. Wszystko jest na DLS, włączam ściąganie, wracam po kawie, odpalam, gram. Mam kilka krótszych tras, kupuję sobie do tego jedną, dwie długie trasy, które dają mi rozrywkę na długie godziny. Pewnie ktoś by zrobił też dłuższą darmową, ale wszystko na DLS, więc łatwo da się ściągnąć. Ja byłbym spokojnie w stanie zapłacić za jedną, dwie dobre trasy, które mogę sobie wziąć, zainstalować i grać. A dodatki - bonus, do urzeczywistniania własnej wizji, jak ktoś ma czas i ochotę. A autorzy mogą sobie za kasę kupić nowego Trainza, nawet w wersji Plus i może jeszcze coś zostanie jako bonus. Do tego wszystko działa w multiplayer, multiplayer surveyor (nowość w TRS2022), może nawet społeczność by się zebrała i przygotowała trasędo dystrybucji wraz z grą? Do mnie to bardziej przemawia.

Uff... długo wyszło, ale mam nadzieję, że przedstawiłem Ci mój punkt patrzenia. Trochę się on różni od Twojego czy Waszego, też nie oczekuję, że go zmienisz. Jeśli znajdziesz tu coś wartościowego, cieszę się. Jeśli nie, nic się nie dzieje :). Gdyby mi też Wasze podejście jakoś mega przeszkadzało, to by mnie tu po prostu nie było.[/quote]

Opcje
HTML: TAK
BBCode: NIE
Uśmieszki: TAK

	Wyłącz HTML w tym poście
	Wyłącz Uśmieszki w tym poście