UNIVERSIDADSANFRANCISCODEQUITOUSFQ

ColegiodeCienciaseIngeniería

Desarrollodeunmotordejuegosonlineconarquitecturaclienteservidorbasadoenenvíodeevento

ProyectoIntegrador .

FaustoIvánZamoraArias

IngenieríaenSistemas

Trabajodetitulaciónpresentadocomorequisitoparalaobtencióndeltítulode

IngenieroenSistemas

Quito,12demayode2017

2

UNIVERSIDADSANFRANCISCODEQUITOUSFQ

COLEGIODECIENCIASEINGENIERÍA

HOJADECALIFICACIÓNDETRABAJODETITULACIÓN

Desarrollodeunmotordejuegosonlineconarquitecturaclienteservidorbasadoenenvíodeeventos

FaustoIvánZamoraArias

Calificación: 95/100

Nombredelprofesor,Títuloacadémico AldoCassola,PhD

Firmadelprofesor

Quito,12demayode2017

3

DerechosdeAutor

Por medio del presente documento certifico que he leído todas las Políticas y

Manuales de la Universidad San Francisco de Quito USFQ, incluyendo la Política de

PropiedadIntelectualUSFQ,yestoydeacuerdoconsucontenido,porloquelosderechos

de propiedad intelectualdel presente trabajo quedan sujetos a lo dispuesto en esas

Políticas.

Asimismo,autorizoalaUSFQparaquerealiceladigitalizaciónypublicacióndeeste

trabajo en el repositorio virtual, de conformidad a lo dispuesto en el Art. 144 de la Ley

OrgánicadeEducaciónSuperior.

Firmadelestudiante:_______________________________________Nombresyapellidos:FaustoIvánZamoraAriasCódigo:00107240CéduladeIdentidad:1720895455Lugaryfecha: Quito,mayode2017

4

RESUMEN

Elpresentetrabajodescribeeldesarrollodeunmotordejuegosbasadoenarquitecturadecliente-servidorysuanálisisderendimientodememoriayusodelCPU.Unmotordejuegospuededefinirsecomoelsistemaencargadodemanejarloscomponentesparaqueunjuegofuncione.Deacuerdoaestosehanhechodistintosmódulosparaintegrarlosenunsólosistema,estosmóduloshansido:elmodelodeobjetos,sistemadeeventos,sistemadered,ysistemadeactualizacióndelhiloprincipal.Cabemencionarqueelenfoquedeltrabajoesquelossistemasymódulosmencionadosseintegrendeunamaneraremotaenredyesporestoqueelsistemaderedesparteprincipaldelsistema.Paralogrardichoenfoquesehadivididoalmotordejuegoenprocesosdeclienteyprocesosdeservidor.Losprocesosdeclienteavisandenuevoseventos,generadosporelusuario,alservidoryestesehadeencargardeejecutarlosyactualizarlosparalosdemásclientes.Además,sehanhechopruebasparamedirelrendimientodelsistematantoparaclientescomoenservidordememoriaydeusodelCPU,lascualeshanmostradounusocasiconstanteenelusodeestas.Sinembargo,laexperienciadeusuarioenLANdeberíapulirseenunfuturopuesesunodelostemasdestacablesparasatisfaccióndeunjuegoquesehagaconelmotoryesquelosusuariospuedanexperimentarenvariosmediosdered.Esasícomoseproponeunsistemademotordejuegoscapazdetrabajarenredconarquitecturacliente-servidor.Palabrasclave:MotordeJuegos,videojuegos,red,cliente,servidor,eventos,modelodeobjetodejuego.

5

ABSTRACT

ThispaperdescribesthedevelopmentofaGameEnginebasedonaClient-ServerarchitectureanditsanalysisofmemoryperformanceandCPUusage.Agameenginecanbedefinedasthesysteminchargeofhandlingthecomponentsforagametowork.Accordingtothis,differentmoduleshavebeenmadetointegratethemintoasinglesystem,thesemoduleshavebeen:theobjectmodel,eventsystem,networksystem,andmainthreadupdatesystem.Itisworthmentioningthattheapproachforthisworkisthatthesystemmodulesbecomeintegratedremotelyinnetwork,thatiswhythenetworksystemisamainpartoftheengine.Inordertoachievetheapproachthegameenginehasbeendividedintoclientprocessesandserverprocesses.Theclientprocesseswarnsofnewevents,generatedbytheuser,totheserveranditmustmanagetheexecutionofthemandupdatethemfortheotherclients.Inaddition,testshavebeenmadetomeasuretheperformanceofthesystemforbothclientsandserverformemoryandCPUusage,whichhaveshownalmostconstantuseofthese.However,theuserexperienceinLANshouldbepolishedinthefutureasitisoneofthehighlightsforsatisfactionofagamethatisdonewiththeengineandbecauseusersmaybeabletoexperiment,inthefuture,invariousnetworkmedia.Inthisway,Itisproposedagamingenginesystemcapableofworkinginanetworkwithclient-serverarchitecture.Keywords:GameEngine,videogames,networking,client,server,events,gameobjectmodel.

6

TABLADECONTENIDO

Introducción......................................................................................................................8

DesarrollodelTema........................................................................................................12

Objetosymecánicasdejuego.........................................................................................12

Sistemadeeventos.........................................................................................................17

Arquitecturaderedparamúltiplesjugadores..................................................................23

Análisisdelrendimientodelsistema...............................................................................28

Pruebasenlocalhost.......................................................................................................29

PruebasenLAN...............................................................................................................34

Conlusionesdelanálisis...................................................................................................39

Conclusiones...................................................................................................................42

Referenciasbibliográficas................................................................................................44

7

ÍNDICEDEFIGURAS

Figura1.ModelodeobjetosdejuegoporComponentes………………………………….16

Figura2.ComposicióndeInterfacesparacomponentesdejuego……………………..22

Figura3.DiagramadelSistemadeeventos……………………………………………………….22

Figura4.Diagramadesistemadered………………………………………………………………..27

Figura5.Juegofuncionalhechoparaprobarelsistema…………………………………….27

Figura6.UsodelCPUdelServidorenlocalhost…………………………………………………31

Figura7.UsodelCPUparaclientesenlocalhost……………………………………………….31

Figura8.Usodememoriaeneltiempoparaservidorenlocalhost…………………..32

Figura9.Usodememoriaeneltiempoparaclientesenlocalhost……………………32

Figura10.Númerodepaquetesenviadosparaconexióncliente-servidorenlocalhost.33

Figura11.Porcentajesdepaquetesenviadossegúnsutamañoentreclienteyservidorenlocalhost………………………………………………………………………………………………………………………33

Figura12.UsodeCPUvsintervalosdetiempodelservidorconmúltiplesclientesenLAN.36

Figura13.UsodelCPUdeclientesconectadosenLANaunmismoservidor……………………36

Figura14.UsodememoriaeneltiempoparaservidorconmúltiplesclientesenLAN……37

Figura15.UsodememoriaeneltiempoparalosclientesconectadosenLAN……………….37

Figura16.NúmerodepaquetesenunsegundoparalaconexióndeclientesyservidorenLAN…………………………………………………………………………………………………………………………….38

Figura17.PorcentajedepaquetesenviadossegúnsutamañoentreclientesyservidorenLAN……………………………………………………………………………………………………………………………38

8

INTRODUCCIÓN

Alolargodelahistoriadelosvideojuegossehanhechoyprogramadotécnicaspara

sumejorimplementaciónenelhardware,asímismolascomputadorashanevolucionadoy

dichastécnicashanevolucionado.Unejemplodeestaevolucióneselusodeparadigmas

computacionalescomolaprogramaciónorientadaaobjetosquepermitelaseparaciónde

