Vlákno názorů k článku
Valve potvrdila Steam pro Linux, nejprve bude pro Ubuntu
od anonym - Zajímalo by mě, zdali pojede L4D i na...
-
Lael Ophir (neregistrovaný)
Ukázat jim, že portovat na Linux stojí za to? To bude chtít trochu víc, než si koupit jednu starou hru. Left for Dead 2 se prodalo minimálně 11M licencí, GTA IV min 22M licencí atd. Aby vydavatelé dostali zprávu, musely by se hry na Linuxu zatraceně hodně prodávat.
Co se podle mě stane? Pár vydavatelů možná zkusí něco vydat i pro Linux, a pak si to spočítají. Pokud se na Linuxu budou prodávat zajímavé objemy, budou i áčkové tituly. Pokud prodeje budou malé, bude sice Steam pro Linux, ale prakticky žádné hry - tedy jako doteď. Protože Linux má na desktopu slabé jedno procento počítačů, vidím to spíše špatně.
-
Lael Ophir (neregistrovaný)
Zatím co na Linuxu je Indie Bundle novinka, na Windows jde o výprodej her, které jsou k dispozici už dlouhá léta (například na Steamu). Komu se ty hry líbily, koupil si je už kdysi zvlášť. Já například zaplatil jen za World of Goo EUR 20, a podobně s pár dalšími tituly z těch bundlů. Jinými slovy situace na Windows a Linuxu je rozdílná, takže srovnání pokulhává. Navíc těžko z výprodeje indie her s cenou do dvou dolarů něco usuzovat o poptávce po áčkových titulech za 50 EUR :)
BTW drobný problém Indie Bundle je v tom, že autoři her dostávají jen minimální část ze zisku. V sekci Software "counterfeits" si můžete přečíst i o "výhodách" uvolnění zdrojáku hry.
http://en.wikipedia.org/wiki/Indie_bundle#Criticism -
Duff (neregistrovaný)
A to že některé hry byly starší něco mění na tom, že je o jejich linuxové verze zájem?
World of Goo za EUR 20. To byl tedy dost předražený. Cena indie her se pohybuje kolem 10 euro nebo 15 dolarů. Myslím, že jsem u nás krabicovku kupoval tak za 200 nebo 250 korun.
V posledním bundlu byly Bastion a Lone Survivor což jsou hry z minulého roku (Lone Survivor možná letošní). V předposledním byla Botanicula, která je letošní ne více než půl roku stará.
To že se jednomu producentovy asi nelíbily podmínky a asi měl problém se s HB dohodnout a že druhý si stěžuje, že pozdější bundly se prodávaly pomaleji jako první, že limbo nebylo nativní, ale zabalené v CrossOver to je drtivá kritika která naprosto deklasuje zájem o ty hry. Uvolňovat zdrojáhy není požadavkem HB. Jo někteří lidé jsou hovada. Ale samozřejmě ne každému podmínky vyhovují.
Hlavním problémem u indie her je jak je dostat do povědomí a k zákazníkovi, což steam pro win a mac eliminuje a pro linux by to mohl udělat taky. A minimálně ty hry co mají mac port by nemělo být tak těžké portovat.
Na gog.com už taky pár měsíců visí požadavek na linuxůvé verze her pokud existují. A tam se nově prodávjí indie hry bez drm jako rojlíky. Ta nepřítomnost drm je pro mě mnohem důležitější než aby byly free nebo open source.
No a že velké korporace nebudou mít AAA hry pro linux hned po tom co linuxový steam vyjde. Korporace jsou vždy konzervativní a nové koncepty nechají prověřit startupy (tady nezávislou scénou) a pokud se ověří tak startupy koupí nebo se postí do stejné myšlenky. Uvidíme časem.
-
Nechci teď předvídat úspěch nebo neúspěch na Linuxu, ale rozeberu trošku, co to ovlivní.
První věc je, kdy se to výrobci vyplatí: musí platit současně obě tyto podmínky:
a) dodatečný výnos (prodeje na Linuxu mínus úbytek prodejů na Windows) bude vyšší než dodatečné náklady (tj. asi hlavně náklady na portaci, nikoli náklady na celý vývoj)
b) tato investice bude nejlepší možnou (tzn. musíme započítat tzv. náklady obětované příležitosti)Dodám, že náklady na portaci by měly právě Steam a Source engine stlačit dolů.
Zřejmě nelze hodnotit vynosnost jako prodeje na Windows * (podíl Linuxu / podíl Windows) i z dalších důvodů:
a) Ochota platit za software. Paradoxně může být u uživatelů Linuxu větší. Uvedu třeba http://www.latrine.cz/linuxaci-za-hudbu-nezaplati-ani-nahodou nebo fakt, že mnoho uživatelů Linuxu má OEM Windows a tak na licenci nic neušetří. Někdo tu uvedl Humble bundle Indie. Já zase radši nechci vědět, kolik jsem dohromady zaplatil za aplikace pro Android. (Ano, u Androidu ne všichni jsou ochotni platit, I ve srovnání s iOS. Asi to ale dost ovlivňují majitelé levnějších modelů.)
b) Konkurence: aspoň zpočátku pro Linux bude vyvíjet jen část výrobců. Budou na tomto trhu mít menší konkurenci, takže relativně (vzhledem k velikosti hráčské základny na dané platformě) větší zisk z jedné hry než na Windows. Pokud se podíl Linuxu na trhu (nebo spíš velikost Linuxové hráčské komunity) nezvětší, bude zde trvale menší konkurence. Pokud se zvětší, bude to signál pro další výrobce.
c) Podíl hráčské komunity na dané platformě - to může být největší problém Linuxu. Uvidíme. -
Lael Ophir (neregistrovaný)
Náklady na portaci budou nejspíš vysoké. Musíte najmout lidi, kteří píší pro Linux. Musíte najmout testery s různými distry Linuxu. A pak jsou tu náklady na support: musíte mít odborníky, kteří rozumí Linuxu. A musíte podporovat různá distra.
Linux má problém v malé uživatelské základně, které je cca 100x menší než na Windows. Ochota platit za hry by mohla s věcí zahýbat, jen pokud by na Linuxu byla *řádově* větší než na Windows. To by mě ale velmi překvapilo. Menší konkurence sice může zpočátku hrát jistou roli, ale podle mě to nespasí.
-
Lael Ophir (neregistrovaný)
No jo, id soft udělal s Linuxem díru do světa :). John Carmack prohlásil o portu hry Rage (mimochodem psané pro OpenGL) následující: "We are not currently scheduling native linux ports. It isn't out of the question, but I don't think we will be able to justify the work."
http://current.com/technology/90807671_john-carmack-discusses-linux-version-of-rage.htm -
opengl se mi sice libi, ale ty extensions to zabily.
Soucasny catalyst driver ma 231 opengl extensions. Pri psani rendereru je bohuzel dost zasadni problem zda je nejaka extension podporovana nebo ne.
OpenGL standard je podobnej J2EE - neni moc pouzitelnej bez custom rozsireni. Takhle to dopadne, kdyz se standardy navrhavaji co nejjednoduseji. Sice to pak umi naimplementovat kazdy, ale vzhledem k nekompatibilnim rozsirenim bez kterych se moc pracovat neda to standard neni.
Idsoft mel vsechno pro linux, takze ma bohaty zkusenosti kolik se toho na linuxu proda.
-
pavel (neregistrovaný)
Počkat! Extensions pro vývoj her už nejsou potřeba. To platilo za OGL 1.1, kde jste ho s pomocí extensions narvali na úroveň 2.0. Od dvojky už se daj psát hry na úrovni cca. DX9 úplně bez extensions (žádný arb shadery). Teď už máme OGL 3.3 a 4.x (ouha, doba se změnila :), které jsou podporované na dostatečné většině moderních karet. Ty umožňují čisté cokoliv co může vývojář potřebovat... Extensions jsou VÁŽNĚ už 5 let nepotřebné pro vývoj her (i aplikací).
-
Duff (neregistrovaný)
A portace z konzolí na windows je řádově jednodušší to jen musíte mít různé sestavy s vindows xp, vista, 7 a brzo 8 v různých verzích s různými verzemi knihoven různými service packy a záplatami a různými verzemi ovladačů. Potřebujete lidi co umí pro toho prostředí psát (gta4 a jiné sprzněné porty). Prostě velká herní firmy do toho hned nepůjdou jen až pokud jim poteče do bot.
-
Vysoké - v porovnání s čím? V porovnání s vývojem hry pro Windows (od nuly) asi moc ne. Tyto všechny náklady máte u Windows taky (navíc ta podpora je z velké části proporcionální k počtu koupených licencí). Podpora různých distribucí je už lepší argument, ale nejspíš taky moc nákladů nepřidá, pokud vůbec bude ta podpora oficiální. (Taky mohou říct: tady máte hru, oficiálně jede na Ubuntu, jinde za to neručíme.) Zvlášť pokud si s sebou hra ponese všechny knihovny.
Samotný vývoj hry, mapy, zvuky a částečně testování jsou značné náklady, které se platí jen jednou. Do dodatečných nákladů pro Linuxovou verzi nepatří.
Navíc část problémů s HW kompatibilitou snad vyřeší Source engine a část bude společná s Windows.
Pokud by podíl hráčů byl ve srovnání s Windows poloviční, díky menší konkurenci by se kupovalo desetkrát více her, byla by dvojnásobná ochota platit a dodatečné náklady na Linuxovou verzi by byly 10 % z nákladů na kompletní vývoj Windowsové verze, pak by i ta platforma se setinovou základnou byla schopna poskytnout stejný procentuálně výnos. (Čísla jsou to vycucaná z prstu. Chci ale naznačit, že to není nereálné.) Navíc při rostoucí konkurenci nebo při dochazejících nápadech na nové hry bude vývoj nových her pro Windows méně atraktivní a výrobci budou víc upřednosťovat portaci pro Linux. Pravda, při klesající konkurenci na Windows, rostoucí konkurenci na Linuxu a dalších a dalších nápadech na nové dobré hry bude zájem spíš menší, závisí na okolnostech.
-
Lael Ophir (neregistrovaný)
Náklady na podporu naopak nerostou proporcionálně k počtu licencí. Když máte deset uživatelů s Linuxem, potřebujete pár lidí na jejich support. Když těch lidí máte pět tisíc, stačí vám pořád těch samých pár lidí.
Náklady na portovávání jsou navíc k verzi pro Windows, a vydavatel si spočítá, kolik výnosů za ty náklady dostane. Podle mě nebude moc šťastný.Source Engine je jeden z mnoha, problém to neřeší.
Každý máme svůj náhled, necheme to rozsoudit historii. Ale obávám se, že jako obyčejně budu mít pravdu ;)
-
Lael Ophir (neregistrovaný)
A vy myslíte, že budoucnost nepatří .NETu a C#? ;) Pokud narážíte na WinRT, tak to je jen náhrada za Win32. Psát v .NETu DB engine nebo driver FS je sice teoreticky možné, ale za současných okolností to není dobré pro výkon (což by se mohlo změnit až s čistě .NET kernelem).
-
dip (neregistrovaný)
Zkuste mi tedy vysvetlit toto (Wikipedia):
"Windows Runtime, or WinRT, is Microsoft's 2011 programming model that forms the backbone of the new Metro-style apps (also known as Immersive) in their new Windows 8 operating system."
Tak jestli vy WinRT chapete jenom jako "nahradu" Win32 api, tzn. vec na psani driveru nebo databazi, tak asi zijeme kazdy v jinem vesmiru. Nebo Wikipedia lze. Jak to chapu ja, tak je vlajkove API pro Windows 8, bez ktereho byste ty uzasne dlazdicove aplikace tezko psal. Ale vy to pravdepodbne vydite jinak...
"Native C++ is a "first-class citizen" of the WinRT-platform."
Spojenim techto dvou vyroku (za predpokladu, ze jsou pravdive) opravdu tezko muzete tvrdit, ze budoucnost patri C# a .NETu.
Sam Microsoft kdesi tvrdil, ze se vraci k nativnimu kodu kvuli mensim narokum a setreni energie. Odpiskal Silverlight. Takze jestli doufate, ze nekdy ve strednedobe horizontu prijde navrat .NETu jako vseobecnemu API a dokonce .NET kernel, tak jste asi opravdu beznadejny optimista.
-
dip (neregistrovaný)
Tak se nad tim zkuste zamyslet.
I kdyz tady Lael cosi placa o tom, ze WinRT je jenom pro psani ovladacu a databazi, tvrzeni MS je diametralne odlisne a pro ne je WinRT jednoznacne vlajkove API pro jejich Win8 a Metro aplikace. Odklon od .NETu a C# je snad jasny, ne?
Kdyby mel byt C# (jazyk) a .NET (api) dal technologii cislo jedna, proc by zavadeli nove API (WinRT) a tvrdili, ze je pro ne C++ "first class citizen"?
Podle me(a nejen me) je to jednoznacne u-turn a naprosty navrat ke korenum a odsun .NETu mozna nekam na servery.
Nekdo to popisoval bojem dvou divizi v MS, kde jedna propaguje C++ a nativni kod a druha C# a managed kod. Ted pry zrovna vyhrala ta prvni...
-
V zásadě to zatím není ve sporu s tím, že by .NET byla jedna z možností pro WinRT a že by to bylo taky first class citizen. Třeba to finálních Windows 8 dají defaultně i .NET.
Neříkám, že se tak stane, jen říkám, že z uvedených informací nevyplývá, že se tak nestane nebo že se .NET odsune na druhou kolej.
-
dip (neregistrovaný)
Ale jakto? Neplette si .NET a C#. NET je API, c# je jazyk. A WinRT je API. Jak si predstavujete, ze .NET API bude moznosti pro WinRT API? Bud budete pouzivat pro vase programy .NET nebo WinRT. Kdyby .NET bylo vhodne API (spolu s managed kodem, VM atd.) pro Metro aplikace, tak by jej MS pouzil. Misto toho si zavedl uplne nove, vhodne pro nativni kod. Nejsem na toto expert, ale diky rozdilne povaze obou pujdou asi tezko kombinovat.
Pokud dam tolik penez do vyvoje API a s nim souvisejicich veci, tak pokud bych s nim byl spokojeny, nezavadel bych neco uplne jineho. Coz MS udelal a tim rika, ze .NET byl krok vedle. Jak to cist jinak nevim...
Ve Win8 asi bude .NET z duvodu kompatibility. Ale uz ne jako preferovane API pro psani novych Metro programu.
-
Lael Ophir (neregistrovaný)
WinRT je evolucí .NETu. Mohl jste si všimnout, že WinRT components používají metadata .NETu, ať už jsou psané v jakémkoliv jazyce, a používají type system korespondující s .NETem. Výsledkem je situace, kdy můžete bezešvě (to je česky?) kombinovat kód v C#, JavaScriptu a C++/CX. Výkonově kritické komponenty, například DB server nebo HTML renderer, budou nejspíš napsané v C++/CX. A front-endy s formuláři a grafikou budou typicky psané v C#/.NET. Nakonec na té Wikipedii najdete i tohle: WinRT supports XAML-based .NET Metro-style applications which are primarily written in C# and VB.NET (and for the first time for XAML with Native Code using C++/CX).
Můžete si také všimnout, že research project Singularity OS v posledních iteracích řešil otázku kombinace managed a nativního kódu. Díky použití .NET metadat je ve WinRT situace taková, že je aplikaci úplně jedno, v jakém jazyce je ta která komponenta napsaná. V další fázi můžeme čekat "úklid", tedy model checking většiny komponent, končící u kernelu.
-
dip (neregistrovaný)
No, sice muzu kombinovat ruzne komponenty z ruznych jazyku, ale proc bych to mel sakra delat? Jenom proto, ze to jde? To, ze je neco podporovane, jeste neznamena, ze to tak ma byt primarne pouzito. To je spis z duvodu zpetne kompatibility, z ruvodu interoperability mezi ruznymi dodavteli, ale jako vyvojovy model pro nove projekty dost tezko.
Rekneme, ze pisu aplikaci typo Photoshop (nepisu, ale to co delam je podne - pulka gui, pulka vypocetni kod). V cem to mam teda podle vas psat?
Mam psat vypocty v C++ a GUI v C#? Jenom proto, ze prostredi si s tim poradi, se mam ja zblaznit a prechazet mezi dvema jazyky? Nebo proto, abyste mohl tvrdit, ze .NET neni na vedlejsi koleji?
A v cem mam psat dlazdicove metro?
Microsoft jasne rekl, ze "C++ is frist class citizen". Ja to ctu jako to, ze tento jazyk bude pro MS primarni a nejvic podporovany. Proto, ze VM a managed jazyky berou moc prostredku. Pak nevim, proc bych mel cas ztracet cas cimkoliv jinym a jeste to dokonce kombinovat mezi sebou.
-
Lael Ophir (neregistrovaný)
A proč byste psal třeba účetnictví v C++/CX, když je to složitější a na chyby náchylnější prostředí, než C#/.NET?
Aplikaci typu Photoshopu můžete napsat kompletně v C#, což ukazuje třeba Paint.NET. Filtry byste ale stejně psal v unmanaged C#, a stejně dobře je můžete napsat v C++/CX (klidně jeden v C# a druhý v C++/CX). Pro každou část si můžete vybrat ze C#, VB.NET, C++/CX, a v budoucnu z dalších jazyků.
Tenhle model je nakonec používaný už delší dobu. Když píšete třeba informační systém pro nemocnici, tak ho napíšete v něčem typu C#, VB.NET, historicky VB, Delphi, C++Builder apod. A například komponenty pro zobrazování dat z RTG a CT mohou být v C++/CX. Typicky vám je dodá externí firma, v každém případě na tom budou dělat jiní lidé. Ve WinRT je model podobný, jen je ta integrace je snazší. -
Lael Ophir (neregistrovaný)
No tak to jste si všimnul špatně. V C/C++ je velmi jednoduché udělat chybu. Pointery mohou ukazovat kamkoliv, snadno zapíšete za hranice pole nebo struktury, a existuje nespočet drobností typu if (a=1) (který vždy projde), switch fall through apod. V C# nebo Javě těžko uděláte buffer overrun, a garbage collection vás uchrání před většinou resource leaks.
-
V C++ jsou nejhorsi pretypovani. Prakticky se bez nich neobejdete a ztracite tim typovou kontrolu provadenou kompilatorem. Dalsi kapitolou je problem rucni spravy pameti a zdroju.
Kdo si mysli ze C++ ma stejnou chybovost jako C# tak pravdepodobne nedelal na zadnym vetsim projektu ktery ma statisice radku.
-
Sten (neregistrovaný)
Pokud máte na mysli přetypování (Type)value, tak ano, to je taky prasárna^Wpozůstatek po C. Pomocí static_cast a dynamic_cast typovou kontrolu neztrácíte.
Momentálně dělám na projektu, který má cca 250 000 řádků C++ a cca 300 000 řádků Javy a moc velký rozdíl v chybovosti mezi těmi jazyky teda nevidím
-
S dynamic_cast máte typovou kontrolu jen za běhu, se static_cast ani to. Ano, s dynamic_cast na tom jsem skoro* jako v Javě, ale tam to nemusím moc používat, protože APIčka na to jsou připravena a nemusím používat nic jako *void.
Vývoj v Javě je jednodušší ve více věcech. U OOP třeba odpadá nutnost řešit hlavičkové soubory, není potřeba řešit přímo includy (akorát importy - IDE dost pomůže), můžu v asi libovolném IDE prostě vytvořit třídu a nestarat se kvůli tomu o vytvoření souboru (IDE pořeší podle konvencí). No nevím, ale ačkoli Javu jako jazyk až tak nemusím (Scala je někde jinde...), přijde mi mnohem pohodlnější než C++. Někdy přímo kvůli jazyku, někdy kvůli podpoře IDE (pro Javu stačí náhodně zvolit, pro C++ jsem se nahledal).
*) dynamic_cast řeší chybový stav NULLem, JVM pomocí ClassCastException.
-
Sten (neregistrovaný)
dynamic_cast vyhazuje std::bad_cast, pokud castujete reference. A pointery byste castovat neměl, pokud k tomu nemáte speciální důvod.
Je pravda, že u C++ je s IDE problém, protože jich spousta není nic lepšího než editor se zvýrazněním syntaxe, ale třeba s KDevelopem taky nemusím řešit includy, protože je doplňuje sám.
-
No a jaky jsou nastroje na vyhledavani chyb v C++ ve stylu Findbugs a PMD (kdyz bereme jen ty opensource).
Problemem C++ je i to ze sice novejsi revize C++ umoznuji hezky veci, ale knihovny na to nejsou prizpusobene a tak se to nepouziva.
Dalsi veci jsou exceptions, vetsina knihoven to nepouziva aby se vyhnula resource leakum.
Javovsky projekty co tu mame jdou malo kdy pod milion radku, Nejvetsi C++ veci tu maji 600k a 850k - vyvoj uz jde dost pomalu.
-
Sten (neregistrovaný)
Pokud je programátor prase, tak to posere v libovolném jazyce, i když je pravda, že C# mu to trošku znesnadní.
Raw pointery není radno v C++ používat a chytré pointery si tohle hlídají. To samé s raw poly.
Jak v C++ zapíšete za hranici struktury?
if (a=1): -Wall -Werror a pá pá ;-) (No, je možný, že MS kompilátor tady zaspal)
Ach ano, ono je v managovaných jazycích tak strašně těžké nevědomky udělat cyklus odkazovaný z nějaké statické proměnné (ukázka pro Javu, ale určitě to půjde stejně i v C#) ;-)
-
Smart pointery - pokud s tím nějaká knihovna nepočítá, tak to moc práce neusnadní. (Jak kdy.) Navíc při reference countingu je potřeba dát si pozor na cykly.
K if(a=1): to je dobrá věc, Java zde ale jde trošku dál s typovou bezpečností - požaduje boolean.
Cyklus v JVM ani .NETu nevadí (v PHP už dokonce taky nevadí - od 5.3), problém je spíš ten neodregistrovaný listener.
-
a) .NET a C# jsou naprosto neperspektivní technologie, podobně jako ASP. Sám Mrkvosoft je potají nahrazuje novými (šmejdy).
b) Pravdu jste zatím téměř nikdy neměl. Mám Vám např. připomenout, jaký jste předpovídal výsledek soudního sporu Oracle-Google? LOL!
c) Portace jakékoliv hry na Linux vychází cca na 0 % nákladů, pokud použijete při jejím návrhu a implementaci multiplatformní technologie a NE Mrkvosoftí šmejdy.
-
a) ASP nahradil MS novějším ASP.NET, který s ASP moc společného nemá. O dalším nahrazování zde nevím. Ano, MS přišel s Razorem (nebo jak se tomu říká), ale to nejspíš nemyslí jako náhradu ASP.NET. (Mimochodem, nejede Razor taky na .NETu?)
Je možné, že .NET čeká něco podobného jako Javu - na desktopu se moc neuchytí, ale na serverech ano.Do b) se míchat nebudu, statistiky si nevedu.
c) Diskutovali jsme situaci, kdy se při vývoji použije multiplatformní Source engine a Steam. I tady jsou nějaké dodatečné náklady. (Ale nebudu se opakovat.) Čím nižší, tím lépe pro hráče na Linuxu.
Volba enginu a technologií je taky otázka nákladů. S některými vyjde vývoj dané hry (aplikace, IS, ...) levněji a s některými dráž. Pochybuju, že bude mnoho firem volit striktně multiplatformní engine a knihovny jen kvůli tomu, že jsou multiplatformní. Sama multiplatformnost je určitě výhodou, ale striktní volba multiplatformního řešení je asi jako "dát přednost analnímu sexu, protože je multiplatformní". Multiplatformnost je výhoda, ale ne dogma. Pokud z možností vybereme a) tu nejlepší multiplatformní a b) tu nejlepší pro Windows (volba bude samozřejmě podle toho, co chceme vyvíjet apod.), mohou nastat tyto situace:
i) Obě možnosti jsou stejné, pak není co řešit. Náklady na volbu multiplatformního řešení jsou nulové.
ii) Vybíráme mezi multiplatformní (ale horší) a jednoplatformní (ale lepší). Náklady (nebo snížené příjmy) tu v nějaké podobě jsou.Další náklady budou i u "multiplatformního řešení zdarma" (tedy v situaci, kdy bych multiplatformní řešení vybral, i kdyby mi na této vlastnosti vůbec nezáleželo). Protože nic multiplatformního není multiplatformní dokonale (snad ani Brainfuck), je potřeba testovat, řešit nekompatibility, je potřeba - vlastně se to již řešilo. Multiplatformní řešení tyto náklady umí snížit (pokud to není úplný sh*t), ale asi ne na nulu.
Dále tu jsou tzv. náklady obětované příležitosti. Názorně: můžete svůj vás investovat do práce se mzdou 50 CZK/hod. Uděláte to? Pokud nemáte k dispozici lepší práci, asi ano. Pokud máte jinou nabídku práce se mzdou třeba 1000 CZK/hod, budete kvůli nákladům obětované ve výši 1000 CZK/hod tratit (ve srovnání s možností lepší práce) 950 CZK/hod. (Pod mzdou mám namysli "superčistou mzdu" - po odečtení nákladů na cestování (i časových), započítání vlivu pracovního prostředí na zdraví apod. Patří sem samozřejmě i nucené náklady - daně.) Podobně to funguje u portace hry na jinou platformu - i pokud by to bylo ziskové, může to být málo, pokud dojde třeba k 1% zhodnocení. Vývoj nové hry poskytne nejspíš větší zhodnocení (to poskytnou i spořicí účty, aspoň u některých měn, takže asi jen blázen by se kvůli 1% zhodnocení pouštěl do vývoje hry).
Dodatečné náklady tu tedy jsou, dodatečné příjmy samozřejmě taky. Je pak jen otázka, jestli dodatečné příjmy budou vyšší než dodatečné náklady (včetně nákladů obětované příležitosti). Pokud ano, vyplatí se to, pokud ne, nevyplatí se to.
-
XMen (neregistrovaný)
no zatial to nevypada tak, zeby mu buducnost mala patrit viac nez teraz. Svoj podiel uz ma a vobec to nevypada tak, zeby mal v buducnosti rast (nepocitam mobilne platformy). Inak co sa tyka winrt, tak od toho si M$ naozaj slubuje vela. Pre mobilne platformy to bude hlavna vetva a vobec to nevyzera tak, zeby bolo pouzitelne iba pre pisanie nejakych driverov.
-
V případě telefonické podpory by muselo být relativně víc lidí pro Linux, v případě "odpovíme do tří pracovních dnů" ani ne.
> Source Engine je jeden z mnoha, problém to neřeší.
Dokud Linux bude trhem jen pro část her, není to problém: budou se portovat primárně ty na Source engine. A pokud časem bude Linux větším trhem pro hry, myslím, že se portuje mnohem víc enginů.> necheme to rozsoudit historii
Tak nějak.
BTW: Já jsem neříkal, že to bude mít úspěch. Já říkal, že to není až tak nereálné, jak se může zdát podle podílů obou platforem. Neřeším to do detailů, nemám akcie herních firem. -
> MacOS má unixové jádro (protože společnost Apple nebyla schopná vyvinout nic lepšího)
To ešte nikto ;-)
> ale primární API nemá s UNIXy nic společného.
Z pohľadu hier má Mac rozdielne hlavne API pre zvuk. Okienka hry príliš neriešia a OpenGL je proste OpenGL. Najväčší problém bude mať samotné Valve a to s portáciou klienta. Najväčší ale neveľký, nakoľko je ich GUI kompletne postavené na Webkite a ne-grafická časť pre linux už dávno existuje.
