játékfejlesztés.hu
FórumGarázsprojectekCikkekSegédletekJf.hu versenyekKapcsolatokEgyebek
Legaktívabb fórumozók:
Asylum:    5448
FZoli:    4892
Kuz:    4455
gaborlabor:    4449
kicsy:    4304
TPG:    3402
monostoria:    3284
DMG:    3172
HomeGnome:    2919
Matzi:    2520

Pretender:    2498
szeki:    2440
Seeting:    2306
Geri:    2188
Orphy:    1893
Joga:    1791
Bacce:    1783
MaNiAc:    1735
ddbwo:    1625
syam:    1491
Játékprogramok objektum-orientált tervezése 2007.10.19 15:46


Az említettek demonstrálásához egy esettanulmányt ismertetek. Az ELTE IK programtervező-matematikus szakon a Programozási technológia 2. tárgy gyakorlati részének teljesítéséhez egy szoftvert kellett elkészíteni csapatmunkában. A mi csapatunk a SpaceHunters nevű 2d-s űrhajós lövöldözős játékot fejlesztette erre a célra. A projekt életciklusa az alábbi fázisokra bontható:
1. Ajánlás
2. Követelményleírás
3. Rendszerterv
4. Implementáció, kódgenerálás (a többi fázissal párhuzamosan)
5. Előzetes bemutatás (demo)
6. Késztermék átadása a teljes dokumentációval
7. Karbantartás, utómunka

A felsorolás elemei tulajdonképpen a projekt mérföldköveit is mutatják, melyeket a félév folyamén határidőre el kellett érnünk. Lássuk részletesen, mit takarnak ezek a fázisok!

1. Ajánlás – (a részfeladat teljesítésének határideje: 2.hét)

Itt kell meghatározni, milyen jellegű szoftvert szeretnénk készíteni, mely eléggé összetett ahhoz, hogy a tudásunkról számot adjon, de nem is túl bonyolult ahhoz, hogy határidőre be tudjuk fejezni. Itt kell átgondolunk, hogy mihez értünk, milyen célokat tűzhetünk ki magunk elé, melyeket meg is tudunk valósítani, illetve a kezdeti feladatok csapaton belüli felosztására is sor kerül.

2. Követelményleírás - (5.hétre)

Le kell írnunk részletesen, akár kategorizálva is, hogy mit kell tudnia a programnak, milyen funkcióit és hogyan szeretnénk megvalósítani. Utalva a Csapatot keresel? jf.hu cikkre, nem elég azt mondani, hogy egy startcraft-szerű játékot szeretnék készíteni, írjuk le, hogy mi lesz benne a játékban: pl.: lesz benne egyjátékos mód, beállítások, ponttábla, stb... ez után részletezve mondjuk az egyjátékos módot, hogy itt egy űrhajót irányítunk, amivel szembe ellenfelek jönnek, őket kell különféle fegyverekkel megsemmisíteni, cél: minél több pont összegyűjtése. Ez után ki lehet térni, hogy működnek a fegyverek, hogy mozognak az ellenfelek stb... Ezeket az ötleteket össze kell gyűjteni egy dokumentum fájlba, mások számára érthetően megfogalmazni, az átláthatóság kedvéért vázlatszerűen pontkra, alpontokra bontani. A dokumentáltság nagyban segíti a hatékony csapatmunkát, a fejlesztők tudják, mit kell tenniük, illetve kisebb a félreértés esélye is.

Az UML az ún. használati esetek diagramjával támogatja, hogy vizuálisan is ábrázoljuk, mire használható, milyen funkciókat és részfunkciókat kell ellátnia, illetve hogyan kommunikál a különféle felhasználócsoportokkal a programunk. A SpaceHunters esetében használati esetek diagramja az alábbi módon néz ki:



A pálcika ember élő személyt ábrázol, körökben találhatók az egyes használati esetek, melyek további esetekre bonthatók. Az ábra mutatja, hogy a játékos milyen funkciókat, azon belül részfunkciókat használhat a programban, illetve van egy speciális felhasználócsoportunk, a tervező, aki nemcsak játszik a programmal, hanem új pályákat is készít hozzá, balanszolást végez stb...
Ezen kívül meghatározzuk a nem-funkcionális követelményeket, pl.: fejlesztőeszközök, grafikai/fizikai motor ...

Az eredeti követelményleírását itt olvashatják
316-kovetelmeny.pdf


3. Rendszerterv – (8. hétre)

Elkészítjük a meglévő követelményleírás alapján a rendszertervet.

A statikus modell:

A rendszerünk szerkezetét az UML által biztosított osztálydiagrammal írhatjuk le.
Először is össze kell szednünk milyen objektumok/osztályok fognak szerepelni a játékban, oly módon, hogy ez később a kódolásban segítségünkre legyen. A SpaceHunters esetében ilyenek pl.: menük, gombok, a világ(űr), űrhajók, lövedékek, bonuszok ... stb. Ezt követően az objektumok közötti kapcsolatokat, közös tulajdonságokat kell átgondolnunk. Ilyenek pl.: tartalmazás, származtatás, művelet végrehajtása egy másik objektumon. A mi esetünkben: a világunkban vannak űrhajók, lövedékek, felvehető bonuszok tetszőleges számban, azt is tudjuk, hogy ezeknek közös funkciója, hogy ki kell rajzolni őket, mozognak, mozgás közben kölcsönhatásba léphetnek egymással. E közös tulajdonságok hatékony megvalósításához használhatjuk fel az OOP programozás egyik alappillérét, a származtatást. Kell nekünk egy absztrakt ősosztály, legyen űrobjektum (CSpaceObject), melyre igazak az említett közös tulajdonságok, tegyük fel, rendelkezik az ezekhez szükséges adattagokkal és függvényekkel. Ezután a CSpaceObject-ből származtathatjuk az űrhajót(CShip), a lövedéket(CShot) és a bonuszt(CBonus), a meglévő(a CSpaceObjecttől örökölt) tulajdonságaik mellé elkészíthetjük a speciális csak rájuk jellemző funkciókat (pl a hajónak vannak fegyverei, a bonusznak meg típusa stb...). A származtatást az UML diagramban az ősosztályhoz kapcsolódó fordított háromszög jelöli, a belőle kijövő ágak a származtatott osztályokhoz vezetnek.
Más jellegű kapcsolat, amikor egy objektum egy másik objektumnak része, ezt a tulajdonságot az UML kétfelé bontja. Az első a (laza) logikai tartalmazás vagy másnéven aggregáció, pl.: a világban (CWolrd) vannak űrobjektumok. Ez laza kapcsolat ugyanis a CWorld és a CSpaceObject-ek élettartama nem függ szorosan egymástól, űrhajók felrobbannak, lövedékek létrejönnek a CWolrd „élete” (létrehozása és megsemmisítése közt eltelt idő) során. Ezen kívül a CWorld létezhet önmagában is mindenféle CSpaceObject nélkül. A másik típus a (szoros) fizikai tartalmazás, másnéven kompozíció. Pl.: a CShip a fegyvereivel (CWeapon) kompozíciós kapcsolatban áll, hiszen ugyanabban az időben jönnek létre, ugyanakkor semmisülnek meg, a mi leírásunk szerint CShip nem létezhet CWeapon nélkül és fordítva, „fizikailag” is összetartoznak. UML-ben a logikai tartalmazást üres fehér rombusz, míg a fizikai tartalmazást fekete rombusz jelöli a tartalmazó osztályhoz kapcsolódva. Tartalmazásnál feltüntethetünk multiplicitásokat is, pl.: a CWorld tartalmazhat tetszőleges számú CSpaceObjectet (*), vagy egy CShip-ben pontosan 20db CWeapon van.
Az objektumok műveleteket hajthatnak végre egymáson, pl a CWorld létrehozhat (ToCreate) új CSpaceObject-eket, míg a CSpaceObject-ek egymással reakcióba léphetnek (ToReact). Ezt az UML-ben az osztályok közötti egyenes vonal jelöli, rajta az akció neve, a mellette lévő kis fekete nyíl az aktív objektumtól a passzív felé mutat. Illetve van még egy viselkedés szempontjából speciális hajótípusunk az CAvatar, melyet a játékos irányíthat.
Íme az így kapott osztálydiagram:



Hasonlóan készíthetjük el a menürendszert, reprezentáló osztálydiagramot, ha tudjuk hogy minden menüben közös, hogy képeket, szövegeket jelenít meg, van rajta kurzor és gombok, melyekkel funkciókat lehet vezérelni (pl átlépés egy másik menübe). Az egyes osztályokhoz szaggatott vonallal magyarázó szövegeket kapcsolhatunk, ha szükséges:



A dinamikus modell:

Programunk működését írja le igény szerinti részletességgel, eszközei többek között az állapot és a szekvenciadiagram. Nézzünk pár egyszerű példát (nem térek ki az összes játékbeli elem működésére)! Vegyük például egy fegyver (CWeapon) működésének leírását állapotdiagram segítségével! A CWeapon állapotát kétféle tulajdonság jellemzi, az aktivitása (ki van-e jelölve aktuális fegyverként) és a feltöltöttsége (van-e benne töltény). Ezt a két tulajdonságot külön, újabb állapotdiagramokban fejtjük ki. Aktivitás szempontjából kétféle állapot létezik: ’Aktív’ és ’Inaktív’ (az egyes állapotok lekerekített sarkú téglalapba kerülnek). Az egyik állapotból a másikba akkor juthatunk át, ha a közöttük lévő nyílon lévő tulajdonság teljesül (vagy az adott akció bekövetkezik). Pl.: ha egy fegyver aktív és választunk egy fegyvert, ami nem ez a fegyver, akkor a fegyverünk ’Inaktív’ lesz, és fordítva. Fegyverünkkel akkor tüzelhetünk, ha aktivitás szempontjából ’Aktív’, illetve Feltöltöttség szempontjából ’Töltött’ állapotban van.



A menürendszer működését leíró állapotdiagram:



A másik fajta diagram típus a szekvenciadiagram, ami a játék egy tetszőleges működését írja le, szemléltetve, miképp kommunikálnak egymással a játék objektumai. Pálcikaember jelöli az aktort, aki a programot vezérli, szaggatott vonal az objektumok életvonalát, felülről lefele haladva az objektumok által egymásnak küldött üzeneteket láthatjuk nyilakon. Az életvonalon található fehér téglalap jelzi, hogy az adott objektum aktív állapotban van, tehát üzenet küldésére képes.



A diagramokon kívül érdemes az osztályokról külön-külön szöveges jellemzést írni, milyen adattagokkal, függvényekkel rendelkeznek.

Itt van a teljes rendszerterv:
316-rendszerterv.pdf



4. Implementáció (a többi fázissal párhuzamosan)

Erről a részről nagyon sok mindent lehetne írni, én csupán néhány egyszerűbb fogást szeretnék mutatni, hogyan generálhatunk kódot a rendszertervünk alapján. Először is szükségünk van egy objektum-orientált programozási nyelvre, csapatunk választása a C++-ra esett. Lássunk először pl.: a tartalmazás kapcsolat (aggregáció) megvalósítását a CWorld osztályban! CSpaceObjecteket szeretnénk tárolni egy olyan adatszerkezetben, melybe könnyen lehet elemet beszúrni, illetve törölni, hiszen a CSpaceObject-ek a program futása során tetszőleges időben jönnek létre és semmisülnek meg. Ez az adatszerkezet legyen a lista, melyhez a Standard Template Library (STL) támogatását használjuk fel. Íme a számunkra lényeges kódrészlet:
Kód:
// World.h: interface for the CWorld class.
//
//////////////////////////////////////////////////////////////////////
#include <list>

class CSpaceObject;

class CWorld 
{
public:
int CheckMoving();
void AddObject(CSpaceObject *so);

protected:
list<CSpaceObject*> m_so;
//...
};

Implementáció a World.cpp-ben:
Kód:
// World.cpp: implementation of the CWorld class.
//
//////////////////////////////////////////////////////////////////////
#include "World.h"
#include "SpaceObject.h"
#include "Ship.h"

void CWorld::AddObject(CSpaceObject *so)
{
so->SetWorld(this);
m_so.push_back(so); //itt kerül bele az obejetum a listába
}

int CWorld::CheckMoving()
{
//...
if (ReadMap()) //ha a map fájl szerint egyn új hajót kell létrehozni
{
AddObject(new CShip(/*...*/))
}

list<CSpaceObject*>::iterator it;
//végig „iterálunk” a listán
it = m_so.begin();
while (it1!=m_so.end())
{
(*it)->CheckMoving(); //meghívjuk az egyes űrobjektumok mozgás vezérlőjét
it++;
}
//...
}

A származtatásos kapcsolatok alapján elkészíthetjük az űrobjektumosztályok vázát:
Kód:
// SpaceObject.h: interface for the CSpaceObject class.
//
//////////////////////////////////////////////////////////////////////

class CWorld;
class CSpaceObject
{
protected:
CWorld *world;
public:
//virtuális típuslekérdező függvények
virtual bool IsShip()  {return false;}
virtual bool IsShot() {return false;}
virtual bool IsAvatar() {return false;}
virtual int CheckMoving(); //a virtuális CheckMoving() metódust minden //származtatott osztályban definiálnunk kell
//...
}

// Ship.h: interface for the CShip class.
//
//////////////////////////////////////////////////////////////////////

#include "SpaceObject.h"
#include "Weapon.h"


class CShip : public CSpaceObject  //a CShipet a CSpaceObjectből származtatjuk
{
protected:
CWeapon[20];
public:
bool IsShip() {return true;}
virtual int CheckMoving();
//...

}

// Avatar.h: interface for the CAvatar class.
//
//////////////////////////////////////////////////////////////////////

#include „Ship.h”

class CAvatar : public CShip  //a CAvatart a CShip származtatjuk

{
public:
bool IsAvatar() {return true;}
int CheckMoving();
}

Az állapotdiagramok kóddá alakításánál egy lehetőség, hogy készítünk egy felsorolás típusú változót, melyben az épp aktuális állapotot tároljuk, és egy elágazásban az egyes állapotok során végrehajtandó akciókat elvégezzük, illetve a lehetséges állapotváltozásokat a feltételeikkel elhelyezzük. Példaként vegyük a fegyver feltöltöttségét:
Kód:
// Weapon.h: interface for the CWeapon class.
//
//////////////////////////////////////////////////////////////////////

enum loading_enum
{
ld_empty, ld_loaded;
}

protected:
loading_enum loading_state;
//...

// Weapon.cpp: implementation of the CWeapon class.
//
//////////////////////////////////////////////////////////////////////
//...

CWeapon::Operate(bool firing)
{
switch (loading_state)
{
case ld_empty:
loading_count++;
//állapotváltozáshoz szükséges feltétel (idő(k) == töltési idő)
if (loading_count == loading_time)
{
bullets = max_bullets;
loading_state = ld_loaded; //az állapot megváltoztatása
};
break;

case ld_loaded:
if (firing) ToFire();
if (bullets == 0)
{
loading_state = ld_empty;
}
break;
}
}