propiedadesymétodosdeunelementodeunprograma,deotrosyotorgaindependencia

paraposiblescambiosenelcomportamientodeesteelemento.Unadeestastécnicasfue

hechaenladécadade1990enelpopularjuegoDOOM,juegodedisparosenprimera

persona,lacualconsistíaendarunaseparaciónclaraentreloscomponentesprincipalesdel

sistema(eventos,organizacióndecomponentes,sistemasdeinteligenciaartificial,manejo

degráficasysimulacióndefísica)deloscomponentespropiosdeljuego(reglasdejuego,

modelosdepersonajes,diseñodeniveles,entreotros).Alresultadodemanejodel

softwareselollamómotordejuegos.Formalmenteunmotordejuegossedefinecomoun

sistemaextensiblequeesbaseparavariosjuegosdevideodiferentessinquesehagan

modificacionesimportantesalsistema(Gregory,2014).Sinembargo,acriteriodeeste

trabajo,sedebetenerclaralascaracterísticasquesedeseantransmitirenelsistema,es

decirqueesloquevaahacer.Paratenerclaroquedeseatenerunmotordejuegossedebe

saberaquétiposdejuegosvaaserorientadoyparaestosetienequetomarencuentalos

principiosdelasmecánicasdejuegoqueseutilizanparadistintosgénerosdejuego

(Roberts,2015).Esasícomoestetrabajotratadeldesarrollodeunmotordejuegos

basándoseenprincipiosdearquitecturademotores,diseñodejuegosporcomputadoray

diseñodesistemas.

9

Laarquitecturadeunmotordejuegossiguelasmismaspautasdeldiseñodesistemas

clásico,enreferenciaaaqueldiseñodesistemasquenoestáenfocadoajuegos,peroconla

diferenciadeenfocarseexclusivamentealasincronizacióndemúltiplessistemasentiempo

real.Engeneralunsistemadejuegosdebemanejarvariossubsistemasparaquese

sincronizanunosconotrosenunlazoprincipal,estopuedelograrsepormediodelusode

arquitecturasmultiprocesador(Gregory,2014).SegúnSommervillelasarquitecturas

multiprocesadorsonunmodelosimpledesistemasdistribuidosenelqueelsistematiene

unnúmerodeprocesosdiferentesquepodríanejecutarseenseparado.Elnúmerode

procesosqueunjuegopuedeejecutardependedelossistemasqueesterequiera,paraesto

setienetresmodelosparaeldiseño:Unhiloporsubsistema,porJobs(trabajos),y

programaciónasincrónica.Latécnicadediseñodeunhiloporsubsistemaesunenfoquede

multitareaparaasignarsubsistemasparticularesdelmotorparaqueseejecutenenhilos

separados,unhilomaestroseencargadecontrolarysincronizarlasoperacionesdeloshilos

secundariosparaqueestoscompartaninformaciónquemantengalalógicadeljuego,pero

alhacerestocadahilodependedeltrabajodeotroconunatareaespecíficaparapoder

llamaralsiguienteypuederepresentarrestriccionesencómolehilosistemavaaser

utilizado.EnelcasodeldiseñoporJobsesdividireltrabajoenpequeñoshilos

independientesllamadosJobsotrabajos,esteenfoquepuedeserresumidocomopiscinade

hilos(threadpool).Porúltimo,eldiseñoenfocadoenprogramaciónasíncronaserefiereal

hechodequecuandounprocesorequierederesultadosdeunaoperaciónpertenecientea

otro,estenovaaestarhabilitadoinmediatamentedespuésdelapeticióndeeste(Gregory,

2014).Dadosestosenfoquesydefinicionesanteriormenteexpuestassepuedegeneralizar

queunmotordejuegosdebeserconcebidocomounsistemadistribuidoconmultitareasy

porlotantodeberíasercatalogadocomounsistemadetiemporeal(Sommerville,2000).

10

Porotraparte,losmotoresdejuegomanejanprogramasquerepresentansistemas

suavesquenosoncríticosparalaejecucióndetransaccionesoprocesos,enotraspalabras

manejanvideojuegoscuyaejecuciónnodependededatoscríticoscomoporejemplolas

transaccionesdedineroquesuelenhacerlobancos,pueselobjetivodeunvideojuegoes

hacersevercomoexperienciainteractivaqueseadivertida.SegúnGregoryunmotorde

juegosesunsistemaquepermitecreardiferentestiposdejuegossinembargonoson

completamenteperfectosparacualquiertipodejuego,porlocualexistenmotores

especializadosparajuegosdepeleas,juegosdedisparosenprimerapersona,derol,entre

otros.Estosgénerosayudanadefinirlasmecánicasysistemasquesehandeconstruirenel

motorpuessepuedeconsiderarquelosrequerimientosdelosgénerosdejuegosson

estándaresquedebencumplirsusrespectivosmotores.Losgénerosmejordefinidosenla

industriadevideojuegossonlosFirst-PersonShooters(FPS):Lascaracterísticasdelosjuegos

FPSdebenserenfocadasenambientesdetresdimensionesconanimacionesdealta

fidelidadparapersonajeseinteligenciaartificialparaenemigos;Plataformasojuegosde

tercerapersona:paraelgénerodeplataformassedebecontarconobjetosquerepresenten

plataformasoartefactosparainteractuarconeljugadorenambientesestilo

rompecabezas,yalgoritmosdecolisióndecámaraparaambientesentresdimensiones;

juegosdepelea:debecontarconunconjuntoricoenanimacionesdepelea,deteccionesde

colisiónmuyprecisasyunsistemadedeteccióndecombinacionesdebotones;juegosde

carreras:usodealgoritmosdetrucosvisualesparasimularelmovimientodeobjetos,uso

deestructurasdedatosparalarepresentacióndelcaminoyalgoritmosavanzadosde

controldecámara;juegosenlíneademultijugadoresmasivos:Necesidaddeservidores

conectadosquemantenganlalógicadeljuegoparavariosjugadores,manejode

transaccionesdedinerodelosjugadores,ysoporteparamuchísimosjugadoresconectados

11

almismotiempo;ydecontenidogeneradoporeljugador:sonjuegosquerequierenqueel

jugadorcree,publiqueycompartaloquehahechoenelmundodejuego,unejemplode

estegéneroesMinecraft(Gregory,2014).Asíesqueunmotordejuegonopuedeabarcar

todoslostiposdegénerosexistentes,puescadaunotienenecesidadesdiferentesque

muchasvecesnosondesarrolladascompletamentepuesesenoseríaelobjetivodelmotor

enparticular.

Estosprincipiosexpuestossonbaseparalacreacióndejuegosydemotores,yen

estetrabajosehancubiertoaspectoscomoelusodelasmecánicasparajuegosde

plataformaymultiprocesamiento.Lasmecánicasdeunjuegodeplataformaspuedenvarias

dependiendodeloquesequieralograrenelmundo,peroelhechodequeunmotorde

juegosseaespecíficodeesegénerorequierequeestépreparadoparaloquevaaquererel

diseñadordeljuego.Teniendoencuentaestoeltrabajoanteriormenteexpuesto,seha

hechoelsuficienteesfuerzoprogramáticoparacomplaceresasnecesidades,peroparaun

ambienteendosdimensiones.Estosesfuerzosincluyeneldesarrollodeunaarquitectura

distribuidaconunenfoqueclienteservidor,peroconunservidorqueaplicaprincipiosde

trabajoconmultiprocesadores.Porotraparte,elhechodequeestéespecializadoen

plataformasnosignificaquenosepuedenhacerotrostiposdejuegos,unejemplodeesto

esUnityqueesunmotorcomercialquehapermitidolarealizacióndevariosgénerosconsu

mismaarquitecturaprincipal(Unity,2017),estoselodejaríacomoobjetivosecundariopero

