[DUDA] que tipo de juegos podremos crear,online?

[SimulatorOne]

Hola

esto es una duda, que me pregunto muchas veces, acerca del futuro modulo online de gemix.

pero son preguntas que siempre me echo, como curiosidad y como futuro planteamiento para el proyecto actual.

La pregunta del millon es: Que tipo de juegos, podremos crear online?
o que tipo de proyectos o aplicaciones podremos haceer online?


-Que tipo de online podemos crear?

Yo no entiendo mucho de esto(por falta de experencia)
pero conozco lo mas basico:

Se que existe estos tipos:
-conexion por LOCAL IP (Red Local IP)

-Conexion por una RED Virtual Local IP, (Simula una conexion local entre amigos de internet, VLAN, Hamachi)
http://juegos.gratisespanol.info/como-c ... licaciones

-Servidor online, Tipo database o gestor, lo que utilizan los MMORPG...


->Otros:
-Conexion a servidor FTP (para transferencia de ficheros,actualizaciones)
-Descarga de paketes online por HTTP (Descarga directas por direcion HTTP)
-Correo eletronico (E-Mails)


no se....
Que alguien me ayude, puede que me equivoque.
pero que no sea tan tan tecnico, pero podria usar alguna aplicacion como ejemplo.

O si cictec ya sabria que tipos de juegos podremos crear online, podria dar el chivatazo, para nosotros ir ya planteando nustros futuros proyectos.

O vosotros, que tipo de proyectos teneis en mente hacerlos online.

necesito ayuda online XDDD

[necro_vampire]

falto UDP:
http://es.wikipedia.org/wiki/User_Datagram_Protocol

No deberia haber problemas para lo que se quiera hacer, creo el principal problema serian, las conexiones al server (ancho de banda, cantidad de usuarios, etc)
y la cantidad de informacion que se envian entre el cliente y el servidor...

[erkosone]

Pues por poder crear, podrás crear cualquier tipo de juego online "Standard".
Los juegos en red los puedes clasificar en dos grandes Grupos:

SINCRONOS: - Son las aplicaciónes que "necesariamente" precisan conexión al servidor, como conexión y para que se entienda, te pongo este ejemplo:

- TU no sabes hablar CHINO, pero tu traductor "red" si, entonces TU mediante la red lo que haces es llamar a la otra persona para "ENTABLAR UNA CONVERSACION", cuando tu terminas de enviar la información "te mantienes a la espera" de una respuesta, mientras tanto, el traductor habla con el tipo chino.. el tipo chino le contesta y el traductor se pone en contacto contigo nuevamente, mientrs no hay respuesta tu estas dedicando todos tus esfuerzos en estar atento a que te respondan.


ASINCRONOS: - EL servidor envia dados indiscriminadamente, sin tener en cuenta si estas o no preparado para recivirlos. Este sistema es el mas comunmente utilizado, pues tiene gran versatilidad a la hora d ehacer Streaming de gran cantidad de datos de una forma mas o menos rápida, ya que no espera a los clientes, los clientes tienen que poseer la capacidad de capturar los datos y procesarlos en tiempo real.



La gran diferencia entre estos dos grandes sistemas globales de comunicación es que el primero "SINCRONO" o comunmente llamado TCP tiene uno o varios protocolos de gestion de errores, de paquetes perdidos, comprueba si los datos son corruptos... es un sistema de muy alta "fiabilidad", el segundo "ASINCRONO" o comúnmente llamado "UDP" no necesita una conexión previa, simplemente hay que saber "donde escuchar".


El primero sirve para conexiones seguras y fiables, el segundo sirve para conexiónes que no requieren esta capacidad de seguridad, pero a cambio tienen el PRO de poder trabajar con una gran cantidad de datos ent iempo real.





En Gemix, en mi opinión, deberias usar el sistema UDP, el cual permite de una forma relativamente sencilla crear un servidor y poder comunicarse con gran numero de clientes de una forma muy sencilla.
O incluso cuando solo existe un cliente y un servidor.. es un metodo mucho mas simple que el TCP.



Como poder hacer... puedes hacer lo que quieras, siempre que te mantengas dentro de unos margenes "standard", como standard quiero decir que, juegos MMO multijugador no son standard, tienen sus propias compilaciones de librerias de red para adaptarse a su caso concreto, es muy complicado consegir performance de red de forma "GENERICA" en juegos que requiern mas de 40/50 clientes..