5. Előzetes bemutatás (11. hétre)

Érdemes a fejlesztés során valamilyen prototípust készítenünk mielőtt a kész terméket befejeznénk. Egyrészt meggyőzni a megrendelőt, arról, hogy jól halad a dolog, emellett, ha valamivel probléma van esetleg egy funkció nem úgy működik, ahogyan elvárt, a hiba még korrigálható. A SpaceHunters esetében ekkorra készült el a grafikai motor, az irányító felület, az alapvető fegyverzet, a menürendszer váza, a sprite-ok jó része, illetve egy pályaszerkesztő is, hogy meghatározhassuk miként és milyen sorrendben jelenjenek meg az ellenfelek a pályán. A projekt ezen mérföldkövénél már elég jól körvonalazódott, hogy fog kinézni a játék és miként fog működni.

6. Késztermék átadása (15. hétre)

Az első demónk bemutatása után sok munka várt még ránk. Befejeztük a nehézfegyverzetet, kiviteleztük az összes menüpontot, megfelelő pályákat szerkesztettünk és készítettünk egy kisebb kampány-sztori rendszert. Ezenkívül sokat kellett foglalkozunk a felület felhasználóbaráttá tételével: informatív szövegek elhelyezése, gombok, konfigurálható billentyűzet kiosztás és játékismertető. Elkészítettük a felhasználói dokumentációt, mely tartalmazza a játék alapvető funkcióinak leírását, hardver és szoftver követelményt illetve a készítők elérhetőségeit. A programot ezután még belepakoltuk egy telepíthető állományba, ezáltal egyszerűbben el lehet indítani.

A felhasználói dokumentáció:
316-felhasznaloi.pdf

7. Karbantartás, utómunka (jelenleg is tart)

Ebben az utófázisban nyílik lehetőség a felhasználók által megtalált rejtett hibák (bugok) kijavítására, és a rendszer balanszolására, hogy a játékmenet ne legyen túl könnyű vagy nehéz. Ha szükséges megpróbáljuk optimalizálni a grafikai motort, illetve igény esetén újabb kampány(okk)al bővíteni a játékot.

Végül összefoglalva miért is lehet fontos számunkra a szoftvertervezés és dokumentálás:
- ha csapatban dolgozunk nagyban segíthet a munkamegosztásban, illetve a félreértések elkerülésében, illetve helyes ütemezéssel (fázisokra bontás) nagyobb az esélye, hogy elkészül a projekt
- ha új fejlesztőket szeretnénk bevonni a projektbe, talán nagyobb eséllyel csatlakoznak, ha látják, hogy a játék jól megtervezett, könnyen átlátható
- ha egy időre szüneteltetjük projektünket, akkor a meglevő dokumentáció alapján könnyebb újra indítani a fejlesztést, tudjuk, hol tartunk vele, hogy működik, és talán nem kell fáradtságos kódbogarászásba kezdenünk, pl.: ha a kód öndokumentáló( megfelelő kommenteket, „beszédes” azonosítókat tartalmaz)
- az egyes szoftver komponensek újrafelhasználhatóak, ezt támogatja az OOP az adatrejtés technikájával, pl ha van egy jól működő grafikai motorunk vagy menürendszerünk, - amennyiben helyesen kódoltuk és dokumentáltuk - könnyebben építhetjük be újabb programjainkba

Remélem segítettem betekintést nyújtani egy lehetséges fejlesztési módszerbe. Szívesen fogadok mindennemű kérdést és kritikát a cikkel kapcsolatban.

Forrás:
Sike Sándor, Varga László: Szoftvertechnológia és UML, ELTE Eötvös Kiadó

Linkek:
- OOP-ről: http://hu.wikipedia.org/wiki/Objektumorient%C3%A1lt_programoz%C3%A1s
- UML-ről: http://hu.wikipedia.org/wiki/Unified_Modeling_Language

A teljes cikk letölthető pdf formátumban is:
316-cikk.pdf

Értékelés: 10.00

Új hozzászólás
Geri          2007.11.04 03:38
A kommunikáció megtörtént.
Szidi_Rezegh          2007.10.31 12:18
Ez lehetséges, az MSN címem: kovmat86@hotmail.com
Szívesen diskurálok a témáról.
Geri          2007.10.31 05:50
Szidi_Rezegh: ezt inkább valami azonnali üzenetküldő protokol segítségével beszéljük meg.
Asylum          2007.10.29 19:33
Ja használati utasitás:

-treeview ben projektre jobb klikk, add
-toolbargombra klikk aztán a rajzfelületre klikk
-tulajdonságok szeresztéséhez dupla klikk az objektumra
-asszociácio stb. -hez klikk a toolbar ikonra aztán klikkelsz az egyik objektumra, lenyomva tartod az egérgombot és huzod a másikra
-objektum törléséhez kijelölöd és a treeview fölötti toolbar on a megfelelö gombra klatty
Asylum          2007.10.29 19:24
progi a honlapomrol letölthetö

http://people.inf.elte.hu/asylum/