muyposibledebidoalprincipiodeextensibilidaddelsistema.

12

DESARROLLODELTEMA

Comosehadescritoanteriormente,unmotordejuegosusavariossubsistemasde

maneraquenecesitadeunaarquitecturaquepermitaelmanejoylasincronizaciónde

múltiplesprocesos.Esporestoquesehadecididodesarrollarelproyectocomounsistema

distribuido,específicamenteconenfoquedearquitecturacliente-servidor.Sinembargo,se

hatomadoenconsideraciónquealestarejecutadovariossistemasenparalelo,sedebería

teneruncontroldeacuerdoacomoestossistemasvayanactuando,esporestoqueseha

decididosumarunaarquitecturademanejodeeventoscompartidaentreelclienteyel

servidor,permitiendoasíelusodeprioridades.Porotraparte,paralarepresentaciónde

mecánicasyobjetosenelsistemasehaoptadoporunmodelodediseñoquepermitala

extensibilidaddeimplementarnuevascualidadesalospersonajesyobjetosdeljuego.Esasí

comoeldesarrollodelmotordejuegossedividióentrespartes:Diseñodeobjetoscon

mecánicasdejuego,sistemadeeventosydesarrollodearquitecturaderedparamúltiples

jugadores.Cabemencionarqueeldiseñodelproyectoestábasadoenlosdeberesdelcurso

defundamentosdemotoresdejuego(GameEngineFoundations)delperiododeotoñodel

2015porelprofesorDavidRobertsenlaUniversidadestataldeCarolinadelNorte.

13

Objetosymecánicasdejuego

Unadelaspartesimportantesdeunsistemadejuegosescómosemanejany

representanlasestructurasdeobjetosdejuego.Estoselograabstrayendoconceptosde

programaciónquepuedandarmanerasdeconsultarlasrelacionesquelosobjetostienen

conotrostiposoaccederalainformacióndeltipodeobjetoentiempodeejecuciónopara

propósitosdedepuración(DeLoura,2001).Paralograrunaabstracciónsatisfactoriaseha

consideradoloselementosbásicosquetienenlosjuegosengeneral,peroenconcentración

algénerodeplataformas,pueselmotorpretendeserparausodedesarrollodeeste

género.

SegúnSchellexistencuatroelementosbásicosqueunjuegoposee,estossonlas

mecánicas,lahistoria,laestéticaylatecnología.Estetrabajoseenfocaenlapartedela

tecnologíapuestratadelmotorydelsistemaquepermitelainteracción.Sinembargo,para

eldiseñodelosobjetosdejuegoqueserepresentaránenelmotorsenecesitaentenderlos

otroselementos,enespeciallapartedelasmecánicaspuesestassonlasquedanlasreglas

yelprocesodejuego,ademásdescribenloquelejugadorpuedeonohacer(Schell,2008).

Asímismoseconsideróquelaestéticadelosjuegospuedeserimplementadaenelsistema

pordefecto,esporestoquesehaimplementadoademásunamaneraderepresentarlos

objetosamaneradecuadrados,talcomosepuedevereneljuego“Thomaswasalone”que

lospersonajessoncompletamenterectangularesylosambientestambién(Bithell,2012).En

elcasodelahistoria,sehaconsideradoqueelmotordejuegosnodeberíamanejarla

historiapuesesunelementoqueeldirectorodiseñadordeunjuegodeberíatomarmásen

cuentaqueloqueharíaeldiseñadordelmotor,sinembargo,esonoquitalaposibilidadde

quesepuedausarelpresentemotorparanarrarunahistoriainteractiva.

14

Conloselementosanterioressehadispuestoahacerundiseñodeacuerdoal

modelodeobjetodejuegoporcomponentes.Uncomponenteesunapartequeesmodular,

instalableyreemplazabledelsistemaqueencapsulaunaimplementaciónyexponeuna

seriedeinterfaces(RogerS&BruceR,2015),estemodelodeobjetostienesufundamento

enlaprogramaciónorientadaaobjetosenelcualcadacaracterísticaquevaatenerun

elementoselollamacomponente(Gregory,2014).Sepuedeentenderelmodelode

componentesparaunjuegoconelsiguienteejemplo:Sedicequesetieneunpersonajeque

puedecaminar,dispararysaltar,paraelmodelosepuededecirqueelobjetodejuegoesel

personajeyquesuscomponentessoncaminar,dispararysaltar(Roberts,2015).Para

implementardichomodeloenelmotorsehacreadounaclasellamada“GameObj”elcual

tienereferenciaacomponentesdeusoposiblesquesehandiseñadoenbaseaunainterfaz

llamada“Component”.Sehadecididoimplementarcuatrocaracterísticasparalosobjetos

dejuego,lascualessehaconvenidoquesonlasimportantesparaeltipodejuegoqueel

motorestáenfocado,estassonqueunobjetoseadibujable,movible,chocableychocable

comounazonamuerta,estaúltimaparaañadirelementosderompecabezasenlos

ambientes.Cabemencionarqueestoscomponentessonopcionalespuesdependiendode

cómosedeseehacerunjuegoconelmotor.Porotrolado,segúnlosprincipiosde

arquitecturademotores,paratodojuegoexisteunlazoprincipalqueseencargade

actualizarlosdatosdelosobjetosdejuegodeacuerdoacambiosenelambienteo

ejecucióndeeventos(Gregory,2014).Esporestoqueeldiseñodelosobjetosy

componentesdebetomarencuentaesteprincipio.Asíquetantolaclasedeobjetosde

juegocomolainterfazdecomponentestienenmétodosdeactualización(“Update”).

Cadacomponentetieneunaacciónespecífica.ELcomponentedibujableseocupadedibujar

enpantalladelcliente,cabemencionarqueelclienteestehechoenbaseaProcessing2el

15

cualseejecutacomounAppletdeJava.Aldibujarselosobjetosenelclientesellamaa

métodospropiosdelframeworkdeProcessingparamostrarcuadradosenpantalla,estos

tienenunconstructorparadeterminarsuancho,largoyposicionesenunespaciodedos

dimensiones,XyY(Reas,2007).Sinembargo,paraquelosobjetospuedanpasardel

servidoralclienteysepuedandibujarsehaagregadounareferenciaaunPApplet,claseen

dondesetieneunlienzoparadibujarfigurasdeProcessing.Asímismoparaelcasodel

componentedemovible,esteseencargaenactualizarlalógicadelmovimientoquese

deseerealizardeacuerdoacomoeldiseñodeljuegorequiera,ydelamismamaneralo

haceelcomponentecolisionable,peroconladiferenciaqueusadeteccióndechoquecon

todoslosobjetosqueposiblementeinteractúen.

Conelmodelodeobjetosdejuegoexpuestosepuedeimplementarlasmecánicas

requeridasparaeldesarrollodejuegosdeplataformas.Lasmecánicasvanadependermás

deldiseñodeljuegoquedelmotor,peroesresponsabilidaddelmotordarcontrolaesetipo

deelementos.Parateneruncontrolentrelosobjetosyelmundoquepuedecambiarde

acuerdoalusuariosedebetenerunmanejadorquedetecteestoscambios,paraestoseha

diseñadounsistemadeeventosqueseexponeenlasiguientesección.

16

Figura 1:Modelo de objeto de juego por componentes.

Figura 2:Composición de Interfaces para componentes de objeto de juego.

17

SistemadeEventos

Paraelcontroldeaccionesquerealicenloscomponentessobreelsistemaylalógica

deljuego,queelmotorhadecontrolar,sedebemanteneruncriteriodepriorizaciónpues

ciertasaccionespuedensermásimportantesqueotras.Unejemplodepriorizaciónde

