Hola,
Como parte del curso de udemy que estoy preparando voy a crear un juego tipo hearthstone, me planteo si es interesante el hacer stream publico, o si es un juego demasiado de nicho y programar algo asi no tiene interes.
¿Opiniones?
eres instructor en udemy?
parece bien para enseñar lo basico de programacion, UI y tweening
No soy instructor en udemy (aun), pero me dijeron que ningun problema por crear un curso y ponerlo a la venta alli... Obviamente para llegar a mas gente lo hare en ingles, y porque en este sector debes saber ingles tanto como programar o arte asi que...
Anyways, es un juego MUY complicado de hacer y tiene mucha programacion para ver, no se si no es demasiado nicho y un tipo de juego poco atractivo para aprender con él, por eso quiero ver que tipo de interes puede tener algo asi. Porque si voy a duplicar trabajo para hacer unos streams en castellano es porque haya publico interesado.
pues si quieres ser po***r di q vas a hacer un GTA o un Fortnite vas a tener mas gamers interesados...
si es solo para aprender a programar no tiene sentido hacer TODO el juego, terminaras mostrando algunos fragmentos y regalando el resto del codigo... ningun programador legitimo quiere estudiar linea x linea, lo q uno quiere es aprender "los trucos" y aplicarlos a un proyecto propio... un programador ambicioso va a querer el codigo para reskinearlo y publicarlo, no le interesa lo q expliques
ademas un juego como ese es MUCHO mas q programacion, la programacion es solo la implementacion de una gran cantidad de decisiones de diseño, sin la explicacion de esas decisiones seria un desperdicio
Buen punto, justo lo que pensaba :)
Totalmente de acuerdo. Como mucho, te aconsejaría que te ganaras algo de Comunidad extra haciendo alguna live session en streaming, de vez en cuando, a medida que avanazas con su desarrollo.
Pero ponerte a compartir todo el proyecto? Ni de coña, es demasiado ambicioso y perjudicará a muchos usuarios noveles...
Avísame cuando tengas el Udemy/Patreon, que me apuntaré esa cuenta...
Cita de: Eskema date=1524749988Hola,
Como parte del curso de udemy que estoy preparando voy a crear un juego tipo hearthstone, me planteo si es interesante el hacer stream publico, o si es un juego demasiado de nicho y programar algo asi no tiene interes.
¿Opiniones?
Me urge una duda -
Vas a crear todo el juego desde la parte servidor al cliente. Si es así, el servidor va a ser dedicado ("Similar a Hearthstone con su Network Blizzard") -
¿Como vas a gestionar las Cartas? << ---
¿Como vas a gestionar la tienda? << ---
Estoy desarrollando un TCG bastante grande, y tuve que plantearme cada paso, pero una de las cosas que más me costó definir es el de las cartas, por ahora ya tengo todo un sistema armado y funcionando. Mi problema puntual era la información de las cartas. Lo que tengo por ahora me permite cargar las cartas en el Servidor y luego crear un paquete de actualización para que el cliente las descargue esto cubrirá la inclusión de nuevas cartas u otro contenido, al mismo tiempo me permite obtener la información para la lógica del servidor.
Este tipos de proyecto son bastante interesantes, tienen sus trucos, me gustaría que el proyecto que estoy desarrollando sea tan simple como Hearthstone, pero al contrario es bastante más complejo, tiene un gameplay bastante complicado -
Si haces algo al respecto me apunto para "Robar" algunas ideas :)....
Cita de: francoe1 date=1524923574Me urge una duda -
Vas a crear todo el juego desde la parte servidor al cliente. Si es así, el servidor va a ser dedicado ("Similar a Hearthstone con su Network Blizzard") -
¿Como vas a gestionar las Cartas? << ---
¿Como vas a gestionar la tienda? << ---
Estoy desarrollando un TCG bastante grande, y tuve que plantearme cada paso, pero una de las cosas que más me costó definir es el de las cartas, por ahora ya tengo todo un sistema armado y funcionando. Mi problema puntual era la información de las cartas. Lo que tengo por ahora me permite cargar las cartas en el Servidor y luego crear un paquete de actualización para que el cliente las descargue esto cubrirá la inclusión de nuevas cartas u otro contenido, al mismo tiempo me permite obtener la información para la lógica del servidor.
Este tipos de proyecto son bastante interesantes, tienen sus trucos, me gustaría que el proyecto que estoy desarrollando sea tan simple como Hearthstone, pero al contrario es bastante más complejo, tiene un gameplay bastante complicado -
Si haces algo al respecto me apunto para "Robar" algunas ideas :)....
Por razones "obvias" no, no voy a currarme el server. Primero y principal porque no tengo ni idea xD, no soy programador de backend. Yo solo estoy creando el proyecto simulando que las cartas se bajan de un server y tal, y lo mismo al jugarlas. Crear un server se escapa de la tematica, "un curso de unity".
En un juego asi para un cliente hicimos eso, al abrir el juego entrabas con tu cuenta y te bajas el mazo de nuestro server seguro, luego al jugar online contra alguien, tu no sabes que cartas tiene el otro, solo sabes de su carta en el momento de jugarla cuando la recibes online, sea via photon u otro servicio. En nuestro caso no habia logica online, con la conexion cifrada ya era bastante para evitar "pesados" y curiosos. Y poco mas a nivel "online"
pues justamente a mi me interesaria un tutorial de network.... servers y tal...
Cita de: Igor date=1524997582pues justamente a mi me interesaria un tutorial de network.... servers y tal...
PAGA por un curso, o aprende de otros tutoriales que hay por Internet y Youtube...
Cita de: Eskema date=1524987440Por razones "obvias" no, no voy a currarme el server. Primero y principal porque no tengo ni idea xD, no soy programador de backend. Yo solo estoy creando el proyecto simulando que las cartas se bajan de un server y tal, y lo mismo al jugarlas. Crear un server se escapa de la tematica, "un curso de unity".
En un juego asi para un cliente hicimos eso, al abrir el juego entrabas con tu cuenta y te bajas el mazo de nuestro server seguro, luego al jugar online contra alguien, tu no sabes que cartas tiene el otro, solo sabes de su carta en el momento de jugarla cuando la recibes online, sea via photon u otro servicio. En nuestro caso no habia logica online, con la conexion cifrada ya era bastante para evitar "pesados" y curiosos. Y poco mas a nivel "online"
Ha, entiendo...
- Suerte entonces - Yo estoy especializandome en Networking desde hace varios años, tanto en la programación como en lo relacionado, ya tengo los cursos de CCNA(CISCO) realizado más una gran variedad de VMWare relacionados a la red, aparte de que tambien tengo estudios en virtualización -
Tuve la oportunidad de ver cómo se estructuran los servicios de Blizzard, por eso lo comentaba arriba, y me parecía algo loco un proyecto así para un Tutorial, pero bueno, tenia la loca idea de que ibas a programar el Backend + Front <--- El trabajo que vengo realizando yo desde hace bastante tiempo, tratando siempre de seguir las normas que requieren hoy en dia tener dichos servicios.
¡Networking! - @Igor, es un tema bastante complejo, pero una vez entiendes las bases todo se facilita bastante, pero debes aprender desde lo más básico, aún si vas a utilizar servicios como Photon, te recomiendo aprender Sockets, crear tus propias "librerías" de Network Game basadas en TCP y luego cuando ya entiendes un poco te pasas a UDP para dar el salto a la gloria, una vez domines UDP el resto es cuestión de prueba y error, te vas a encontrar con preguntas como ¿Esto es lo mas optimo?, y luego ya pasas a cosas un poco más complejas como la multiplataforma, la compatibilidad con IPv6, NAT, Ataques DoS, Encriptación, Protección de Datos, Programación en Capas, vas a descubrir rápidamente la programación TDD <<< --- UNA VERDADERA JOYA para el debug.
En fin, me interesaba esa parte para compartir un poco de conocimiento.
@pioj Por qué no crear un sección "Networking" entonces vamos aportando dudas o material :)
Cita de: francoe1 date=1525062592Ha, entiendo...
- Suerte entonces - Yo estoy especializandome en Networking desde hace varios años, tanto en la programación como en lo relacionado, ya tengo los cursos de CCNA(CISCO) realizado más una gran variedad de VMWare relacionados a la red, aparte de que tambien tengo estudios en virtualización -
Tuve la oportunidad de ver cómo se estructuran los servicios de Blizzard, por eso lo comentaba arriba, y me parecía algo loco un proyecto así para un Tutorial, pero bueno, tenia la loca idea de que ibas a programar el Backend + Front <--- El trabajo que vengo realizando yo desde hace bastante tiempo, tratando siempre de seguir las normas que requieren hoy en dia tener dichos servicios.
Nunca he sido programador de backend, bastante tenemos los programadores de juegos con hacer un juego como para meternos en ese tipo de marrones xD. Mas alla de programar el multijugador con sockets/photon/loquesea, nunca he hecho nada de networking por la parte server. Y no es un area que me llame, demasiado nos especializamos en este sector como para querer abarcar tantas areas :/
Cita de: Eskema date=1525069139Nunca he sido programador de backend, bastante tenemos los programadores de juegos con hacer un juego como para meternos en ese tipo de marrones xD. Mas alla de programar el multijugador con sockets/photon/loquesea, nunca he hecho nada de networking por la parte server. Y no es un area que me llame, demasiado nos especializamos en este sector como para querer abarcar tantas areas :/
Pero entonces, ¿los recursos de un Backend son consumidos mediante el protocolo de conexión establecido?, WebRequest, Sockets, Etc? Por la experiencia que tengo, el backend se desarrolla antes que el Front o en su defecto en paralelo, pero, ¿como controlas las sesiones?, ¿La lógica del juego? - O simplemente creas la plantilla con las características requeridas y luego el "Contratista" se encarga de transportar el proyecto a una capa Networking.
Siendo WebRequest - Sockets - o cualquier otro tipo de transporte existen métodos de validación, encriptación, creo son parte importante del FrontEnd para el "Debug" - ¿Como logras crear los test?
Me gustaria saber, obvio si no es molestia de tu parte contestar :) -
Estuve viendo el video de los Timers, no pude llegar a estar en el streaming, me gusta la implementación y la abstracción, algunas cosas me sirvieron como idea, el "Pool" si tiene un tamaño asignado desde el inicio ¿Porque lo trabajas con una lista?, se me ocurre que podrias utilizar un arreglo, trabajar con "unsafe" y "fixed" para optimizar el recorrido del bucle en un 100% por otro lado, cuando reciclas un objeto del pool podrias guardar el índice un una variable, entonces la próxima vez que requieras un objeto puedes evitar recorrer parte de las lista, estos "tips" mejorarán en un 100% el tiempo en los timers - Es solo como un aporte. Como tu lo dijiste mil veces, para gustos colores :) -
Cita de: francoe1 date=1525075318Pero entonces, ¿los recursos de un Backend son consumidos mediante el protocolo de conexión establecido?, WebRequest, Sockets, Etc? Por la experiencia que tengo, el backend se desarrolla antes que el Front o en su defecto en paralelo, pero, ¿como controlas las sesiones?, ¿La lógica del juego? - O simplemente creas la plantilla con las características requeridas y luego el "Contratista" se encarga de transportar el proyecto a una capa Networking.
Siendo WebRequest - Sockets - o cualquier otro tipo de transporte existen métodos de validación, encriptación, creo son parte importante del FrontEnd para el "Debug" - ¿Como logras crear los test?
Me gustaria saber, obvio si no es molestia de tu parte contestar :) -
Estuve viendo el video de los Timers, no pude llegar a estar en el streaming, me gusta la implementación y la abstracción, algunas cosas me sirvieron como idea, el "Pool" si tiene un tamaño asignado desde el inicio ¿Porque lo trabajas con una lista?, se me ocurre que podrias utilizar un arreglo, trabajar con "unsafe" y "fixed" para optimizar el recorrido del bucle en un 100% por otro lado, cuando reciclas un objeto del pool podrias guardar el índice un una variable, entonces la próxima vez que requieras un objeto puedes evitar recorrer parte de las lista, estos "tips" mejorarán en un 100% el tiempo en los timers - Es solo como un aporte. Como tu lo dijiste mil veces, para gustos colores :) -
En el caso que me ocupa, y el "hearthstone" que cree en una empresa en la que estuve trabajando funcionaba de la siguiente forma.
-el jugador entra en el juego, se conecta al server y nos bajamos su json con sus datos, su mazo de cartas, etc, etc.
-cuando se inicia una partida online, se llama a nuestro server para decirle que "manolito" quiere jugar online, se espera a que alguien conecte (via photon) y esa segunda persona tambien ha enviado al server el tipico "hola soy pepe y quiero jugar".
-una vez encontrados y matcheados via photon, ambos le envian al server nuestro el "ok estamos listos para jugar", y arrancamos la partida
-cada cliente se encarga DE TODO, el juego transcurre a nivel local y el server solo se usa para lanzar cartas.
-cuando el player 1 lanza una carta, se la envia a nuestro server, si la carta es ok (coincide, no se ha trucado, etc), entonces se le envia la carta jugada al player 2 via photon
-player 2 la recibe y replica la jugada de player 1. (por supuesto alguien podria interceptar el paquete y poner otra carta en juego, no se valida aqui nada)
Tal cual, sin mas seguridad ni nada, ¿que se puede hacer de otra forma?, pues seguramente habra mil formas mejores, pero creemos que con este nivel de seguridad era bastante para quitarnos de encima a los scriptkids, porque esta claro que a un hacker con ganas no lo vas a parar....
Respecto a los timers, tengo un id que recorre la lista, de forma que no recorro toda la lista siempre, el "for" empieza en la ultima posicion asignada. La ganancia es minima como suele pasar pero algo es algo.
¿Por qué una lista?, ¿y por qué no?, quiero decir, ¿que otra estructura gastarias?, ¿un diccionario?, ¿una queue?. No vi ninguna estructura que me fuera mas rapida para como lo tengo montado (de estructuras "nuevas", el array no lo discuto).
Podria ser un array de toda la vida que es mas optimo que una lista y si un dia tengo ganas probablemente lo cambie a array. Los arrays son mas rapidos que las listas y al fin y al cabo es una lista "estatica", una vez creada no se modifica, solo se recorre y se actualizan los timers activos, no se añade nada ni se modifica nada. Dado que la lista es fija y no cambia no hay motivo para usar la lista, aparte claro de una cuestion de comodidad y vagancia xD
Cita de: Eskema date=1525081920
En el caso que me ocupa, y el "hearthstone" que cree en una empresa en la que estuve trabajando funcionaba de la siguiente forma.
-el jugador entra en el juego, se conecta al server y nos bajamos su json con sus datos, su mazo de cartas, etc, etc.
-cuando se inicia una partida online, se llama a nuestro server para decirle que "manolito" quiere jugar online, se espera a que alguien conecte (via photon) y esa segunda persona tambien ha enviado al server el tipico "hola soy pepe y quiero jugar".
-una vez encontrados y matcheados via photon, ambos le envian al server nuestro el "ok estamos listos para jugar", y arrancamos la partida
-cada cliente se encarga DE TODO, el juego transcurre a nivel local y el server solo se usa para lanzar cartas.
-cuando el player 1 lanza una carta, se la envia a nuestro server, si la carta es ok (coincide, no se ha trucado, etc), entonces se le envia la carta jugada al player 2 via photon
-player 2 la recibe y replica la jugada de player 1. (por supuesto alguien podria interceptar el paquete y poner otra carta en juego, no se valida aqui nada)
Tal cual, sin mas seguridad ni nada, ¿que se puede hacer de otra forma?, pues seguramente habra mil formas mejores, pero creemos que con este nivel de seguridad era bastante para quitarnos de encima a los scriptkids, porque esta claro que a un hacker con ganas no lo vas a parar....
Respecto a los timers, tengo un id que recorre la lista, de forma que no recorro toda la lista siempre, el "for" empieza en la ultima posicion asignada. La ganancia es minima como suele pasar pero algo es algo.
¿Por qué una lista?, ¿y por qué no?, quiero decir, ¿que otra estructura gastarias?, ¿un diccionario?, ¿una queue?. No vi ninguna estructura que me fuera mas rapida para como lo tengo montado (de estructuras "nuevas", el array no lo discuto).
Podria ser un array de toda la vida que es mas optimo que una lista y si un dia tengo ganas probablemente lo cambie a array. Los arrays son mas rapidos que las listas y al fin y al cabo es una lista "estatica", una vez creada no se modifica, solo se recorre y se actualizan los timers activos, no se añade nada ni se modifica nada. Dado que la lista es fija y no cambia no hay motivo para usar la lista, aparte claro de una cuestion de comodidad y vagancia xD
Genial - Es similar a lo que estoy haciendo yo, la diferencia es que la lógica la mantiene el servidor, ya que no contiene ninguna propiedad 3D, no utilizo photon, creo que es un servicio que se adapta a otro tipo de juegos, ya que estamos hablando de algo basado en turnos, con muy pocos paquetes en cada partida.
Por lo demás, quizas comparta mi librería de Networking para que le peguen un OJO, está estable, y totalmente funcional es algunos proyectos, tiene algunas características que a mi gusto hacen que el desarrollo de un backend se super simple.
La tienda para comprar cartas u otros objectos¿Con que servidor lo hacen? -
La pregunta va por lo siguiente, vos inicias el juego y te conectas a un MasterServer, el master server tiene el servicio de sesión de usuarios, para realizar una compra, ¿no pasas por la sesión activa del master server?, veo que el interés por la seguridad no es un problema, pero pienso, seria muy facil de hackear si no se tiene un servicio de sesión activo. <---- hago hincapié en que en estos tipos de juegos los sobres de 5 cartas tiene un valor real U$D por lo que sería preocupante la clonación de sesione, imagino que utilizan un método de encriptación de punta a punta.
Cita de: francoe1 date=1525084532Genial - Es similar a lo que estoy haciendo yo, la diferencia es que la lógica la mantiene el servidor, ya que no contiene ninguna propiedad 3D, no utilizo photon, creo que es un servicio que se adapta a otro tipo de juegos, ya que estamos hablando de algo basado en turnos, con muy pocos paquetes en cada partida.
Por lo demás, quizas comparta mi librería de Networking para que le peguen un OJO, está estable, y totalmente funcional es algunos proyectos, tiene algunas características que a mi gusto hacen que el desarrollo de un backend se super simple.
La tienda para comprar cartas u otros objectos¿Con que servidor lo hacen? -
La pregunta va por lo siguiente, vos inicias el juego y te conectas a un MasterServer, el master server tiene el servicio de sesión de usuarios, para realizar una compra, ¿no pasas por la sesión activa del master server?, veo que el interés por la seguridad no es un problema, pero pienso, seria muy facil de hackear si no se tiene un servicio de sesión activo. <---- hago hincapié en que en estos tipos de juegos los sobres de 5 cartas tiene un valor real U$D por lo que sería preocupante la clonación de sesione, imagino que utilizan un método de encriptación de punta a punta.
La logica en el server nos la saltamos porque creemos y confiamos en el player, deberiamos poner la logica en el server pero se penso que no era necesaria esa capa porque ya hemos validado la tirada.
Validamos que el player 1 ha lanzado una carta y el server le ha dicho "carta ok, no esta trucada", entonces se la enviamos al player 2 via photon. Como decia alguien podria interceptar la llamada de photon y cambiar la carta... pero cuando el player 2 fuera a lanzar su carta (en el siguiente turno) se veria que no coincide y el juego se quedaria bloqueado/se cerraria, le explusariamos de la partida, etc.
El tema compras va por nuestro server tambien. Tu quieres comprar algo asi que vamos a la api de android o de ios (a sus sitema de IAPs) y sacamos el item y demas, Una vez comprado se valida la compra con nuestro server, en caso de fallo la compra se anula.
En nuestro caso ademas las compras NO se hacen ingame, mientras juegas no se puede comprar nada, las cartas nuevas se compran en el menu, tras acabar la partida o antes de empezarla, con lo cual con el sistema de pagos de apple/android mas la validacion del server es mas que suficiente para saber que nadie te hackea, porque para eso la llamada al server la hace el cliente logeado previamente y validado, si algo no coincide porque han intentado cambiar el token de sesion el server le dice que "una mierda que te comas".
La unica parte como digo donde "flojeamos" con la seguridad es que el player 2 cuando recibe la carta no se valida, se da por hecho que viene la carta correcta, y aunque se hackee, la tirada se ejecutara, pero como luego al lanzar la carta que sea se vera que hay una inconsistencia pues... le sacaremos de la partida y lo marcaremos en el server como tramposo xD. Osea que le damos al jugador tramposo unos segundos en los que parece que todo esta ok y se cree que nos la ha colado, para luego en su tirada sacarlo de la partida por tramposo xD.
Como digo con este sistema nos ahorramos tanto el tener que validar las cosas tantas veces, no sera el mejor ni de lejos, pero hasta la fecha hackeos hemos tenido 0, intentos muchos xD
Cita de: Eskema date=1525087308
La logica en el server nos la saltamos porque creemos y confiamos en el player, deberiamos poner la logica en el server pero se penso que no era necesaria esa capa porque ya hemos validado la tirada.
Validamos que el player 1 ha lanzado una carta y el server le ha dicho "carta ok, no esta trucada", entonces se la enviamos al player 2 via photon. Como decia alguien podria interceptar la llamada de photon y cambiar la carta... pero cuando el player 2 fuera a lanzar su carta (en el siguiente turno) se veria que no coincide y el juego se quedaria bloqueado/se cerraria, le explusariamos de la partida, etc.
El tema compras va por nuestro server tambien. Tu quieres comprar algo asi que vamos a la api de android o de ios (a sus sitema de IAPs) y sacamos el item y demas, Una vez comprado se valida la compra con nuestro server, en caso de fallo la compra se anula.
En nuestro caso ademas las compras NO se hacen ingame, mientras juegas no se puede comprar nada, las cartas nuevas se compran en el menu, tras acabar la partida o antes de empezarla, con lo cual con el sistema de pagos de apple/android mas la validacion del server es mas que suficiente para saber que nadie te hackea, porque para eso la llamada al server la hace el cliente logeado previamente y validado, si algo no coincide porque han intentado cambiar el token de sesion el server le dice que "una mierda que te comas".
La unica parte como digo donde "flojeamos" con la seguridad es que el player 2 cuando recibe la carta no se valida, se da por hecho que viene la carta correcta, y aunque se hackee, la tirada se ejecutara, pero como luego al lanzar la carta que sea se vera que hay una inconsistencia pues... le sacaremos de la partida y lo marcaremos en el server como tramposo xD. Osea que le damos al jugador tramposo unos segundos en los que parece que todo esta ok y se cree que nos la ha colado, para luego en su tirada sacarlo de la partida por tramposo xD.
Como digo con este sistema nos ahorramos tanto el tener que validar las cosas tantas veces, no sera el mejor ni de lejos, pero hasta la fecha hackeos hemos tenido 0, intentos muchos xD
Genial, quizas suena un poco "inseguro", pero viendolo desde ese punto puede que funcione y te ahorres cierto "USO" por parte del servidor, en mi caso, veo poco fiable que el jugador ejecutará la Lógica debido a algunos factores en el gameplay, pero me gusta la idea que implementaron, quizas haga unas pruebas de esa manera en otros juegos que tengo aún por desarrollar -
¿Como se llama el proyecto en el que estás trabajando actualmente?
Suena inseguro porque dejamos que el jugador se crea que nos ha hackeado en la jugada actual, cuando en la siguiente lo tiramos a la calle XD.
En nuestro caso como el heathstone hay poca logica, carta X quita X puntos de daño a carta Y, carta Y a su vez ejecuta trigger y daña a carta N y cura a carta B. Meter todo eso en el server era un poco coñazo la verdad.
Actualmente estoy en 2 proyectos personales (estoy en paro). Un top down shooter y uno de gestion de recursos