ajánlom figyelembe a Tools -> Doom Monsters opciot amivel szörnyeket is (hát csak képeket) lehet letenni.
Ezért lett DooML a neve
kzprog          2007.10.28 11:20
Nem kívánom osztani az észt, ezért csak néhány - szerintem lényeges - gondolattal egészíteném ki (foglalnám össze) az eddig elhangzottakat:

1. Valamilyen terv kell!
2. A feladatot elsőként felülről érdemes áttekinteni (felülről lefelé tervezés)! Vizuálisan is! (milyennek képzeljük majd el működés közben - nyugodtan lehet rajzolni! nem túl részletesen; az emberek többsége inkább vizuális típus!)
3. Kell egy (csapat esetén közös) leíró nyelv! (ez akár folyamatábra is lehet ) Ez a leíró nyelv egyik csapattagnak se legyen túl magas (Nem kell erőltetni az UML-t)
4. Nem szabad a tervezésnek elnyomni a kreatívitást! (kis csapatoknál ez a csapat életképességét jelentheti - a shareware kategóriában legalábbis!)
5. Mindenki olyan módszert használjon, amellyel alkotni (valódi értéket, nem pedig tucatárút!!!) képes!

A cikk azok számára is hasznos - szerintem - akik még sosem terveztek (csak el ne riassza őket!) és azok számára is, akik már terveztek (jó elgondolásokat vehetnek át - csak meg ne próbálják ugyanígy csinálni)!
Szidi_Rezegh          2007.10.27 15:44
Asylum:
Néztem követelményleírást meg rendszertervet jók lettek, magára progira is kíváncsi lennék.
Tervminták tényleg hasznosak, itt a lehetőség, hogy cikket publikálj belőlük.