ejecuciónesladiferenciaentrelaaccióndelusuariodepulsarelbotónparamoverseala

derechayladepulsarelbotóndesalto,entrelasdossellamanalmismocomponente,

movible,perolasdostomandistintostiemposdeprocesamiento,enespecíficoelde

movimientoaladerechasóloleconciernemoveralobjetounospixeles,peroenelcasodel

saltolalógicaesmásextensayelmovimientopuededurarvariossegundosdependiendode

ladistanciarecorridaloquesuponemayorescálculos.Lamayorprioridadenesteejemplo

seledaríaaldelmovimientoaladerechapueseltiempoesmenoryunjugadorpuede

esperarqueelmovimientoseamásrápidodebidoasumenorcomplejidad.Asímismo,el

movimientodelsaltotendríamenorprioridad,pueselusuariopuedeverqueelmovimiento

esmuchomásgrande.Esteejemplotratadeexplicarloqueentérminosdesistemas

operativosseconocecomoSchedulling,programacióndetareas(Silberschtz,2012).Sin

embargo,pararepresentarestoenelmotordejuegossehadecididoponerlastareasa

maneradeeventos,esasíqueparaelmanejodeeventossehaoptadoporunaarquitectura

detreselementos:eventos,manipuladores(handlers)ymanejador(Manager).Esta

arquitecturafuncionaregistrandoeventosenmanipuladoresindependientesquesehande

ejecutarenelmanejadordeacuerdoaalgunaprioridad(Gregory,2014).

Paraeldiseñodelsistemadeeventossehantomadoalgunasconsideraciones

basadasenconceptosdesistemasoperativoscomoelschedulingysincronizacióndetareas.

Labaseparaunabuenaprogramaciónoschedulingdelastareasdelsistemaessaberelciclo

deejecuciónqueunatareahadetenerylaesperaquepuedeaguantarlatarea,ademásde

18

asegurarquenosedejealprocesoenestadoocioso,enunaesperaconstanteoenun

puntomuerto(Silberschtz,2012).Lastareasparaestesistemasehanprogramadoenlos

manipuladoresdeeventos.Paraevitarlosproblemasantesmencionadossehadecidido

dotaralsistemadeeventosconunaestrategiadesincronizaciónbasadaenmonitoresque

consisteendeclararvariablescuyosvaloresdefinenelestadodelatareaypermiten

sincronizarconotrosprocesosohilosdeacuerdoaestosvalores(Silberschtz,2012).

Porotrolado,lastareasysuejecucióndependendelostrescomponentesquetiene

elsistemadeeventos:Eventos,ManipuladoresyManejador.Paraladefinicióndeeventos

sehahechounaenumeraciónparaloscasosposibles.Loseventosmáscomunesparaun

juegodeplataformassonlosgeneradosporeljugadorpormediodeunHID(Human

interactiondevise)queenestecasoseríaelteclado(Gregory,2014).Esasícomoloseventos

sehandefinidoporlasteclasarriba,abajo,izquierda,derechaybarraespaciadora.Porotra

parte,unodelosobjetosquesehaimplementadoenelmotorsonlasplataformasmovibles

lascualeshanderesponderaeventosquesuenumeraciónespecíficatambiénseha

implementado(AUTOMATIC_PATTERN).Asímismo,losmanipuladoresquesonlos

encargadosdeejecutarlasaccionesqueeleventogenerará.Pararepresentarlosenel

sistemasehahechounaclasellamadaEventHandlerquecuentaconcincoatributos

importantesparadefinirlaacciónqueelobjetohadehaceryquesonnecesariosparael

schedulingdelsistema,estosson:type (tipodeevento),timeStamp(tiempoenelquese

registróelevento),subdivisions(sieleventovaaestarasociadoconmáseventos),

priority(prioridaddeejecución)yage(tiempodevidamáximoquedeberíaesperarpara

ejecutarse).Además,estaclasecuentaconunmétodoqueregistraelcomportamiento

deseadoalmanejador,yunmétodoparaejecutarlo.Porotraparte,Lapiezamás

importantedelsistemadeeventoseselmanejadorpueseselencargadodeprogramarque

19

manipuladoresvayanaejecutarseyenquéordendeacuerdoasuspropiedades,esdecir

delschedulingensí.Losatributosdelosmanipuladoresayudanaqueelmanipuladordecida

elordendeejecuciónpormediodeunacoladepreferencia.Elmanejadorhasidointegrado

enelservidorpueslaejecucióndeeventosdebeinteractuarconlosdemásobjetosdejuego

yestarsincronizados.

Sinembargo,loseventosnosolodebenestarpresentesparaserejecutados,sino

quesuejecucióndebeestarhechadeacuerdoaunalógicaparaeljuegoenestecasosería

lafísicaparaunjuegodeplataformas.Lafísicaenelmotorestádadaporunaestructurade

tiempoylógicaenloscomponentesmovibleycolisionable.Laestructuradetiempoestá

dadaporlaclaseTimeLineycuentaconunmétodo(calculateTic())yselausadetal

maneraquecadaobjetodejuegoquedebarelacionarseconfísicaseactualicehaciendouna

diferenciadetiemposdelprocesadorobtenidoalinicioyalfinaldellazodejuego.Esta

estructuraestáincluidacomopropiedadenlaclasedeObjetosdejuegoyseusapara

actualizarloscomponentesdeMovimientoyChoque.Paraelmovimientodeobjetosque

actúanpormediodeinteraccióndelusuario,teclado,sehacreadounafunciónparacuando

elusuarioactivaeventosdemovimientodeizquierdaoderechaenrelaciónaltiempoque

estádadaporlasiguienteecuación:x=5t/20yqueespositivacuandoelmovimiento

deseadoesaladerechaynegativacuandoesalaizquierda.Asímismo,paraeventosde

saltosehahechounalgoritmobasadoenelmovimientodecaídalibrequeeselfenómeno

queenausenciaderesistenciadelairehacequetodoslosobjetoscaiganconlamisma

aceleraciónconstante(Giancoli,2008),sinembargo,paramantenersimpleloscálculosdel

componentesehahechoavelocidadconstantedey=2t/10.Elalgoritmodesaltoestá

gobernadoporunavariablebooleana,llamada"jumping",queactivaelpatrónde

movimientohastaqueestesecompletealtocarunasuperficieconpropiedadesdelímiteso

20

choque.Lavariablequecontrolaelalgoritmoesactivadacuandoelusuariopresionael

botónolatecladesalto.Sinembargo,sufuncionamientopuedeextenderseporvarias

iteracionespuessebasaenellanzamientodeunproyectil:cuandoelobjetoespuestoenel

saltoiniciaconunavelocidadconstantehastaquellegaasupuntomáximoqueestres

vecesmayorqueeldesupropiaaltura,despuésdeestoelobjetohadeempezarsu

descensoconlamismavelocidadhastallegaralbordeochocarcontraotroobjeto.EL

comportamientodemovimientomuchasvecesvaadependerdeldechoquepuespara

variosobjetoseneljuegolacondicióndechoquevaaserobligatoria(saltarsobre

plataformas,porejemplo),esporestoqueenpatronescomoeldesaltoesnecesariosaber

siocurrióunacolisiónenlapartedeabajodelobjetoparacomprobarsielmovimiento

continúaosepara.

Porotrolado,elmanejadorhadeserunárbitroparaelsistemayquienintervenga

entrelalógicadelservidorylosmanipuladoresquevienendesdeelcliente.Elsistemaestá

hechodetalmaneraquelosmanipuladoressehandegenerarenlosclientes,luegohande

llegaralservidorquientienealmanejadordeeventoscorriendoenparaleloconunhiloque

seencargadellenarunacoladeprioridadconmanipuladoresparaefectuaroperacionesde

