A játékfejlesztés lendületben van, ígéretes és egyre népszerűbb. A tanulási játékfejlesztés útjáról részletes infografikát készítettünk.

A játékfejlesztéshez számos terület kapcsolódik, és a tanulás minden szakasza az előző szakaszra épül. Például nem szabad azonnal a játékmotorokhoz ugrani. Kezdje a szoftverfejlesztéssel, tanulja meg a matematikát a játékprogramozás élesítésével, és csak ezután térjen át a játékfejlesztésre. A bemutatott lépések mindegyike egy lépésről lépésre szóló útmutató, amely könyveket és egyéb anyagokat tartalmaz.

0. Gyermekjátékok fejlesztése

Sok könyv a legendás és intuitív Scratch fejlesztőkörnyezetre összpontosít gyerekeknek, beleértve a ScratchJr-t is. Az alap után jönnek a Python Pygame-ről szóló információk. Van egy könyv ötéveseknek, de a legtöbb anyag 8 éves és annál idősebb gyermekek számára alkalmas.

1. Számítástechnika

Az elméleti kovácsolás kötelező elem, enélkül értelmetlen a további tanulmányozás. Ez az oktatási irodalom válogatás tartalmazza az alapokat, információkat az algoritmusokról és a matematikáról a számítástechnika tanulmányozásával összefüggésben.

2. Programozási nyelvek

Számítógépes nyelvet beszélni nem könnyű, de lehetséges. És nagyon sok ilyen mód létezik. Például a C nyelv jelentősen befolyásolta a szoftveripart azáltal, hogy megosztotta szintaxisát a népszerű C#, C++ és Java nyelvekkel. A C++ pedig egy hatékony nyelv hatékony programok és szoftvercsomagok létrehozásához. Sokan C#-ban is írnak játékokat: a nyelv okos, kényelmes, és gyorsabban elindítja a fejlesztést.

De Lua átvett valamit a C ++-ból. A szkriptnyelv jó a játék logikájához. Ez megkönnyíti a szint inicializálását, a feladatok objektumokhoz kötését, az NPC viselkedésének interaktív megváltoztatását a projekt újrafordítása nélkül, és még sok mást.

3. Alkalmazások létrehozása

És ha az informatika elméleti alap, akkor itt több a gyakorlat. A játékfejlesztés rögös út, és az alkalmazások a legjobb kiindulópont. A gyakorlati feladatokat tartalmazó könyvek, valamint a mintákkal és az UML-lel kapcsolatos információk segítenek kitalálni, hogy mi is az.

4. Matematika a játékfejlesztéshez

Nem, nem lesz iskolai kurzus algebrából és geometriából. A válogatás a matematika alapjaira tagolódik a játékfejlesztés területén és egy haladó szintre.

5. Játékprogramozás

Hardverplatformok, operációs rendszerek, API-készletek, algoritmusok, platformközi és egyéb fontos szempontok, amelyek a fejlesztés alatt álló játék alapját képezik. A könyveket számos gamedev cikk egészíti ki, amelyek hasznos információkat tartalmaznak a programozásról.

6. Játékmotor fejlesztés

A motor a játék szíve, amely "feltölti" a funkcionalitást és a szükséges eszközöket. Az első könyvek bemutatják az építészetet és a tervezést. Továbbá a "játékmotorok" eszközökre, optimalizálásra, szkriptekre és cikkek formájában további anyagokra vannak osztva. Az ismerkedés során a minták, az algoritmikus trükkök, a Unity-ben való optimalizálás és egyéb árnyalatok érintik.

7. Számítógépes grafika

Igen, a tartalom fontos, de a számítógépes grafika analóg az alkalmazási felülettel, amelyet a felhasználók láthatnak. Ezért különös figyelmet kell fordítani rá.

Nem csoda, hogy ez a szakasz a legnagyobb. Ez magában foglalja a Real-Time 3D, DirectX és OpenGL programozás alapjait. Mindent kiegészítenek a rendereléssel és a technológiákkal kapcsolatos információk. A kiválasztás során kiemelt figyelmet kapott a Direct3D és az OpenGL.

8. Játék audio

A játékfejlesztés a hangról is szól: ezek az NPC-k, a főszereplő, a jelenségek vagy tárgyak által kiadott hangok, valamint a zene. Az audioprogramozás mindössze két könyvbe kerül, de a szükséges információkat hozzáférhető módon biztosítják.

9. Játékfizika és animáció

Az egyik legnehezebb szakasz. A szoftveralap és a képek mellett törvényeknek kell lenniük, amelyekkel mindez kölcsönhatásba lép. A játékfizikával és az animációs programozással 17 könyv foglalkozik. Külön érinti a folyadék utánzata.

10. Játék mesterséges intelligencia

Nagyon sok számítógép által vezérelt karakter létezik: lehetnek csőcselékek, küldetések és akár közönséges sakk is. A rengeteg könyv lehetővé teszi az AI elveinek megértését. Az alábbiakban felsoroljuk a tematikus hasznos cikkeket.

11. Többjátékos játékprogramozás

Az egyjátékos játékfejlesztés nagyon különbözik a többjátékos lehetőségektől. Itt figyelembe kell venni a kapcsolatot, a szálak munkáját és egyéb árnyalatokat. A válogatás szerverprogramozásról, hálózati programozásról és hálózati protokollról szóló cikkekre és könyvekre oszlott.

A globális ötletek megvalósításának sok más módjához hasonlóan a számítógépes játékok fejlesztése is egy jól megtervezett és jól olajozott esemény. A játékok létrehozása szigorúan szakaszosan történik, ráadásul a játékfejlesztés egyetlen szakaszát sem ajánlatos kihagyni. Ez azzal magyarázható, hogy a projekt kidolgozása sok időt vesz igénybe, és a 3D-s modellek megrajzolása és a játék fizikájának véglegesítése közötti időszakban az ötletek többször is változhatnak.

A játékfejlesztők gyakran nem tudnak ésszerű időn belül befejezni egy játékot. Ez annak köszönhető, hogy a számítógépes játék fejlesztése után és megjelenése előtt béta tesztelésre kerül sor, ahol azonosítják a hibákat, majd a fejlesztők módosítják a játékot. Ha egy játék létrehozásának folyamatát nem veszik komolyan, akkor a ciklus (béta kiadás -> béta tesztelés -> korrekció -> béta kiadás) nagyon sokszor átmegy és a fejlesztők nem tartják be a rájuk szabott határidőket.
Egy világosan megfogalmazott ötlet megakadályozza, hogy a fejlesztők feladják a játék létrehozását, amikor a munka felét már elvégezték. Hiszen ha ragaszkodsz a tervhez, garantált a siker, persze ha jó a terv és reálisak a határidők.

A számítógépes játék fejlesztésének szakaszai.