Geri:
Elég tömören fogalmaztál és némely esetben nem tudom, hogy jóra gondoltam?
"rosszak az elvek amelyekre fel lett húzva?" tehát azért rossz a dolog, mert maga az UML és a terv alapján történő szoftverfejlesztés ilyen formája nem megfelelő? Ez jogos felvetés lehet, mert az UML-t sok kritika éri, több oldalról is mindemellett széles körben alkalmazzák.
Vagy talán azt kifogásolod, hogy egy GP esetén erőltett/felesleges az ekkora mélységű tervezés, jobban a megvalósításon lenne a hangsúly?
"A játékfejlesztés nem holmi egzakt tudomány." Ez így igaz, de ez szerintem nem feltétlenül zárja ki, hogy tudományos eredményeket felhasználjunk, ha valamilyen "komolyabb" problémát szeretnénk megoldani. Pl.: fizikai motor írása, tudnod kell, hogy mi rejtőzik a háttérben és matematikai módon tudnod kell leírni, AI, hálózati kommunikáció, hatékonyan működő algoritmusok, épkézláb adatbázis, stb..., ezeknek mind-mind komolyan lefektetett, egzakt, tudományos alapjai vannak. A projekt- és csapatmenedzsmentnek szintúgy(útobbiak persze nem biztos, hogy túl lényeges tényezők "GP szinten".

Matzi:
Ha jól veszem ki a szavaidat, te arra gondolsz hasznos a tervezés, csak kiscsapatnál kevéssé lényeges.
ShAdeVampirE          2007.10.27 07:06
JÓ cikk, mindenképp érdemes volt közzé tenni, szerintem sokan tanulhatnak belőle, valamint időnként újranézni is érdemes (mert hát ugyebár felejt az ember...)
Geri          2007.10.27 05:19
Természetesen igazad van, ez így van, és örülök hogy te így gondolod (és bízom benne hogy a cikk írója is így gondolja). Az a bajj ott kezdődik hogy sokan nem így gondolják. Amit írtam, az nekik szólt. Úgyis nemsokára megjelennek itt.
Matzi          2007.10.27 02:42
Geri:
Szerintem te nem érted a lényegét. Ez egy tervezési módszertan, ami nem abban segít, hogy jó játékot csináljál, hanem abban, hogy amit elterveztél, azt meg is tudd csinálni, ha kell úgy, hogy sok ember dolgozik rajta, stb. Az egész nem a játéktervezésre van kihegyezve, tehát nem foglalkozik olyan kérdésekkel, mint játék élmény vagy a zseniális alapötlet. Amikor egy hárazt terveznek, azt sem úgy teszik, hogy majd otthonos legyen, hanem legyen egy épeszű elrendezése, a belső tereket meg majd kitölti a lakberendező, illetve az elrendezést (ötlet) megmondja valaki, aki ért hozzá. Az építész ehhez rajzol egy tervet, amit ha megépítenek nem fog összedőlni a ház, meg nem lesz az egész összegányolva. Persze lehet minden nélkül építkezni, és az esetek kis százalékában egy nem túl bonyolult struktúrát össze is lehet hozni, de ez általában lényegtelen. Ettől viszont nagyon nem lesz értelmetlen a tervezés, sőt, a hatékonysága igazolja a létjogosultságát, maximum vannak olyan kiegészítő szerepek (a tervezőn kívül), akik egyéb szempontokat is figyelembe véve kiegészítik az alapot. A játékfejlesztés is ilyen, ez a módszertan nem fogja kiváltani a designer, grafikus, stb egyéneket, csak ad egy lehetőséget, hogy a programozók struktúráltan dolgozzanak, minden a helyén legyen, stb. Az egészben az a jó, hogy a terveket könnyeb módosítani mint a kódot, így egy egységnyi hibát jelentősen kevesebb munkába kerül kijavítani a tervezési fázisban, mint később. És ez a játékfejlesztésben sem lebecsülendő tulajdonság, bár ez nem igazán jön ki 1-2-3 adott esetben egyébként összeszokott programozó esetében, de nagy csapatban igenis jó ez.
Geri          2007.10.26 17:25
(bocs Szidi_Rezegh, ez nem ellened irányul, hanem az elvek ellen.)

Rossz a leírás, rosszak az elvek, amelyekre fel lett húzva. Rossz a szemlélet.
A játékfejlesztés nem holmi egzakt tudomány. Aki azt hiszi, az egy tapottat sem tett még meg az igazi játékfejlesztés irányába.
Asylum          2007.10.24 08:10
Még tervmintákról jöhetne egy cikk azok is baromi hasznosak tudnak lenni.
Asylum          2007.10.24 08:05
Jó hogy végre itt is megjelenik ez a témakör Az én csapatommal UML szerkesztöt irtunk csak a pdf ek nincsenek már meg Megprobálom elökeriteni.
Carlos          2007.10.24 05:11
Gratulálok! Nagyon szép munka!
Valahogy így kell professzionálisan (játék)szoftvert kivitelezni.
Sok sikert a továbbiakban is.

Üdv,
Carlos

U.i.
UML-modellezéshez ajánlom a StarUML-t, nagyon jó, és nem utolsó sorban ingyenes!
Szidi_Rezegh          2007.10.23 02:28
Mi speciel ketten dolgoztunk a kódon és alapvetően két implementációs fázis váltogatta egymást. Először beosztottuk, hogy ki milyen osztályokat valósít meg, ezeket külön elkészítettük, aztán összeültünk, hogy a programot "integráljuk", azaz a különálló osztályokat összekapcsoljuk, aztán megint külön dolgoztunk az osztályokon. Az integrálás az ún. XP(Extreme Programming) modell szerint zajlott, azaz egy ember kódolt, a másik pedig figyelte, hogy mit csinál, és ha a kóder elakadt vagy hiba merült fel, a figyelő ember gyorsabban meg tudta mondani mi a megoldás, mert neki nem kellett annyira a kód szerkesztésére figyelnie. Ez néha nagyon mókás tud lenni, pl a másik türelmetelnül anyáz mögötted "hogy te barom megint mit csináltál, lehagytad a pontosvesszőt...", de helycserénél is ez van akkor meg te osztod az észt. Így egyébként sokat lehet tanulni, ha a másik alkalmaz egy jó módszert azt elsajátíthatod, ha valamit meg nem csinál olyan jól arra meg javasolhatsz valami jobbat.
Lord_Crusare          2007.10.22 10:15
"Ameddig egymagad dolgozgatsz a prog részen addig persze működhet az, hogy fejben elmélkedsz róla":

Ez teljesen jogos, én ugyanis eddig MINDIG egyedül fejlesztettem, és zömmel mindig a fejemben volt az, hogy mit is szeretnék. Mivel az engine-t és a játékot is egyedül dobtam össze pl. az Arcan-nál, ezért aztán sosem gondolkodtam azon, hogy akár többen is programozhatnánk.
Egyébként még sosem próbáltam másik programozóval vállvetve dolgozni... Egyszer lehet kipróbálom, milyen is az. Na, valaki? Tapasztalatok ?
kicsy          2007.10.22 04:28
Játékfejlesztésnél elsősorban a game-design az, ami kell, és amit rendesen dokumentálni kell már egy GP-méretű projectnél is. Az UML elsősorban a programozók eszköze, a program-tervezési modellben a design-doksi leginkább a követelményeknek felel meg. Mondjuk én is elsősorban erre gondoltam tervezés címen, de a kézzel foghatóbb részeket is valamilyen szinten meg kell tervezni: ha nincs pl egy kidolgozott content pipeline-od, akkor gyárthatják a grafikusok a modelleket, meg írhatja a kóder a nextgen engine-t, egy ponton rá fogsz jönni hogy nem tudsz mit kezdeni velük, és mondjuk az összes modellen/textúrán változtatni kell.
Matzi          2007.10.22 03:45
kicsy:
Nekünk is tanítottak több tárgyból mindenfélét, de ezeknek az igazi ereje abban van, hogyha van egy nagy rendszered, amibe bármikor új embereket kell bevonnod, vagy megtalálni egy apró hibát, akkor jóeséllyel menni fog. Ha nagyjából változatlan, kisméretű csapat dolgozik rajta, akkor a nagy része felesleges. Ha kutyaházat készítesz, ahhoz nem kell részletes tervezés, egy sufnihoz már nem árt valamennyi, egy házhoz kell normális alaprajz, de például egy hídnál, vagy egy felhőkarcolónál brutális mennyiségű tervezés szükséges.
Ezért mondom, hogy szerintem egy átlagos GP, de talán még egy nagyobb program is elég jól meg tud lenni szekvencia diagrammok nélkül, és sokkal fontosabb, hogy minden fontosabb elemre gondoljon a készítő. Nekünk tanítottak komplexebb módszereket is, amikkel lehet verifikálni és validálni a tervezett modellt, sőt, akár kész kód is generálható az alapján, de valamiért kétlem, hogy a játékfejlesztésben használnának ilyesmit.

Szidi:
Persze. Nem azt mondom, hogy az egész hülyeség, sőt, van néhány része, ami akkor is elengedhetetlen, ha az ember nekifutásból fejleszt. Bizonyos részei meg arra jók, hogy legyen specifikálva, és a kínai napszámos tudjon úgy kódolni, hogy lövése sincs sarról mi lesz a végén a projektből.
nagyy          2007.10.22 02:00
Szidi_Rezegh:
Kösz az infót, asszem meg is nézem majd azt a progit.

~Cre@tine~>:
Igen, a pdf-eket valóban nem olvastam végig, de akkor majd ezt is bepótolom.
Szidi_Rezegh          2007.10.22 01:28
Matzi: annyiból jogos a felvetés, hogy az UML és a modell alapján történő szoftverfejlesztés igazi ereje nem kisebb játékoknál, hanem kompex rendszerek elkészítésénél mutatkozik meg. A SpaceHunters is elkészülhetett volna részletes dokumentáció nélkül(talán még gyorsabban is), de nem ez volt a célunk.
Azt se felejtsük el, hogy GP és GP közt is nagy különbségek vannak. Egyszerűbb eseteknél lehet, hogy elsőre nem tűnik kézenfekvőnek, hogy tervezgetéssel töltsük az időt (azalatt már elkészülne a kód is), annyiból viszont megfontolandó a módszer, hogy pl ha egy egyszerűbb feladatot tervezett módon oldassz meg, akkor nagyobb az esély arra, hogy egy összetettebb problémával(amit esetleg nehéz lenne fejben kezelni) is boldogulsz. Pl.: ha egy valamirevaló AI-t akarsz írni, ott segítségedre lehet egy állapotdiagram, míg hálózati kommunikációnál a szekvenciadiagram lehet hasznos.(hangsúlyozom, hogy nem kötelező használni, csak segíthet).
Hogy mennyire felesleges a teljes életciklus(habár a példabeli nem is egy túl bonyolult modell), azt nehéz megmondani, mindenesetre jó, ha az ember ilyet is lát.
kicsy          2007.10.21 18:03
Matzi: a jelenlegi és elmúlt idők garázsprojectjeit elnézve azért vad kijelentés, hogy felesleges ilyen szinten a tervezés. Egy-egy minigame-szintű játékhoz oké, ha egyedül vagy és lekódolod max fél hét alatt, de még ott is meggyorsíthatja a fejlesztést ha lefixálod mit akarsz és hogyan. De a GP-k nagy részénél azért nem minigame szintű az ötlet.
A követelményváltozás meg azért elég gyakori a szoftverfejlesztésben (legalábbis nekünk két tárgyból párhuzamosan ezt verik a fejünkbe). Persze az alap dolgok nagyjából tiszták, de pl GUI-módosítások, további fícsörök és elég sok minden bejöhet még: kezdetben sokszor a megrendelő sem tudja mit akar, vagy hogyan fogalmazza meg - persze ennek mértéke erősen esetfüggő. Mint írtam a hatékonyabb modellek arra épülnek, hogy prototípus-fejlesztés, és a visszajelzések alapján a specifikáció egyre pontosabb megfogalmazása, újabb prototípus és így tovább, minél gyakrabban. Egy játéknál pl. simán alap az ilyesmi, hiszen ott nincs kőbe vésve a game-design, a fejlesztés közben fícsörök jönnek-mennek a teszterek visszajelzései alapján.
~Cre@tine~>          2007.10.21 15:22
@Lord_Crusare: Ameddig egymagad dolgozgatsz a prog részen addig persze működhet az, hogy fejben elmélkedsz róla, néhány ötletet papírra vetsz (esetleg CASE ezközt is bevetsz), de onnantól kezdve, hogy más programozó is bekapcsolódik a fejlesztésbe kénytelen vagy valahogy ledokumentálni a gondolataidat (amúgy se ártalmas dolog). Ha már rögtön többen kezditek akkor meg pláne, mert a többiek miből fogják kitalálni, hogy te mégis mit akarsz? Az, hogy megmondod, hogy űrhajós játék lesz, meg majd menet közben improvizálsz 1-2 osztályt is hozzá az nem sok instrukció.

@nagyy: Nem olvastad el a .pdf-eket: Rögtön az elsőben írják: "Fejlesztıeszközök: ...rendszertervhez modellek készítését PSUML nevő diagramszerkesztővel végezzük..."
Matzi          2007.10.21 12:17
Azért az ilyen fejlesztési módszerek nem épp a garázs játékfejlesztésre lettek kitalálva, sokkal inkább ipari méretű és előre viszonylag jól behatárolható működésű rendszerekre. Ott pedig senkinek nem jut eszébe menet közben, hogy a vasuti irányító rendszer inkább kezelje a reptér forgalmát, ami meg szóbajöhet módosítás, az megoldható adott kereteken belül. Nálunk úgy volt, hogy a skeleton leadása után mindig változtattak valami többé-kevésbbé lényeges részletet (lévén a feladat is adott volt), hogy az ember tudja mit kell csinálni ilyenkor.

Kis csapatoknál ez a módszer igazából fölösleges. Van pár értékes része, ami dokumentálja nagy vonalakban, hogy mi-mit csinál, és úgy általában jól felsorolja, hogy mit kell megvalósítani, és nem utólag kell beleheggeszteni az olyan részeket, amiket az ember túl egyszerűnek vélt, hogy foglalkozzon bele, de a legtöbb dolgot egyszerűbb leprogramozni, mint megrajzolni a sequence diagramokat. Nálunk eleve úgy nézett ki, hogy kiadták a feladatot, és aznap estére leprogramnoztam a játékot, bár ha mi dönthettünk volna a játék témája felől, akkor lehet, hogy bonyolultabbat választunk, és kellett volna még némi idő.
Szidi_Rezegh          2007.10.21 11:35
nagyy:
Pacestar UML Diagrammer-t használtam

Lord_Crusare:
Nekem az a tapasztalom, hogy amelyik projektemet nem terveztem meg előre, az nem sikerült túl jól, de ez egyéntől is függ. Vannak emberek, akik rögzített terv nélkül is átlátnak egy rendszert, mert elég tehetségesek vagy nem olyan bonyolult a feladat.
Ha a játék implementálása közben támad az embernek egy jó ötlete, akkor persze beleteheti, módosíthatja utólag a tervet (ahogy ez velünk is előfordult), de ez függ a változtatás nagyságától, pl ha menet közben derül ki, hogy nem TPS-t akartunk csinálni hanem RTS-t, akkor az rengeteg plusz munkát és hibát eredményezhet (enyhe kifejezés, hogy nem lesz optimális a kód, valszeg ki kell dobni a nagyrészét).
Úgy látom, hogy ipari szinten inkább a bevett minták és szabványok alapján történő fejlesztést részesítik előnyben(kisebb kockázat, nagy rendszerekre könnyebb alkalmazni), de ez nem jelenti azt, hogy a "kreatív" fejlesztőknek ne lenne jövője(sőt!).
Valaki predefiniált dallamokból rak össze zenéket? Őket hívják DJ-nek nem?
kicsy          2007.10.21 08:31
Több féle tervezési modell létezik, a legtöbbnek lényeges eleme, hogy a követelmény fejlesztés közben változik.
Lord_Crusare          2007.10.21 06:35
Hmm... Most ne sértődjön meg senki sem, de ez az egész nekem kicsit olyan, mint amikor egyik volt osztálytársam szolfézsre járt, és a zenei "szabályok" keretei között, logikus elemekből, predefiniált dallamokból rakott össze zenéket.
Ez ugyanilyen. Nekem a programozás mindig ötletek megvalósításáról szól, és a legjobb ötletek a játék készítése közben keletkeznek. De ugye az már nem a tervezés fázis, tehát nem tehetem bele? Vagy én értettem félre?
Meg aztán én sokszor próbáltam már előre tervezni, de mindig azokból a projektekből nem lett semmi. Nálunk csak jönnek az ötletek, és mikor van 1-1 kiemelkedő, akkor megvalósítjuk, és ezek spontán jönnek, a fejlesztés is így zajlik. Talán nem lesz precíz a kód, 1-2 helyen biztos optimalizálni kell, de mégiscsak jobb, mint minta után programozni.
kicsy          2007.10.21 04:21
Mi is épp ezzel a témával foglalkozunk proginfón - szintén progtechből -, be is linkeltem a cikket a kollegáknak
A mi beadandókból is össze akarok majd dobni egy hasonló cikket ha sikerül a jf témába vágót összehozni, egyelőre mondjuk még egy nagy homály hogy mit kell csinálni - így 7. hét környékén
De jó volt látni néhány ismerős diagramot, jó kis cikk
warlock          2007.10.21 01:21
nyomtatva...
buszon olvasásra kerül még a mai nap
nagyy          2007.10.20 11:15
Jó kis cikk lett.
Tavaly nekünk is volt egy hasonló tárgyunk a BMF-NIK-en, így legalább fel tudtam eleveníteni kicsit az ott tanultakat. Az UML diagrammokat egyébként melyik progival rajzoltattátok?
Joga          2007.10.20 05:39
Hasznos cikk

Főleg nekem
Szidi_Rezegh          2007.10.20 01:50
Elfelejtettem írni, hogy az említett SpaceHunters című játék jf.hu-s adatlapja innen is elérhető
http://ilabstudio.com/jf/gp.php?id=d1847afded38d6d

Magát a játékot pedig innen szedhetitek le:
http://www.silverforge.extra.hu/sh/sh_v1.0_install.exe
MaximumViolence          2007.10.19 23:20
nagyon jó
azt hiszem átértékelem a gondolatmenetem