sincronizaciónentrelalógicaquemanejaelservidorylaejecucióndelosmanipuladores.

Unacoladeprioridadesunaestructuradedatosquepermitehacerschedullingensu

coleccióndeobjetosypuedeestarordenadaporlaprioridadmásaltaalamásbaja,pero

paraquelosobjetospuedansercomparadosdebentenerunainterfazcomparable(Weiss,

2012).Lacoladeprioridadimplementadaparaelproyectotienelaparticularidadde

compartirelementostantoenlalógicaprincipaldelservidorcomoenelhilodeejecución

porestodebeseratómica.Enconsecuencia,sehausadounacoladeprioridaddeltipo

PriorityBlockingQueuequeesunacolecciónatómicadeJava(Oracle,2016).Porotrolado,

21

paraquelacoladeprioridadejecutelosmodificadoresyqueestostenganefectodentrode

losobjetosdejuegodelservidor,sedebesincronizarlasoperacionesrealizadasenel

manejadorconelhiloprincipaldelservidor.Sibienesciertolosmanipuladoresalestar

dentrodeunacolecciónatómicanodeberíansufrirproblemasdesincronización,siestos

sonejecutadosenunhilosinesperaselsistemapodríacaerenunlazoinfinitoqueen

ausenciadeeventosconsumiríarecursosdelprocesadorinfinitamente.Paranotenereste

problemasehausadolaestrategiadesincronizaciónpormediodeunobjetomonitorque

cambiasuestadoaesperacuandolacolaestávacíaycuandolacolaestállenacambiade

estadoparapermitirquesecontinúeconlaejecucióndelhilodelmanejador.

Elsistemadeeventosdescritopermitequelalógicasecompartaentreclientey

servidor,sinembargo,elsistemaqueseencargadelacomunicaciónusaotrosprincipios

computacionales.Comoyasehadescritolosmanipuladoresnecesitanschedulingpara

funcionar,sinembargo,paralacomunicaciónesnecesariotenerunamaneraparecidasies

quesevaaintercambiarinformacióndeeventosydeobjetosquecomosedescribió

anteriormentesontiposdistintosquemanejancosasdiferentesdelmotor.

22

Figura 3:Diagrama del Sistema de Eventos.

23

Arquitecturaderedparamúltiplesjugadores

Paralaarquitecturaderedsehaoptadoporelmodelodeclienteservidorpues

permitequeelsistematrabajedeunamaneradistribuidayquelaexperienciadeusuario

seaenfocadaparajuegosconvariosjugadores.Enparticularelmodeloclienteservidoren

motoresdejuegorequiereresolverlapreguntadesisedeseaqueelclienteseainteligente,

ounsimplepresentadordeimágenes(Roberts,2015).Esporestoqueparaesteproyectose

hadecididoporunpuntointermedioenelcualelclienterecibedatospreprocesadosporel

servidorparamostrarlosenpantalla,yademásgenerayenvíacontroladoresdeeventosal

servidorparasuejecucióncorrespondiente.

Paralaimplementacióndelmodelodeclienteservidorsedebetenerclarocómoes

queestefuncionayquéestrategiasetendráparaeldesarrollodetodossuscomponentes.

Elmodelodearquitecturadecliente-servidoresunmodelodesistemadistribuidoenelcual

semuestracomolosdatosylosprocesossondistribuidosentreunaseriedeprocesadoreso

computadoras.Loscomponentesdeestaarquitecturason:unconjuntodeservidores

autónomosquedenserviciosaotrossubsistemas,unconjuntodeclientesquellamenalos

serviciosofrecidosporlosservidores,yunaredquepermitaquelosclientesaccedanalos

servidores(Sommerville,2000).Deestamaneraserequiereunservidorqueseacapazde

mantenerconexionesconvariosclientes,dichoservidorademásdesercapazdelograrlos

objetivosdeunmotordejuegos,debemantenerlalógicadeljuegoycomunicarlo

sincronizadamenteatodoslosclientes.Pararealizarestosehaimplementadounasolución

conenfoqueenselectoresdemúltiplescanales,siendocadacanalunaconexiónauncliente

enparticular.Porotrolado,losclientessehanhechoenbaseaProcessing,versión2,quees

unframeworkhechosobreJavaorientadoalaprogramacióndeartesvisuales(Processing,

24

s.f.),deestamaneraseaseguraqueelmanejodegraficasdelsistemaestéacargodel

frameworkalimplementarloenlosclientes.

Asímismo,paraeldiseñodelsistemaesimportanteentenderlaredenlaqueseha

deusarlaarquitectura,yelobjetivoqueparaestecasoespermitireldesarrollodejuegos

enredesdeárealocalconprotocoloEthernet.UnareddeárealocaloLANesunaredde

propiedadprivadaqueoperadentroycercadeunsoloedificiocomounacasa,oficinaouna

fábrica,ademássonmuyusadasparaconectarcomputadoraspersonalesyaparatos

electrónicosparaqueestospuedanintercambiarycompartirrecursoseinformación

(Tanenbaum,2011).Conestoenmente,elresultadodelmotorpermitiríaavarias

computadorasconectarseparaquemúltiplesjugadorespuedandisfrutardeunapartidade

juego.Sinembargo,paraquelascomputadorasconectadasenredpuedanenviaryrecibir

paquetessenecesitadeprotocolosquepermitanqueunpaquetededatossepaaqué

computadoradelaredir,entoncessehaoptadoporelusodelossiguientesprotocolos:

Ethernetparalacapadeenlace,IPparalacapadeenlaceyTCPparalacapadetransporte,

cabemencionarquelacapadeaplicaciónhadeestardadaporlosprogramasdelservidory

delcliente.

Paraimplementarestaarquitecturasehanhechovariaspruebascondiferentes

enfoques,elprimeropormediodeserversocketsyelsegundopormediodesocket

channelsconselectores.SegúnladocumentacióndeOracle,unsocketenjavaesunpunto

finaldeunaconexióndecomunicaciónentredosprogramasqueseejecutanenlaredque

ademásusaTCPcomocapadetransporte.Ladiferenciaentrelosserversocketsylossocket

channelseslacapacidaddeusarselectoresporcanales.

ElenfoqueporServerSocketstratademúltiplesconexionesmultihiloconvarios

socketsconectadosaotrosvariosserversocketsparadospuertos,unoparaintercambiode

25

objetosdejuegoyotropararecepcióndeeventos,peroqueharesultadoineficiente.Un

ServerSocketesunaclasedejavaqueesperaporpeticionesquevienendelared,realiza

operacionesbasadasenesepedidoyquepuedeenviaralgúnresultadoalsolicitantedel

pedido.EsasíqueparaesteenfoqueenparticularsehausadodosobjetosServerSockets

quehacenoperacionesaccept(operaciónparaaceptarunaconexiónentrante)enelhilo

principal.Despuésdecadaacceptelsistemallamaaunhilo,unoparaintercambiode

objetosyotroparaejecucióndeeventos.Elhilodeintercambiodeobjetossehade

sincronizarconeldeejecucióndeeventosparaquedeestaformaseenvíenobjetos

actualizadosalclienteysemantengalalógicadeljuego.Sinembargo,esteenfoquegenera

hilosporcadaconexiónaceptadaenelsocketserver,ytambiénnuevossocketsparaenviar

informaciónaquienhizolapetición,loquellevaauncongestionamientodelaredyuso

excesivodelprocesador.Cabemencionarquesehanhechopruebasendostiposde

procesadores:AMDA8yenunIntelCorei7,yelcomportamientodelmotorfuetotalmente

diferenteentreambospuesenelAMDA8lacargadeprocesamientohacíaqueelprograma

ylosdemásprocesosdelacomputadoraseanmáslentos,sinembargoenelcasodelInteli7