Előkészületi szakasz (előkészítés)- Ez a játék első és nagyon jelentős szakasza. Ebben a szakaszban kidolgozzák és dokumentálják a játék koncepcióját, a karakterek tervezését, és meghatározzák a projekt megvalósításához szükséges eszközök megválasztását. Érdemes megjegyezni, hogy ebben a szakaszban egy csapat művészekkel, játéktervezőkkel, műszaki igazgatóval, felettesekkel vagy akár az egész csapattal kidolgozza a játék elkészítésének tervét, a továbbiakban .
Az újonc csapatok gyakran figyelmen kívül hagyják ezt a lépést, mert Nagyon sok időt vesz igénybe egy tervdokumentum megírása, de ez óriási tévedésük. Hiszen jól átgondolt, világos terv nélkül készítik el játékukat, a tervdokumentum hiánya legjobb esetben is nagymértékben késlelteti a határidőt. A fejlesztők nem tudják, mit kell tenniük, és menet közben találnak ki feladatokat, először jól sikerül, majd ez az ajándék is eltűnik a lelkesedéssel és az inspirációval. Az a csapat, amelyik rendelkezik tervdokumentációval, gyorsan haladhat a határidőkön, anélkül, hogy időt pazarolna a munkája kidolgozására, átgondolt feladata van. A színpad, amolyan sínek, a fejlesztők látják maguk előtt a célt, tudják, hogy pillanatnyilag mit kell tenni, és mivel kell teljesíteni a feladatukat. Ez megtérül a gondolkodásra és a dokumentum megtervezésére fordított időnek.
Ha minden adminisztratív probléma megoldódott, a játék gyártási fázisba lép.

Termelés- Ez a legfontosabb és leghosszabb szakasza a játék létrehozásának. Valószínűleg a név alapján sejti, hogy a fejlesztő által korábban elkészített terv megvalósítása zajlik.
A játék fejlesztésének előrehaladtával nem ritka, hogy módosítanak egy korábban megírt terven, aminek következtében a csapat időközi felülvizsgálatra készteti az aktuális fejlesztési eredményeket. A játékfejlesztés egy bizonyos szintjén, legyen szó demóról, első, második vagy utolsó előtti szintről, a játékot felülvizsgálják a nem tervezett változtatások miatt. Lehet, hogy a tervezők egy zseniális ötlettel álltak elő, és az időzítés lehetővé teszi számukra a módosításokat. Mellesleg, az időzítésről - a fejlesztőknek ki kell számítaniuk a határidőket, a kiigazítások határidejével.

Kiadás– és végül eljön a pillanat, amikor megjelenik a játék. Több százezer példány kerül a boltok polcaira. Ezt a szakaszt a kiadói nyomás végeként jelölik, mert a fejlesztő már előkészítette a játékot a megjelenésre, most a kiadó lép fel. Az ő feladata, hogy minél több példányt terjesztsen és adjon el, és csökkentse az interneten kalózkodó játék példányszámát. A kiadó fő célja a haszonszerzés, mert a példányértékesítésből származó bevétel egy minőségi játék fejlesztésének finanszírozását indokolja.

Támogatás Nem titok, hogy a PC-s játékok gyakran megjelennek hibákkal – a PC-játék-fejlesztőknek nincs mindig idejük kiadni egy projektet, mire a bétatesztelőik elkapják az összes javítandó hibát. De szerencsére megoldható. A PC-s játékokon olyan javításokat telepíthet, amelyek javításokat tartalmaznak. Minden következő javítás tartalmazza az előző javítással hátramaradt hibák kijavítását. De nem kívánatos ezzel visszaélni, aki olyan fejlesztőtől szeretne játékot vásárolni, akinek van tapasztalata a játék nyers verzióinak kiadásában. Érdemes vigyázni a hírnevére.
A konzolokra kiadott játékok általában hibamentesek, mert a konzolos játékfejlesztők ezt komolyabban veszik, egy csipetnyiben inkább későbbre halasztják a megjelenést, mintsem egy buggal rendelkező játékot. Ez könnyen megmagyarázható azzal, hogy a javítások telepítése a játék konzolos verzióira szinte lehetetlen.

Alig van olyan ember, aki életében legalább egyszer ne játszott volna legalább egy számítógépes játékot, akár laptopon, akár mobileszközön. Nos, melyikőtök, blogunk kedves olvasója, nem álmodott arról, hogy saját játékot készítsen, és ha nem is milliomossá váljon a projektjének köszönhetően, de legalább a barátai körében híressé váljon?

De hogyan készítsünk Android-játékot a semmiből, speciális ismeretek és a programozás alapjainak ismerete nélkül? Kiderült, hogy kipróbálni magát játékfejlesztőként nem is olyan nehéz feladat. Ez lesz a mai anyagunk témája.

1. ötlet vagy forgatókönyv.
2. Vágy és türelem.
3. Játék konstruktor.

És ha a siker első két összetevője többé-kevésbé egyértelmű, akkor a harmadik összetevőt részletesebben kell tárgyalni.

Mi az a Game Builder

