Gå til innhold

Veien å gå til å lage spill?

krokeen

Anbefalte innlegg

krokeen

krokeen

Skrevet
Skrevet

Hei.

 

Har drevet litt med ActionScript også endel C++. Har tenkt til å lage deler Zelda: Ocarina Of Time i 2D som ett øvingsprosjekt. Men jeg vet ikke helt hvilken vei jeg skal gå etter jeg har lært C++. Altså når jeg skal lage noe mer avansert enn ett tic-tac-toe spill så blir eg usikker på hvordan lagre de forskjellige dungeons og hente forskjellige "zones" inn ettkvert som spillet går. Sjønner ikke helt hvordan det henger sammen så og si. Noen som kan gi en pekepinn?

Lenke til kommentar

Videoannonse

Videoannonse
Annonse
Giddion

Giddion

Skrevet
Skrevet (endret)

Jeg har ikke spilt Zelda: Ocarina Of Time så jeg vet ikke helt hva du tenker på, men hva er du usikker på?

Prøv å bryt ned sonene (du har jo delt dungeons ned i zones....eller? ) i elementer som du kan kan forstå.. f. eks.

 

monster og deres posisjon?

Kart?

våpen og deres posisjon?

npc?

start posisjon?

hendelser?

 

Lykke til

Endret av Giddion
Lenke til kommentar
GeirGrusom

GeirGrusom

Skrevet
Skrevet (endret)

Hvis du har kontroll på C++ burde dette bli åpenbart for deg ;)

 

Finn et 2D eller 3D bibliotek (SDL, OpenGL eller Direct3D)

Hvis du vil lage Windows spesifikt anbefaler jeg Direct3D, hvis du skal ha crossplatform er SDL anbefalt, da det er enkelt og veldig egnet for 2D grafikk.

 

Når det kommer til det teknisk kan jeg bare gi en grov skisse, det finnes mange tekniske problemer du vil møte som ikke lar seg beskrive på et kort innlegg.

 

Verden deles hovedsaklig i 2 lag, bakgrunn og forgrunn. Bakgrunnen er grafikken som gjør opp miljøet. Dog det kan fint bli mer komplisert enn dette (noen ganger vil verden være foran spilleren, for eksempel i huler eller korridorer, løsningen for dette blir det du som må lage)

 

Du må skrive en grunnklasse for alle units i verdenen. Denne må ha en posisjon og størrelse, og funksjoner som kreves for:

- å flytte enheten (og eventeull kollisjon)

- AI

- Rendering

 

For kollisjon kan du bruke enkel sirkelkollisjon. Da er det snakk om bare litt pythagoras for å sjekke hvor langt unna enheter er hverandre

avstand = sqrt(pow(b.x - a.x, 2) + pow(b.y - a.y, 2))

Endret av GeirGrusom
Lenke til kommentar
krokeen

krokeen

Skrevet
  • Forfatter
Skrevet (endret)
Hvis du har kontroll på C++ burde dette bli åpenbart for deg ;)

 

Det er det altså ikke da, kan ikke akkurat si at jeg kan på noen måte vite hvordan jeg skal lage ett slikt spill etter å ha lest Accelerated C++.

Endret av krokeen
Lenke til kommentar
krokeen

krokeen

Skrevet
  • Forfatter
Skrevet (endret)

Takk, dette hjalp mye ;)

 

Men kan du forklare hva du mener med units ?

 

Sånn som jeg ser det for meg no er klasser i denne duren:

 

