Cities: Skylines Dead Effect 2 Ori and the Blind Forest Lara Croft: Relic Run
..és a sor bőven folytatható. Teljesen más a Unity, mint egy Game Maker, és kár úgy fikáznod valamit, hogy sosem próbáltad ki. A labda pattintgatós játékból meg kihagyod, hogy mostanában nem elég hogy megcsinálod a játékot, nem árt ha ez fut Android/iOS kombón és eléri az adott platform service-ait (pl. Play Services, Admob). Ami Unity-ben egy-egy plugin, illetve egy-egy klikk a build, míg ezt only C-ben elég sokáig fog tartani összehozni.
@Matzi: sorry, ezt közben írtam. De Geri, válaszolj az általános topicban
Ezt a hozzászólást gopher módosította (2016.12.15 16:15 GMT+1 óra, ---)
Igen pont arról volt szó, hogy nem programozók fejlesztenek, már amennyire a pár soros fgv alapú scriptelést, meg a visual scriptinget a nem programozók csoportjának tekintjük. Szóval igen, nekik már az is sok, hogy van egy engine/lib, amit le kell fordítani forrásból, esetleg linkelni, vagy kódolni C/C++ ban, ezt mint negatívumot hozzák fel már kapásból és már nem is foglalkoznak vele. Még a "maker" motoroknál is kifogás, ha nem elég egyszerű a használata a közel 0 programozás mellett is, nincsen mondjuk match3, vagy booble template, hanem dokumentációkat kell olvasni (phejj). Hátrány, hogy egy Hello alkalmazás is 200 mb és nyilván szuboptimális lesz az eredmény egy sokféle igénynek megfelelő motorral, egy adott célra kifejlesztettel szemben.
Most a JF azt a korszakát éli, ami az üzleti szoftvereknél volt a 90-es években. Szakértői rendszerek, vizuális fejlesztői eszközök voltak, ahol pár kattintással szinte 0 programozással lehetett létrehozni alkalmazásokat. (Progress, Magic stb.) Aztán rájöttek, hogy egyéni igényeknek nem lehet megfelelni ilyen "maker" eszközökkel és ma már még a felhasználói felületet is programozással kell létrehozni (lásd WPF). Szóval majd lehet a JF is túljut ezen az időszakon, ha lesz rá igény, ki tudja.
szerintem egyszerűen arról van szó, hogy parallax, szerintem egy valamihez hozzá kell pattintani egy labdát jellegű játékot egyszerűbben megcsinálsz mondjuk C-ben mint bármi másban pusztán azért, mert C/c++-ban szabadabban és nagyon gyorsan meg tudod csinálni hozzá az azt hajtó logikát és koordinátageometriát, míg mondjuk egy librarykból összedobált szkriptelőtool erre nem biztos, hogy alkalmas pusztán azért, mert ha ehhez a logikához valami épp nincs leimplementálva mellé, akkor egy ilyen környezetben erősen valószínű, hogy érdemben nem is fogod tudni leimplementálni. mivel a c# a statok szerint már halott, mondjuk előlegezzük meg, hogy egy ilyen tetszőleges toolban is vagy C-vel, c++-al, vagy esetleg javaval, basiccel, vagy a tool saját nyelvével kell majd dolgozni eleve, tehát ebből a szempontból nincs különbség. egy alapvető engine néhány ezer sor valamilyen tetszőleges apira építve (de ha meg valaki vadállat eléggé, az is megvan 2ezerrel több sorból, ha nagyon akarja), és akkor az tud már keyframe animot, meg alapvető effekteket is, elég mondjuk 10 évente újat írni belőle. középiskolás mateknál sem kell sehová több. tehát nem egy olyan traumatikus programozási probléma, amit el kell kerülni. a munkának talán 1-2%-át teszi ki, az adott játékban lévő kódnak talán 5-10%-át. a többi meg mondjuk az engine azon része, ami már a konkrét játékot vezérli - pl fps esetén egy fps logic ami irányítja az npc-ket, a fegyverek lövéseit, meg mondjuk azt, hogy a falon ne sétálj át, meg a töltény se mindenhol menjen át. tehát egyszerűen arról van szó, hogy aki ezt is le akarja spórolni arra hivatkozva, hogy milyen bonyolult, az általában nem egy rendes programozó, de még csak nem is egy rendes játékfejlesztő, ugyanis az engine magjának a leimplementálása több nagyságrenddel egyszerűbb, mint mondjuk felhúzni egy pokemon-rpg harcrendszert. ha az első nem megy neki, akkor a második sem fog. hogy akar egy 40ezer soros battle logicot lekódolni, ha az 5 ezer soros enginetől összefossa magát valaki, hogy az milyen bonyolult? sehogy. ezzel nem spórol sem időt, se semmit, csak a világ felé teszi a szépet, hogy ő milyen király, meg hogy mennyit haladt, és hogy már wasd-vel lehet repkedni benne, ő itt a király. így aztán a kezei közül kikerülő alkotások is szarok, mint ahogy mondjuk unity kapcsán látjuk a sok hulladékot. az eredmény aztán nem komolyan vehető, nem eladható, nem továbbfejleszthető, 10x nagyobb, 5x annyi erőforrást használ, tud pár ezer letöltést és max 40 eladást, azok is a haverjai a fórumokról... vannak persze jó enginek, csak azok eléggé célirányosak szoktak lenni, nem ilyen toolcopy, szintűek, de ha valaki ténylegesen alkotni akar valamit, akkor azokat is érdemes hanyagolni.
ma már olyan egyszerűen meg lehet írni bármit normálisan, hisz az internet korát éljük, kontrasztban mondjuk 1995-el és 2000-el, amikor még csak 1-2 embernek volt internetje, semmiről nem lehetett semmit sem tudni, egy pixelt sem lehetett kirajzolni, mert minden információ rejtve és titkolva volt, hogy egyszerűen nincs értelme annak, hogy thirdparty toolokkal akadályozza az ember saját magát.
IdézetGeri :
nem hagyhatom, hogy idegen, homályos érdekeket szolgáló propaganda olyan inproduktív és rossz toolokra vigye rá az érdeklődőket, amelyekbe kár minden belefektetett energia.
Azt azért szögezzük le, hogy a C/C++ ban írjunk engine-t hullám már lecsengett jópár éve. Hozzá kell szoknod, hogy "maker" = fejlett editorral rendelkező motorral nem feltétlen programozók fejlesztik ma már a játékok többségét. Hobbiból, tanulási céllal, vagy valamilyen más indíttatásból van 1-2 fanatikus (pl én is), aki C/C++ szal ír engine-t, de ez ma már elenyésző, ebbe bele kell törődni. Egyszerűen nem éri meg ezzel vesződni, gyorsan, akár minden hónapban/héten ki kell termelni 1-1 játékot, amik szintje akár egy c64-es profi címet is alulmúlhat, de most erre van igény. Elnézem én is, hogy mikkel játszanak a mai fiatalok pl.: egy forgó geometriai forma lapjaihoz kell pattintani egy labdát, ennyi a játék, ettől mesze van van pl egy c64-es Turrican, Elite stb színvonal, vagy akár egy Mario is, de most ez a menő és ehhez "maker" eszközökkel kell futószalagon termelni, ez van. Ma, aki a játékfejlesztésbe fog inkább designer, mint programozó és olyan eszközt keres, ahol lehetőleg programozás nélkül is lehet fejleszteni. Mivel jól lehet automatizálni egy engine-t így a programozók innen ki is koptak, mint a dinoszauruszok.
Lord_Crusare, itt elsősorban a félig már megdöglött c#-ról volt szó a beszélgetésben - eleve a c++ topikban vagyunk - és annak kapcsán lett megemlítve az unity talán parallax részéről, hogy a c# és unity kombó micsoda jelentős meg fantasztikus dolog (hát nem az). az már csak hab a tortán, hogy itt a c#+unity házassággal a sánta a hátára veszi a púpot, tehát mindkét megoldás önmagában is rossz, hát még együtt...
és miért baj az, hogy az unityt a game makerhez hasonlítom? a konkrét működési elve nem lényeges ahhoz, hogy a két dolgot párhuzamba állítsam. nem kell értenem ahhoz a ledek tervezéséhez, meg a wolfram szál izzásához, hogy össze tudjam hasonlítani a két izzót abból a szempontból, hogy melyiket veszem meg. a game maker egy nagyon komoly tool, a maga idejében hasonló szerepet töltött be, mint most az unity, és alapvetően hasonló véleményem is volt róla eleinte, de ma már valamennyivel jobb a véleményem a game makerről, mint az unityről.
én se game makert se unityt személyesen nem láttam, meg használni nem is akartam - és a jövőben sem fogom egyiket sem, tehát személyesen problémám sem lehet egyikkel sem.
pusztán a fát terméséről bibliai elv alapján bennem egy igencsak kedvezőtlen kép alakult ki az unityről a benne elkészített dolgok alapján, meg alapvetően a közösségéről is azok alapján, amit eddig láttam tőlük, róluk. de például a c#-ot használtam egyszer már személyesen is, szóval annak sokkal személyesebb tapasztalatok alapján is nekimehetek, és ezt, ha szűkséges, meg is teszem., mert nem hagyhatom, hogy idegen, homályos érdekeket szolgáló propaganda olyan inproduktív és rossz toolokra vigye rá az érdeklődőket, amelyekbe kár minden belefektetett energia.
A piacképességet a kereslet határozza meg, amit pedig az eladott példányszámokból lehet lemérni. A felsorolt játékok kivétel nélkül elég durva példányszámmal keltek el, és ha utánanézel Steam-en, láthatod, hogy nem csak ezek a Unity-s játékok sikeresek ennyire.
Egyébként a vita C#-re vonatkozó része azért ferdítés (részemről is), mert szigorúan véve amivel a Unity-t scriptelik, az igazából nem C#, csak úgy néz ki. Épp ezért az ilyen statisztikákba általában nem szokták beleszámítani.
A "böki a csőröd" részt inkább arra értem, hogy anélkül, hogy utánanéznél a Unity működési elvének, támadod és a game makerhez hasonlítgatod (elárulom, a kettő bőven nem ugyanaz a szint, a Unity-hez azért vastagon tudni kell programozni is). Mivel agyatlanul nekimész újra és újra, meg automatikusan feltételezed, hogy rossz, ezért gondolom, hogy neked kifejezetten valami személyes problémád van az ilyesmivel.
Idézetami neked valamiért nagyon böki a csőröd, és ezért valótlan dolgokat próbálsz állítani
miért bökné, mi hasznom, vagy károm származik belőle? valótlanságot meg nem állítottam, amiket leírtam. amiket belinkeltél, azok sem nagyrészt épp a piacképesség csúcsai, főleg ilyen ár mellett nem. érvelési szempontból azért ez sem valami nagy érv, hogy van olyan, ahol az unity sikeres játék mögött dohog, mert hát biztos, a kivétel erősíti a szabályt alapon a szovjetunióból is kerültek ki jó termékek, csak épp a döntő többség mégsem volt piacképes, mint ahogy unity esetén sem az.
tessék, itt egy könnyűszerrel kikereshető tényszerű számadat: például a c# 4 év alatt elvesztette a piaci részesedése 70%-át a tiobe index alapján. ez például egy tény, és nem vélemény. biztos nem azért, mert olyan nagyon szupcsi unitys játékokat írtak vele.
Itt arról van szó, hogy továbbra is bőven készülnek piacképes játékok C# alatt, ami neked valamiért nagyon böki a csőröd, és ezért valótlan dolgokat próbálsz állítani. A statisztika nem hazudik. Többszázezer, esetenként milliós eladással rendelkező játékokról van szó, amiket Unity-vel készítettek. Tehát, a rendszer működik és sokan használják, sikerrel.
Ezekután az, hogy neked ezek nem tetszenek, érvelési szempontból lényegtelen. Az én véleményem is az. Egyszerűen arról van szó, hogy az általad tényként közölt információk teljességgel alaptalanok és könnyűszerrel cáfolhatók.
ha szimbólumokban egyáltalán nem akarnánk gondolkodni, és szigorúan szó szerint vesszük a wasd-vel való röpködést, akkor nyilván túlmutatnak... mondjuk a quern nem annyira ugorja meg még ezt sem
nem látom azt, hogy tévednék ennek az infrastruktúrának a megítélésével kapcsolatban, ezeket én nem tartom semmilyen szempontból sem említésre méltó alkotásoknak, persze elfogadom a véleményed, csak épp sehogy sem tudja ez megváltoztatni az enyémet.
Manapság már ezt használja a Ubisoft, a Square Enix is egyébként, hogy csak párat említsek a nagyobb nevek közül.
Tehát, visszatérve arra, amit eredetileg mondtál: igen, még bőven használják a C#-t arra, hogy "wasd-al repkedés"-nél komolyabb dolgokat fejlesszenek. A magánvéleményedhez jogod van, de a tények, amiket állítani próbálsz, tévesek.
IdézetLord_Crusare :
Ja, és tévedsz! A Pokemon GO is Unity-s.
a pokemon go egy szkript, ami pokemonokat renderel ki a kamera képe elé, és meghívja a c-ben megírt poke-enginet (mert androidra még nincs nekik enginejük vagy kóduk). maguk a pokemon játékok már nem unitysek.
Tyranny: ez a grafika és animáció nekem a red alert 2-t idézi fel, talán ha annak az enginét használják, nem kéne 6 giga ram ahhoz, hogy elindítsd. ebben a játékban az unity engine aligha csinál mást, minthogy kirajzolja a tájat és a karaktereket rajta, semmi extra, ezt akár egy sima for ciklussal is össze lehetett volna rakni, és akkor talán 50 euró/stück helyett ki lehetett volna hozni 20-30 euróért, hogy valaki esetleg meg is vegye. itt az unity szerintem sokkal több kérdést felvetett, mint amennyit megoldott, mert nem hiszem, hogy annak a pár modellnek a kirajzolása, és a tök béna keyframe animációhoz egy külsős enginet kellett mindenképp igénybevenni. 4 nap alatt 13 ember bírt hozzászólást írni hozzá, csak hogy érezzük, mekkora egy valami is ez (semekkora).
SUPERHOT: ez egy rohadtul gagyi effektes-pálcikaemberes játéknak tűnik, ha agyonvernének sem játszanék vele. tipikusan olyan játék, amit értelmes ember nem vesz meg, hanem csak az olyan unatkozó félmilliomos, aki már virtuális lobotómiát csinált a fején önkéntesen. teljesen mindegy, hogy miben írja meg az alkotó ezt a hatalmas semmit, akár 30 éves qbasicben is megírhatta volna, akkor sem töltötték volna le se többen és se kevesebben, inkább adta el a marketing meg az a fajta hírnév, ami a The Brick nevű butatelefont is 2014-ben.
Shadow Tactics: Blades of the Shogun: a grafikája tetszett, gondolom erre idomították rá a polygonfaragó szakmunkásokat, tényleg szép munkát végeztek az átvezető animációkon, de semmi extra. a játék maga már megintcsak az a tipikus red alert 2 szint csak 2016 révén 35 euróba kerül, meg 13 giga szabad helyet kér... meg egy kicsit több effekt van benne. nem mondom hogy rossz, mert nem rossz, csak valahogy ugyanazt érzem, mint a Tyranny esetében, mintha ugyanazt adnák el nekem ők is, csak ők most ilyen guminő-shogunokkal. ezzel sem játszanék soha a büdös életben.
Quern - Undying Thoughts: íme a lejjebb már említett teljesen értéktelen wasd-vel röpködős ,,játék'', ami annyit tud, hogy wasd-vel röpködsz benne, és játék. az engineírást láthatóan teljesen megspórolták, az unity mint modellrenderer szerepét tölti be, összedobtak hozzá pár modellt, aztán viszont látás, tessék, itt a játék, repkedj benne wasd-vel a föld fölött, mert az olyan fantasztikus dolog, meg fizess érte 23 eurót kedves pcbleb, elvégre néhány csillogó modell, amiben wasd-ben repkedhetsz, nyilván pénzt is ér. élvezhetetlen, egy percet se játszanék ezzel sem.
szerintem végtelen hosszan folytathatnánk, úgyis tudom, hogy az összes unitys game ugyanilyen mint ezek, te is nyilván ezért adtad példának ezeket. game makerben is ezerszer különbb alkotások születtek, mint ezek, ezek szerintem nem érnek szart sem.
Az Obsidian új szerepjátéka. Ha nem tudod kik ők, nos, ők korábban a StarWars: Knights of the Old Republicot készítették, valamint a Dungeon Siege és Fallout játékokat. A saját enginejüket cserélték Unity-re, mert a Unity jobb.
Az idei év egyik nagy dobása volt, majdnem 300 000 példányban kelt el csak Steamen (ezt az adatot itt tudod ellenőrizni: https://steamspy.com/app/322500 ). Ez egy Unity-s FPS.
A régi Commandos játékokat fejlesztő cég egy része új céget alapított. Ez egy Commandos-hoz hasonló taktikai játék, szintén Unity-s, jelenleg a toplisták élén van.
a pokemon nem azzal készült, meg a miku miku dance sem. más meg idén nem keltette fel az érdeklődésem. hogy józsika otthon mit kattint össze benne hogy 10 letöltést produkáljon, az meg pont hogy nem érdekel.
parallax, már eltemettünk egy managed dx-et, egy taot, meg egy xna-t annélkül, hogy bárki az univerzumban bármit is csinálni tudott volna velük. nagyon örülök neki, hogy semmire sem való csodalibrarykat ki tudsz googlizni te és mások c# alá az elmúlt 12 évből, csak valamit már fel kellett volna mutatnia velük a közösségnek, ami mondjuk bonyolultabb annál, hogy wasd-vel repkedni lehet benne. (ez mondjuk az egész unityre is vonatkozik).
ez c# alatt eddig még mindig nem sikerült senkinek, és ennek az a legvalószínűbb magyarázata, hogy aki képes valóban létrehozni valamit, az általában normális programnyelveken csinálja meg, nem ,,microsoft librarygyűjtemény for kóklers sharp'' jellegű függvénygyűjtemények fölött. ez egy technológiailag impotens nyelv.
az meg, hogy valamiben wasd-vel repkedni tudsz, az nem engine, hanem maximum egy ügyes renderer.
Idézet
Na és aztán már melyik krőzus kincse engine nincs fent a github-on?
én még olyan valamire való enginet nem láttam, ami opensource lett volna. nem nyílt forrású a wow alatti engine, nem nyílt forrású a final fantasy sorozat alatti engine, nem nyílt a pokemon. semmilyen valamire való játékengine nem nyílt forráskódú, semmilyen valamire való játék nem épül nyílt forrású enginere. egy komoly szoftver sosem nyílt forráskódú. egy nyílt forrású engine azért nyílt, mert semmit sem ér, eladhatatlan, vagy szar, vagy már annyira elavult, hogy semmire nem lehet már felhasználni, így aztán jó eséllyel kiadják a forráskódját. hisz az már nem eladható úgysem.
Idézet
Meg amúgy is dokumentáció nélkül mire mész több millió soros obfuscated JavaScript kóddal? Ami pénzt ér egy motorban az a support és a content, nem a forráskód.
hát ha egy engine több millió soros, akkor az annyira már nem szokott sokat érni, hisz túl van azon a bonyolultsági fokon, hogy átlátható, módosítható, felhasználható legyen - tehát lásd az előző pontban, semmit sem ér, így aztán ki is lehet adni nyugodtan, hisz úgysem ér semmit. nem attól lesz valamit is érő egy engine, hogy nagy, meghogy szét van dokumentálva. a cryengine sem ér semmit, ezért is ment csődbe a crytek karácsonyra. valaha persze ért, mint ahogy a quake3, meg a doom, csak ma már nem, ezért ki lehet adni. úgysem fog bennük senki SEMMIT, értsd szó szerint, SEMMIT sem csinálni.
IdézetGeri :
dehogy... a c#-ból már rég kiveszett minden 3d, meg úgy az egész nyelv is eltűnt szerencsére a süllyesztőben.
Aha, akkor a Xenko-ból el is tűnt a 3D, a Unity nem is használ C#-ot semmire, mert eltűnt a süllyesztőben. A valóság inkább az, hogy az MS cross-platform irányba terelte a .NET-et és már mindenütt ott van.
IdézetGeri :
ki a fene rakná már ki a nagy nehezen megírt forráskódját a weboldalba, nem azért dolgozik az ember, hogy lelopják
Na és aztán már melyik krőzus kincse engine nincs fent a github-on? Meg amúgy is dokumentáció nélkül mire mész több millió soros obfuscated JavaScript kóddal? Ami pénzt ér egy motorban az a support és a content, nem a forráskód.
Ezt a hozzászólást Parallax módosította (2016.12.13 11:40 GMT+1 óra, ---)
Ez a cikk egy hót baromság; az így megírt kódot krvanehéz átlátni is és használni is. "Milyen metódusai vannak az array-nek? array:: és nincs ott semmi wtf?" Egyébként meg nem hallott még precompiled header-ről?
IdézetParallax :
a motorokat már C#-al, meg JavaScript-el írják
dehogy... a c#-ból már rég kiveszett minden 3d, meg úgy az egész nyelv is eltűnt szerencsére a süllyesztőben. a javascript meg tulképp egy minimalisztikus c, változótípusok nélkül, de szinte csont ugyanaz a kód lefordul (vagy akár direktben a C-t is át lehet jsé konvertálni, van hozzá compiler). csak ugyebár ott az a baj, hogy ki a fene rakná már ki a nagy nehezen megírt forráskódját a weboldalba, nem azért dolgozik az ember, hogy lelopják.
@Geri
Hát, nekem azért egy kicsit túlzás, amit írsz.
Konkrétan ugye arról beszélt, hogy inkább fogja, és szétválasztja az adatot az operációtól, azaz nincs olyan osztály, ami függvényeket is definiál. Kicsit olyan, mint c#-ban az Extension különböző osztályokhoz - csak ott szebben van megoldva, mert az egész olyan lesz, mintha az adott osztály memberfüggvénye lenne.
Nekem alapvetően tetszik a blog, vannak olyan felvetései, amik engem is foglalkoztattak. Például az általad is emlegetett VFC tud problémás lenni nagy jelenetekre. Brute-force módon végigiterálni az elemeken nem túl szerencsés, ha meg mégis, akkor az lehet egy érdekes kérdés, hogy hogyan optimalizálod (többszálúsítás, SIMD, stb.)
@Parallax:
Na igen, én sem akartam fejest ugrani, és így csinálni, nekem alapvetően nem tetszik ez a megközelítés. Persze elviekben van értelme, de gyakorlatilag csak szenvedés lenne belőle. Ráadásul azzal a megkötéssel élni, hogy az ilyen osztályok memberjei publicok, de azért ne módosítsa már őket senki, mert "_"-al kezdődnek.
A c-hez legalább könnyebb interpretert írni. Persze azért kicsit elkésett azon filózni, hogy rossze e a C++ OOP, amikor a motorokat már C#-al, meg JavaScript-el írják. Több gyakorlat és tapasztalat kell a C++ és OOP használatához ez tény, de teljesen elvetni azért egy nagy architektúránál szerintem öngyilkosság.
instalok: hát ez még így is c++ és oop, csak leveszi a hangsúlyt a manapság divatos kényszeredett osztályképzésről.
mivel én ellene vagyok az oopnek, és egyáltalán nem is használom, mondhatnám ebből kifolyólag azt, hogy ez így jó. de persze nem mondom, mert nem jó, hisz mert mi értelme oopt használni úgy, hogy közben nem is használjuk, de mégis oop-vel fertőzött marad az egész kód, ráadásul feleslegesen?
ha valaki szakítani az oopvel, akkor szakítson vele rendesen, ez a félmegoldás, amit az emberke itt reklámoz, szerintem inkább tanuljon meg hatékonyan dolgozni C99-ben, minthogy oop szintaxissal akarjon procedurálisan programozni.
persze tudok oopzni is, csak épp nem szoktam, és elnézve ezeknek a kényszeredett oop-c++ usereknek a kódját azt látom, hogy az emberek 99%-a egyszerűen nem jól használja az oopt. egy objektumorientált kód az egész egyszerűen nem úgy néz ki, és általában ezekből az overlyobjectoriented dolgokból nem lesz soha semmi, csak javíthatatlan katyvasz, aminek a fejlesztési ideje a normális tízszerese. valahogy ezek az emberek úgy gondolják, hogyha létezik valamilyen nyelvi elem, akkor azt ki kell használni, mert csak. ha törik, ha szakad, csak épp utána senki más nem képes a kódot átlátni, csak ők.
pl mi a halál fasza ez? normális ember, aki megírni, dolgozni, eladni, és hónapok múlva is megérteni szeretne valamit, ilyen kódot soha a büdös életben nem ír le, egy normálisan megírt oop forráskód mégcsak közelről sem így néz ki. így programozni nem lehet, nem szabad.
aki ilyet leír, az egy mentális pótcselekvést csinál. addig sem kell a probléma érdemi részével dolgoznia, de legalább leírt valami bonyolultnak tűnő, semmire sem jó zagyvaságot, és ezt pszichológiai faktornak használva beadja magának, hogy fú de jól halad, meg minden faszom, közben meg nem, mert amíg ezt írta, addig sem csinált semmit, nem a programját írta, és ez alább ki is derül.
nem tudom, hogy ki a csávó, meg hogy mit ír, de a blogja alapján 3d-t, a frustum cullingról lamentál, de nem arról, hogy milyen módszerrel érdemes megcsinálnia, hanem látszik, hogy a csávó magával az implementálással küzd, amelyet mármár krőzus kincseként szeretne implementálni és elmaszkolni valahogy az eléggé hasznavehetetlen kódolási stílusához illesztve. látszik, hogy a normális esetben 20-30- de maximum 40-50 soros problémának csak a keretezése már önmagában egy blogbejegyzés szintű bonyolultságú dologgá eszkalálódik (nekem ez a feladat a régi enginemben összesen konkrétan 5 sor volt, amiben egy függvényhívás volt, ami 5 soros volt, amiben mégegy függvényhívás volt, ami 2 soros volt).
így programozni, dolgozni nem lehet, amikkel küzd, nem nagy bonyolultságú problémák, de ő azzá teszi őket.
szerintem ez a blog azt példázza, hogy hogyan nem lehet dolgozni.
Ezt a hozzászólást Geri módosította (2016.12.09 01:40 GMT+1 óra, ---)
Erről egyébként mit gondoltok? Nekem ez a megoldás kvázi a c++ és az egész OOP kidobása a kukába. Persze van benne logika, de ezek a dolgok nem véletlenül lettek kitalálva. Amiről írt, az igazából a pure C, pluszplusz nélkül.
@Instalok: Jó hát a pofa már átesett a ló túlsó oldalára és mindent wrapperelt olyat is, amit 2 primitív paraméterrel meg lehet oldani GC nélkül is. Így aztán csodálkozik, hogy kismilliom Lua object miatt teker a GC. A script csak event alapú vezérlésre való ("blueprint"-ek vezérlésére), nem arra, hogy a fél engine-t kiwrappereljük, aztán azzal írjunk egy nagy update ciklusba mindent.
A másik, hogy nem biztos, hogy mindig egyedül fogsz dolgozni és C++ coder már olyan, mint a fehér holló és aranyrudat kér napi fizetésnek, míg egy scriptelő minden bokorban terem fillérekért.
Nekem bejön ez a módszer, mert egyébként az editornak ígyis-úgyis wrapperelni kell bizonyos C++ osztályokat, hogy lehessen szerkeszteni, akkor meg már miért ne csináljam rendesen komplett script rendszerrel. Sima confighoz pedig table-vel meg lehet oldani az olvasás/mentés funkciót is, így editorban az egyszerűbb beállításokat is külön erőfeszítés nélkül lehet egy scaffold controllal kezelni.
Ezt a hozzászólást Parallax módosította (2016.12.07 07:56 GMT+1 óra, ---)
Hogy lehet megoldani, hogy a win input nélkül ne kapcsolja ki a monitort amikor ablakban fut a program? Még rajzol is, meg minden, mégis kikapcsol a monitor.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
Érdekes, pont tőle olvastam a múltkor valamit. Ennek a gamedev topicnak az alján ajánlotta valaki.
Látszik azért az is, hogy a Lua felvet néhány problémát is, amellett, hogy megold néhány másikat. Egyébként a pointerezgetés elkerülhető c++11 óta, a smart pointerek egész jók tudnak lenni, tulajdonképpen ugyan ott van vele az ember, mint c# esetén. Persze minden ízlés kérdése, évekkel ezelőtt is nézegettem a Lua-t, akkor nem igazán nyerte meg a tetszésemet, persze én nem is vagyok gameplay programmer.
@Instalok
Az editorra, mint külön fejlesztői eszközre gondoltam, ahol mehet a scriptelés,. scene szerkesztés, debug, stb. Igazából a játék logika sebesség intenzív részeket nem tartalmaz, így nagy jelentősége nincs annak a kis sebesség vesztésnek, amit mondjuk egy PlayMusic fgv hívás okozhat a wrapperen keresztül. Ha nagyon kell a sebesség még mindig ott van a LuaJit. Mivel a nyelv olyan egyszerű, mint a faék, azért nem olyan túl bonyolult annak a futtatása sem.
C++ scripttel próbálkoztam én is, de az már annyira összetett nyelv, hogy ahhoz futtatót írni 100%-ban azért kemény dió, teljes megoldás ehhez nem hiszem, hogy lesz. A másik, hogy játék logika szintjén én már nem akarok a pointerekkel, template-ekkel, meg egyebekkel vacakolni, csak gyorsan, produktívan dolgozni egy magas szintű API-val/nyelvvel és erre az ilyen dinamikus scriptek sokkal jobbak.
Még egy érdekesség:
Lua in the Stingray 3D game engine:
Egy próbát megér ez is, meg a te módszered is, aztán meglátod, hogy hosszútávon, amikor az engine-el több játékot is kell fejleszteni, több platformra is, melyik módszer a hatékonyabb.
@Parallax:
Ja hogy az az ablak nem egy külön alkalmazás, hanem az editor által megnyitott ablak.
Igen, a VS edit & continue nem az igazi, általában nem is erőltetem, ha ilyesmi van. Az lenne az előnye amúgy a c++ scriptnek, hogy release módban nyilván nem dll készülne belőle, hanem összelinkelődne azzal a kóddal, ami egy alkamazást indít el, így a lehető legnagyobb teljesítményt tudná adni, míg egy Lua esetén az interpretálás és extra függvényhívások mindig lassítanak.
Amit egyébként néztem még az a Runtime-Compiled-C++, ami egy egész jó ötlet egyébként. Megnézem azért majd a Lua-t is, köszi a tippet meg a videót!
Elveszett a mozgó aabb vágása polygonba programom (fogalmam sincs hogy hívját, de a lényeg, hogy belevágja az aabb-t a poligonba a mozgás iránya szerint és ráilleszti a legközelebbi pontra), tud valaki egy jó anyagot hozzá, hogy ne kelljen kikísérletezni? A válasz (vagyis a mozgatás) is fontos lenne, azzal voltak gondjaim egyszer.
u.i: nem intersection, hanem tulképp rávetíti az aabb-t a polyra.
A Half-Life 2: Deathmatch promóció megszűnt! [B¤°
Kezdetben volék az üresség. Ám akkor a Struktúrfüggöny megteremté az Urat.
DrunkenDragon* Blackwolf
Scene módosítása pause közben az editorral nem értem miért lenne probléma, ugyanúgy módosul, mint ahogy játék közben módosulnak az elemek, párhuzamosan pedig, hogy ezt hova és hogy mented már független ettől. A Lua pedig sokkal dinamikusabb és egyszerűbb, mint a C#, szóval ami Unity-vel megoldható az Lua-val egyszerűbben megoldható. Többek között a futás közbeni módosítás/kód újratöltés az egyik erőssége, ami miatt érdemes használni. (pl az angelscript ilyet nem tud, a C# is csak korlátozottan).
Ez lényegében ugyanaz, mint, amit te írsz, csak itt a Lua kód és scene file módosul és fordítódik párhuzamosan, te meg egy DLL-t fordítgatsz és töltesz be. Annyival rugalmasabb a Lua, hogy ott bármit meg lehet nézni és módosítani, míg a DLL-nél csak azt, amire az editor rálát, közben pedig a fordítgatás, újratöltögetés sokkal nagyobb időveszteség, mint egy script esetén. Akkor már egyszerűbb.ha a VisualStudio edit and continue-val futás közben átírod a C++ kódot, de persze ez is korlátozottabb, mint egy script. A C++ amúgy se erre lett kitalálva, szerintem scriptelésre scriptet kell használni.
@Parallax:
Igen, ez a része tényleg jó, viszont azon a problémán agyaltam mostanában, hogy hogyan lehetne a scene load részét kikerülni a gameplay futtatásakor. Úgy értem, hogy tök jó dolog ez a scripting, de ez csak azt a részt oldja meg, hogy miként módosítsunk már meglévő dolgokat. Ha viszont az editorban oda szeretnék tenni egy dobozt, vagy akármit, akkor ahhoz el kell menteni a scene-t, majd újra kell tölteni a pályát (avagy újra kell indítani a programot) a tényleges gameplay esetén. Persze ez a kisebbik baj, azért az igen kényelmes a Unity-ben, hogy futás közben nyomhatok egy pause-t, és megnézhetem ott helyben az összes objektum állapotát, ha akarom módosíthatom, és folytathatom úgy a futást.
Valami olyasmi megoldáson gondolkoztam, hogy dev-time a gameplay kódból egy dll készülne, de maga az engine maradna static lib. Ez ugye annyiban lenne gond, hogy, ha betöltöm a dll-t, akkor a hozzálinkelt engine "duplázódva" lenne. Azonban sikerült átírnom az engine egy részét úgy, hogy Dependency Injectiont használjon. Ekkor viszont megtehetem azt, hogy az editor alkalmazáshoz már létrehozott systemek pointerjeit "átpasszolom a dll-nek", így az nem hozna létre pl. egy új renderert, hanem a már meglévőt használná.
Így viszont megoldható a hot-reload is, hiszen csak az adott dll-t kell újratölteni, és meghívni néhány entry point-jellegű függvényét.
Nem tudom, hogy ez így mennyire működne, de nem lenne rossz, mert akkor maradhatnék c++ban a "scripteléshez" is, az összes feature-jével együtt.
IdézetInstalok :
Be kell vallani azért, hogy a Unity megoldása elég kényelmes. Adott egy editor, amiben ott helyben lehet futtatni és kipróbálni a gameplay kódot.
Ezért jó a Lua. Könnyű bindolni és hozzá editort írni és bármire lefordítható, amire van C compiler.
Az alapvető gond ezzel a megosztott dologgal ugye az, hogy a gameplay kód függ az engine liben, de ugyan úgy az editor is. Az engine jelenleg egy statikus lib, amit szimplán összelinkelek a gameplay kóddal, így nyugodtan használható az engine funkcionalitása. Viszont mivel "duplikált kódot" nem szeretnék, így nem lett volna elég, ha a gameplay kódból csináltam volna shared libet, az engine is az kellett volna, hogy legyen. Onnantól kezdve pedig ugye csak egyre bonyolultabb minden, végül ezért elvetettem az egész megközelítést. Be kell vallani azért, hogy a Unity megoldása elég kényelmes. Adott egy editor, amiben ott helyben lehet futtatni és kipróbálni a gameplay kódot.
Persze, lehet egy ahhoz hasonló megoldás is, amit írtál. Készülne a gameplay-ből egy olyan futtatható bináris is, ami tud kommunikálni az editorral. Pontosabban az editor tud vele. Így például különböző signalokat tudna neki küldeni, amivel az editorból lehet resetelni egy scene-t, megállítani az update-et, stb. Persze mehet a visszafelé kommunikáció is, hasonlóan ahogy írtad (be kell valljam, a socketes kommunikáció eszembe sem jutott ), csak ugye egy egyszerű signalt küldeni könnyebb, mint egy "teljes objektumot" átküldeni. Persze az is megoldható, csak kell egy jó serializer/deserializer hozzá, így az editor bizonyos eseményekkor lekérhetné a jelenlegi adatokat egy entity-ről / komponensről (mint például az objektum pozíciója). Végül is megoldható ez a socketes kommunikáció, nem is olyan rossz ötlet, bár ezt szerintem csak egy későbbi változatnál csinálom meg, ha úgy alakul - néha tényleg muszáj egyszerűsíteni, mert így sem készül el sohasem az ember. Köszi az ötletet!
Ja és az automatikus DI dolgot dícséretnek szántam. Mostanában néztem google talk videókat, ahol nagyon nyomatták a DI-t meg Law of Demeter-t meg minden ehhez hasonlót, és rájöttem, hogy eddig én is teljesen rosszul csináltam. (továbbá megnézve az UE4 forráskódját, ők is teljesen rosszul csinálták, hehe csak hát ugye csinálni egy singleton-t, amit elér az ember mindenhonnan könnyebb, mint normális design-t kitalálni).
Nem akartalak amúgy elbizonytalanítani. Anno én is csináltam valami hasonlót, de egy UE4 ötletet követtem: module managert írtam, de a lényege végső soron ugyan az volt, mint amit te csináltál. És én is azt tapasztaltam, hogy működött, bár én csak MSVC-vel próbáltam ki. Szóval, ha működik, akkor tök jó! Ők egyébként a következő kódrészletet használták:
Kód:
// If we're linking monolithically we assume all modules are linked in with the main binary.
#define IMPLEMENT_MODULE( ModuleImplClass, ModuleName ) \
/** Global registrant object for this module when linked statically */ \
static FStaticallyLinkedModuleRegistrant< ModuleImplClass > ModuleRegistrant##ModuleName( #ModuleName ); \
/** Implement an empty function so that if this module is built as a statically linked lib, */ \
/** static initialization for this lib can be forced by referencing this symbol */ \
void EmptyLinkFunctionForStaticInitialization##ModuleName(){} \
PER_MODULE_BOILERPLATE_ANYLINK(ModuleImplClass, ModuleName)
szerk.:
Apropó, egy apró ötlet a kódhoz, amit csináltál: Lehetne egy csak debug módban használt guarding, ami figyelné azt, hogy az implementáció ne hívja meg az szülőosztály adott függvényét, mert az jó kis végtelen ciklushoz vezetne. Erre gondolok:
Kód:
class ServiceA
{
public:
virtual void foo()
{
if (impl)
impl->foo();
}
private:
ServiceA* impl;
};
class ServiceAImpl : public ServiceA
{
public:
void foo() override
{
ServiceA::foo(); // inf loop
}
};
A szülő osztályban ha lenne egy check, akkor ez elkerülhető. Persze, a programozó bármikor tökön tudja magát lőni, ha akarja, ettől függetlenül. Szóval lehet, h csak én vagyok túl óvatos önmagammal szemben is.
Ezt a hozzászólást Instalok módosította (2016.10.26 21:03 GMT+1 óra, ---)
@Instalok:
Hát végül is még ezzel is lehetne dinamikusat csinálni. Ugyebár a kis példából jól látszik, hogy nem nagyon tudod mit injektálsz, ezért akár csinálhatnál valami ilyesmit:
- Adott az editor (ilyesmi komponensalapú szerkezetben). Ott meg vannak adva miféle interfészeket lehet megvalósítani. Ez egy standalone alkalmazás exe, vagy linux bináris.
- Adott egy másik ilyen projekt, ami az összes "szkriptet" tartalmazza. Persze köztes halmazt képeznek a nyilvános interfész header-ek ilyenkor.
- Ebben a másik projektben a main és az alap dolgok adnak szolgáltatásokat az editorral / runtime-al való protobufos, vagy socket-es kapcsolathoz.
- Ez a kapcsolat kézfogás-alapú, de fel van készítve arra, hogy felépül és leépül, miközben az editor várakozó helyzetbe tehető.
Ezek mellett már lehet olyat, hogy az editoron belül egy kis ablakban (vagy persze külső szerkesztőben írod a tényleg igazi c++ kódot, ami persze a másik projekt fájljait módosítja és akkor van egy gombnyomás, ami leállítja a másik socketes progit, majd az összes ottani scriptet make-eli. Ugyebár a make-elés eleve figyeli, hogy csak az új dolgokra fusson így fel a struktúra miatt és ha visszajött a shell, akkor elindul az editor másik fele, ami szól, hogy készen vagyunk.
Persze ez már nem csak a barátom tartaná szerintem kicsit overcomplicated-nek, de szerintem működne. A dolog előnye ugye, hogy használhatod ugyanazt a c++ fordítódat, amit egyébként is (a legújabb lambdákkal, meg unique pointerekkel), de itt már nem lehet std::vector paramétereket átadni meg hasonlók... ez itt legalábbis nehezebb lenne akárcsak egy DLL-nél.
Ami esetleg még érdekes lehet, hogy ha magad akarsz valamit és nem mondjuk Lua-t, hogy esetleg valami FORTH variációt magadnak tudsz implementálni. Ahhoz persze megírod a fordítód és még kifejező is, viszont az tuti ziher, hogy szerintem valami meglévő megoldás jobban optimalizál majd...
Az se rossz mondjuk, ahogy most van a leírásod alapján. Végülis tetszik. Elsőre én is mindig valami bonyolultat akarok, aztán lesz valami olyan, ami egyszerű és meg is felel. Majd persze az is tud szépen fejlődni ;-)
ui.:
"Látom azért automatikus dependency injection is van a frameworkben."
- Túl sok volt az enterspájz programming már és ilyeneket csinálok )
"Arra kell figyelni, hogy vannak fordítók, amik az "unused object"-eket kioptimalizálják, azaz a static registernél erre lehet, hogy figyelni kell majd."
- Amikor kitaláltam, akkor meg voltam győződve, hogy szabványosan meg kell hívódjon ez a kód. Szoktam több fordítón is tesztelni optimalizálva is ezeket a kódjaimat és nem volt még ezzel baj, de ez persze nem jelenti, hogy nincs ezzel talán szopás. Most el is bizonytalanodtam :-)
Ezt a hozzászólást Prenex módosította (2016.10.26 18:55 GMT+1 óra, ---)
@Prenex:
Igen, ez a megközelítés már eddig is megvolt/megvan - csak saját implementációval -, csak pont az lett volna a lényege, hogy a hot reload lehetséges legyen. Látom azért automatikus dependency injection is van a frameworkben. Arra kell figyelni, hogy vannak fordítók, amik az "unused object"-eket kioptimalizálják, azaz a static registernél erre lehet, hogy figyelni kell majd.
Azóta már találtam az editorhoz egy másik megközelítést. Próbáltam ugye azt elérni, hogy hasonlóan működhessen majd, mint a Unity: átírom a scriptet/komponenst/akármit, lefordítom dll-be, az editor újratölti, és máris látom az editorban a változtatásokat. Ez viszont magával húzná a dll-ek bonyolultságát, így végül elvetettem.
Azt a kevésbé "szép" megközelítést választottam, hogy az editor ilyen szempontból buta, és direktben nem tud a gameplay komponensekről. Cserébe az editor csak egy adatszolgáltató. Azaz egy objektumra definiál egy új komponenst xy névvel, amihez fel tud venni értékeket [key, value] alakban. Maguknak a komponenseknek a feladata parse-olni és használni az adatot. Magyarán megfordítottam az irányt: az editornak továbbiakban nem lesz függősége a gameplay lib, csupán adatokat szolgáltat, amit a gameplay lib felhasznál. Így legalább nem kell megoldanom azt sem, hogy hogyan olvassam ki a komponensekből az editor számára látható elemeket.
Az általad felvetett két alternatíva mellett egy engine esetén még talán érdekes lehet a komponensalapú megközelítés is. Lényegében a DLL / shared object is ilyen (runtime komponens), de mostanában azzal szoktam kísérletezgetni, hogy fordítási idejű komponens-architekturákkal mókolok. Arról van szó, hogy ez egy ugyan olyan plugin szerkezet, mintha DLL, SO, vagy OSGi lenne és a hasonló heavyweight dolgok, de nem runtime - sőt amikor egy plugint ki akarok cserélni, vagy mondjuk letöltesz egy komponenst, akkor újra kell fordítani a kódot.
Tudom ez nem teljesen drag&drop, viszont nagyon egyszerű megcsinálni és átlátható szerintem az architektúra. A minimalista barátomnak, már így is "túl overcomplicated" lett és egyébként is kíváncsi vagyok kinek mi a véleménye.
- Itt megtalálható a jelenlegi változat (direkt egy minimál példa van csak megvalósítva, de majd csinálok ezzel valami nagyobb progit is).
- Ez még szerintem változni fog. Például bekerülnek a komponensekbe tehető bináris asset-ek és filozofálok a make-elés egyszerűsítésén.
Ha nem kell mindenáron dinamikusnak lennie, akkor szerintem ez egy engine esetén is járható út lehet. Az ötlet teljesen ingyenes és opensource, csak említs meg ha használod ;-)
A Lua beépített módon támogatja az OOP-t, de annyira rugalmas, hogy osztály, egységbe zárás és öröklkés könnyen megoldható. Lehet AngelScript-et is használni, ami már majdnem olyan, mint a C++, de ott asszem a futás közbeni kód módosítás nem annyira rugalmas, mint Lua alatt, pedig ez a script egyik alap lényege.
Ezt a hozzászólást Parallax módosította (2016.08.01 07:52 GMT+1 óra, ---)
A legnagyobb gondom talán csak az marad így, hogy hogyan rendeljek egy adott scriptet egy objektumhoz. Mert ugye a script követheti a komponenses megközelítést (van néhány "eseménykezelője", és igazából ennyi), csak valahogy ezt társítani is kell egy adott objecthez.
Ráadásul a Lua-t nem ismerem, de amennyit foglalkoztam gameplay kóddal, ott előfordult, hogy kellett (érdemes) volt használni öröklődést, stb., amit egy c-alapú programozási nyelv nyilván biztosít.
Igen, lehet, hogy valami ilyesmiben fogok én is kikötni. :/
Bár, megfelelő mennyiségű UE4 és/vagy Unity után nagyon szimpatikus az a módszer, hogy saját komponenseket alkothatunk, amiket az editorban is látunk, és csak simán "rádobjuk" a game objectekre.
Anno a cégnél használtunk valamiféle lazy dll load dolgot. Ha jól rémlik, valami olyasmi volt a lényege, hogy megmondtuk a linkernek, hogy semmi gond, hogy nem találja a függvényt, majd menet közben betöltünk egy dll-t, amiben benne lesz.
Megközelítem másképp: scriptelésen gondolkozok, és a leggyakoribb megoldás, amit láttam, az az, hogy az engine-t dll-be fordítják, és nagy részét exportálják (amit ugye használhatóvá akarnak tenni a kliens által). Előnye az, hogy használhatsz egy jól megszokott programozási nyelvet, le tudod fordítani, és gyors (főleg, ha c++ban írod a scripteket is). Hátránya meg nyilván az, hogy shared lib lesz az engine, mindenféle dolgot ki kell exportálni, arról nem is beszélve, hogy az STL-t nem használhatod, mert még a vector-t sem lehet értelmesen kiexportálni.
A másik megközelítés az, hogy az engine-t nem bántjuk ilyen szempontból, maradhat akár statikus lib is, cserébe a script az, amit runtime betöltünk, és futtatunk.
Ezen belül ugye lehet több megoldás is:
Lehet valamilyen virtuális gép / interpreter, ami egy saját nyelvet dolgoz fel, és meghívja az engine megfelelő részét. Ennek több hátránya is van. Például az, hogy amennyiben egy új funkció bekerül az engine kódba, azt majdhogynem duplikálni kell. Megírjuk magát a kódot, meg azt a kódot is, ami ezt futtatja a scriptből. Továbbá egy saját VM/Interpreter megírása akár bonyolult is lehet, és lassabbá is teheti a futást.
A másik, ami eszembe jutott az a fent említett lazy dll loading. Olyat lehet-e valahogy csinálni, hogy az engine marad statikus lib, a scripteket szintén c++ban írom (felhasználva az engine headeröket), de valahogy megmondom neki, hogy ne aggódjon a linkeléskor, mert menet közben meg fogja találni a függvényeket / objektumokat?
Szóval valahogy így nézne ki a dolog:
Engine - lib
Application - exe
Game - dll
Természetesen az Application-be belefordítom az Engine-t. Az alkalmazás indításakor pedig fogná a Game.dll-t, és betöltené. Azonban a Game.dll-hez nem lehet hozzálinkelve az Engine.lib, mert akkor ugye minden "duplikálva lenne". Itt kellene az, hogy amikor a Game.dll-t fordítom, akkor ne hasaljon el a linker, hogy nem találja a függvényeket, amiket meg akarok hívni.
Így gondoltam én is, azért kérdeztem. Azután javasolni akartam, hogy azon projekt beállításait nézze át, amelyikből a dll fordul. Hülye azért nem vagyok.
Frissebbek | Korábbi postok 