Olyan programról beszélünk, amely nagymértékben leegyszerűsíti a játékok fejlesztését, így a programozási ismeretekkel nem rendelkező emberek számára is elérhetővé teszi. A Game Builder egy IDE-t, egy játékmotort és egy szintszerkesztőt kombinál, amely vizuális szerkesztőként működik ( WYSIWYG- Angol. "amit látsz, azt kapod" rövidítés.

Egyes konstruktorokat műfaj korlátozhat (például RPG, játéktermek, küldetések). Mások, miközben lehetőséget biztosítanak különféle műfajú játékok tervezésére, ugyanakkor a kezdő fejlesztők fantáziáját a 2D-s játékokra korlátozzák.

Még a már leírtak elolvasása után is világossá válik, hogy egy kezdő fejlesztő számára, aki úgy dönt, hogy bármilyen operációs rendszerre ír játékot, beleértve az Android operációs rendszert is, a megfelelő konstruktor kiválasztása a fő feladat, mert a jövőbeli projekt sorsától függ. az eszköz funkcióiról és képességeiről.

Hogyan válasszuk ki a megfelelő tervezőt

Kezdje azzal, hogy felméri saját tudásszintjét a programozás területén. Ha nullára hajlik, vagy teljesen hiányzik, akkor jobb, ha a legegyszerűbb lehetőségeket próbálja ki. És még ha nem is rendelkezik a szükséges angol tudással, akkor ebben az esetben megtalálhatja az Önnek megfelelő programot.

És a második fontos szempont a tervező kiválasztásánál a funkcionalitás. Itt nagyon pontosan kell elemeznie a projekt forgatókönyvét, mert minél nehezebb a játék, annál többféle eszközre lesz szükség a létrehozásához, és a tervezőnek erősebbre lesz szüksége.

A választás megkönnyítése érdekében az alábbiakban a legjobb programokat-konstruktorokat mutatjuk be, ami általánosságban nem zárja ki azt a tényt, hogy alaposan áttúrva a fórumokat vagy a speciális oldalakat, mást választ magának, hiszen a programkínálat meglehetősen széles.

Az 5 legjobb játéképítő

2. konstrukció

Ez az alkalmazás következetesen az első sorokat foglalja el a játéktervezők értékelésében. A Construct 2-vel szinte bármilyen műfajú 2D-s játékokat készíthet különféle platformokra, beleértve az Androidot, valamint a HTML5-öt támogató böngészőket célzó animációs játékokat.

Tekintettel a rengeteg segédeszközre, még a kezdő felhasználók is elsajátíthatják a programot.

A Construct 2-vel való munka elsajátításához nem szükséges licencet vásárolni, az ingyenes ingyenes verzió bőséges eszközöket és lehetőséget kínál a kész projekt exportálására bizonyos platformokra. A késztermék mobilplatformokra való kódolása és a funkcionalitás teljes köréhez való hozzáférés azonban 129 dolláros személyes licencet ad. Ha a játékkészítési készséged elérte a tetőfokát, és már elkezdett több mint 5000 dollár bevételhez jutni a projektedből, akkor ki kell fizetned a Business opciót, ami 429 dollárba kerül.

Most pedig nézzen meg néhány gyakorlati oktatóvideót a játékalkalmazások létrehozásáról a Construct 2-vel:

Clickteam Fusion

A Clickteam Fusion egy újabb példa egy nagyszerű, teljes értékű játéképítőre, amely még egy kezdőnek is segít egy teljes értékű játék létrehozásában. A program lehetőséget biztosít a létrehozott alkalmazások HTML5 formátumba történő ingyenes exportálására, ami azt jelenti, hogy lehetőség nyílik böngészős játékok közzétételére, és ezen felül a különböző mobilpiacokon, például a Google Playen való közzétételre konvertálására.

A fő jellemzők között meg kell jegyezni az interfész egyszerűségét, a shader effektusok és a hardveres gyorsítás támogatását, a teljes értékű eseményszerkesztő jelenlétét, a projektek mentését különféle platformokkal kompatibilis formátumokban, beleértve az Androidot is.

A program fizetős Developer verziója nem érhető el az Orosz Föderáció lakosai számára, de licencelt lemeze ugyanattól az Amazon-tól megrendelhető, ami átlagosan 100 dollárral csökkenti a személyes költségvetést. Lehetőség van az étlap oroszosítására harmadik féltől származó oroszosítón keresztül.

Hogyan kell dolgozni az alkalmazással, nézzen meg egy speciális videó tanfolyamot:

Stencyl

A Stencyl egy másik nagyszerű eszköz, amely lehetővé teszi egyszerű 2D számítógépes játékok fejlesztését a kódok speciális ismerete nélkül, valamint programozási nyelveket minden népszerű platformra. Itt szkriptekkel és diagramokkal kell dolgozni, amelyek blokkok formájában jelennek meg, és objektumokat vagy jellemzőket húzhat az egérrel, ami nagyon kényelmes.

A programfejlesztő lehetőséget kínál arra is, hogy saját kódot írjon blokkokban, de ehhez természetesen programozási ismeretek szükségesek.

A kiváló grafikus szerkesztő jelenléte Scene Designer lehetővé teszi a felhasználó számára, hogy a fantáziáját használja játékvilágok rajzolására.

Az optimális funkciókészlet elősegíti a különböző műfajú, kiváló minőségű játékok létrehozását, de a leginkább csempézett (csempés) Stencyl grafika releváns lesz a lövöldözős vagy rpg-játékoknál.

A program terjesztése ingyenes, de az asztali formátumokba exportáláshoz előfizetés szükséges, ami évente 99 dollárba, a mobiljátékok licence pedig évi 199 dollárba kerül.

Tekintse meg a Stencyl-lel végzett munka gyorstanfolyamát:

játékkészítő

A program fizetős és ingyenes változatban is létezik. A költségvetési opció lehetővé teszi szilárd kétdimenziós játékok létrehozását az asztalon. Míg a fizetős verzió lehetővé teszi egészen "divatos" 3D játékok írását Windowsra, iOS-re és Androidra. Továbbra is érdeklődünk egy ingyenes lehetőség iránt, hogy megtanuljuk, hogyan valósítsd meg magad a játékiparban, és a Game Maker éppen az a lehetőség, amely lehetővé teszi, hogy saját forgatókönyveddel készíts játékokat a műfajválasztás korlátozása nélkül.

A program kész helysablonok, objektumok, valamint karakterek, hangok és hátterek választékát kínálja. Tehát minden kreatív munka a kiválasztott elemek munkaterületre húzásán és a feltételek – hely és más objektumokkal való interakció – kiválasztásán múlik. Bár a programozási nyelv ismerete nem szükséges, de a "tudós" felhasználók használhatják a GML-t, ami hasonló a JS-hez és a C ++-hoz.

A Game Makert angol nyelven terjesztik, így annak, aki nem ismeri elég jól, le kell töltenie a crack fájlt.

Azoknak, akiket érdekel ez a program, javasoljuk, hogy nézzék meg a képzési videót:

Unity 3D

A Unity 3D talán a legjobb ajánlat egy minőségi 3D projekt létrehozásához. A teljesen kész modellek beépülnek a programba, valamint textúrák és szkriptek. Ezen kívül lehetőség van saját tartalom hozzáadására - hang, kép és videó.

A Unityvel készített játékok minden népszerű platformmal kompatibilisek az iOS vagy Android mobileszközöktől a SMART TV-vevőkig.

A programot nagy fordítási sebesség, könnyen kezelhető felület, rugalmas és többfunkciós szerkesztő jellemzi.

A karakterek minden játékművelete és viselkedése a PhysX hangzó fizikai magján alapul. Az ebben a játékkonstruktorban létrehozott objektumok események és szkriptek bizonyos kombinációja, amelyeket maga a fejlesztő irányít.

Fontos megérteni, hogy bár a program kezdőknek készült játéktervezőként van pozicionálva, bizonyos szintű tudásra még szükség van az alkalmazás használatához. Nos, a 3D-s grafikával való munkához egy meglehetősen modern számítógépre van szükség, amely hardveres videokártyával van felszerelve.

Leckék sorozata a Unity 3D-vel való játékok létrehozásáról:

Tehát úgy döntött, hogy megvalósítja álmát, saját egyedi játék létrehozásával. Igyekeztünk olyan információkkal szolgálni, amelyek ebben segíthetnek. Ügyeljen arra, hogy ha figyelmesen elolvasta a bemutatott anyagot, és legalább röviden megnézte az egyes programok video-oktatóanyagait, akkor valószínűleg észrevette, hogy az egyes játéktervezőkkel végzett munka ugyanazon az elven alapul. Ezért nagyon valószínű, hogy olyat tud majd felvenni, ami jobban megfelel az Ön igényeinek. Legalábbis reméljük, hogy ebben a szakaszban az a kérdés, hogyan készítsünk játékot Androidon, lezárult. Sok szerencsét!

Mit kell figyelembe venniük a jövőbeli játékfejlesztőknek? Milyen nyelvet érdemes elkezdeni tanulni? Mire kell törekedni? Kire kell felnézni? És mit kell először csinálni?

A legtöbb rockzene szerelmese előbb-utóbb gitárt vesz a kezébe. A sportrajongók szenvedélyesen álmodoznak arról, hogy futballpályára, kosárlabdapályára vagy teniszpályára lépjenek. Nos, azok, akik több száz eltérítést követtek el a GTA-ban, több tucat órát töltöttek számítógépes klubokban Counter-Strike-kal, vagy jelentős sikereket értek el MMORPG-ben, valószínűleg játékfejlesztői karrierben gondolkodnak.

A probléma az, hogy ezt az irányt néhány oktatási intézményben tanítják. Ezért a legtöbb játékfejlesztő autodidakta, ők egykor maguk állították össze a tananyagot. De milyen árnyalatokat vettek figyelembe? Honnan indultál és mire törekedtél? Melyik nyelvet tanultad meg először? Ezekre és más releváns kérdésekre próbáltunk választ adni.

Mire kell törekedni?

Mielőtt elmennél a boltba, összeállítasz egy bevásárlólistát (legalábbis fejben). Mielőtt a város másik végébe utazna - határozzon meg egy útvonalat. Nos, mielőtt megtanulná, hogyan kell játékokat fejleszteni, tanácsos feltenni magának a kérdést: mit is szeretne pontosan csinálni? Mobilalkalmazásokat vagy böngészős játékokat hoz létre? Nagy vagy kicsi cégnél dolgozol? Professzionálisan szeretnél játékokat fejleszteni, vagy a szabadidődet ennek szentelni? És ha az előbbi, mi érdekel jobban: interfész létrehozása, játékmenet csiszolása vagy forgatókönyvek írása?

A megfelelő célmeghatározással sok időt és erőfeszítést takaríthat meg. Ezenkívül lehetővé teszi, hogy a legrövidebb úton elérje a végső célt. Anélkül, hogy letérünk az útról vagy mocsárba kerülünk.

Milyen nyelvet tanuljunk?

Ráadásul az égető kérdésre adott válasz a céltól is függ: milyen programozási nyelvvel kezdjek?

Tehát az olyan játékok jövőbeli fejlesztőinek, mint a Minecraft és az Android mobilalkalmazások, fokozott figyelmet kell fordítaniuk a Java-ra. Kezdésként azt tanácsoljuk, hogy járjon intenzívebbé, különösen mivel ez ingyenes. Azok számára, akik az iOS felé néznek - az Objective-C-n. Böngészős játékokhoz néha elég a Ruby-On-Rails ismerete. Nagyon kicsi és egyszerű időkhöz elég a HTML. A flash játékok gyártása ActionScriptet használ, és bármilyen bonyolultságú szkript írásához JavaScriptre vagy talán a kevésbé elterjedt Luára van szükség. Kis konzolos játékok készítéséhez C# ismerete szükséges.

Ami a legnagyobb költségvetésű játékokat illeti (az úgynevezett AAA osztályt), ezek többsége saját vagy kollégáitól kölcsönzött "motorral" van felszerelve. Gyakran azonban az egész "motor" vagy annak nagy része C++-ban van írva. Ezt a nyelvet használták számos híres "játék" létrehozásához - a Doom 3-tól és a Call Of Duty-tól a FIFA-ig és a The Sims-ig. Míg az olyan klasszikusokat, mint a Quake, C nyelven írták.

A C++ elsajátításában azonban van egy bökkenő – a túlzott bonyolultság. Nem csoda, hogy azt mondják, hogy a C++ nyelvek ismerete nélkül ugyanazt jelenti, mintha lineáris egyenletekkel kezdené a matematika tanulmányozását.

Elég egy nyelv?

A programozás egyik szépsége az állandó önfejlesztés lehetősége. A játékok (különösen a nagyok) fejlesztése során az önfejlesztés, beleértve a lehető legtöbb nyelv tanulását, nem szeszély, hanem létszükséglet. Tehát a tapasztalt fejlesztők, akik a játékipar óriásaiért dolgoznak, gyakran szembesülnek azzal, hogy felváltva 7-8 nyelven kell írniuk. Ugyanakkor a fenti nyelveken kívül meg kell tanulniuk például a Pythont vagy akár az SQL-t is (értsd, adatbázisok létrehozásához).

Ezért, ha úgy dönt, hogy sorsát nagy játékok gyártásához köti, készüljön fel arra, hogy „poliglott” lesz. Ezenkívül minél több nyelvet sajátít el, annál érdekesebb és változatosabb feladatokat kap. És persze jelentősen megnő az esélye annak, hogy álommunkát kapjon.

HOL KEZDJÜK?

Mielőtt körbeutazná a világot, meg kell tanulnia járni. Nos, egy komoly játékprojekt előtt ki kell próbálnia valami kevésbé jelentőset.

Szinte minden tapasztalt fejlesztő, függetlenül a dísztárgyaktól és a tehetségtől, kis alkalmazásokkal kezdett: társasjátékok, híres "játékok" változatai, egyszerű "flash drive". Aztán nem az E3-hoz hasonló nagy kiállításokra gondoltak, hanem felbecsülhetetlen értékű tapasztalatokat halmoztak fel. Miért nem követik a példájukat? Ebben az esetben nem szükséges összetett kódot írni. A debütáláshoz elegendő speciális programokat használni a játékok létrehozásához (például Game Maker). Hiszen még egy egyszerű eszköztárral is nagyban megkönnyíti az életét. Először is, miniatűrben megérti szinte minden játékalkalmazás logikáját és szerkezetét. Másodszor, kitöltöd azokat a dudorokat, amelyek begyógyulnak a komoly projektekre való átállás során. Végül, harmadszor, gazdagítsa portfólióját. Hiszen egy egyszerű "játékhoz" is sok idő, türelem és kreativitás kell egy koncepció kidolgozásához, a kód megírásához és a hibák kijavításához. Ezenkívül azt mutatja, hogy Ön nem csak száraz elméletben ismeri a játékok gyártását.

Mit vegyünk iránymutatásnak?

Bárki, aki arról álmodik, hogy író lesz, könyvek százait olvassa el, mielőtt egyetlen szót is írna. A zongoramesterek fejből ismerik Strauss, Chopin és Beethoven legjobb műveit. A nagy kiállítások előtt ismert művészek memorizálták a művészet történetét.

Ugyanez az elv vonatkozik a játékfejlesztésre is. Nem lehet légüres térben fejlődni. Ezért játsszon, inspirálódjon a mesterektől, és szivacsként szívja magába a legjobbat. Ugyanakkor próbálja meg az alkalmazásokat ne a "játékosok", hanem a fejlesztők szemével nézni. Más szóval: transzponálja a játékot. Gondoljon arra, hogy ebben az időpontban a "bot" miért balra futott, és nem vissza? Milyen tényezők változtatják meg a ütés erejét és pontosságát egy sportszimulátorban? Hogyan hozzunk létre „fáradtsági hatást”, amikor egy karakter hosszú ideig fut? Hogyan lehet elérni, hogy esőben a játékos cseppek hangját hallja, ne disznóvihogást? Lényegében térj a lényegre. Próbáld meg újra létrehozni a fejedben azokat az algoritmusokat, amelyekkel a játék során találkozol. Hidd el, egy ilyen konstruktív hozzáállás segíteni fog a jövőbeni nehéz, de átkozottul izgalmas játékfejlesztői karrieredben.

Hogyan fejleszthetsz egy RPG játékot egy hét alatt a semmiből és költségvetés nélkül. I. rész

RPG egy hét múlva? A semmiből? Egyáltalán lehetséges?
Kockázatot vállaltam és megcsináltam.

Az internet tele van információs forrásokkal, amelyek a kis, független (indi) játékfejlesztők rendelkezésére állnak. Az egyik ilyen nyilvános fórumon egy vita során meggondolatlanságom volt kimondani, hogy ha kapok egy hét időt, egy számítógépet frissen telepített Windows rendszerrel és egy jó internetkapcsolatot, akkor költekezés nélkül tudnék tisztességes játékot készíteni. egy fillért rajta. Nem, biztosan nem lesz képes felvenni a versenyt a Halo 2-vel vagy valami hasonló szintű játékkal (ha egy hét alatt csinálhatnék egy ilyen játékot, már rég felmondtam volna a munkámat), de elég érdekes és játszható lesz. .

Tom Bampton, a havi Game of the Day Game Reviews (www.gameinaday.com) szerzője azt mondta: "Hajrá!" Aztán hozzátett egy további feltételt – ezt a meglévő játékmotorok használata nélkül kell megtennem. Csak alapvető könyvtárakat/API-kat használhatok.

Eleinte feladtam ezt az ötletet. Nem volt túl sok időm egy hét szünetet kivenni a jelenlegi játékprojekt fejlesztéséből a munkahelyemen. De aztán arra gondoltam: a pokolba is, mert mi az a hét? Egy tipikus vállalatnál, mint például az EA, a heti munkaidő 40 óra. Akkor miért nem készít egy játékot nem egy naptári héten, hanem 40 tiszta óra alatt? Ez már valóságosabb – de nem akartam újabb Tetrist vagy Arkanoidot létrehozni. És mi a helyzet a szerepjátékkal – az egyik legnehezebb játékműfajjal? Lehetséges?

Tudtam, hogy rendkívül nehéz lesz. De elfogadtam a kihívást.

Ezen kívül részletesen leírtam, hogy mit és hogyan csinálok, leírtam a fejlesztés előrehaladását. Arra gondoltam, hogy érdekes lehet a játékfejlesztők számára – vagy legalább szórakoztató felvételeket szerezzenek arról, hogyan estem pofára a sárban, ha hirtelen kudarcot vallok. Csak egy hosszú, döcögős feljegyzést találtam óránkénti tevékenységemről. Igyekeztem úgy változtatni, hogy az olvasás ne okozzon unalmat. Hogy ez hogyan történt, döntse el maga.

Tehát a következőképpen készítettem egy játékot egy hét alatt a semmiből, költségvetés nélkül. Ha lusta vagy olvasni, és gyorsan a sztori végére szeretne ugrani, hogy lássa, hogyan is néz ki a végtermék, és látni fogja az összes hibáját, letöltheti a játék Windows verzióját innen: http://www. .rampantgames.com/hackenslash.html

TERVEZÉS
Cél
Hozzon létre egy old-school RPG-t a 80-as évek elejéről származó régi játékok stílusában, felülről lefelé néző nézetben, mint például a The Temple of Apshai, az Ultima III és a Telengard. A játékos egy tipikus kazamatában fog áthaladni a szobákon, és „karddal és mágiával” harcol különféle szörnyekkel. Fokozatosan fejleszti képességeit tapasztalatszerzéssel, szintlépésekkel, mágikus felszerelés beszerzésével.

A játék azonban nem csupán magából a harcból áll majd. A játékosnak lehetősége lesz elsurranni a szörnyek mellett, vagy tárgyalni velük. Lesznek zárt ajtók és ládák, valamint egyedi kazamatai funkciók, amelyek váratlan hatásokkal járnak. A játék nem tartalmaz hosszú leírásokat vagy párbeszédeket – többnyire tipikus hack & slash lesz. Addig követed az utat, amíg nem leszel elég erős ahhoz, hogy szembenézz a végső főnökkel, teljesítsd a küldetést, és biztonságosan hazatérj (a kezdőszobádba).

Fejlesztési szabályok

1. szabály: A fejlesztési idő egy hétre korlátozódik (beleértve a 40 órát is)
Összesen legfeljebb 40 órát szabad játékfejlesztésre fordítani. Ezek magukban foglalják a játékkal való tényleges munkával és az arról való gondolkodással töltött időt is. A tíz percnél hosszabb fejlesztési szünetek nem számítanak bele. Ez egy „tökéletes” munkahét lenne 40 nagy teljesítményű órából.

A teljesen működőképes alfa verzió 40 óra alatt készül el. A további befejezéseket, például a játék végső hibakeresését, a teljes idő alatti terjesztéshez szükséges telepítő létrehozását nem vesszük figyelembe, ebben a szakaszban nem adunk hozzá új funkciókat. A fejlesztési folyamat dokumentációját sem veszik figyelembe.

2. szabály: Csak ingyenes eszközöket használjon
A Windows telepítéséhez mellékelt szoftverek kivételével csak ingyenes szoftvereket használnak, ha lehetséges, nyílt forráskódú. Ennek az a lényege, hogy megmutassa, nincs szükség drága (sőt olcsó) eszközökre egy játék fejlesztéséhez. Ez a szabály nem érinti az olyan berendezéseket, mint a szkenner, mikrofon és digitális fényképezőgép – ha nincs ilyen, akkor feltételezzük, hogy valakitől kölcsönözhetők.

3. szabály: Nincsenek motorok, csak szabványos könyvtárak/API-k
A játékot "a semmiből" kell létrehozni a meglévő játékmotorok használata nélkül. Nincs csalás, és a játék vagy annak bármely részének létrehozása játéktervezők segítségével vagy hasonló szoftverek használatával.

Eszközök
A kód:

Python 2.3 (http://www.python.org/)
Python Win
PyGame (http://www.pygame.org/)
Py2exe – a történéseket futtatható fájlba fordítja terjesztésre. (http://starship.python.net/crew/theller/py2exe/)

Gimp 2.0 (http://gimp-win.sourceforge.net/)
MS Paint (amely a Windowshoz tartozik) - a PrintScreen billentyűvel rögzített képernyőképek beillesztéséhez (a GIMP valamiért megtagadta ezt)
A szabad textúrák innen származnak (http://www.textureartist.net/textures/index.htm) és (http://www.mayang.com/textures/)

Audacity (http://audacity.sourceforge.net/) plusz a mikrofonom vagy az ingyenesek.

A munkák ütemezése (terv).
Az ütemezéseket később megbontják, de továbbra is szükség van rájuk a haladás és a vonalak ellenőrzéséhez, és szükség szerint módosításokhoz.

1-10 óra: Alapvető építészet
A motor felépítése és a fő alkatrészek. Jelenítse meg a világot a képernyőn. Meg kell valósítanom azt a képességet, hogy egy tesztjátékost mozgassam a világban, és megnézzem a dolgokat, majd a történéseket játékszerkesztővé alakítsam.

11-20 óra: Játékos opciók
A játékos összes fő funkciójának megvalósítása - mozgás, támadás, ajtónyitás, halál, dolgok felvétele és készlet használata. Hozzon létre egy drótvázas ábrázolást a környezetben lévő összes objektumról, hogy tesztelje a játékos képességét a világgal való interakcióra.

21-30 óra: A világ revitalizációja
Adjon hozzá mesterséges intelligenciát, játékeseményeket, csapdákat, speciális effektusokat. Ennek az időszaknak a végére egy meglehetősen teljes tech demóval kell rendelkeznem, beleértve a játék összes fő jellemzőjét.

31-40 óra: Tartalom és szabályok hozzáadása
Szerezzen be egy teljes értékű játékot egy techno demóból. Adjon hozzá minden további tartalmat. A játékmechanika teljességének és egyensúlyának elérése érdekében. Csiszoljon mindent, amire van elég idő, adjon hozzá speciális effektusokat, animációt stb.

40 óra elteltével: A játék tesztelése és kiadása
Tesztelje és javítsa ki a talált hibákat (új funkciók hozzáadása nélkül!) Gyűjtsön össze mindent, és tegye fel az internetre. Teljes dokumentáció.

Hackenslash Dev Diary: A hét játéka

1. óra – Wild Design és alapórák
Ez az óra a játék néhány alaposztályának létrehozásával és a további tervezésben való felhasználásával telt. A világ egy portál által összekapcsolt helyiségek sorozataként kerül bemutatásra. A világon minden a szobákon alapul, akárcsak a régi kalandjátékokban vagy a MUD-okban. A legtöbb objektum a játékban "Játéktárgyként" van ábrázolva, amelynek van pozíciója és tartalma (más objektumokat is tartalmazhat - a térkép tartalmazhat szobákat, egy szobában egy láda, egy láda tartalmazhat kardot. . és szerintem egy kard több helyiséget is tartalmazhat, de ezt nem tesszük.)

Tárgyakat hozok létre lény (lény) és játékos (játékos)
Attribútumokat generálok a lények számára, és beillesztem őket egy osztályba. Úgy tűnik, én egy majom vagyok, aki túl sok RPG játékot játszik. Még nem tudom pontosan, hogyan fog kinézni és működni a játékmechanika.
Készítek egy szobaobjektumot, amely a GameObjecttől örököl. Egy szobának szélessége, magassága és falai vannak – jelenleg semmi más.

Fokozatosan kezdem megérteni, hogyan fog működni minden, és megteszem a szükséges korrekciókat. Jelenleg nem is próbálom használni a PyGame-et, és a program nem mutat semmit, csak a konzolt. De úgy érzem, hogy mindaz, ami történt, nagy előrelépés!

2. óra – PyGame 101
Ennek az órának az a célja, hogy inicializáljuk a PyGame-et, és elkezdjünk legalább valamit rajzolni a képernyőre. Valójában az időm nagy részét a PyGame dokumentációjának olvasásával töltöm, és próbálom kitalálni, hogy mi van benne, és hogyan, mivel alig van tapasztalatom a PyGame vagy az SDL terén.

Ez az óra egy olyan programmal zárul, amely egy üres képernyőt jelenít meg feketével. Nem lenyűgöző. Valójában sok minden van az ablak mögött. Van egy játékhurok, keretváltás, több osztályhívás és sok tétlen csonk. De ettől még nem lesz lenyűgöző a fekete képernyő.

3. óra – Ha a falaknak lenne füle, erősen szidnám őket.
Ennek az órának az a célja, hogy meghatározzuk a falakkal ellátott helyiség kontúrjait, és ezt egy még fekete képernyőn megjelenítsük. Ehhez szükségem van helyre és grafikára. Sok időt kell töltenie a GIMP-ben az internetről letöltött textúrák szerkesztésével, hogy megfelelő csempévé váljanak. Egy textúrakezelő osztályt hozok létre. És kitöltöm a minta szobaszerkezetet. Kicsit több időt töltöttem a PyGame dokumentációjának átnézésével is, hogy találjak bármi mást, amivel megkönnyíthetem a munkát.

Eltelt az óra. Még mindig ugyanaz a fekete képernyőm van. Nem voltak falak, és nem.

4. óra – A szállodában van egy szabad szoba
Néhány szintaktikai hibával küszködve végre sikerült elérni, hogy a falak megjelenjenek a képernyőn. Igaz, hibásan jelennek meg, nem a jelzett helyen vannak, sőt a szegmensek közötti résekkel. Ez szörnyű. De egy kis finomítással és szerkesztéssel olyan szobát kaptam, ami a képernyőn 10 x 10 négyzetes.

Részletes projektterv nélkül nagyon könnyű összezavarodni egy bizonyos munka elvégzése után, és azon tűnődni, hogy "Mi a következő lépés?" Úgy döntöttem, hogy ha jó egy szobát rajzolni, akkor kettőt kétszer jobb.

A létrehozott szobák tárolására létrehoztam egy "minidungeon" fájlt.
Elkezdem hozzáadni a „portálok” logikáját – nyílások a falakban, hogy más helyiségekbe juthassanak (és a szomszédos helyiségek helyes megjelenítéséhez szükséges összes eltolási információ megadása).

5. óra – Hackenslash több szobát kap

Az ablak címét "Hackenslash"-re változtattam. Csak mert menő.
Létrehoztam egy objektumtérképet a helyiségek tárolására, valamint egy több térképet tartalmazó MapMaster osztályt.
Hozzáadtam egy második szobát, és a portálon keresztül csatlakoztam az elsőhöz.
A szomszédos helyiségek portálokon keresztül kapcsolódnak a jelenlegihez, és most megjelennek a képernyőn.
Kijavítottam néhány vágási hibát, hogy a részben az ablakon túlnyúló falak megfelelően jelenjenek meg.

6. óra - mely során fejlesztjük rajzkészségünket

Hozzáadott egy ajtóosztályt, és beállított egy térképet az ajtók elhelyezéséhez (az ajtónak két helyiségben közösnek kell lennie). (Szerkesztés: Kár, hogy sosem használtam!)
Létrehoztam még 3 fali csempét, ezeket egy képpé kombináltam.
A falak grafikai megjelenése típusonként változik.
Egy egyszerű grafikát készítek felülről lefelé.

7-8 óra – Pörgetések és felkiáltások!

Rájöttem, hogyan forgathatom a bitképeket a PyGame-ben.
A tesztlejátszó zökkenőmentes forgását értem el. Sok beállításra van szükség a forgásszög korrigálásához.
Megtanultam a betűtípusok használatát a PyGame-ben, és létrehozok néhány osztályt a szöveg megjelenítésére és animálására.
Hozzáadott egy osztályt az automatikus szövegfeldolgozáshoz, mivel ezt a funkciót a jövőben gyakran fogják használni.

9-11 óra - Elemek - brrr!

És itt megint meg kell oldanom a „Mi lesz ezután?” kérdést.

A szobákhoz érdekesebb elemekre van szükség, ezért listát kell készíteni róluk. Nem tudom, hogyan kell rendszerezni őket, ezért úgy döntöttem, hogy az általánosakkal kezdem. Bemutattam három statikus elemet, amelyek egy tipikus börtönszobában megtalálhatók: egy szőnyeg, egy oszlop (a falakkal azonos funkciójú blokk) és egy létra (lehetővé teszi, hogy új helyre költözzön)

Úgy döntöttem, hogy az elemek egynél több lapkát is elfoglalhatnak, és tetszőleges mértékben elforgathatók. (Szerk.: Utólag visszagondolva nagyon buta megoldás – túl sok időt töltöttem a megvalósítással, de szinte haszontalannak bizonyult.)

Összességében körülbelül három órát dolgoztam az elemeken, a grafika készítése és a kódírás között tépelődött.

12-13 óra – Zsákmányra van szükségünk!

Grafikát és kódot készítek a dolgokhoz. Elképesztő, mennyi ideig tart a rajzolás. Különösen bosszantó, ha a kép úgy néz ki, mintha a csirke a mancsával rajzolna, bármennyit is fektettek bele.

Rengeteg statisztikát adtam hozzá a cikkekhez, beleértve a költségüket, méretüket, felszerelési helyeiket és még sok mást. Még nem lehet velük érintkezni, de legalább a megfelelő helyeken megjelennek a szobában.

14. óra - Szőnyegek

Nagyon le vagyok maradva a menetrendről, mit tegyek?
A fekete háttér túl rondának tűnik, ezért a helyiségben szőnyeggel burkoltam a padlót - külön csempével.

Ezek után hirtelen kiderült, hogy elfelejtettem átlátszó hátteret adni a lejátszó és a dolgok sprite-jaihoz. Sok időt kellett töltenem ennek a mulasztásnak a kijavításával.

De a szint most jónak tűnik. Nos, legalább hidegebb, mint a fekete.

15-16 óra - Klikk! Kattintson!

El voltam foglalva az egérvezérléssel és az eseménykezeléssel.
Hozzáadott egérvezérlés. Míg a mozgás szaggatott, a szint görgetése nem egyenletes.
A játékos kimozdulhat a helyiségből, nincs ütközésellenőrzés.
Kijavítottam néhány hibát.
Megkínozta a GIMP-et, és gyönyörű lépcsőket hozott létre.
.
Már majdnem 17 óra fejlesztés telt el, úgyhogy kezdek kicsit ideges lenni. A játék elkészítésének útja 2/5-ét elmentem – a fejlesztés második „munkanapja” véget ért. Lenyűgöző, amit már csináltam, de megértem, hogy még sokkal több van hátra. Még négy órám van, hogy befejezzem a lejátszó alapvető funkcióit, és a menetrendhez igazodjak. Nehéz lesz... de még mindig nem bánom, hogy grafikai rajzolással töltöttem a plusz időt!

17. óra – Lassan mozogjunk, amíg a homlokunkat a falhoz nem ütjük

Az idő nagy részét a grafika finomhangolása és a hibák javítása tölti el.
Hozzáadott ütközésészlelés és egyenletes görgetés, amikor a játékos mozog.
A játékos most több lépést (fordulatot) tehet egy egérműveletre válaszul.

18. óra – A küszöbök átlépése

A játékos most átmehet a portálokon más szobákba.
Ez olyan kozmetikai hibát okoz, amely a szomszédos helyiségek falai és padlói között átfedik egymást.
Sok, a rotációval kapcsolatos hibát javítottunk, ami járhatatlanná tette a portálokat.

19. óra – Mennybe vezető lépcső, a pokol menüje

A bátyám önként jelentkezett, hogy zenét csináljon a játékhoz. Ő készítette a Void War zenéjét, és elég jól sikerült. Ez emlékeztetett arra, hogy hang- (és zene) lejátszást végezzek. Úgy tűnik, hogy ezt meglehetősen könnyű megtenni a PyGame-ben, ezért nem kell túl sokáig tartania. (Szerk.: Soha nem találtam erre időt, sajnos a Hackenslash-ben egyetlen hangot sem fogtok hallani.)

A következő célom a lényekkel és tárgyakkal való interakciók kezelése. Nagyon szeretem, ahogy ez a The Simsben és a Neverwinter Nightsban történik, amikor egy játékobjektummal szeretne kapcsolatba lépni, megjelenik egy helyi menü. Valami hasonlót tervezek megvalósítani.

Lépcső tanítása a játékos új szobába költöztetéséhez.
Kicsit böngésztem az internetet és a PyGame dokumentációját, hogy megnézzem, van-e nyílt forráskódú menü a PyGame hasonló menüjéhez. És nem talált semmit.
Elkezdtem elkészíteni a saját menümet.

20-21 óra - Mi van az étlappal?

Tovább dolgozom az étlapon. A menü könnyen csatlakoztatható az objektumhoz, vagy inkább az objektum egy menüt generál, ami megkönnyítette a visszacsatolás megvalósítását a játékos választásának feldolgozásához.
Elkezdtem dolgozni a tételmenüvel. Már megjelenik a megfelelő helyen, és lehetőséget ad egy-egy elem kiválasztására, de megnyomva még nem csinál semmit, csak a menü bezárására szolgáló gomb működik.

22 óra – Elalvás folyamatban

Továbbra is dolgozom a dolgokon – próbálom megvalósítani a funkcionalitásukat, és megtanítom őket reagálni a menüparancsokra, beleértve a környezeti információk hozzáadásának lehetőségét is. Most már kevés a funkciója, de továbbra is működik, és információkat jelenít meg a futó parancsról
Javítottam a mozgás számítását különböző akciók végzése során, nagyobb mobilitást szerezve.

Észreveszem, hogy már késő van, és jóval túlléptem az erre a munkára szánt órát. Ha nem figyelnék a teljes fejlesztési időt, valószínűleg reggelig ülnék. De mivel időkorlátom van, egy majdnem elvesztegetett óra nagyon rossz hír. Érdekes, hogyan változnak a prioritások, amikor nincs elég idő. Általában lefekszem.

23. óra - Csataparaméterek!

Módosítom (jó, tulajdonképpen csak most kezdem) az első órában létrehozott osztályattribútumok egy részét.
A jobb felső sarokban létrehozok egy panelt, amely megjeleníti a lejátszó opcióit.
Ezt az ablakot úgy optimalizáltam, hogy olyan képpé alakítottam, amely gyorsabban rajzol, mint a betűtípusok. Ez a kép csak akkor frissül, ha a kapcsolódó karakterparaméterek megváltoznak.

24 óra – Játékos menü

Befejeztem az opciók ablakának optimalizálását.
Létrehozott egy felugró menüt, amely akkor jelenik meg, ha a játékos egy karakterre kattint.
Készítettem egy gyorsmenüt a bájitalhasználathoz, varázsláshoz stb.
Kijavítottam néhány hibát a menüben.

25 óra – A padló és a falak (egyszeri) fűrészelése előtt

Ma reggel az agyamban támadt egy ötletem (tényleg akkora agyam van, hogy ennyi ötlet elfér benne?), hogyan lehetne megoldani a szomszédos szobák átfedő falainak problémáját (lásd a tizennyolcadik óra leírását). Mi van, ha csak a falak felét festem le? Így egyáltalán nem lesz átfedés, és nem kell bonyolult logikát hozzáadni az átfedések észleléséhez és kijavításához.

Elkezdek dolgozni ennek az ötletnek a megvalósításán. Sajnos valójában a kitalált egyszerűsítés még nehezebbé teszi a helyiség (főleg a padlók) rajzolását, és nem biztos, hogy olyan gyorsan valósul meg, mint reméltem. A rendszer létrehozása és hibakeresése körülbelül egy órát vett igénybe. De megérte.

A kód hibakeresése közben találtam még néhány hibát a szobák közötti átmenettel kapcsolatban.

SZÜNET – Válság!

Most vettem észre, hogy a fejlesztési idő több mint 3/5-e eltelt, és kevesebb, mint tizenöt óra van hátra a játék befejezéséig. Miután megnéztem a játék szükséges funkcióinak ütemtervét, és megbecsültem, hogy mindegyik megvalósítása átlagosan egy órát vesz igénybe, rájöttem, hogy körülbelül huszonöt órába telne minden megvalósítása. Tíz órával idő előtt. A projekt hivatalosan is veszélyben van.

Nem léphetem túl az időkorlátot. Asszisztenst vonzani, vagy kódot / erőforrást vásárolni sem lehet, mivel feltéve, hogy 40 órán belül egyedül készítem el a játékot. Ki kell találnom, hogyan dolgozhatok még hatékonyabban – de már most is maximális termelékenységgel dolgozom. Úgy tűnik, nincs más választásom, át kell gondolnom a funkcionalitást, és eldöntenem, hogy mely funkciókat dobjam ki a játékból.

Ajtók: Vágjuk! Nagyon szeretnék ajtókat csinálni a játékban. Kár megválni ettől a funkciótól - főleg, hogy már egy ideje dolgozom rajta. De még mindig túl sok a munka, például a mesterséges intelligencia. Valószínűleg 2-3 órába telik, míg munkába állnak, ami nekem nincs.
Leltár: Egyszerűsíts! Felejtsd el a kiegészítő készletet és a fegyverváltás lehetőségét. Minden, amit felvesznek, és nem lesz a jelenlegi felszerelés, azonnal pénzre váltják.
Buktatók: Egyszerűsíts! Szeretnék sok csapdát, amelyek érdekes és változatos következményekkel járnak az aktiválásukhoz. Nem arra való. A csapdák egyszerű vizuális hatást fejtenek ki, sebzést okoznak, és átmenetileg megnövelik annak esélyét, hogy véletlenszerű szörnybe ütközzek
Íjak (kis fegyverek): Vágd! A játékban csak közelharci fegyverek lesznek, távolról varázslatokkal támadhatsz.
Játék mentése/betöltése: Egyszerűsíts! Csak a karakter menthető meg, a világ állapota nem. (EDIT: én sem csináltam!)
Részecskerendszer: Halasztás! A részecskerendszer létrehozása áthelyezve a prioritáslista aljára. Kétlem, hogy meg kell tenni őket. Jó lenne lenyűgöző látvány varázslat részecskékkel... de valószínűleg soha nem lesz.
Varázslatok: Egyszerűsíts! Komoly elképzelésem volt a varázslatokról: tekercsek formájában is megtalálhatóak voltak, a számuk pedig több mint egy tucat. Szomorú, de csak néhány varázslat lesz: Heal, Damage, Weaken, Empower és Restoration. Ha szintet lép, lehetővé teheti a játékos számára, hogy a varázslatok növelésével növelje a varázslatok számát.
Animáció szörnyekről és játékosokról: Vágd! Szegény művész vagyok ahhoz, hogy elég gyorsan csináljam.

Amikor eldöntjük, mit nem fogok megtenni (vagy mit halasztok későbbre), ugyanolyan fontos eldönteni, hogy mit kell először megtenni.

Rengeteg olyan dolgot terveznek a játékban, amit nagyon fontosnak tartok - csapdák keresése, titkos ajtók (most, titkos átjárók) és ládák kinyitása. De a játék alapja mégis a harc. Ezért úgy döntöttem, hogy erre összpontosítok, és ez lesz a legfontosabb. Célt tűztem ki magam elé, másfél óra múlva életre kelnek a szörnyegeim, hogy megölhessék őket.

Remek, kitaláltuk a prioritásokat, tovább fejlődünk.

26. óra – Dobjunk kockával

A "kockák" mechanikáján dolgozom, egy olyan mechanizmuson, amellyel a véletlenszerűség egy eleme bekerül a játékba. Mivel nincs valódi kockamegkötésünk, tetszőleges tartományban kaphatunk véletlen számot. Például 1-től 33-ig, vagy 6-tól 17-ig. Így tudok dobni a kockával, összehasonlítani, mi esett a támadásommal és az ellenség védekezésével. Ha a dobott szám nagyobb, mint a védekezés, a támadás sikeres.

Tegyük fel például, hogy a teljes támadási értékem 15. Megtámadok egy szörnyet, amelynek 10-es védelme van. Az esélyem 15 a 25-ből (25 = 15 +10), vagy 3 az 5-ből. Tehát a játék egy véletlen számot generál 1 és 25 között, és ha ez meghaladja a tízet, én nyerek.

Az okozott kár kiszámítása kissé eltérő módon történik. Hozzáadtam a "páncélt" a védőhöz és a "sebzést" a támadóhoz. Egy véletlen számot generálok 1-től az összegükig, majd kivonom a páncélt. Ha az eredmény egynél kisebb, akkor nem történik kár. Ellenkező esetben megegyezik az eredménnyel. Így, ha egy 10 sebzéses szörnyeteg megtámad egy 5 páncélponttal rendelkező játékost, a játék egy 1-től 15-ig terjedő számot generál, amiből levon 5-öt, ami történik, az a sebzés.

Ez a magyarázat és leírás tovább tartott, mint a megvalósítás.

Az óra végén lecsökkentettem a dungeon megjelenítési terület méretét, most a jobb oldali ablakrész teljes egészében a kezelőfelületé lett, ez a változtatás enyhe teljesítménynövekedést adott. Arra is ügyeltem, hogy a lejátszó mozgása ne függjön a képfrekvenciától.