elprogramaseejecutabafluidamente,perodeigualmaneracongestionarlaredinternade

lacomputadora.

Porotrolado,elenfoqueporSocketChannelsusaunsocketquefuncionacomo

selectorenelservidorelcualrecibeconexionesentrantesylasregistraencanales.Los

clientesvanatenertrestiposdeoperacionesbásicasparaconectarseconelservidor:

Lectura,escrituraydeaceptación.Cadacliente,dentrodesulazoprincipal,realizará

ordenadamentelossiguientespasos:primero,enviaralservidorunalistadeobjetos

serializablesconelobjetodejuegopertenecientealjugador,yconeventosquehayan

surgidodentrodelclientecomoeventosprovocadosporelteclado.Después,elcliente

26

esperaráarecibirunalistaconlosobjetosdejuegoactualizadosporelservidor.Deesta

maneraelservidortienequeajustarloscanalesparaqueleanyescribanenrelaciónconlo

queelclientequierehacer.Paralograrestosehadecididoalternarlasoperacionesdel

canaldelasiguientemanera:Laoperacióndeaceptaciónsedacuandolaconexiónesnueva

yporprimeravezporpartedelclienteydelservidor.Esporestoquecuandoelservidor

detectaunanuevaconexiónsehaderegistraruncanalqueseacapazderecibirdatosdel

cliente,enotraspalabrassehabilitaalaconexiónpararecibirdatosyqueelservidorpueda

leerlainformaciónquehademandarelcliente.Asímismo,unavezqueelclientehaya

escritodatosenelservidor,estehadecambiarelcanalparaquepuedaenviardatosdel

servidoralcliente.Deestamaneraseaseguraquelasoperacionesdelecturayescriturase

mantengansincronizadascadaquesepresentennuevassolicitudesdesdeelcliente.Por

partedelrendimientoencomputadoras,enlasqueseprobóestaarquitecturaconunsolo

jugadorenlocalhost,elresultadoesinvariableysatisfactoriopueshanpresentadoun

juegofluidosinalteraroralentizandootrosprocesos.

Elsistemaderedparaesteproyectoesunodelospilaresimportantes.Como

objetivodelsistemasehadadoelhechodequeestesepuedamanejarenredconvarios

jugadoresconectadosyparaevaluarlaexperienciaqueestostenganalconectarsesedebe

medirlosrequerimientosdeusodelascomputadorasquetendráncorriendoalosprocesos.

Esasíqueunavezqueelsistemaderedesimplementadoenelmotordejuego,seha

procedidoamonitorearelrendimientodelsistemaenconjunto.

27

Figura 4:Diagrama de sistema de Red

Figura 5: Juego funcional hecho para probar el sistema

28

Análisisdelrendimientodelsistema.

ParamedirelrendimientodelsistemasehaobtenidodatosdelusodelCPU,memoriayde

lospaquetesderedresultantesdepruebashechasconunjuegofuncionalquepruebalos

aspectosbásicosdelmotor.Comoelsistemaestáhechoparafuncionarenredseloha

probadodedosmaneras,laprimeraporlocalhostylasegundaporLAN.Laspruebaspor

localhostbuscandemostrarqueelmotorfuncionaparalacreacióndejuegosdeunsolo

jugador,porotrapartelaspruebasenLANbuscanasegurarunaexperienciamultijugador

paraelmotor.

TantolaspruebasdelocalhostcomoenLANfueranhechasconayudadehilosque

recolectabanelusodelCPUylamemoriausadaporelproceso,deestamanerase

recolectarondatosparaobtenerconclusionesdesufuncionamiento.Asímismo,parala

recoleccióndedatosderedsehausadoWiresharkparaverlacantidadyeltamañodelos

paquetesparahacerunanálisisenfuncióndeltiempo.Cabemencionarquelosdatos

obtenidosusandiferentesunidades:ParaelusodelCPUseusanporcentajes,paraelusode

memoriaseusaBytesyparaelanálisisderedsehausadopaquetes/segundo,todosellos

analizadosversuseltiemposiendolosdatosobtenidosdeloshilosenunintervalode

aproximadamente100milisegundosylosobtenidosporWiresharkdeintervalosde1

segundo.Cabemencionarquecadapruebaseharealizadocontresexperimentospara

luegoobtenerunpromedioqueresumaelcomportamientodelosexperimentos.

29

PruebasenLocalhost.

Estas pruebas se han hecho en una misma computadora que funciona al mismo

tiempodeservidorydecliente,conaproximadamentetresminutosdejuegoconenvíode

eventos aleatorios según el uso de un jugador humano. Cabe mencionar que la

computadora tiene un procesador de Intel Core i7 a 2.8 GHz con 4GB de RAM. Por otra

parte,sehanhechodostiposdepruebaspara localhost.Laprimeraconsisteenusodeun

solojugadorylasegundausomultijugador,variosclientesenlocalhost.

Paralapruebadeunsolojugadorsehaencontradounalíneadetendenciade

y=-0.0022x+4.213 para el uso del procesador en el servidor,mostrando así un gradiente

decrecientequedemuestraqueelusodelCPUesmayoraliniciodelprogramadelservidor.

Porotrolado, latendenciadelusodelprocesadorparalaaplicacióndelclientefuedey=-

0.0037x+14.236,mostrandouncomportamiento similar,pero conunusomásaltoqueel

del servidor. En el caso del análisis de memoria para un solo jugador, el servidor ha

mostradounatendenciaacrecerdey=730.13x+1E7yenelcasodelclienteunatendencia

de y=698.61x +2E7, con la particularidad que para los dos casos el uso del recolector de

basura aumenta entre el intervalo 400 y el intervalo número 1000. Como resultado del

análisisdereddeunsolojugadorsehadetectadounatendenciadelnúmerodepaquetes

enviadosporsegundodey=0.0225x+203.26quemuestraunlevecrecimientodepaquetes

enviados al avanzar el juego y un promedio de paquetes enviados de 205

paquetes/segundo. Por otro lado se ha detectado que el 50.01% de paquetes tenían un

tamaño de entre 40 a 79 bytes que pertenecen a paquetes tipo ACK, y 49.99% de los

paquetes fueron de entre 1280 a 2559 bytes que contenían datos de objetos de juego y

eventos.

30

Asímismoparalapruebademultijugadorenlocalhostseobtuvoresultadossimilaresalas

deunsolojugador,peroconlíneasdetendenciamásempinadasparalamemoriayCPUy

losclientes.LatendenciaparaelusodelCPUenelservidorhasidodey=-0.0019x+4.7843,

que igual que en el caso anterior,muestra un decrecimiento de procesamiento desde el

iniciodelprograma,siendo losprimeros200 intervalosposeedoresdeporcentajesdeuso

mayoresqueelrestosobrepasandoel20%delCPU,peroelrestodeltiempoelusodelCPU

seestabilizaenunpromediode3%aproximadamente.Asímismo,elusodeCPUpara los

clientes, dos, en localhost ha mostrado una tendencia de y=-0.0029x+13.564, que

igualmentemuestraundecrecimientodesdequeelprogramaempiezaaejecutarseenlos

primeros100intervalosconpicosdehastael31%deusodelCPU,paraluegomantenerun

11%depromedioenusodelCPU,8puntosmásarribaqueelservidor.Porotraparte,eluso

dememoriaparaelservidorfuedey=751x+1E7,tendenciaqueseencuentramuyparecida

a la obtenida para un solo jugador,así mismo por parte de los clientes se obtuvo una

tendenciadey=1406.5x+2E7queesmayorque la tendenciaparaunsolo jugador, locual

suponequecuandoenelsistemainteractúanmásobjetos,lamemorianecesariaaumenta

