Spelutveckling - tutorial?

Hej,

Jag har fundering kring ett spel(2d) jag vill utveckla för android, finns det några vettiga tutorials på antingen engelska eller svenska? jag kan programera android applikationer så jag behöver inget som börjar med grunderna i java och android programmering. behöver just något som visar hur utvecklingen av 2d spel går till.

tack!

 

http://developer.android.com/videos/index.html#v=U4Bk5rmIpic

http://developer.android.com/videos/index.html#v=7-62tRHLcHk

 

Ett tips är att använda en färdig "spelmotor" som till exempel AndEngine. Ganska bra dokumenterad och underlättar vid spelprogrammering.

 

tack för tipsen! skall kolla på det lite, verkar så otroligt krångligt jämfört med vanliga applikationer^^ men är väl som allt att man bara måste sätta sig in i det

 

Jag håller för närvarande på med ett projektarbete där jag ska göra ett spel för Android. Vad jag rekommenderar står endast för mig och är absolut ingenting som behöver passa alla.

Vad jag rekommenderar är följande:

1: Använd ingen spelmotor eller dylikt. Försök hellre själv att bygga upp en spelmotor genom att hämta inspiration från andra projekt samt använda din egen kunskap. Först när du har gjort detta så har du en förståelse som krävs för att förstå ändå in i djupet i spelmotorn (om du nu vill det dvs. ).

2: Lär dig olika mönster s.k. "patterns" som gäller för spelprogrammering. Till exempel Memory Pools, Component och dylikt. När du har satt dig in i dessa förstår du strukturen i hur ett spel ska vara uppbyggt. Det kan annars vara lätt att missa detta när man använder sig av en spelmotor.

3: Ta tid på dig. Många slänger ut spel (vissa gör det bra, andra gör det inte) som säkert i sig är kul men strukturen i koden är fruktansvärd. Detta gör spelet fruktansvärt svårt att underhålla. Detta är bara ett antagande men det känns som att i alla fall 10% - 20% av alla lätta spel är ett ihopplock av olika saker. Jag har t.ex. i mitt projektarbete precis kommit till delen där själva fysiken ska utvecklas (spelet i sig) men spelmotorn är klar. Detta för att jag har tagit månader åt att förstå specifika saker (som inte bara gäller för Java/Android-utveckling).

4: Först nu skulle jag rekommendera att köra en spelmotor då spelmotorn oftast löser spelmönstersproblemen. Nu har du förståelsen som krävs (och jag lovar), den förståelsen är härlig när man förstår något ändå in i djupet.

5: Börja med Canvas-API:et om du känner att OpenGL ES är för svårt i början. Jag håller för närvarande på med OpenGL ES i både 2D och 3D där jag skiftar allt eftersom förståelsen kommer till.

Sista punkten: Om du har problem med något specifikt mönster, gör ett enskilt projekt som hanterar detta. Jag har själv gjort fyra olika "tutorials"/projekt som demonstrerar vissa "patterns"/mönster (ett Type Object-pattern-projekt och tre Memory Pools-pattern-projekt) där t.ex. de tre delarna i Memory Pools-projekten definerar en egen svårighetsgrad/användningsområde. Detta är något jag inte har lagt ut men det är något jag tänka mig dela till Swedroid forum.

Till slut, jag har inte släppt något spel på Market och jag gör det inte om jag inte känner att det blir bra. Vad jag vet är att jag har förståelsen för hur ett spel är uppbyggt och att det kan vidareutvecklas ytterligare. Det som jag tycker är kul är när man faktiskt bygger hela spelmotorn själv. Då framstår själva spelet som väldigt simpelt och att det går snabbt att göra. Att det har dröjt en längre tid för mig är för att jag själv har valt att vilja förstå det jag gör. Jag vill inte bara skapa tre, fyra klasser och kludda ihop något projekt (vilket jag kunnat göra för att "bara" få ihop till ett projekt).

Dessa ord är säkert inga perfekta utan detta är vad jag tror ger en mest kunskap långsiktigt tänkt.

 

Kolla på Corona, som är ett färdigt framework för att skapa spel. Där programmerar du dock inte i Java, utan i ett språk som heter Lua.

 

Memory Pools: Gör det verkligen någon skillnad? Har du utfört några mätningar? För vad jag vet så förekommer försöker dalvik-vm återanvända objekt. Du kanske använder din Memory Pool för preallokering främst?

"ett Type Object-pattern-projekt": Vad är detta för pattern? Är intresserad.

Annars instämmer jag med att "högre förståelse" = "bättre kontroll". då jag själv gör en spelmotor/ramverk ( en stor sådan också ca 6000-8000 rader kod) och när jag själv utvecklar spel till den så går det blixtsnabbt och med fullkontroll.

 

Samtidigt; Premature optimization is the root of all evil. Börja koda. Optimera när det bevisat behövs.

 

Det beror på hur stort spel du tänker göra. För ett litet spel behöver man inte ett sådant system men vid större projekt bör man överväga detta. Jag själv tycker att det är smidigare att använda detta.

Nej. Innan jag använde detta system så fick jag en GC-körning ungefär en gång per minut via min aktivitet. Nu händer det betydligt mer sällan (cirka var femte minut), vilket jag har jämfört via DDMS och min aktivitets pid.

Innan man ska ge sig på dessa mönster så ska man vara säker på att det verkligen behövs, annars blir det onödig optimering.

Ja. Jag använder det också inom t.ex. detta taget-ur-luften-exemplet: "Du har tio bollar, en utav dem försvinner ur spelet -> skickas tillbaka till poolen, redo för återanvändning senare".

Säg att du har en parent-klass "Byggnad". Istället för att du skapar en ny klass för varje "Byggnad" (såsom lägenhet, bostadsrätt, villa etc) så har du istället en Byggnad-klass och sedan en child-klass som är en Boende-klass (kom inte på något bättre namn ). Sedan skickar du in olika parametrar till Boendeinstansen beroende av vilken byggnad det är. Det är en kort förklaring. Googla så får du upp en mer fullständigare förklaring.

Ja. Man ska dock inte använda t.ex. Memory Pools om man inte behöver det eller om optimeringen är onödig.

 

LibGDX
Kanske inget bibliotek att börja med men rekommenderas för er som redan kan en del om OpenGL. Fördelen med LibGDX är att det går att köra spelen på datorn med hårdvaruacceleration så att testning går snabbare, sedan används samma kod för att köra det på Android. Och att det stödjer OpenGL ES 2.0

 

Det är just detta fallet som dalvik-vm brukar kunna fixa själv genom att "ibland" återanvända bollen. Dock så garanterar memory poolen att det återanvänds.

jaha "Composition before polymorfism".