På tide å forstå mekanismen i ett spill

[Tabbe]

Nå har jeg programmert en god stund, jeg forstår det meste jeg selv mener man trenger å forstå for å lage et veldig veldig simpelt 2d spill med c++.

Problemet mitt er bare at jeg ikke vet hvor jeg skal starte.

Når man skal lage et spill, hva er liksom det første man gjør, etc etc.

Hvordan er et spill bygd opp? hvordan fungerer alt sammens?

 

Jeg har sett på en del open source spill og sett igjennom sourcen deres og lært en del der, men jeg vet forstatt ikke hvor jeg skal starte og hvor jeg går derifra.

 

Det er derfor jeg lurer på om det er noen sider som har en steg for steg tutorial på hvordan du lager et veldig enkelt 2d spill?

 

Takker for all hjelp mottatt.

[Cronius]

Selv har jeg laget Slangen i 16-bit DOS, noe jeg syntes var veldig morsomt å drive med. Først må du finne ut nøyaktig hva du vil lage, slik at du har et klart mål å jobbe mot. Deretter er min personlige erfaring at det grafiske må ordnes, og etter du har ordna noe prototyp grafikk-funksjoner som f.eks. at man kan styre en kar med piltastene eller noe sånt, så må man lage en "timer-loop" sånn at animasjoner og forskjellige ting skjer likt på alle pcer. Etter at du har fått til dette er det bare å jobbe videre derfra og legge til mer og mer ting inntill du får et slags spill ut av det

 

Som du kanskje ser har jeg ikke ekstremt mye erfaring innenfor feltet, men jeg vil allikevel anbefale deg å begynne i det "små" med et litt enkelt spill først (som f.eks. slangen eller pacman eller noe sånt) sånn at du får litt mer feelingen på hvordan du skal gå fram på ditt neste større prosjekt (som f.eks. et plattform spill).

 

Hvis du skal lage det i DirectX så har jeg en bok som heter "Learn Computer Game Programming with DirectX 7.0," og den går fram slik (dette er kapittlene i boka):

 

-Displaying the background

-Page flipping

-Full-screen Animation

-Sprite Animation

-Sprite Clipping

-Parallax Scrolling

-Artificial Intelligence

-The Game Shell

-Sound

-The Mouse

-The Joystick

-Winning and Losing

-The High Score List

-Pausing the Game

 

Siden dette er en bok for å lære DirectX er ikke dette en framgangsmåte man kan bruke for å lage et spill, men allikevel vil jeg si at prioriteringen her kan følges på samme måte: start med å få igang litt grafikk/animasjoner, derfra en liten graphics-engine får du går videre med ekstra funksjoner i spillet osv.

 

Håper ikke dette ble alt for mye rot og tull på en gang

[A_N_K]

Når du skal analysere et program lønner det seg å ta utgangspunkt i den ytre løkken, og ta det derfra. Har ikke noen stor erfaring med spill, men de enkle tingene jeg har sett på går i løkke for hver frame. I virkelige applikasjoner/spill er det typisk et utall funksjoner/klasser, som gjør flyten litt vanskelig å følge, men de må jo kalles fra et sted : )

Hvis du er interessert i å lære sjekk www.gamedev.net, og/eller skaff deg en av bøkene til André LaMothe (Tricks of ...).

[Tabbe]

Tusen hjertelig takk for hjelpen, virkelig greit.

[A_N_K]

Håper det var til hjelp.

[hogamaster]

Skal du lage et spill for første gangen kan jeg jo gi deg et par tips. Bruk java er det første jeg vil anbefale, mht enklere programmering og veldig enkle grafikk rutiner. Men skal du først bruke c++ så er det en oppskrift du trenger.

 

Lær deg tilebased maps.. med tiden kan du lære deg å scrolle og så smooth scrolling.

Tilebased maps går ut på å ha en array med map data. Det er f.eks vanlig å tre "lag" med kart data. Tre array'er altså. Men man klarer seg også fint med ett til å begynne med. Jeg lagde feks bomberman med kun tre forskjellige brikker, en gress, en knusbar og en uknusbar. Så tok jeg og brukte en array til for ekslosjoner og pickups.

 

Feks kan ett 1 tall representere en brikke, mens 2 kan representere en annen brikke.

Det første du må gjøre er altså å kunne laste en map fil inn i en array vise dette. så kan du legge til flere dimensjoner oppå dette grunn kartet.

 