en los clientes. Finalmente, en el análisis de red se ha obtenido una tendencia de

crecimientomayora ladeunsólocliente,queresultaeny=0.1375x+319.02conpromedio

de333paquetesenviadosenunsegundo,promedioelcualsemantienecomotendenciaen

la vida del sistema , sin embargo la ecuación resultante es una línea que crece con

pendientepositivaque seexplicaporqueal iniciode la vidadel servidor seenvíanpocos

paquetestipoACKhastaqueserealizanlasprimerasconexiones.

31

Figura 5: Uso del CPU del Servidor en localhost

Figura 6: Uso del CPU para clientes en localhost

32

Figura 7: Uso de memoria en el tiempo para servidor en localhost

Figura 8: Uso de memoria en el tiempo para clientes en localhost

33

Figura 9: Número de paquetes enviados en un segundo para la conexión de clientes y servidor en localhost

Figura 10: Porcentaje de paquetes enviados según su tamaño entre cliente y servidor en localhost

34

PruebasenLAN

Paraestetipodepruebassehausadolacomputadoraantesmencionada,parael

experimentoenlocalhost,comoservidoryademásunequipoparagenerarunaredLANpor

cableEthernetde10Mbpsdeanchodebanda.Ycomoenelexperimentoanterior,sehan

hechopruebasconunoycondosjugadoresconectadosalservidor.

ParaelexperimentoconunsólojugadorconectadoenLANalservidorsehaencontradouna

tendenciadey=-0.0012x+4.2814queesaproximadamenteigualalaobtenidaparalos

experimentosdelocalhost,ademásdepresentarelmismopromediode4%alestabilizarse

elusodelCPUdespuésdelintervalonúmero200.Asímismo,elclientehamostradouna

tendenciadeusodeCPUsimilaraldelexperimentoanteriorconunatendenciadey=-

0.0043x+13.047yconunpromediodeaproximadamente13%deusodelCPUdespuésdel

intervalo200.Sinembargo,enelcasodelamemoriautilizadaelservidorexperimentaun

incrementoapartirdelintervalo1500deunmáximode14Mba19Mb,sinembargopor

causadelrecolectordebasuradejavalalíneadetendenciahasidodey=522.02x+1E7que

esmenorquelaobtenidaparalocalhostperoenestecasoelusodememoriaesmenos

uniformequelasanteriores.Enelcasodelamemoriadelosclienteslamemoriasigueuna

tendenciamásuniforme,peroconunmáximode28Mb,mayorqueenelservidor,ycon

ecuacióndetendenciadey=1249.7x+2E7.Porotraparte,enelanálisisderedseencontró

unatendenciadey=0.031x+255.68conunpromediode355paquetesporsegundoyconun

33.33%depaquetesdetamañodeentre1280a2559bytesquerepresentanlasegunda

mayoríadespuésdeun33.34%depaquetesdeACK,mostrandoasíqueenconexión

ethernetseenvíanpaquetesmásgrandesqueenlocalhost,estopuedeserporqueel

protocoloesmáscomplicadoqueenlocalhost.

35

EnelexperimentodeLANparamúltiplesjugadoressehanusadodoscomputadorascomo

clientesyunservidorqueeslamismacomputadorausadaanteriormente.Las

computadorasquehansidousadascomoclientestienendiferentesprocesadores,la

primerausaunIntelCorei7a2.9GHzcon16GbdememoriaRAM,lasegundausa…Cabe

mencionarqueesteexperimentofueelqueconmásdatossehancontado.Paraelanálisis

deusodelCPUdelservidorseencontrómayornúmerodepicosqueencualquierotra

pruebayunmáximoalcanzadoenmediaejecuciónde28%deusodelCPU,sinembargo

sigueunatendenciadey=-0.00017x+6.4801conunpromediode6.4%deusoeslaprueba

endondeelusodelCPUsehaduplicadoenrelaciónalasanterioresyaunquees

decrecienteelnúmerodepicosesmayorqueenotraspruebas.EnelcasodelCPUdelos

clienteslatendenciaessimilaraladeanteriorescasosdey=-0.00057x+11.54quemuestra

casiunaconstantede11.5%deuso,estohacesuponerqueelrendimientodelcliente

puedeestardadoporlaestructuraqueestáhechoProcessingmásquedelas

particularidadesdelmotorpropuesto.Enelcasodelamemoriadelservidorsehanotado

unpatrónquediferenciadelosanterioresexperimentosyesqueelusodelrecolectorde

basuraesmáscomúnqueenlosanterioresperoconunatendenciaacrecersegúnla

ecuacióndey=987.58x+1E7,peroenelcasodelosclienteselllamadodelrecolectorde

basuraesmenosfrecuentequeenanterioresexperimentosyadiferenciadelosanteriores

lamemoriarequeridatiendeabajarporlatendenciay=-1494.9x+2E7.Porotraparte,el

análisisderedhamostradoqueelnúmerodepaquetesenviadosporsegundoesmayorque

enlosanteriorespuesestádadoporlatendenciadey=0.2259x+589.62,ademásdequeel

38.63%depaqueteshantenidountamañodeentre1280a2559bytes,representandola

mayoríadeinformaciónintercambiadaenelsistema

36

Figura 11:Uso del CPU vs Intervalos de tiempo del servidor con múltiples clientes en LAN

Figura 12: Uso del CPU de clientes conectados en LAN a un mismo servidor.

37

Figura 13: Uso de memoria en el tiempo para el servidor con múltiples clientes en LAN.

Figura 14: Uso de memoria en el tiempo para los clientes conectados en LAN.

38

Figura 15: Número de paquetes enviados en un segundo para la conexión de clientes y servidor en LAN.

Figura 16: Porcentaje de paquetes enviados según su tamaño entre clientes y servidor.

39

Conclusionesdelanálisis

Comoconclusionesdeestosexperimentossepuededecirqueelsistematantoel

servidorcomoelclientesiguenunaecuacióncasiconstanteparatodosloscasos,conuna

estabilidadluegodelintervalonúmero200.

Enelcasodelamemoriausadaporelprocesodeservidorsehaencontradouna

diferenciapronunciadaentremáximosymínimoslocalesdehasta1.12Mb,perode1.5MB

paraelservidordemultijugadorenLAN.Estecomportamientodegenerarpicosdememoria

constantementedeunamaneraperiódicasedebealusodelRecolectordeBasuradeJava

quealusarestrategiasdeeliminaciónnormalyeliminaciónconcompresiónpermitequelos

objetosquenosehanusadodespuésdeciertotiemposeeliminenparadarprioridadalos

másjóvenes(Oracle,n.d.).Estecomportamientodelrecolectordebasurapuedeser

justificadoporqueelservidorrefrescalosobjetosdejuegoquemandanlosclientespor

actualizacionesdelmanejadordeeventos,loquesignificaqueelmapaqueseencargade

mantenerlosobjetosdejuegovaaestarcambiandoreferenciasdeobjetospornuevos

actualizadoscadaqueunclientehagaunaconexión,ademásqueelprocesodeintercambio,

lecturayescritura,requierelacreacióndeunSocketChannelydeunobjetodeflujode

entradaosalidadedatosquesólovanaserusadosunasolavezcuandolosclientes

requieran.

Enelanálisisdelamemoriaparalosclientessemostróunatendenciacreciente,al

igualqueelservidor,perocondiferenciaentrepicosde0.65Mbloquemuestraun

comportamientodeliberacióndememoriamenosagresivoqueenelservidor,ademáscon

unmínimode9Mbusadosparatodalavidadelprocesoyunmáximode26Mb.La

explicaciónparaestecomportamientoperiódicoesdebidoalrecolectordebasuradeJava

queesllamadocadaquelapantallaserefresca,puesProcessing,ensuPApplet,vaa

