Názory k článku Historie vývoje počítačových her (70. část - Transport Tycoon a Transport Tycoon Deluxe)
-
Juraj (neregistrovaný)
Mne ani bratovi ta grafika vobec nevadila, dohrali sme aj tu variantu az do konca. Viac nam vadili strasne malo vykonne a pomale "priblizovadla", zvlast prva lokomotiva "Ploddyphut ChooChoo". Radsej sme nastavili zaciatok hry v neskorsom roku.
Stoji za to pripomenut ze herny svet sa s casom vyvija aj technologicky, co bol tiez novy prvok v tychto hrach, na zaciatku hry su dostupne iba parne rusne potom dieselove, elektricke a monorail az po maglev. Podobne aj vsetko ostatne, lietadla, lode, budovy. Kedze lietadla mali handicap na rychlost kvoli tomu ze mapa bola velmi mala, najlepsi maglev rusen Chimaera bol rychlejsi ako lietadla :)
-
Pavel TišnovskýZlatý podporovatelS pouzitim VolatileImage by to problem nebyl, hlavne u klasickeho isometrickeho zobrazeni. Problem v Jave je, ze lidi hodne pouzivaji BufferedImage s nekompatibilnim pixel formatem, potom jsou rastrove operace (nebo pokus o softwarovy double buffering) skutecne pomale - to je ostatne videt i na GUI (Swing).
Stejny problem by nastal, kdyby to nekdo implementoval v Xlib s nekompatibilni pixmapou nebo pres WinAPI (SetDiBitsToDevice se to tusim jmenovalo).
-
Pavel TišnovskýZlatý podporovatel
Jestli se bavime o vykreslovani, tak je to nejakych zhruba 400-600 policek na obrazovce - vsechno to jsou normalni bitmapy s jednobitovou maskou. Pokud jde o zmenu stavu modelu, porad tady mas vypocetni silu, ktera se prakticky nelisi od jinych kompilovanych jazyku - vzdyt ten model je predstavovan +- stejnym mnozstvim objektu.
Pokud mas na mysli rychlost javovskych programku, kde se vytvari a zase rusi tisice objektu za sekundu, tak presne toto *neni* ten pripad - zakladni model nacpeme do 2D pole, vlaky atd. mutable objekty, naprosta vetsina stavovych promennych jsou inty.
Co uznam je to, ze se o tu predelavku asi nikdo jeste nepokusil, takze nemuzeme porovnavat v praxi, nicmene TT neni prikladem aplikace, kde by Java ztracela (a to z toho duvodu, ze se zcela obejdou ty knihovny, ktere jsou pomaly kvuli d******e panu ze Sunu a Oraclu).
-
Vypocetne tolik Minecraft narocny neni, pametova narocnost je stale opakovana, ale koho to zajima? Pamet je dneska tak levna, ze kvuli tomu vyrobci krachuji. Na hru, kterou spustim, zahraju si a vypnu, me fakt nezajima jestli mi to sezere vic nebo min, k nicemu jinemu tu pamet v tu chvili stejne nepotrebuju. Myslet si, ze hra jako TT by se nestihala vykreslovat je opravdu uz spis na diagnozu nez diskuzi, protoze diskuter ma ocividne osobni problem s Javou. Java je pro hry jako Minecraft nebo TT v dnesni dobe jako stvorena.
-
Rax (neregistrovaný)
To si podlehl propagandě a nemáš vlastní zkušenosti. Původní TTD dá odhadem více než 20 fps, do toho si můžeš otevřít asi 15 oken s výhledem na jiné části plochy, stíhá jezdit se stovkami vozidel, včetně směrování na tratích a k tomu asi 8 AI. V Javě se ti to v této pětiletce nepodaří.
-
Opravdu myslis, ze v desktopu/notebooku jsou ECC bezne ci nutne? Intel ECC podporuje snad jen u serverove platformy a AMD snad uz taky jen servery a non-APU desktopu (tj. AM3+ apod. a tam je to stejne jeste v rukou vyrobce desky). Kdyz uz bys stavel nejaky narocny workstation na nejake takove platforme, da se predpokladat, ze tam budes mit i tak dost pameti a to ne kvuli hram. Navic, to cele nafukujes. Zas tak cerne to neni, ano, je to v Jave a zere to vic, ale neni to kriticke, ze bys nahle nutne potreboval ohromne mnozstvi pameti a musel neco dokupovat. To, co je dnes bezne mit pro plynuly chod systemu, nenazranych browseru a potrebnych aplikaci je vic nez dostatecne pro samotnou hru. Pamet je od toho, aby se pouzivala, ne aby se nadavalo, ze neco zere vic nez si myslime, ze je nutne.
-
bkralik (neregistrovaný)
Promiň, ale nepřesvědčíš mě. Nejspíš to je tím, že minecraft psalo nějaký prase, ale když ti hra náhodně hází OOM error (měl jsem 2 GB ram a windows 7), tak to asi není normální.
To že na rozjetí serveru bez GUI potřebuješ taky alespoň 2 GB ram pro javu (takže reálně na celej server minimálně 2.5 GB) se mi zdá taky nenormální.Podle mě tenhle argument "proč hledět na paměťovou náročnost když dnes máme xx GB ram za yyy kč" dost nerozumnej...
-
v pradavnych dobach pocitacovych pociatkov program naprogramovany v assembleri bolo vyrazne citit, co do rychlosti, velkosti, efektivity .. taky Volkov Commander napriklad .. boli to top kusky citelne odlisne od vsetkeho ostatneho ..
predstavit si tak win7 kompletne napisany v assembleri :D :D
celkova velkost 111 MB a ta rychlost svetla .. :D :D -
Biktop (neregistrovaný)
To není pravda. Celý život programuji v Assembleru a nepozoruji nižší produktivitu. Dělat v Assembleru znamená nejdříve si to pořádně promyslet, sestavit si potřebná makra a konvence a pak už to jde stejně rychle, jako v čemkoli jiném. Zásadní nevýhodou Assembleru je jeho nepřenositelnost.
Že vývoj v Assembleru trvá déle jsou prostě báchorky od lidí, kteří se v něm nikdy programovat doopravdy nenaučili. Ostatně i např. jazyk Forth je jen k dokonalosti dovedený "metamakroassembler".
Pracné bylo, když jsme v kroužku ve čtverečkovaném sešitě programovali ve strojáku IQ-151. Ale makroassembler - to je hodně mocný nástroj. Takový program vůbec není nepřehledný, když si můžete pojmenovat pozice v zásobníku relativně k bázovému registru a zavést aliasy pro jména registrů, uděláte si makro na volání podprogramů atd. Docela nechápu ty údivy. Programovalo se tak celá desetiletí a přitom nešlo o žádné malé prográmky, jak si mnozí neustále představují. Každý program se dá faktorizovat tak, aby šel normálně zvládnout v Assembleru.
-
Přezdívka je povinná (neregistrovaný)
A píšeš programy co mají 111MB jak napsal . voc? Spočítej si kolik by to bylo instrukcí. Tohle se prostě ani s perfektním plánováním nedá zvládnout. A to neřeším, že takhle velký program bude v čase potřeba dost podstatně upravovat. Jaký smysl by mělo psát programy ve vyšších jazycích, když by programátoři neměli vyšší efektivitu?
-
Biktop (neregistrovaný)
NIKDO nepíše programy, co mají 111 MB! :-D To totiž není vůbec ani zdaleka v lidských silách. Naprostou většinu z těch 111 MB tvoří kód, který autor toho programu ve skutečnosti vůbec NEVYTVOŘIL. A takto je samozřejmě možné programovat v čemkoli, třeba ve strojáku. :-) Především je lhostejné, kolik má výsledný kód. Porovnávat můžeme počty napsaných řádků, počty modulů, tříd, procedur apod. A na této úrovni se dostáváme na srovnatelná čísla u čehokoli. Takové frameworky, jako vidíme kolem C++, Javy atp., by šly vybudovat i kolem Assembleru. Jenže to nikdo z pochopitelných důvodů nedělá.
Smysl používat vyšší jazyky je v první řadě v jejich přenositelnosti - jak těch programů, tak jejich autorů. Pokud jde o efektivitu produktivity, tak se naopak s přibývajícím rozsahem prací všechny jazyky, včetně Assembleru, sbližují. Napsat "write'Hello, world!'" je pochopitelně jednodušší než v Assembleru definovat řetězec, napsat kód pro spočítání jeho délky (má-li to být aspoň trochu univerzální), vypsání jeho písmenek atd. Ale jakmile takové procedury už mám, začne to vše být velmi srovnatelné.
-
Přezdívka je povinná (neregistrovaný)
Já si občas na root.cz připadám jak v blázinci. Ve fórech se považuje gentoo za distribuci pro začátečníky, java je prý neskutečně pomalý a zkriplený jazyk, největší zábava na páteční půlnoc je být první v diskuzi pod komiksem a efektivita programování v assembleru je stejná jako ve vyšších jazycích. Evidentně sem buď chodí mimozemšťané nebo zde platí jiné přírodní zákony.
-
Rax (neregistrovaný)
Normálně lžeš a nebojím se ti to říct do očí. V ASM si možná plácáš něco pro osmibitové jednočipy, tam bych to chápal, ale nikdo nepíše v ASM něco velkého jako třeba účetnictví Pohoda nebo Microsoft Office nebo Adobe Photoshop. Většina vyšších jazyků jako třeba C/C++ vznikla právě proto, že vývoj v assembleru byl a je neúnosně pomalý.
-
omg (neregistrovaný)
vetsina jeste vyssich jazyku vznikla proto, ze vyssi jazyky proti assembleru zavadi nesmyslna omezeni, ktera se musi slozite obchazet a zdrzuji zhruba stejne jako rvat to tam v assembleru. problem je uz akorat v tom, ze ty super vysoke jazyky jsou po odstraneni techto omezeni trpi stejnymi nedostatky jako assembler (s vyjimkou neprenositelnosti projektu).
-
JS (neregistrovaný)
Jelikoz v praci spravuji programy napsane casto v assembleru, ono se to da do urcite velikosti. Pak to zacne byt maler a velky. Treba je potiz zmenit nekde datovou strukturu. Takze takhle jednoduse to bohuzel neplati, je to silne nelinearni; zkratka vetsi programy vyzaduji zcela novy pristup.
-
Nelze nezmínit pár triků pro TTD (i když něco se zde už v předchozích dílech zmiňovalo) - např. likvidaci konkurenčních automobilů a autobusů přejížděním rychlou lokomotivou (pro lokomotivu nedestruktivní), či likvidaci konkurenčních vlaků vlastním vlakem (pro lokomotivu destruktivní), pokud se natáhly koleje až za stanici konkurenta, kde jeho vlak zrovna nakládá.
Také jsem přišel na jednu chybku, na které se dalo slušně vydělat - pokud byl dosažen maximální limit vlaků, kdy bylo možné postavit jen jedno poslední vozidlo a postavila se lokomotiva skládající se ze dvou vozů, tak se objevila jen půlka tohoto vlaku a zisk z jeho následného prodeje značně převýšil pořizovací náklady (možno pakovat stále).
Dále by možná stálo za to v článku zmínit vliv vedení měst, které vám při nespokojenosti snadno mohlo zabránit v postavení stanice, nebo bourání nepohodlných domů ve městě.
-
ondro (neregistrovaný)
Pvodne TT malo niekolko nedokonalosti. najviac mi vadilo, ze bolo mozne dosiahnut len urcitu sumu zisku(nepametam presne aku ale bola vysoka). Ak som ju prekrocil, tak cely financny model hry sa zhrutil a prestal som zarabat(prerabal som). Asi obmedzenie stylu 640kB :)
Dalej som vyuzival nedokonalost hry s pokrytim uzemia. Ak sa postavili rozne stanice vedla seba, tak sa ich pokrytie spojilo. To spojenie trvalo aj ked som postavil viacero stanic a nechal len tie posledne(postavil som zeleznicu a pomocou zastavok pre auta a ich postupnym presuvanim a buranim som nakoniec vdaka jednej zeleznicnej stanici a zastavke pokryl cele mesto).
Ten trik s nicenim konkurencnych vlakov som tiez vyuzival.Neviem, ci tieto chyby boli odstranene.
Auta som pouzival len v zaciatkoch na rozbehnutie, nasledne boli neefektivne.
Nakoniec som vyuzival hlavne vlaky, potom lietadla a niekolko lodi(len na trasach, kde zarabali viacej ako ine dopravne prostiredky).Dost som vyuzival dotovanie miest na ich rast(to dost pomahalo). Dalej buranie budov, upravu terenu kvoli idealnej polohe stanic, idelanej dlzke a profilu trate. Limitujuci bol pocet vozidiel, tak som vyberal len to, co bolo najziskovejsie.
Je to jedna z mala hier, ktoru som si kupil. Dostalo sa mi do ruk demo a tato hra ma v momente dostala.
-
Jirka1 (neregistrovaný)
Původní TT mělo neošetřené přetečení, takže po dosáhnutí určitého množství peněz (mám pocit že 4G$) došlo k přetečení, hráč se stal dlužníkem a do 1/2 roku tak zbankrotoval. V OpenTTD byla tato chyba opravena jen částečně, počítadlo se na příslušné částce zastavilo a ke krachu nedošlo. Ostatní hodnoty ale ošetřeny nebyly, takže hodnota společnosti byla záporná. Roční zisk, který se počítal z rozdílu stavu peněz, byl +- 0, což se občas projevilo na zhoršeném hodnocení hráče.
Jinak celý ekonomický model měl zavedenou dost velkou inflaci, ale nepočítal s ní stejnoměrně i při udělování půjčky na rozjezd firmy. Asi po roce 2010 tak s přidělenou půjčkou prakticky nešlo postavit trať a koupit vlak. Stejně tak málo rostly příjmy ze silniční dopravy v poměru k nákladům - nejspíš byla příliš zvýhodněna rychlost, kterou dosahovaly jen vlaky a letadla. -
Pavel TišnovskýZlatý podporovatel
Jak pise Jirka1, bylo to "normalni" preteceni long cisel (64bitu). Dalo se toho vyuzit u triku s postavenim dlouheho tunelu, ktery stal vic nez 2 miliardy, potom doslo k preteceni do kladnych hodnot.
U Duny II, tedy u verze bez patchu, byl problem o dost vetsi, tam pretikal budget uz u 32768 kreditu, coz bylo dost malo.
-
Pavel TišnovskýZlatý podporovatel
Z testu na detech 5,7,10 let :-) Jim pripadl tento typ krajiny hodne neprehledny, neni to tak problem tech tovaren (ty jsou vtipne, i prevazene materialy) ale kostickovaneho povrchu. Zajimave je, ze davali prednost hlavne polopoustnimu svetu - byl nejprehlednejsi (i kdyz me se libi puvodni krajina).
-
Rax (neregistrovaný)
TTD je v C/C++, v ASM jsou maximálně jenom vybrané části. Na hře nepracoval jenom Sawyer, ale bylo to 15 až 20 lidí:
Chris Sawyer, Andrew Parton, Simon Foster, Alkis Alkiviades, John Broomhall, Andrew Parton, Mike Rudderham, Darren Kirby, Craig Lear, Andrew Luckett, Daniel Luton, Justin Manning, Philip McDonnell, Jason Sampson, Patrice Stauder, Donald Witcombe, Rick Haslam, Sarah Warburton, Sarah Kerr, Adrian Turner, Rob Davies, Peter Moreland, Jacqui Lyons
-
Jirka1 (neregistrovaný)
Logika semaforů v OpenTTD je popsána zde: http://wiki.openttd.org/Signals Není na ní nic složitého. Běžně stačí používat klasické jednokolejné semafory jako v TTD (ty první), u nádraží pak kombinaci vjezdového návěstidla s cestovým, která ale neumožňuje průjezd více vlaků zhlavím (křížením). Proto nakonec přibyly poslední 2 typy (PBS), což jsou inteligentní semafory, které počítají s postavení výhybek - takže přes jedno zhlaví mohou projíždět vlaky najednou v různých směrech, pokud se jejich cesta neprotíná.
-
Pavel TišnovskýZlatý podporovatel
Jediny vetsi problem se semafory je jejich uprava na trati, kde uz projizdi vlaky - nekdy se vlaky zmatou tak, ze zabloudi nebo do neceho narazi :)
-
lol (neregistrovaný)
Tak... teraz v jave spravis hello world, loaduje sa to 5 sekund, zozere 200 mega ram a na disketu sa to nevojde :) Hovorim si, ze svet IT ide zlym smerom. Programovanie malo ostat domenou genilnych ludi ala Sawyer. Robit programatorov z klikacov je cesta do zahuby. Jediny kto je z tohto stastny je asi len ten vyrobca HW - na rovnaku funkciu je treba vzdy lepsi, novsi a vykonnejsi hardware. Kde su tie casy demo parties so 64KB intrami...
-
JmJ (neregistrovaný)
TT ve vsech podobach radim mezi nejlepsi hry, ktere jsem kdy potkal. Mozna je to hra, kterou jsem hral uplne nejvic. Radim ji mezi river raid, solo flight, carmageddon nebo quake 3.
Openttd prineslo to, co mi ve hre vzdy chybelo a tak na tt frcim dodnes. Na nejvetsi mapu si vygeneruju cca 20 mest a trva mi rok realneho casu, nez vsechny mesta propojim. Jednu mapu jsem schopny hrat nekolik let.
Zde par screenshotu. To jsem jeste neuzival ten posledni typ navestidel :-)
http://barinka.net/share/pub/ttd/Katastrofa%20Transport,%208th%20Aug%202578.png
http://barinka.net/share/pub/ttd/Katastrofa%20Transport,%2014th%20Sep%202578.png
http://barinka.net/share/pub/ttd/Katastrofa%20Transport,%2021st%20Jul%202578.png
http://barinka.net/share/pub/ttd/Katastrofa%20Transport,%2024th%20May%202578.pngA male video z jizdy vlaku s oceli :-)
http://m.youtube.com/index?&desktop_uri=%2F#/watch?v=M4aZpx1AWUI
-
Pavel TišnovskýZlatý podporovatel
pekna krizovatka :-) Ve starem TTD to slo resit krizicimi se tunely, protoze v nich se vlaky nesrazely (taky bug, ale peknej :-)
-
Mě by zajímala jedna věc - hrál jsem kdysi jak původního Transport Tycoona, tak potom i Deluxe verzi. A vzpomínám si, že v tom původním byly i celkem reálné názvy vozidel - nejvíc patrné to bylo asi u letadel. Různé DC, Boeingy, Airbusy a tak. No a pak v TTD byly sice pro vozidla použité stejné sprity (například B747 s hrbem je dost typický), ale názvy byly nějaké jiné... Že by se ozvaly majitelé nějakých ochranných známek?
-
Sten (neregistrovaný)
Skutečné názvy byly v původním Transport Tycoonu, v Deluxe už byly přejmenované, právě kvůli ochranným známkám.
-
Pavel TišnovskýZlatý podporovatel
nojo však to taky odpovídá skutečnosti, akorát tam tuším chyběla japonská auta :-) Já jsem spíš narážel na to, že některé firmy (spíš jejich právní oddělení) se tváří, jak je strašně špatně, když se název této firmy nebo jejich výrobku používá jako obecný název a přitom je to podle mě ta nejlepší reklama.