Så trenger du seff en helt som må kunne bevege seg rundt kartet på en logisk måte. Dvs at hvis han treffer på en vegg skal han ikke kunne gå videre.

 

Etter å ha klart dette er du klar for å lage det du vil. Det kan være RPG, jump'n run osv. I starten skal man holde det enkelt og man skal også ferdigstille et spill. Er lissom alltid døft å se på halvferdige spill. Er mye bedre med et ferdigpollert, enn 10 uferdige.

 

Uansett så er google til stor hjelp og spillprogrammering er dritmorsomt.

Ord du kan søke på er: game programming tilebased jump'n run "graphics for games" <-- for å finne litt gratis grafikk du kan bruke.

 

Ellers er det bare å ønske lykke til.

[smetho]

Interessant tråd, og bra innlegg hogamaster. Har selv tenkt tanken på å lage spill, og det er denne grafikk-delen som er "hindringen" for meg iogmed at jeg har null erfaring på området. Kom med flere innlegg folkens, det får ihvertfall min fantasi og vilje på gli.

[Cronius]

Lær deg tilebased maps.. med tiden kan du lære deg å scrolle og så smooth scrolling.

 

Tanke: klassiske Zelda til snes: kombinerer scrolling og "skjermbytte," hvor jeg nok tror skjermbytte er veldig mye lettere å lage.

 

Problemet med all programmering er egentlig bare å komme over begynnerfasen, når man faktisk kommer til det punktet at tid investert er proposjonalt med framgang - det er da det blir gøy

[hogamaster]

import java.awt.*;

import java.lang.*;

import java.applet.Applet;

 

//Dette er en tutorial jeg skrev fordi det ikke tar lang tid og jeg husker fra egen læringsprosess

//hvor vanskelig det var å komme igang med noe produktivt.

//Det jeg har skrevet her er en veldig enkel sak som viser fram bilder representert med et tall i en

//array. Loopen går hele tiden og bildet er konstant likt. Du kan prøve deg frem med å lage en egen

//array slik at du får et penere brett. Det her viser bare 10 * 10 av den samme brikken. Uansett, så

//hvis du er en nybegynner innen spillprogrammering så kan du lese koden og skrive i forumet på HW.no

//hvis det er noe du lurer på. ENJOY!! Nå må jeg stikke.

//Bare sørg for å få kompilert den og lagt ved tre bilder i GIF formatet (35x29 pixler helst).

 

 

public class Tute1 extends Applet

{

Image[] img = new Image[3];

Image offScreenBuffer;

 

//Her må du angi størrelsen på grafikkfilene du skal bruke.

//Her er dem 35 pixler brede (horisontal), og 29 pixler høye (vertical).

final int IMG_BREDDE = 35;

final int IMG_HØYDE = 29;

//Angi størrelsen på kartet.

final byte MAPSIZE_X = 10;

final byte MAPSIZE_Y = 10;

//Angi konstanter som gjør det lettere å forstå kartet.

final byte IKKE_KNUSBAR = 0;

final byte KNUSBAR = 1;

final byte GANGBAR = 2;

 

//Arrayen som skal brukes til å holde kartdataen. Her brukes kun en dimensjon.

//å legge på flere for mer detaljer er en smal sak.

byte[] kart = new byte[MAPSIZE_X * MAPSIZE_Y];

 

//Denne kalles automatisk når en applet starter opp og tar seg av initialisering.

public void init()

{

//Opprette en array(kart), som er 10 * 10 stort.

 

//Sette hele kartet gangbart for enkelthetensskyld. Seinere kan man

//lage egne klasser for å laste inn store kart fra fil.

for(byte i = 0; i < 100; i++)

kart = GANGBAR;

// Her kan du lage noen grafikk filer selv, men husk at dem må være 35 x 29 pixler. Eller så må

// du endre på IMG_BREDDE og IMG_HØYDE konstantene.

img[0] = getImage(getDocumentBase(),"tile1.gif");//Ikke gangbar(stål)

img[1] = getImage(getDocumentBase(),"tile2.gif");//Knusbar(murstein)

img[2] = getImage(getDocumentBase(),"tile3.gif");//Gangbar(gress)

}

 

//Java's grafikk rutiner er standard laget for deg. Ikke bry deg så mye om hvordan dette skjer.

//Men her brukes såkalt "double buffering". Dvs at man tegner ferdig et helt bilde før man viser det,

//så det blir flimmerfritt og nyyydelig. det er i selve paint metoden det du skal tenke på skjer.

//Sjekk ut java.sun.som for å finne mer om java og grafikk.

public void paint(Graphics g)

{

byte imgIndex = 0;//For å hente ut hvilket bilde fra arrayen.

for(int y=0;y < MAPSIZE_Y; y++)

for(int x=0;x < MAPSIZE_X; x++)

try {

imgIndex = kart[y+x];

g.drawImage(img[imgIndex],x * IMG_BREDDE,y * IMG_HØYDE,this);

}catch(ArrayIndexOutOfBoundsException e)

{ System.out.println("Array index out of bounds");}

}

 

public void update(Graphics g)

{

Graphics gr;

// Will hold the graphics context from the offScreenBuffer.

// We need to make sure we keep our offscreen buffer the same size

// as the graphics context we're working with.

if (offScreenBuffer==null ||

(! (offScreenBuffer.getWidth(this) == this.size().width

&& offScreenBuffer.getHeight(this) == this.size().height)))

{

offScreenBuffer = this.createImage(size().width, size().height);

}

 

// We need to use our buffer Image as a Graphics object:

gr = offScreenBuffer.getGraphics();

 

paint(gr); // Passes our off-screen buffer to our paint method, which,

// unsuspecting, paints on it just as it would on the Graphics

// passed by the browser or applet viewer.

g.drawImage(offScreenBuffer, 0, 0, this);

// And now we transfer the info in the buffer onto the

// graphics context we got from the browser in one smooth motion.

}

 

 

public boolean mouseDown(Event ev, int x, int y)

{

//Fulfør en gjentegning av bildet...

 

repaint();

return true;

}

}//Slutt på klassen Tute1

 