npc (alle npc's i en klasse ?)

player

zone

drawengine

backback

Endret av krokeen
Lenke til kommentar
GeirGrusom

GeirGrusom

Skrevet
Skrevet (endret)

Units er alle "ting" på brettet, alt som ikke er bakgrunn

 

Du har noe slikt fullstendig HELT eksempelvis:

 

class Unit
{
private:
protected:
//...
public:
 Point Location();
 void Location(Point value);

 AI& AI(); // Retrieves AI
 void AI(AI& intelligence); // Changes unit AI

 virtual void Render();  

 virtual void OnKill();
 virtual void OnSpawn();
 virtual void OnFrameTick();
 virtual void OnCollide(Unit &other);
};

class Player : public Unit
{
 Player()
 {
// SeekAI just makes the unit follow directions
AI(*(new SeekAI()));
 } 
};
class Enemy : public Unit
{

};
class BeastarTheDestroyer : public Enemy
{
public:
 BeastarTheDestroyer()
 {
AI(*(new TerrifyingAI()));
 }
};

Endret av GeirGrusom
Lenke til kommentar
kernel

kernel

Skrevet
Skrevet
Det er det altså ikke da, kan ikke akkurat si at jeg kan på noen måte vite hvordan jeg skal lage ett slikt spill etter å ha lest Accelerated C++.

 

Design av spill bør gjøres språk uavhengig, og grensesnitt kan med fordel defineres på TCP/IP nivå.

 

Spill er gjerne komplekse programmer, første regel er da å benytte splitt og hersk metoden og designe godt. Ellers går du i surr og ser ikke skogen for bare trær.

 

Har et hobby prosjekt hvor jeg utvikler et strategispill, først splitter man jobben i flere hoveddeler

 

- GUI front-end

- spill engine

- AI engine

- kommunikasjon

 

og selv om man gjør et solo prosjekt, så er det lurt å tenke på samme måten. I mitt tilfelle så er det naturlig å støtte spilling over nettet (human vs human), så når applikasjon startes -- kobler den seg opp til en game server.

 

Spørsmålet er da hvem som holder på "game state", hvis alle klienter har full tilgang på "game state" så er det lett å jukse, men det går kjappere å oppdatere GUI med "game state" lokalt. For "first-shooter" spill, er rask oppdatering av skjerm viktig, men ikke så viktig for et strategi spill.

 

Hvis man ikke trenger nettverkstøtte, så kan samme design likevel benyttes, du bare starter game server lokalt, og definerer grensesnitt via TCP/IP på lokalhost. AI bots fyres opp og kobler seg til game server, akkurat som andre klienter.

Lenke til kommentar
kernel

kernel

Skrevet
Skrevet (endret)
Har også sett litt på LUA, er det noe å satse på for ett enkelt 2d spill (enkelt men stort);

 

Jeg bruker Lua som scripting engine i mitt prosjekt. Lite språk og enkelt å integrere med C/C++.

 

Ville ikke brukt Lua som hovedspråk på et større prosjekt dog, men flott til interpreter og scripting.

Endret av kernel
Lenke til kommentar
kernel

kernel

Skrevet
Skrevet

Her er et eksempel på hvordan man kan embedde Lua scripting fra et C/C++ program:

 

[b]$ cat lua_run_scipt.c[/b]
/*
* Lua 5.1 Example - Running a Lua script from C/C++
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>

#include "lua.h"
#include "lualib.h"
#include "lauxlib.h"

/** Generate & run a Lua script:  test1.lua */
static void howto_run_script(lua_State *L)
{
       const char fname[] = "test1.lua";
       FILE *f = fopen(fname, "w+");

       assert(L && f);

       printf("*** Generate a Lua script to file: '%s' ***\n", fname);
       fprintf(f, "-- \n");
       fprintf(f, "-- This Lua script has been generated\n");
       fprintf(f, "-- \n");
       fprintf(f, "a = 1;\n"
                  "b = 2;\n"
                  "c = a + b;\n"
                  "print (\"1 + 2 = \" .. c);\n");
       fclose(f);

       printf("Run a script: luaL_dofile(L, \"%s\")\n", fname);
       luaL_dofile(L, fname);
}

int main(int argc, char* argv[])
{
       lua_State* L;

       L = luaL_newstate();
       if (NULL == L) {
               puts("luaL_newstate(): Error Initializing lua");
               exit(1);
       }
       luaL_openlibs(L);
       howto_run_script(L);
       lua_close(L);

       return 0;
}
[b]$ gcc -I/usr/include/lua5.1 -llua5.1 lua_run_scipt.c
$ a.out[/b]
*** Generate a Lua script to file: 'test1.lua' ***
Run a script: luaL_dofile(L, "test1.lua")
1 + 2 = 3
[b]$ cat test1.lua[/b]
--
-- This Lua script has been generated
--
a = 1;
b = 2;
c = a + b;
print ("1 + 2 = " .. c);

Lenke til kommentar
Arti-Ravnos

Arti-Ravnos

Skrevet
Skrevet (endret)

Han skrev sikkert riktig, men Gamdev.net er et fint sted å begynne.

 

Til et slikt spill tror jeg det ville være lurt å først lage en spillmotor i C++ og deretter bruke f.eks. Lua til scripting. Jeg er ikke noen scripter selv, men ønsker å lære det så jeg har lest litt om det. Sikkert noen her som kan forklare deg bedre enn meg hvilke fordeler det er ved å bruke scripting. Det fins en god artikkel om det på GameDev.net, men jeg fant den ikke nå.

 

Uansett. Årsaken til man ønsker å scripte, er for å kunne skille innholdet i spillet fra spillmotoren. Script-filene er selvstendige, uavhengige filer som kan inneholde informasjon om rom, NPC, objekter, AI osv. På den måten slipper du å rekompilere hele prosjektet for hver gang du endrer på en liten detalj, f.eks. prisen på et item. Dette sparer deg for veldig mye tid.

 

 

Dette virker som et alt for stort prosjekt å kaste seg over. Du burde vel begynt med noe enklere, men du velger selv. Håper å kunne lage et slikt spill som du ønsker å lage en dag, men det kommer til å ta mange år før jeg når så langt. :p Lykke til!

Endret av Arti-Ravnos
Lenke til kommentar
  • 4 uker senere...

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
Gå til emneliste
×
×
  • Opprett ny...