Así que olbidate de hacer un MMO inmenso... Eso se escapa del formato Standard.

Juegos como los propuestos en otro hilo: De cartas, de coches, de naves, plataformas... todo eso da igual.. mientras no excedas la capacidad de red "normal".


El método mas utilizado en juegos de red suele ser el de compartir una estructura de datos, en la cual los clientes tienen acceso de lectura/escritura a una pagina de la Struct y acceso de Lectura a todas las demas.


Puedes hacer lo que tu imaginación quiera, pero no te lleves a engaños, un lib de red generica no te va a servir para conectar a 100 personas en un servidor y hacerte un World of Warcraft jeje..


Espero te haya aclarado algo tio

[SimulatorOne]

si.... pero no entiendo muy bien del todo.... :/

necesito ejemplos, o de algun juego.

veamos(enseñarme):
para jugar en RED LAN normal, se llama TCP/IP ,no?
y RED LAN son ordenadores conectados por cable de red, del mismo Rango de IP (mascara de subred...)
Es decir el mismo grupo de trabajo???

1-Seria crear la partida, seria el afitrion del juego.(jugador 1 jefe)
2-Los clientes(otros ordenadores de la misma RED) Buscan y se unen en la partida del afitrion(Jugador 1 jefe)

Pregunta, cuandos jugadores se pueden conectar?? depende de la LAN??
8,16....?¿?¿

Hamachi te crea una RED LAN virtual, que otros usuarios de Hamachi se pueden unir a esta RED Virtual creada por mi(por ejemplo)
tiene un chat y una gestion de nombre de la RED Virtual...

yo con esa RED virtual puedo usarlo para los juegos que usen TCP/IP???
Serviria tambien para lel futuro Gemix online??


Yo personalmente no me interesa tener un PC haciendo de Server conectado 24Horas a internet con ADSL de alta velocidad.
para un juego :/

Yo busco algo mas sencillo
y creo que con esas red privadas de Hamachi creo que es lo que busco.

no se, necesito una ayuda para plantearmelo para mi proyecto.
no pretendo que sea un MMORPG de esos.
Pero algo mas tipico online que muchos juegos tienen.

y vosotros que teneis en mente?para vuestros proyectos?

[erkosone]

Pues mira, esto mas o menos funciona de esta manera:

TCP/IP: En verdad son la unión de dos protocolos de red, el TCP que gestiona las diferentes vias o caminos de la información dentro de un mismo adaptador de red hacia todos los programas mediante PUERTOS.

Y el IP, que basicamente encapsula todo el paquete de información de ese adaptador de red en un paquete mas grande que sirve para identificarte como una ENTIDAD = IP concreta.

Entonces ya sabemos que el protocolo TCP/IP en verdad son dos, el TCP que es la capa que gestiona ( APLICACIONES <> ADAPTADOR_DE_RED ) y el otro que es el IP que gestiona todos estos paquetes en otra capa superior, donde se encapsula todo lo que hace el TCP en un paquete que lleva tu "firma" osea.. tu IP para identificarte en la red.


Independientemente de todo esto que es a bajo nivel y no interesa para nada.. Existe una alternativa a PROTCOLO TCP, recuerda que el TCP es el que utiliza "n" puertos para "n" aplicaciones, como por ejemplo:

Telnet - Puerto 23.
Ftp - Puerto 21.



Esto son claros ejemplos de conexiones TCP, pues el FTP por ejemplo sirve para descargar/cargar archivos, y necesitas usar un proto que tenga control de errores y verificación de paquetes corruptos.
Esto como es normal.. resta una prociosa velocidad a la red y a la aplicación.. pues necesitas utilizar una parte del ancho de banda para toda la gestion de errores. Pero es un proto muy seguro y fiable.

Por ejemplo, para tener la necesidad de utilizar el protocolo TCP, tu juego tendria que tener alguna caracteristica que requiera la verificación 100% exaustiva de errores en la información.
Este protocolo es BLOQUEANTE, lo cual seguro que se habla de ello muchas veces.. y suena hasta mistico.. pero es muy facil de entender...