DETTE BLE VELDIG STYGT. TA COPY PASTE INN I EN EDITOR.

LEGGER VED HTML FILA DU KAN BRUKE FOR Å STARTE DEN ETTER DU HAR KOMPILERT.

 

<HTML>

<HEAD>

<TITLE>

Spillprogrammering - første leksjon

</TITLE>

</HEAD>

 

<BODY>

<FONT SIZE="4">

Første leksjon. Tilebaserte kart.

</FONT>

<BR>

<CENTER> <APPLET CODE="Tute1.class" WIDTH=350 HEIGHT=290>

</APPLET>

</CENTER>

<P>

</BODY>

</HTML>

[hallgeirl]

Jeg vil anbefale deg på det sterkeste å gå igjennom "Game Programming Genesis" tutorial'en på gamedev.net.

http://www.gamedev.net/reference/articles/...article1229.asp

Den begynner med litt enkel win32 programmering (som du kan hoppe over hvis du kan det) og går over til DirectDraw, og videre til å lage din egen tile map engine.

Og, som A_N_K foreslo, skaff deg boka "Tricks of the game programming gurus" av Andrè LaMothe. Den boka dekker så godt som alt du trenger for å lage et ferdig spill, inkludert DirectInput og DirectSound, AI, fysikk osv.

 

Jeg har gått igjennom hele Game Programming Genesis, og driver og småleser litt i "Tricks of the game programming gurus" når jeg trenger det, og driver nå og lager en game engine med støtte for tilemaps med flere layere (du kan sette det selv når du lager mappet), alt som har med directinput å gjøre (mus,tastatur,joysticker) osv., sprites med animasjoner, og en del mer som kommer senere.

 

Hvis du er interessert, så kan jeg legge ut kildekoden på nett, og gi deg adressen dit. Bare svar på det innlegget her så skal jeg gjøre det [/url]

[GeirGrusom]

Dette jeg skriver er av egen erfaring, og ikke fra noen bok.

Her er noen enkle grunnleggende konsept:

 

Aller først: Skisser hvordan spillet skal fungere, tegn tegninger som viser lett forståelig koplinger, og grunnleggende konsepter.

 

Helt grunnleggende har jeg tre-fire arrays(pools) som inneholder klasser og strukturer som vil bli referert i koden:

En array jeg kaller Base-pool, som inneholder alle grunnleggende enheter, som vil være prototyper for alle ting som vil bli brukt i spillet, disse vil ikke bli direkte referert, men mange egenskaper vil bli kopiert til til enheter når de blir skapt (3DAnimasjon(sprite hvis det er et 2D spill), lyd, helse, våpenstatus o.s.v.)

