A játékmotort az android - tutorial 1. rész (primitívek) szerint írjuk, programozunk az androidra, java -
Ki vitatkozna a leghasznosabb és legnehezebb programokról minden mobil platformra - ez minden bizonnyal egy játék! És az Android sem kivétel. A mai időben egy mobil eszköz egy szórakoztató központ a zsebében. Elmondhatjuk, hogy a modern termelékenység versenye ennek a trendnek a közvetlen eredménye. Hát, így és mi lesz a trend! A játékmenet fejlesztése meglehetősen időigényes és fáradságos. Igazoló játékmotor - talán nem kevésbé bonyolult dolog.
Úgyhogy úgy döntöttem, hogy megpróbálom megírni a szerény játékmotoromat Androidra, és megosztom veled ezt a tapasztalatot.
Először is meg kell határozni, hogy milyen lehetőségekkel rendelkezünk motorunknak? Végül is a teremtés lényege, hogy megkönnyítse számunkra a játék jövőbeli fejlesztését. Nem fogunk írni egy háromdimenziós motort. Túl nehéz nekünk kezdőknek. Ezért próbáljon meg egy egyszerű 2D-s motort létrehozni sprite animációhoz. Talán a folyamat során kibővítjük. Funkcionális része a következő:
- Maga a rendszerrel dolgozik, például: létrehoz egy felületet rajzoláshoz, a renderelés követéséhez.
- A grafikai primitívekkel való munka - (pont, vonal, téglalap, kör, ellipszis).
- A primitívek mozgatásának képessége.
- Spritzekkel dolgozni (terhelés, mozgás, forgatás, átméretezés).
Mindez elég egyszerű ahhoz, hogy megszervezze a rendszer beépített funkcióit, de ha több játékot írsz, akkor minden alkalommal elég unalmas. Ezért az egyszerű következtetés, hogy ezeket a funkciókat a kis osztálykönyvtárba kell dobni. Ez az a teremtmény, amivel foglalkozunk. Túllépve próbáljunk kitalálni, honnan származik ebben a androde-ban. Így létrehozunk egy új Android-projektet:
Nos, a projekt jött létre, most haladunk a motorunk legegyszerűbb és legegyszerűbb osztályához. Tehát mBasicnak hívják. Minden más osztály, amely a primitívekkel való együttmûködéshez fog örökölni ebbe az osztályba a jövõben. Itt van a kódja:
Így definiáltunk egy absztrakt osztályt (ez azt jelenti, hogy programjainkban nem tudunk ilyen osztályt instantiálni), amelyben többféle primitív típust konstansokként definiáltunk. TYPE_POINT - pont, TYPE_LINE - szegmens, TYPE_POLYLINE - vonallánc TYPE_RECT - téglalap, TYPE_CIRCLE - kör, TYPE_SIMPLESPRITE - egyszerű sprite. Tény, hogy nem gondolom, hogy szükségünk lesz minden ilyen primitívre a játékban, de csak abban az esetben, legyen szó. Szintén ebben az osztályban, mi határozza meg egy absztrakt update () metódus, amely lehet használni, hogy frissítse a paraméterei a primitív és a másik módszer logikai isSelected (float f, úsztatott g) - nekik fogjuk használni annak meghatározására tartozik, ha a pont koordinátái az f és g a mi primitív. Nos, állítsuk be a rajzot (Canvas c, Paint p). Szükségünk lesz rá, hogy felhívja a primitívjeinket. A módszer paraméterei a vászon típusú objektumok (a vászon, amelyre rajzolni szeretnénk) és a Paint (amelynek kefét szeretnénk rajzolni). Mindkét módszer elvont, majd végrehajtjuk azokat a megfelelő osztályokban.
Most kezdjük el a könyvtárunkat. Kezdjük az mPoint osztályral - ez az osztály felelős lesz a ponttal való együttműködésért. X és y paraméterek - ez érthető, a pont helyzete a képernyőn (vagy azon kívül). dx és dy a pontok sebessége az egyes tengelyek irányában. axX és axY egy pont gyorsulása, ha nagyobb, mint egy, akkor a pont felgyorsul, ha kevesebb, mint egy, majd lelassul. (miért kell később foglalkoznunk ezzel). Maga az mPoint osztály örökli az mBasic osztályt. És számos különböző konstruktort fogunk megadni, így nem lenne unalmas :-). Ennek eredményeképpen a következő osztályba jutunk:
És mit csinál a frissítés () módszer, amelyet örököltünk a szülőosztályból? Felolvassa a pont új koordinátáit, tekintettel annak gyorsaságára és gyorsulására. Ne feledje, hogy minden egyes konstruktorban szigorúan meg kell adnunk a létrehozandó objektum típusát:
Így néhány jövőbeni probléma miatt megmentjük magunkat a jövőben. Egy másik módszer azt realizoavli darw (vászon c, Festék o) annak standard módszer használható realizitsii vászon osztály: Canvas.drawPoint (float x, úszó). Többek között kérdeztünk még néhány hozzáférési módszert. Alapvetően azt gondolom, hogy az összes kód meglehetősen átlátható, és nem okoz nehézséget.
Most hajtsa végre az osztályt, amely felelős a szegmensekkel való együttműködésért. Itt van a kódja:
Nos, itt semmi bonyolult! A megértésünket a szegmens végei határozzák meg. Valójában itt van két pont p1 és p2 - amelyek a szegmensünk végei. Több különböző konstruktor, amelyekben ezeket a pontokat meghatározták, és egy módszert a pontok helyzetének frissítésére (mivel a mline osztály mBasic-ból származik, akkor ezt a módszert is végre kell hajtani). Csakúgy, mint egy pont rajzolásakor, a standard darwLine () módszert alkalmaztuk.
Tetszett? Hasznos volt? Megosztani!
A jövőben valószínűleg könnyebb működtetni a gyorsító vektorral, ahelyett, hogy a gyorsulást a két tengely mentén tárolná.
Akkor adja meg (gyorsulás) az alap osztály - és akkor építeni nagyon összetett mozgásokat tárgyak, például a szaggatott vonal mozog a saját útját egy gyorsítás és plusz pont mozog, mindegyik saját. Valami hasonló hasonló a Goo világában.
Ha azonnal végrehajt egy vektort, a felső szinten sokkal könnyebb lesz a munka.
Csak az én IMHO-m, persze.
Igen, az ötlet jó! Azt is gondoltam, hogy először csinálom, akkor valami túl lusta. 🙂 Ha végrehajtod, akkor nagyszerű lesz, de ha elküldi nekem a forráskódot is, nagyszerű lesz!
A sebesség- és gyorsulásszámításokat a frissítési módszerben, az mPoint osztályban - számomra úgy tűnik számomra, hogy a sebességet nem kell gyorsítani, hanem hozzá kell adni. Képzelj el egy beadandó tárgyat a valós világban, a gyorsulás 10 m / s ^ 2 (9.8). Jelen pillanatban a test 10 m / s sebességgel esik le, másodpercenként 20 m / s, majd 30 stb. Ha a sebességet megszorozzuk a gyorsítással, akkor egy második 100, majd 1000 stb. Hát nem túl jó? Ezenkívül, ha a képletek alapján az objektum kezdeti sebességét veszi meg = 0, akkor nem számít, mennyit szorozzuk meg a gyorsítással, a sebesség nulla marad. Általában az iskola fizikája)
Igen 🙂 Hát, elvileg logikus 🙂 Nem is nagyon bánom, mint írott és írott 🙂 Tanult 🙂
Igen. Egyetértek. A logika az, hogy az első, hogy a második különbség azonos.
Merem helyes: ne gyorsítsd fel a sebességet, amit hozzá kell adnod, és a gyorsulás szorozva az idővel, mert sebesség és gyorsulás különböző mértékegységekkel rendelkezik. A sebesség egy bizonyos időpontban Vt = V + a * t. Nos, és a kódoláshoz igazad van, azóta használjuk ezt a "dx + this.axX" -t úgy gondoljuk, hogy a frissítés minden másodpercben megtörténik.
Hello.
Öregkoromban úgy döntöttem, hogy programozom. Tapasztalat C-ben és Java-ban, míg a tölgy-tölgyfa.
A leginkább nubi kérdés:
Mi létrehoztuk a projektet, aztán azonnal írjuk a kódot. És hol helyezze be? Annyira megértettem, hogy a projektben -> apu scr -> a névtérben - be kell lépnie egy új fájl létrehozására a kiterjesztésű java-val, és be kell illeszteni a kódot. És nevezze meg az egyes fájlokat ennek megfelelően. Jó vagy rossz? És vajon szükség van-e valahova valamilyen típusú #include használatára, mint a With ++ -re? Vagy az Eclipse mindent össze gyűjt egy nagy csomóba? Neponyatnenko.
Most egy kicsit kevesebb, mint a Noob kérdés. Az első felsorolásban lehetséges-e az enum használata, hogy jelentősen csökkentse a kód méretét a jelentés teljes megőrzésével?
Hát, hogy tegye le - minden cikkben, jó lenne egy linket létrehozni a "tartalomjegyzék" elején és a cikk végén.
Az én nubi kérdésemmel részben felismertem - letöltöttem az utolsó oktatóról a projektedet, és úgy nézett ki, mintha megtörtént volna. Szóval, ahogy gondoltam
Is megtalálható a fejlécben a blog tétel "leckék androyd", így a kérdés, hogy megtalálja a tartalomjegyzék is megoldódott)
Igen. Maga ugrott. Ahol pontatlanul írtam a módszert, ott a különbségtől elvárja a modult, és hasonlítsa össze a deltával.
Mindhárom listát külön fájlokba kell beágyazni? és hogyan nevezik ezeket a fájlokat? Mint az osztálynevek? hol találhatók ezek a fájlok? általában valamit, amit nem értek ...
És nem írhatott volna még egy olyan osztályt, amely egyszerűen megjelenítené a motorban végrehajtott primitíveket? Azt hiszem, ezúttal nem fog sok időt tölteni, de jó példája lesz az osztályok munkájának.