Mira para utilizar TCP sobre IP, osea, lo que hace un MSN messenger al enviar files, un ftp.. una conexión de terminal remoto.. necesitas usar "n" puertos, y como ya he dicho, al tener TCP tienes verificación de errores, ya depende de la aplicación y lo integrada que este a bajo nivel con el proto y la lib de red, pero basicamente al usar TCP tienes que ser muy cuidadoso, y al enviar una información por la red hacia un "DESTINO CONCRETO" tienes que "BLOQUEAR" el socket que has utilizado... para que el programa no se vuelva loco e intente recivir inmediatamente la respuesta.. entonces, cuando tu interlocutor, te contesta que ya está preparado para enviar, "TU" has de desbloquear el socket.. y asi le dices a la lib de red, que la info viene "YA".

Como ves... es super engorroso de programar a bajo nivel con TCP... Es el proto que tiene una fiabilidad mas alta.. pero es un autentico calbario para un principiante meterle mano a esto directamente.

NO TE LO ACONSEJO BAJO NINGUNA CIRCUNSTANCIA QUE EMPIECES CON "TCP".

---------------------------------------


El otro sistema se llama UDP... este es la salvación para todos los que no vamos a hacer aplicaciones hyper complejas y seguras, es diseñado para otro tipo muy diferente de conexión que te detallo ahora mismo mira:


UDP: Conexión ASINCRONA, aunque pueda parecer muy raro esto... es muy facil y es "GENIAL" para programar juegos concretamente.

Las conexiones UDP bajo IP son muchisimo mas sencillas que las TCP de gestionar...

La IDEA o el CONCEPTO de porqué fue creado este sistema diferente es muy simple mira, por TCP dijimos que la conexión es ultra segura, con control de errores... necesitas bloquear sockets en muchisimos casos..
Vamos un autentico coñazo...
Con UDP esto es muy diferente, realmente no existe conexión.

SIP!, no te conectas a ningún sitio... y tu diras... como leches recibo y envio info??

Pues muy facil, este sistema se creó en su dia para todos los softwares que necesitas enviar GRAN CANTIDAD DE INFO POR LA RED, como es normal... un juego multijugador es un caso estupendo para esto.. pues cada decimas de segundo las variables cambiand e valor y necesitas de un sistema de STREAMING.

STREAMING trabajo de esta forma: El servidor simplemente pasa de los clientes... sencillamente y para que lo entiendas.. el server se pone a enviar información como un poseso... a toda leche... ignorando si te ha llegado a ti o no, es mas, se la suda... si no te llega te jod.. jejej

Este sistema es genial para juegos en red, pues lo bueno que tiene es que el server está enviando a todo trapo información sobre toda la estructura de variables que comparte.. independientemente de si te han lelgado, si te han llegado bien... si se han corrompido por el camino por culpa de una interferencia...

Entoces, este sistema puede parecer muy poco fiable, si, y es cierto, pero para enviar una información a mas de 10 destinos... directamente la lanza a la red.. encapsulada con su "IP" claro.. y los clientes son como los cazamoscas.. cuando ven un paquete de este server, simplemente lo procesan y sacan sus conclusiones.

Nunca jugaste a un juego en red multijugador "MASIVO" y viste a un personaje en un sitio y al segundo siguiente estava 10 metros mas atras? U D P tiene la culpa.

-----------------------------------------


Entonces para Gemix, UDP es genial, el server hace Streaming como si estuviera emitiendo una pelicula... o como si fuera un canal de radio online... y tu simplemente le mandas un pauqete diciendo OYE!!! que estoy aki!

Y se lo mandas si te da la gana.. sino ni hace falta.. simplemente te pones a capturar la informacion de ese servidor y ya estas online con el, si quieres comunicarte tu hacia el pues entonces lo normal es que le avises.


Como ves, TCP y UDP son diferentes protocolos de red, que gestionan la información de maneras muy distintas, una es con control CRC y la otra es asi a saco.

Cada una tiene sus pros y sus contras.

Pero está claro que Gemix va a rendir infinito mas con UDP... Porlomenos para el sistema compatible con Div2, ya despues si se mete a bajo nivel la implementación de la libreria de red pues genial tambien.




Y respondiendo a tu pregunta, NO, no tiene que ser un server dedicado y lo demas todo clientes, puedes hacer que el que crea la partida tambien entre a jugar como cliente, es mas, el motodo normal de hacerlo es este:



Arranco el juego, si existen partidas ya las listo e indico si quiero conectarme a alguna de ellas.
Si no existen partidas activas, la creo yo y entro como cliente.

Como ves, el mismo programa puede hacer de Server/cliente al mismo tiempo.




Todo el toston de antes iva por si quieres saber conceptos ya mas avanzados que no se suelen explicar así yanamente. Espero te aya aclarado algo mas el tema. Cualquier duda ya sabes tio

[SimulatorOne]

jopeee, eres muy muy tecnico!! xDD

yo no se tan tan profundo sobre redes.

si mirandolo bien, como tu dices, parece que el sistema UDP es lo mejor que hay
http://es.wikipedia.org/wiki/User_Datagram_Protocol

supongo que los juegos mas modernos usaran este sistema para jugar online.

Para mi proyecto no tengo pensado crear un servidor, ni menos de pago.
prefiero algo mas sencillo como una VLAN que crea hamachi

una pregunta, no se si tu lo has usado o no.

Existen 2 versiones del hamachi.
esta el viejo 1.xx
y el moderno 2.xx
yo de momento uso el 2.xx
pero de momento aun no echo la prueba real con algun juego.

pero parece bastante sencillo, para aquellos que te piden IP para unirse a jugar...

[necro_vampire]

UDP, no soporta reenvio de paquetes...
se usa mas para streaming y aplicaciones en tiempo real...
No es lo mejor para el caso de los juegos...

[erkosone]

UDP por poner ejemplos:

- OpenArena.
- Quake 3 Arena.

- Son juegos donde no es necesario una preción exacta, ademas, de que la seguridad en el envio de paquetes no es algo primordial.


Tcp + UDP


Todos los juegos de PS3 por ejemplo, autentificación por TCP+encriptación y control CRC.
Y todo el flujo de información del juego "posicion de los players", "disparos", etc etc etc UDP puro y duro, ejemplos:


PlayStation Network:

TCP: 80, 443, 5223
UDP: 3478, 3479, 3658


Juegos:

+ BurnOut Paradise:

TCP: 21800 - 21899
UDP: 3659, 6000, 9565, 9579

+ Call of Duty 3:

TCP: 3074
UDP: 3074

+ Call of Duty 4 *por confirmar:

TCP: 80, 443, 5223
UDP: 3074, 3075, 3478, 3658

+ FIFA 08:

TCP: 20400-20499, 9980-9989
UDP: 3659, 6000, 9570.

+ Gran Turismo 5 Prologue

TCP: 80, 443, 5223
UDP: 3478, 3479, 3658, 10070, 50100


+ MotorStorm:

UDP: 3659, 3660

+ NBA 2K8:

UDP: 4658

+ Pro Evolution Soccer 2008:

TCP: 14020 y del 8800 al 8899
UDP: 5730 - 5739

+ Resistance: Fall of Man:

UDP: 6505, 6999

+ Warhawk:

TPC: 53346
UDP: 6000, 6499, 10029



Como ves, el UDP se usa mucho, cuando hace falta velocidad.. un juego multiplayer... por TCP.... olvidate... weno.. si son unos pocos players si, es sencillo.. sino.... hace falta un mega servidor, lib´s especialmente desarroyadas para ese trabajo concreto y es un desperdicio brutal de velocidad entre Cliente server..

UDP para gran cantidad de datos se usa comercialmente desde SIEMPRE, y se segirá usando asta que salga algo mejor apra una transferencia de alto rendimiento.
TCP se usa unicamente cuando se envia información muy concreta, o por ejemplo, para funciones "muy concretas" en juegos. Para nada mas.




Todos los programas de chat por voz multi cliente como Ventrilo, TeamSpeak ect.. todos usan UDP, siendo TCP una opción con muy poco performance y sobrecarga muy a tener en cuenta en los servidores.



Vamos que no me lo invento yo.. los datos estan ahi.. TCP hay que usarlo para lo que se creó, para transferir archivos o cosas similares, para todo lo demas, con UDP.

[necro_vampire]

Pero esos juegos usan TCP y UDP en simultaneo, no solo UDP...

[erkosone]

Y para que quieres TCP en un juego de Gemix?