Dette blir laget i en linked list, for da er det enkelt å slette og legge til enheter uten å måtte flytte noe i minnet.

Hvis du ikke vet hva linked list er, så er dette en type:

struct linkedlist

{

 linkedlist *prev;

 linkedlist *next;

 void *data;

};

Hvis du fortsatt ikke forstår, så er en linked list en struktur, som peker til den neste i arraysen, dermed blir det som en kjetting (på en måte), så hvis du sletter en midt inni, kan du bare feste den på nytt uten å flytte på noe som helst. Ett krav er at du har 100% kontroll på pekere.

 

Når alle arrayer er skapt, er det bare å lage hovedløkken, der du endrer posisjonen til hver enhet ved å gå gjennom linked listen som jeg pleier å kalle unitpool.

 

Så programmet vil se nogenlunde slik ut:

#define ERR_OUT_OF_MEMORY    10

struct unitlist

{

 unitlist *prev;

 unitlist *next;

 unit *thisunit;

};

unitlist *unitpool = 0;

baseunit *basepool = 0; // baseunit må defineres slik du trenger den selv

animation *animpool = 0;

sound *soundpool = 0; // sound må også det.

int initEngine(unsigned int baseunits)

{

 if((basepool = (baseunit*)malloc(baseunits)) != true)

   return ERR_OUT_OF_MEMORY;

 // All annen initialisering

 return mainGame(); 

}

int mainGame();

{

 bool game_running = true;

 int render_err = 0;

 while( game_running )

 {

    readInput();

    frameMove();

    render_err = render();

    if(!render_err)

      return !render_err;

 }

}

void frameMove()

{

 // Flytter og sjekk kolisjoner o.l.

 static unitlist *cunit = basepool;

 while( cunit != 0 )

 {

   cunit->thisunit->moveFrame();

   // Den over burde ikke lages på denne måten

   cunit = cunit->next;    

 }

}

void render()

{

 // Tegner skjermbildet

 static unitlist *cunit = basepool;

 while( cunit != 0 )

 {

   cunit->thisunit->animation->render();

   cunit = cunit->next;

 }

}

 

Enkelt vist slik jeg gjør det i C++ (animation er faktisk en klasse som er laget(av meg) for skeletal animation i opengl, som fungerer! )

[Tosh]

Kan legge inn et par ord her jeg også, fra når jeg og et par andre måtte sette oss ned for å lage et spill i et fag jeg vi hadde i vår..

 

Måtte første finne på noe vi ville lage spill om, og vi kom etter hvert frem til et sykkelspill. Tenkte så over et par hoveddeler vi måtte ha.. så kom vi frem til bakgrunnen, som skulle være en tilemap som scolla nedover. I tillegg skulle vi ha et bilde vi kunne bevege med piltastene (syklisten).

 

Etter hvert måtte vi finne ut hvordan vi skulle kombinere disse, og få inn litt kollisjonsdetektering og sånn.. men det ordna seg etter hvert..

 

Og til slutt pakka vi inn det hele i en fin gui.

 

Men sånn som det er bygd opp her, med looper, hvis jeg uhsker litt rett.. så har vi noe ala...

-en loop som starter når spillet kommer igang. for hvert "liv"

---som da starter en loop som tegner bakgrunnen,

---en loop for beregning av posisjonen til syklisten, alt etter knappetrykk

---en loop for å finne bakgrunn, finne syklist, og tegne disse

 

Er mange looper her og der inni disse også.. men disse er de hovedloopene, som kjører hele tida når selve spillet funker.

 

Det hele blir da egentlig som en stor fin tilstandsmaskin..

 

spillet fins forresten på www.ntnu.no/~tosh/velocipedro hvis du vil se på..

Vet det er java, mens dette er c/c++-kategorien.. men spillmekanikk blir det samme uansett

[GeirGrusom]

Det kan også være en fordel at alle bevegelser blir satt inn i en tima thread. threads blir startet med CreateThread() eller noe lignende, husker ikke helt. slike ting kan jeg desverre ikke sjekk opp nå, men kanskje noen andre vet det, ihvertfall, time hver gang en loop avsluttes i threaden, slik at det blir timebased(Unreal Tournament) spill istedet for Framebased(GTA1 og GTA2) og kjør Render loopen i en egen thread.

 

Da vil det straks bli mye enklere å implementere evt. multiplayer, hvis det skulle bli aktuelt.