40

dibujaryausarnuevosobjetos,enestecasocuadrados,parapoblardenuevoallienzoque

serefrescaenellazoprincipal,dadoporlafuncióndraw(Reas,2007).Sinembargo,enel

experimentodemultijugadoresenLAN,lamemoriadelosclienteshapresentadouna

tendenciaadisminuirelusodemásmemoria,estopuedeserelresultadodequeel

recolectordebasurausaestrategiasdecomprensiónenvezdeeliminacióndirectapara

mantenerlosobjetosqueseactualizanenlosclientes,puessóloesunoelquerepresentaal

jugadorenelmapadejuego.

LasconclusionesobtenidasdelanálisisdelusodelCPUmuestranqueambos

procesos,elclienteyelservidor,tiendenatenerunusocasiconstantedelCPU.Paraelcaso

delservidorparatodaslaspruebas,exceptolademúltiplesclientesenLAN,seobtuvouna

tendenciadeusodelCPUde4%,yenlosclientesunusodelprocesadoraproximadaal13%.

EnelcasodelusodelCPUenLANconmúltiplesclienteselusosubióa6.4%queesmayor

quelasanteriorespruebas,locualesesperadoporqueelservidortendríaqueocuparsede

máspeticionesporelnúmerodeclientesyserviracadaunosegúnsuordenenelselector.

Sinembargo,algoquecompartentodoslosexperimentosesunincrementodelusodeCPU

enlosprimeros200intervalosqueesdondesecreanyseinstancianlamayoríadeobjetos

quelosprocesoshandeusar,comoenelclientequeseinicianlosobjetosdejuegoy

propiedadesdeProcessingenelmétodosetup.

41

42

CONCLUSIONES

Sibienelpresentetrabajohadescritoelfuncionamientoydiseñodevariossistemasparala

organización y combinación de estos en un motor de juegos, también ha mostrado el

comportamiento de recursos que el motor ha de requerir en una computadora. Las

integracionesdetodoslossistemassonimportantesporelhechodequeunjuegorequiere

interacción entre el jugador y el mundo del juego, y estos sistemas ayudan a que esto

suceda.

Para que un jugador pueda mover a su personaje a través de la pantalla necesita

comunicarseal juegopormediodel teclado.Paraqueel sistemaentiendaqueelusuario

quieremoveralobjeto,esterecibeeventosquesetransmitenalservidor,dondeelsistema

guarda la lógica y que a su vez dicte lo que va a pasar a continuación con el objeto si

interactúaconotrosenelmundodel juego.Paraque losobjetos interactúenoactúende

ciertamanera en elmundo han de tener componentes que son dados por elmodelo de

objetos.Sinembargo,comolaarquitecturaesdeltipocliente-servidor,lapartedelalógica

y actualización de componentes se encuentra en el servidor, por lo que los eventos

generadosporelusuariohandeserenviadoporredhaciaelservidor.Esteenvíoesposible

por el uso del sistemade red paramúltiples jugadores que usa canales para representar

conexionesyselectorespararesolverel tipodeoperacionesquesenecesitan(escriturao

lectura).

Sinembargo,elsistematambiénhasidoprobadoparadefinirlosrequerimientosdered,de

procesamientoydememorialoquehamostradouncomportamientopeculiar.Eltamañoy

número de paquetes enviadosmuestran un comportamiento optimo pues lamayoría de

paquetessonenpromediode2KBy270paquetesenviadosenunsegundoporelsistema

43

loquenocongestionalarednicausaproblemasdelatenciaenelsistema.Sinembargo,el

usodelamemoriahaproducidouncomportamientodeusoyliberaciónperiódicoqueno

sehapodidoatribuira lascausascomunesde liberacióndememoriapor recolectoresde

basura de Java. Así mismo, para procesos separados semostró que los clientes siempre

tienenunusodeprocesadormásaltoqueeldel servidor,13%y4% respectivamente. Lo

quehacesuponerquelaejecucióndelclienteconsumemásrecursosqueladelsistemaen

generalporelusodeProcessingenelcliente.

Por otra parte, el sistema aquí descrito puedemejorarse para poder competir con otros

motoresdejuegoscomerciales.Porhaberseconcebidocomosistemaextensible,elmotor

de juegos puede mejorar sus capacidades de programación de escenarios, personajes y

efectos al aumentar componentes al modelo de objetos. Además, para mejorar la

experienciadeusuariosconectadossepodríadepurarelsistemaparaservidoreslejanos.Sin

embargo,dichoscambiospodríanrequerirmásrecursoshumanosytécnicos.

Porúltimo,eldesarrollodeestetrabajoesperaatraer laatencióndenuevos ingenierosal

campo del desarrollo de videojuegos. De acuerdo con la página de Gamedevmap, una

página de en el Ecuador sólo existen dos empresas de videojuegos. Es por esto que los

conocimientos aquí expuestos puedan ser expuestos más abiertamente en el país y así

mejorarlariquezadeprofesionalesenelárea.

44

REFERENCIASBIBLIOGRÁFICAS

Reas,C.(2007).ProcessingAprogrammingHandbookforVisualDesignersandArtists.Cambridge:MITPress.

DeLoura,M.A.(2001).GameProgrammingGems2(Vol.2).Hingham,Massachusetts,USA:

CharlesRiverMedicaINC.Hasiotis,N.(2015,Noviembre27).JavaNioSocketExample.RetrievedAbril6,2017,from

JavaCodeGeeks:https://examples.javacodegeeks.com/core-java/nio/java-nio-socket-example/

Cairó,O.(2006).EstructuradeDatos(3ed.).México:McGrawHill.Gregory,J.(2014).GameEngineArchitecture(2nded.).CRC.PaulDeitel.(2015).JavaHowtoprogram(10ed.).Pearson.Silberschtz,G.G.(2012).OperatingSystemConcepts(8ed.).USA:JohnWiley&SongsINC.Sommerville,I.(2000).SoftwareEngineering(6thed.).England:AdisonWesley.Tanenbaum.(2011).ComputerNetworks(5ed.).USA:PrenticeHall.Oracle.(2016).Selector(JavaPlatformSE7).Retrieved0211,2017,fromJava™Platform,

StandardEdition7APISpecification:https://docs.oracle.com/javase/7/docs/api/java/nio/channels/Selector.html

Oracle.(n.d.).JavaGarbageCollectionBasics.Retrieved0327,2017,fromOracle:

http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html

Oracle.(2016).PriorityBlockingQueue.RetrievedAbril19,2017,fromJavaSE7:

https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/PriorityBlockingQueue.html

Roberts,D.(2015,0915).ObjectCentricModels.GameEngineFoundations.Raleigh,NC,

USA.Unity.(2017,Marzo29).UnityManual.RetrievedAbril18,2017,fromUnity3D:

https://docs.unity3d.com/Manual/index.html?_ga=1.52214889.1336573092.1492525367

R.P.,&B.M.(2015).SoftwareEngineeringAPractitioner'sapproach(edición8ed.).

McGrawHill.

45

Schell.(2008).TheArtofGameDesignABookforLenses.MorganKaufman.Bithell.(2012,Junio30).mikebithellgames.RetrievedAbril18,2017,fromThomaswas

alone:http://www.mikebithellgames.com/thomaswasalone/Weiss,M.A.(2012).DataStructuresandAlgorithmAnalysisinJava.Pearson.Giancoli.(2008).Físicaparacienciaseingeniería.Pearson.Processing.(n.d.).RetrievedAbril20,2017,fromProcessing:https://processing.orgGamedevmap.(2017,Abril24).RetrievedMayo1,2017,fromGamedevmap:

https://www.gamedevmap.com/index.php?country=Ecuador&state=&city=&query=&type=

46