Vés al contingut

Motor de videojoc

De la Viquipèdia, l'enciclopèdia lliure
(S'ha redirigit des de: Motor de jocs)
Videojoc Yo Frankie!, desenvolupant-se amb Blender

Un motor de videojoc (o Game Engine en anglès) fa referència a una aplicació de programari que permeten el disseny, la creació i la representació del videojoc.[1] Hi ha diversos motors de joc que són dissenyats per donar resultats gràfics per a videoconsoles i ordinadors. El nucli funcional que títpicament proveeix un motor de videojoc inclou un motor de renderització (“renderer”) per gràfics en 2D o bé en 3D, un motor de física o detecció de col·lisió (i resposta en col·lisió), so, scripting, animació, intel·ligència artificial, xarxa, streaming, gestió de la memòria, multifils, suport en localització i gràfic d'escenes.[2] El procés de desenvolupament de videojocs sovint s'economitza, en gran part, mitjançant la reutilització/adaptació del mateix motor de joc per crear videojocs diferents.[3][4]

Definició

[modifica]
Simulació d'un mur de blocs destruint-se, utilitzant el motor de física Bullet

La majoria de motors de jocs es distribueixen en forma d'API, però alguns motors es distribueixen en forma de conjunt d'eines que agilitzen i simplifiquen encara més el desenvolupament de videojocs, per exemple: IDEs, script pre-programats, i els programes que "empaqueten", preparen els videojocs per a la seva distribució. Aquests motors "complets" se'ls anomena Middleware (o programari intermediari), amb l'objectiu d'agrupar diversos programaris en un de sol. Com que són distribuïts amb altres eines, que aporten tot el necessari i es redueixen els costos Per exemple, alguns dels motors es poden citar: Torque Game Engine, Unity, Blender i Unreal Engine.[5]

Un motor de joc es pot dividir en dues categories principals: motor gràfic i físic. Els motors gràfics tracten la infografia, i són responsables del processament de dades d'alt i baix nivell perquè s'entengui amb el maquinari. Alguns exemples, es poden citar: OGRE Crystal Space i OpenSceneGraph. Els motors de física tracten amb la física, el que representa per a la simulació d'accions reals, a través de variables com la gravetat, massa, fricció, força i flexibilitat. Exemples d'això, es poden citar: el Havok, el Bullet i l'ODE.[1]

Tot i l'especificitat del nom, els motors de joc també s'utilitzen per crear altres tipus d'aplicacions interactives amb gràfics en temps real, com ara demostracions, visualitzacions arquitectòniques, simulacions d'entrenament (com el pilotatge d'aeronaus i maneig d'armes), eines de modelat i la simulació física per crear animacions i escenes realistes al cinema.[6]

Abstracció de maquinari

[modifica]

Els motors de joc ofereixen una capa d'abstracció de maquinari, permitint al programador desenvolupar jocs sense necessitat de conèixer l'arquitectura de plataforma que està destinat a ser executat, que pot ser un videojoc o un sistema operatiu. Per aquesta raó, molts motors es desenvolupen a partir d'una API disponible a OpenGL, DirectX, OpenAL i SDL, o fins i tot d'un altre motor, que poden facilitar el seu desenvolupament. L'abstracció de maquinari és també és essencial per al desenvolupament de motors de jocs multiplataforma.[7]

Abans que existís el maquinari d'acceleracció de gràfics 3D, s'utilitzava la renderització per programari. La renderització per programari encara s'utilitza en algunes eines de modelat i renderitzatge d'imatges, on es prioritza la qualitat gràfica quan el maquinari no és compatible amb certes tecnologies, com per exemple els "shaders".[8]

Història

[modifica]
El Pitfall!, creat el 1982 per a l'Atari 2600, és exemple de videojoc programat des de zero.

Abans dels motors de jocs, els jocs normalment es programaven com a entitats úniques: un videojoc per a l'Atari 2600, per exemple, va haver de ser dissenyat de dalt a baix per fer un ús òptim del maquinari gràfic—aquesta rutina principal gràfica que avui se'n diu el nucli pels desenvolupadors "retro". Altres plataformes tenien més llibertat d'acció, fins i tot quan el gràfic no era una preocupació, en general la memòria formava gran part del disseny de flux de dades que genera avui en dia un motor. Fins i tot, en les plataformes més complaents, es reutilitzava molt poc entre els jocs. El ràpid avanç del maquinari de les màquines recreatives, que era l'avantguarda del mercat en el moment, va significar que la major part del codi es rebutgés de totes maneres, com les generacions posteriors dels jocs que utilitzen dissenys de joc completament diferents que prendre avantatge extra de recursos. Així, la majoria dels dissenys de videojocs a través de la dècada de 1980 han estat dissenyats a través d'un conjunt de regles codificades amb una petita quantitat de nivell de dades i gràfics.

La primera generació de motors gràfic de tercers o renderitzadors (i precursor del que es coneix per motors) va ser denominat per tres jugadors; BRender de Argonaut Software, Renderware de Criterion Software Limited i Reality Lab de RenderMorphics. Reality Lab va ser el més ràpid dels tres i va ser el primer a ser adquirit en un moviment agressiu per Microsoft. L'equip RenderMorphics, format per Servan Keondjian, Kate Seekings i Doug Rabson posteriorment es van sumar al projecte de Microsoft que va convertir Reality Lab en Direct3D abans que Keondjian i Rabson marxesin per iniciar una nova empresa de programari intermediari anomenada Qube Software Arxivat 2007-07-07 a Wayback Machine.. Renderware va ser comprada per EA (Electronic Arts) però va ser marginat pel gegant dels videojocs.

El terme "motor de videojoc" va sorgir a mitjans de la dècada de 1990, especialment en relació amb els jocs en 3D com els d'acció en primera persona (FPS). Amb la popularitat amb Doom i el Quake de part de Id Software, en lloc de treballar a partir de zero, altres desenvolupadors van llicènciar les parts principals del programa i van dissenyar els seus propis gràfics, personatges, armes i nivells, "continguts del joc" o "missions de joc". La separació entre les regles del joc i les dades com ara la detecció de col·lisions i les entitats del joc significava que els equips poguessin créixer i especialitzar-se.

Els videojocs posteriors, com és el cas de Quake III Arena i el Unreal per part d'Epic Games el 1998, van ser dissenyats per utilitzar aquestes idees, amb el motor i el contingut desenvolupat de manera separada. La pràctica de la tecnologia de llicències ha demostrat ser un flux d'ingressos auxiliars útils per a alguns desenvolupadors de jocs, ja que les llicències per a motors de joc d'alta qualitat comercials poden variar des de $10.000 a milions de dòlars americans, i el nombre de llicències pot arribar a diverses desenes d'empreses, com s'observa en el Unreal Engine. Si més no, els motors reutilitzables fan que el desenvolupament de continuacions de videojocs sigui més ràpid i fàcil, que és un valuós avantatge en la competitiva indústria dels videojocs.

Els motors de videojocs moderns són algunes de les aplicacions programades més complexes, sovint amb dotzenes de sistemes d'afinació que interaccionen per garantir a l'usuari una experiència controlada amb precisió. La contínua evolució dels motors de joc ha creat una forta separació entre la renderització, scripting, grafisme, i disseny d'escenaris. Ara és comú, per exemple, per a un típic equip de desenvolupament de videojocs que en diverses ocasions, hi ha tants artistes com programadors reals.[9]

Els motors de videojocs d'acció en primera persona segueixen sent els predominants pels usuaris de motors de videojocs de tercers, però ara també s'utilitza en altres gèneres. Per exemple, el videojoc de rol de The Elder Scrolls III: Morrowind i el MMORPG Dark Age of Camelot són basats en el motor Gamebryo, i el MMORPG Lineage II és basat amb el Unreal Engine. Els motors de videojocs són utilitzats en jocs en principi desenvolupats per a consoles domèstiques; per exemple, tel motor RenderWare s'utilitza per a les franquícies de Grand Theft Auto i Burnout.

El Threading (o fil d'execució en català) està prenent més importància per l'àuge dels sistemes multi-nucli (per exemple els Cell) i la increment demanda de realisme. Els típics fils d'execució tenen a veure amb la renderització, l'streaming, el so i la física. Els videojocs de curses amb vehicles normalment són capdavanters en els fils d'execució sobre motors de fisica treballant en fils per separat molt abans que altres subsistemes bàsics ho facin, en part a causa de tasques de representació i necessitats relacionades amb l'actualització a tan sols 30–60 Hz. Per exemple, en la PlayStation 3, la física que es treballa al Need For Speed és a 100 Hz contra la de Forza Motorsport 2 que és a 360 Hz.

Encara que el terme va ser utilitzat per primera vegada en la dècada de 1990, Hi ha alguns sistemes abans de la dècada de 1980 que són també considerats com a motors de joc, com ara l'Adventure Game Interpreter (AGI) i el SCI de Sierra, el sistema SCUMM de LucasArts i el Freescape engine de Incentive Software. A diferència de la majoria dels motors de jocs moderns, aquests motors de joc mai van ser utilitzats en els productes de tercers (excepte en el sistema SCUMM que va ser llicenciat i utilitzat per Humongous Entertainment).

Tendències recents

[modifica]
Vista prèvia del motor de joc PlayCanvas Editor

Com la tecnologia del motor del joc madura i es torna més fàcil d'usar, l'aplicació dels motors de joc s'ha ampliat en el seu abast. Ara estan sent utilitzats per videojocs seriosos: aplicacions de visualització virtual, entrenament, mèdic i simulació militar.[10] Per facilitar aquest accés, les noves plataformes de maquinari estan sent dirigits pels motors de joc, incloent telefòns mòbils (p.e. telèfons amb Android, iPhone) i navegadors webs (p.e. WebGL, Shockwave, Flash, el WebVision de Trinigy, Silverlight, Unity Web Player, O3D i dhtml pur).[11]

A més a més, més motors de joc es basen en llenguatges de programació d'alt nivell com és el cas de Java i C#/.NET (p.e. TorqueX, i Visual3D.NET) o Python (Panda3D). La majoria de videojocs amb objectes en 3D estan limitats o controlats per la GPU (és a dir, limitada per la potència de la targeta gràfica), la desacceleració potencial de llenguatges d'alt nivell són insignificant, mentre que els guanys de productivitat que ofereixen aquests llenguatges beneficiïen els projectes dels desenvolupadors de motors de videojocs.[12] Aquestes tendències recents estan sent impulsades per empreses com Microsoft per donar suport al desenvolupament de videojocs anomenat Indie, tot i haver també projectes col·laboratius. Microsoft va desenvolupar el XNA com a SDK d'elecció per a tots els videojocs disponibles per a Xbox i productes relacionats. Això inclou el canal Xbox Live Indie Games[13] dissenyat específicament per als petits desenvolupadors que no tenen els amplis recursos necessaris als videojocs de venda tradicional comercials, com ara la venda a les botigues. Cada vegada és més fàcil i més barat que mai per a desenvolupar motors de videojocs en plataformes que suporten codi gestionat (o frameworks en anglès).[14]

Videojocs middleware

[modifica]

En el sentit més ampli del terme, els motors de videojocs es poden descriure com a middleware. En el context dels videojocs, això no obstant, s'utilitza sovint per referir-se als subsistemes de funcionalitat dins d'un motor de joc. Alguns videojocs de middleware s'especialitzen en aspectes concrets, però ho fan de manera més convincent i més eficientment que els middleware de propòsit general. Per exemple, el SpeedTree s'utilitzava per fer renderització d'arbres realístics i vegetació en els videojocs de rol com és el cas de The Elder Scrolls IV: Oblivion[15] i el Fork Particle s'utilitzava per simular i renderitzar en temps real efectes o partícules visuals gràcies a Particle Systems en el Sid Meier's Civilization V.[16]

Els quatre kits o aplicatius middleware més utilitzats[17] que proporcionen la funcionalitat dels subsistemes d'inclouen el RAD Game Tools de Bink, el FMOD de Firelight, Havok i Scaleform de GFx. El RAD Game Tools s'hi pot desenvolupar renderització amb video anomenat Bink, àudio anomenat Miles i renderització de 3D anomenat Granny. El FMOD de Firelight és una biblioteca d'àudio de baix cost i un robust conjunt d'eines. El Havok proporciona un sistema de simulació física robusta, juntament amb un conjunt de solucions d'animació i de comportament. El Scaleform de GFx proveeix alt rendiment d'Interfície d'usuari de Flash, juntament amb una solució de reproducció de vídeo d'alta qualitat, i a més compta amb l'Input Method Editor (IME) per a suport de xat de llengües asiàtiques.

Alguns middleware contenen de forma completa el codi font, altres només ofereixen una referència de l'API per a una biblioteca de binaris compilats. Alguns programes middleware poden ser objecte de llicència de qualsevol tipus, generalment amb una tarifa més alta per al codi font complet.

Videojocs multijugador massius en línia

[modifica]

Els middleware dels videojocs multijugador massius en línias (MMOs, MMOGs) són molt més complexos que dels videojocs per a un sol jugador. Tècnicament tots els motors de videojocs normals es poden utilitzar per posar en pràctica un videojoc MMO si es combina amb middleware per a MMO. La creixent popularitat dels MMOG està estimulant el desenvolupament de paquets de middleware per a MMO. Alguns paquets de programari middleware de MMO ja inclouen un motor de videojoc, mentre que altres només es permet la creació de xarxes i per tant ha de ser combinat amb un motor de videojoc per crear un videojoc de MMO. Algunes prominents solucions de middleware de MMO es podien incloure:

Motors de videojocs d'acció en primera persona

[modifica]
Videojoc Freedoom,[23] basat en el videojoc comercial Doom, realitzat amb el motor PrBoom[24]

Un subconjunt ben conegut dels motors de videojoc en 3D són els d'acció en primera persona (FPS o first person shooters en anglès). El desenvolupament innovador en termes de qualitat visual es porta a terme en els videojocs de FPS en l'escala humana. Mentre que els simuladors de vol, de conducció i estratègia en temps real (RTS) proporcionen un realisme cada vegada més a gran escala, els d'acció en primera persona estan a l'avantguarda dels gràfics per ordinador en les escales més petites.

El desenvolupament dels motors gràfics en els FPS que apareixen en els videojocs es caracteritza per un augment constant de les tecnologies, amb alguns avenços. L'evolució entre les diferents generacions tecnològiques dins de l'era informàtica ha fet que siguin decisions arbitràries les que constitueix una versió altament modificada d'un "motor vell" i el que és un motor completament nou.

La classificació és complicada en els motors de videojoc, ja que barreja tecnologies velles i noves. Les característiques considerades avançades en un nou videojoc d'un any en concret normalment es pot convertir en l'estàndard esperat en l'any següent. Normalment, els videojocs són una barreja de característiques o avanços de tecnologies velles i noves que solen marcar en generacions en el futur. Per exemple, en el Jurassic Park: Trespasser (1998) va introduir la física en els videojocs de FPS, però no es va generalitzar fins al voltant de l'any 2002. El Red Faction (2001) apareixen les parets i paviments destructibles, cosa que encara no va ser comú en els motors d'anys més tard (per exemple, en el Unreal Tournament 2004 encara no hi havia objectes destructibles). En el Battlezone (1998) i el Battlezone II: Combat Commander (1999) s'hi afegeixen els vehicles de combat a la barreja de FPS habituals, que no es va generalitzar fins més tard. El Tribes 2, el Battlefield 1942, el Halo: Combat Evolved i el Unreal Tournament 2004 són exemples complets de la integració entre els vehicles de combat i l'acció en primera persona.

Motors de novel·les visuals

[modifica]

A causa de la naturalesa menys intensiva de gràfics en els jocs de novel·la visual, en els motors de novel·les visuals en comparació als motors de joc FPS solen ser més simples. Alguns exemples de motors nous de novel·les visuals es poden trobar:

Glossari d'aspectes relacionats

[modifica]

Assets (Actius): Són els models, animacions, sons, IA, físiques. Són els elements que formen el joc en si, el codi fa funcionar els assets.

Application Programming Interface (Interfície de Programació d'Aplicacions): És un sistema de rutines, de protocols i d'eines per desenvolupar programes d'aplicació. Un bon API fa més fàcil desenvolupar un programa proporcionant tots els blocs del desenvolupament del programa. El programador posa els blocs junts. Entre aquests els més importants són el DirectX (de Microsoft) i el OpenGL (que treballa amb la majoria dels sistemes operatius).

Render (Renderització): És la part del codi que posa en pantalla els ambients i objectes.

  • Objectes 3D: Els objectes s'emmagatzemen per punts en un món 3D, anomenats vèrtexs. Els vèrtexs van formant polígons; com més polígons posseeixi un objecte, més complicat es fa, porta més temps de processament però és més detallat. El joc no necessita saber quants objectes hi ha en memòria o com el Render va a mostrar-los, només li interessa que el render els desplegui de la forma correcta, i que el model estigui en el quadre correcte de l'animació.
  • Higher-order surfaces (superfícies d'alt ordre): Renderizatge matemàtic, usat en les targetes gràfiques més recents i poderoses. També anomenat: Patches (pegats).
  • Patches (normalment anomenats en català com a Pegats): Són perfectes per descriure geometries, sobretot quan es tracta de corbes, car l'expressen mitjançant fórmules matemàtiques aconseguint col·locar punts al món del joc.
  • Culling: Codificat que aconsegueix que els objectes que no es veuen en determinat quadre de l'animació per causa d'objectes que els obstaculitzen (com una paret) no prenguin temps de renderizat. Així es redueix la quantitat de treball del motor.

El Culling és més fàcil d'implementar en jocs on la visió és controlada com els RTS en comparació del FPS. Un mètode de Culling pot ser per "Arbres BSP"

  • BSP Tree Hierarchy (BSP Arbre de Jerarquia): És un mètode per determinar quines superfícies d'un món, i objectes, estan realment en l'escena en un moment donat, donada la seva localització al món. Això s'utilitza sovint per als objectes de la desferra, i també per treure-ls per reduir el procés de l'AI (Intel·ligència Artificial) i de l'animació.
  • Retesselation: Tècnica usada per la característica de TruForm d'ATI que consisteix a prendre un model basat en triangles i transformar-ho en un de High-Order Surfaces per allisar-ho i de nou passar-ho a un model de triangles.

Il·luminació (lighting): Diferents APIs proveeixen diferents tipus d'il·luminació

  • Vertex Lighting: Es determinen quants polígons creuen el vèrtex, es pren el total de totes les orientacions dels polígons (Normal) i s'assigna la normal al vèrtex. Per a cada vèrtex, un polígon donat reflectirà la il·luminació en una forma lleument diferent. L'avantatge és que al maquinari li pren menys temps en processar-ho, però aquest tipus d'il·luminació no produeix ombres.
  • Flat Shading Lighting (Il·luminació d'Ombreig Pla): Consisteix que cada polígon representi un valor lleu que es passi al polígon complet que generi una imatge plana d'aquest, a aquesta imatge també se li assigna un color determinat. Hi ha diferents tipus:
  • Vertex Shading (Ombreig de Vèrtex, Gouraud shading): sol·licita al motor de renderitzat un color per a cada vèrtex, després per mitjà d'interpolació es renderitza cada píxel per la distància en relació amb el seu respectiu vèrtex.
  • Phong Shading: és similar al Gouraud Shading, treballen amb la textura, solament que el Phong Shading usa als píxels en lloc del vèrtexs.

El Phong Shading pren més temps de processament que el Vertex Shading però el seu resultats són molt millors en qüestió de suavitzat de textures.

  • Light Map Generation (Generació del mapa de llum): s'usa una segona capa de textura (mapa de llum) que donarà l'efecte d'il·luminació als models, és un efecte excel·lent però ha de prendre's abans del renderitzat però si es tenen Llums Dinàmiques (o sigui llums que es mouen, encenen o apaguen sense intervenció de programa) s'ha d'estar regenerant els mapes en cada Frame d'animació el que pren molta quantitat de memòria (però són de render ràpid).

Textura: és essencial perquè les escenes 3D es vegin reals, en si les textures són imatges que es trenquen als diferents polígons del model, moltes imatges prendran molt espai en la memòria per això s'ha d'usar tècniques de compressió:

  • Mapatge MIP: consisteix en preprocessar les textures creant múltiples còpies del mateix cadascuna la meitat de l'anterior, això perquè si la textura solament és pegada al polígon cada textura és a cada píxel i prengués més temps de render; així cada Texel (element de Textura) pren menys espai.
  • Textures Múltiples: requereix múltiples renderitzats pel que per obtenir bon resultat es necessita una targeta amb accelerador de gràfics, proveeix millor qualitat que el simple mapatge. Es pot col·locar una imatge sobre una altra (més transparent) per donar el sentit de moviment premo o fins a ombra.
  • Bump Mapping: tècnica vella de textures que tracten de mostrar com la llum es reflecteix en l'objecte. Solament fins fa poc s'ha reprès.
  • Antialiasing: L'anti-aliasing revisa els polígons i difuminarà les bordes i vèrtexs, perquè les vores no es vegin com a dentats. Aquesta tècnica es pot fer de dues maneres. La primera es realitza de manera individual, entremesclant polígons per sobreposar-los uns davant d'uns altres.

La segona manera es fa per mitjà de prendre tot el marc i llevar-li les vores dentades, però això requereix molta memòria.

  • Vertex and Píxel Shaders (Vèrtexs i Sombreig de Píxels): Amb aquest mètode es poden extreure i utilitzar directament les característiques i facilitats de la targeta de video, sense haver d'utilitzar molt l'API. Però no és utilitzable en totes les targetes.
  • Stencil Shadowing (Plantilla d'Ombreig): la idea és renderizar una vista d'un model des de la perspectiva de la font de llum i després utilitzar això per crear o per generar un polígon amb la forma d'aquesta textura sobre les superfícies afectades pel model. Així s'obté una il·luminació que sembla real. Però és costosa, perquè es crea textures "en vol", i fa múltiple render de la mateixa escena.

El maneig del cache de textura és imprescindible perquè el joc es desenvolupi ràpid (i per a qualsevol motor), ja que si es presenta un constant swapping de les textures en la targeta el joc es veurà lent i tediós, alguns APIs descarreguen cada textura quan això passa, però això faria que en cada quadre es refresquin les textures donant més lentitud. Tot es tracta de carregar la menor quantitat de vegades una mateixa textura, però això també depèn de l'API que s'utilitzi. Una altra tècnica és la compressió de textures, comprimir textures és com comprimir MP3, els algorismes de compressió aconsegueixen una relació 4:1 que no és molt però ajuda.

  • LOD (level of detail, nivell de detall): el sistema de nivell de detall aquesta relacionada amb la complexitat geomètrica dels models. Alguns sistemes necessiten que es facin múltiples versions del model, perquè depenent de quan a prop s'aquest del model així serà la seva quantitat de polígons. Altres sistemes ajusten dinàmicament aquesta característica però en aquest cas dona més càrrega al CPU.
  • Depth Testing (prova de profunditat): Amb això es comença a eliminar els píxels oclosos i es posa en pràctica el concepte de sobre dibuixat. La prova de profunditat és una tècnica utilitzada per determinar que objectes estan davant d'uns altres en la mateixa localització del píxel.
  • Sobre Dibuixat: és la quantitat de vegades que s'ha dibuixat un píxel en un frame. Es basa en la quantitat d'elements existents en la tercera dimensió (profunditat).

Scripting Systems (Sistemes de scripting): Diferents tipus:

  • Pre-scripted Cinematics: usada normalment en una situació que necessita l'explicació en una manera controlada. Per presentar les escenes de la història, ara s'utilitzada el tallar-escenes que presenta la història en vídeo digital i després per mitjà de transicions es passa a les gràfiques reals del joc.

El scripting li permet al dissenyador prendre comandament de l'escena i manipular-la, com col·locar objectes o esdeveniments que el jugador no controla. En molt complicat[Cal aclariment], cal una ment molt metòdica i lògica, la majoria d'aquests scripts es basen en llenguatge C.

  • Visual Scripting Systems: com ho diu el seu nom, permet manejar el script en un ambient gràfic en lloc d'un codi escrit, es maneja un caràcter real en un ambient del joc real.

So: Creative Labs ara ha proporcionat les seves extensions manejadores de so EAX per DirectX, i la nova iniciativa d'OpenAL (biblioteca àudio oberta). OpenAL, com sona, és un API per als sistemes dels sons de la mateixa manera que OpenGL és un API.

Per al processament de so és molt similar al processament dels models, moltes vegades un programari els processa abans de passar al maquinari respectiu, per exemple DirectSound fa al so per a la Targeta de so el que Direct3D fa al modelatge abans d'arribar a la Targeta 3D. Això és anomenat "prebarreja" al programari.

  • Music Tracks in Games (pistes d'àudio): Hi ha dues formes de manejar el so. Un és per mitjà d'arxius .wav (o similars), la qual cosa emet un molt bon so, però es requereix molta memòria. D'altra banda també s'utilitzen arxius midi, això redueix la necessitat de memòria, però els sons no són tan bons.

Intel·ligència Artificial (IA o AI): És la característica més important que se li atribueix a un motor al costat de la representació de models o Render. La IA proveeix d'estímul al joc. És crític en la part de la forma de joc (game play).

La intel·ligència artificial de determinat joc pot tornar-se molt complexa, primer s'ha de definir la línia basi del comportament dels NPC (Senar Player Characters - Personatges no Jugables), primer ha de definir-se quée fa el NPC (patrulla, guarda, etc.), després es delimita la seva "visió del món", que és el que el NPC pot veure del món del joc; s'ha de prendre en compte que el personatge no només estarà enmig del món del joc sinó que també interaccionarà amb ell, després venen les rutines de Presa de decisió: si el NPC està patrullant, i hi ha un so, ha de donar-li importància o no, investiga el seu origen o no, etc.

És un sistema de regles per a les accions que responen (o inicien) i que el jugador ha de respondre, això és un concepte més general de IA.

Emergent game play (Forma de Joc Emergent): Consisteix a programar a l'AI amb un conjunt de regles que li permetin al programa adherir situacions que el programador no preveiés.

Vegeu també

[modifica]

Referències

[modifica]
  1. ↑ 1,0 1,1 «Serious Game Engine Shootout». Gamasutra, 22-02-2007. [Consulta: 7 abril 2010].
  2. ↑ «Torque Game Engine (engine)». devmaster.net, 30-09-2011. [Consulta: 17 desembre 2011].
  3. ↑ What is a Game Engine? from GameCareerGuide.com
  4. ↑ «Freescape Engine». www.uvlist.net. [Consulta: 14 octubre 2011].
  5. ↑ «my-turn-the-real-cost-of-middleware». [Consulta: 5 abril 2011].
  6. ↑ «La investigació sobre l'ús de middleware en els jocs». Arxivat de l'original el 2013-10-17. [Consulta: 5 abril 2011].
  7. ↑ «Què és un HAL?». Arxivat de l'original el 2010-10-28. [Consulta: 17 abril 2011].
  8. ↑ «Software Rendering School: Part I». www.devmaster.net, 19-10-2003. [Consulta: 17 abril 2010].
  9. ↑ «Game Development Team Composition Study - Changes over time.». [Consulta: 17 gener 2011].
  10. ↑ «Video Games Starting to Get Serious». Gazette.net, 31-08-2007. Arxivat de l'original el 2008-12-03. [Consulta: 17 gener 2011].
  11. ↑ «Gaming: Mobile and Wireless Trends for 2008». M-trends.org. Arxivat de l'original el 2011-01-08. [Consulta: 17 gener 2011].
  12. ↑ 3D Game Engine Programming (book). Books.google.com [Consulta: 17 gener 2011]. 
  13. ↑ [enllaç sense format] http://www.xboxlivecommunitygames.org/
  14. ↑ «Microsoft to Enable User-Created XBox360 Games».
  15. ↑ «Gamusutra Product Review of Top Vegetation Middleware». Gamasutra.com, 01-10-2003. [Consulta: 17 gener 2011].
  16. ↑ [enllaç sense format] http://www.gamasutra.com/view/news/30820/Firaxis_Using_Fork_Particle_Toolset_For_Civ_Vs_Visual_Effects.php
  17. ↑ «Gamasutra Engine and Middleware Technology Survey». Gamasutra.com, 08-05-2009. [Consulta: 17 gener 2011].
  18. ↑ «AGC MMORPG Review». Mmorpg.com, 19-09-2006. Arxivat de l'original el 2011-07-14. [Consulta: 17 gener 2011].
  19. ↑ staff. «Exit Games' Neutron Gaming Platform to Power Konami's Multiplayer Mobile Dance Dance Revolution». Uk.wireless.ign.com, 27-05-2008. Arxivat de l'original el 2008-07-01. [Consulta: 17 gener 2011].
  20. ↑ Sinclair, Brendan. «BioWare uses HeroEngine». Gamespot.com, 08-08-2006. [Consulta: 17 gener 2011].
  21. ↑ Alicia Ashby. «Virtual Worlds News March 2009». Virtualworldsnews.com, 04-03-2009. Arxivat de l'original el 2009-04-14. [Consulta: 17 gener 2011].
  22. ↑ «Front Page - Trinigy | Creators of the Vision Game Engine». Trinigy. [Consulta: 17 gener 2011].
  23. ↑ (anglès) Pàgina oficial de FreeDoom
  24. ↑ (anglès) Pàgina oficial de PrBoom

Enllaços externs

[modifica]
A Wikimedia Commons hi ha contingut multimèdia relatiu a: Motor de videojoc
Obtingut de «https://ca.wikipedia.org/w/index.php?title=Motor_de_videojoc&oldid=32404572»