Man bruger mange forskellige teorier i spil. jeg nævner i flæng:
Spilteori (der er der faktisk en matematisk teori der hedder, bruges bl.a. i freds og konflikt spild) Shannons informations teori Shortest path og operations analyse
Mange af disse teorier danner grundlaget for de resultats algoritmer spildene bygger på. Ekspemlevis vil et spild som CS anvende dele af operationsanalyse teorierne til at beregne skaden på figurene efter beskydning eller eksplotioner.
Shortest path anvendes til AI (kunstig inteligens) for virtuelle enheder og spildere
bufferzone: Hvorfor mener du at operationsanalyse bliver brugt til sådanne beregninger. De implementationer jeg har lavet af operationsanalyseteori har været rimelig tungt. Jeg tror det er hurtigere med en eller anden passende heuristik til hver type eksplotion.
Jeg arbejder bl.a. med simulation af militære operationer (jeg er på hærens officersskole) og grundlaget er altid operationsanalyse. Når det er sagt, så bliver de færdige modeller ofte noget andet, enten fordi de meget tunge algoritmer simpelthend kræver formange ressourcer eller fordi resultatet bliver overrealistisk i forhold til det pædagogiske mål man har med simulationen. De praktiske implementationer er normalt meget mere simple, men de låner deres slægtsskab og den teoretiske baggrund i operationsanalysen.
Jeg tror problemet ligger i at vi taler lidt forbi hinanden. Et er den matematik der ligger i at skabe grafiken, den interessere ikke mig så meget, det jeg taler om er spillets intilligens om du vil, de algoritmer der afgør resultatet, men dybest set er det hele jo matematik
jeg er ikke spil-programmør, så ta' mit svar som en guideline :)
>Hvilke matematiske teorier bruges der hvis man skal lave 3-d spil ? der er rigtigt meget matematik, og der er meget teori...google kan anbefales f.eks sider som gamedev.net, bliver diverse teorier diskutteret livligt. Det kan være teorier på lavt niveau som pixel-precise-collision, eller på højere niveau f.eks. computer AI.
>Sidder man og programmerer dissse teorier i C/C++ ? mjaaaeee, det gør man. Men hvilke teorier afhænger af dit arbejdsområde: udvikler man et spil, udvikler man en game-engine, udvikler man et framework til behandlingaf grafik/grafik engine.
men kan nok sige at jo længere "ned" mod grafik engine, og grafik framework - jo mere "basale" (men stadig svær matematik :D) ting udregner man. Jo højere op mod programmering af selve spillet jo mere overodnet er det, det man arbejder med.. hmm, det var nok lidt vrøvlet! det jeg nok prøver er at sige, at hvis du skal lave et spil så køber man funktionaliteten til at lave en flot "stjerne himmel" ell. et flot terrain, og så er det algoritmer/teorier der vedrører dit spil som du implementerer...
>eller findes der værktøjer som kan oprette f.eks, 3-d personer der skyder på >hinanden hvorefter man så bestemmer deres bevægelse via C/C++ ?
ja der er "værktøjer", hvis man vil lave spil er det en rigtig god ide at finde sig en gameengine (det er værktøjet!).
En gameengine tager sig af de mere baseale ting som: vise figurer, beregne bevægelse/animationer af sine 3d figurer, finde ud af om figurerne støder sammen. fysik/partikel-engine med tyngedekraft og eksplotioner osvosv.
Det kan ta' rigtigt lang tid at lave en gameengine. Derfor køber man ofte denne del og bygger sit spil ovenpå.
på garagegames.com kan du se et eksempel på en "game-engine" torque hedder den. Jeg har købt den, men ikke fået taget hul på den endnu (man ka' også købe en bog som giver lidt tips til den, og hvordan den bruges).
når man køber en game-engine får man source-coden med (torque er f.eks. skrevet i c++). så man kan "rette" den ind, til dine specifikke behov, hvis det er nødvendigt.
men! der findes også "gratis" game-engines, jeg kender bare ikke nogen der har erfaringer med dem, så jeg ved ikke hvor "god" stand de er i. Men prøv evt. google: "game engine" free.
...det her med spil, og spilprogrammering - det er et kæmpe område! (men sjovt og lærerigt :D)
nåe ja, der er også blitz basic - når nu jeg har forvildet mig ind i noget med at lave spil. Blitz basic er et script sprog til en game-engine. Og når man sidder med den slags, så skal du "kun" koncentrere dig om spillet og de algoritmer der nu skal bruges her
Jeg har brugt det meste af min fritid de seneste 2 år på at studere dette. Og tror mig, der er MEGET matematik i at lave et 3d spil. Som mickni33 er inde på tager det meste grafik-relaterede matematik udgangspunkt i linær algebra, nemlig matrix og vector matematik.
Grundlæggende kan man vælge at licensere en game-engine hvor det meste matematik er implementeret (og forhåbentlig testet) i forvejen, eller man kan lave det hele fra bunden selv (ikke noget man bare lige gør).
Hvis du har interesse for spiludvikling bør du kigge på gamedev.net - der er masser af tutorials/artikler til at komme igang på. Men lad være med at tro at du kan lave HalfLife2 eller Doom3 som noob. De fleste der går igang med at lave spil (har læst 97% et sted) får aldrig færdiggjort noget spilbart, simpelthen fordi deres mål er for urealistiske. Det bedste råd er at starte med at lave simple 2D kloner (fx. tetris, pac-man, shot-em-up arcade spil etc.) og hvis du ikke kører sur i det er der måske en spiludvikler gemt i dig :o)
Jeg er datamatiker samt ingeniør studerende så nu synes jeg at jeg ville prøve noget af det teori man har lært indtil nu bla matematik og programmering.. Så når jeg snakker om spil er det ikke et færdig udviklet spil men måske bare lave en figur som kan gå hen ad en vej men med så realistiske bevægelser som muligt... når det er gjort er mit projekt færdigt :-)
Emner som "Bazier flader", "Hermite flader" (og for begge de tilsvarende kurver, "Zbuffering", "Phong Shading" etc er noget du kan undersøge.. det er forholdsvist simpelt...
mickni33 >> Ja, 'bare' lave en figur der kan gå henad en vej....Det er altså ikke 'bare'. Det kan bla. laves vha. en teknik der kaldes skinning eller skinned meshes. Du opbygger en bone-struktur (et skelet) og hver vertex i mesh'en tildels en weight pr. bone, dvs. hvor meget et bone påvirker verticerne. Men det er stadig et stort arbejde at lave, og også at forstå alle detaljerne.
Hvis du downloader DirectX SDK'en fra microsoft er der en række samples med, bl.a skinned mesh'es. Hvis du tager udgangspunkt i denne kode kan du nå ret langt på kort tid. Hvis du ikke har arbejdet med 3D før vil jeg anbefale at tage nogle af de samples/tutorials der er under 'beginner' først.
bromer >> jeg mener nu at der er mere elementære ting at tage fat på (og forstå) i første omgang. Først og fremmest hvordan man laver et vindue med et grafisk device (DirectX og/ellerOpenGL) organiserer sin geometri i vertex- og index buffere, hvordan man bevæger dem, culling etc. etc.
hmmm....det giver ikke mening at sige at et spil er opbygget af polygoner, men grafikken i ethvert 3d spil er grundlæggende opbygget af trekanter (også kaldet primitiver eller faces eller polys). Jo mindre trekanterne er, jo finere er modellen. Fx. er en kugle opbygget af mange trekanter (gerne over 100), og jo flere der er, jo mere glat ser overfladen ud (groft sagt - det kommer i virkeligheden også an på den shading model man anvender m.m.), mens en kasse kun består af 12 trekanter (2 pr. side). Det der så er målet med en renderingsengine er at vise så mange trekanter som muligt pr. sec.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
