Activity
Mon
Wed
Fri
Sun
Jan
Feb
Mar
Apr
May
Jun
Jul
Aug
Sep
Oct
Nov
Dec
What is this?
Less
More

Memberships

UETC.mx - Echo GameDev Club

55 members • Free

8 contributions to UETC.mx - Echo GameDev Club
Quien está haciendo juegos para Steam?!? (Pc/Mac) Aquí? Abrazos.
“There’s a commonly used indie rule of thumb that a Steam game sells 31 units per user review. meaning that a game with 500 reviews would be expected to sell around 15,500 units. at a $20 price point, this means ~$185k in net revenue after platform fees, refunds, taxes and PPPPs” - Cristi nuestro lead de Mkt/Publishing. Como ven?!? 🤔 Pd. Inviten más gente al club bros! Porfa si pueden! Abrazo.
Quien está haciendo juegos para Steam?!? (Pc/Mac) Aquí? Abrazos.
1 like • 2d
Por ahí hay que considerar también que de un juego con reviews en los dos dígitos y cercano a 20's... es altamente probable que esos reviews sean de friends and family. Así que juegos con ese número tan bajo de reviews ni si quiera tienen los ~12,000 USD que se esperaría haya generado ese juego en ese punto.
TactiCarum - Dev Updates
El último tirón del año, logré terminar de implementar la comunicación entre nodos de servicios que ya no necesita "plomería". Esto nos permitirá simplificar la manera en la que agregamos features a los servicios de backend a futuro y aumentará nuestra velocidad de ejecución. Un ejemplo de un feature que necesita comunicación entre servicios de extremo a extremo es la de otorgar trofeos a los jugadores y guardarlo en la base de datos. Para contexto, la info tiene que viajar desde el game server donde ocurrió la partida (un extremo) hasta la base de datos (el otro extremo) y hay 3 "nodos de servicio" entre game server y base de datos. Con esta feature ya no se tiene que escribir código en esos 3 nodos sólo para pasar el mensaje; el framework lo hace automático. Ya tenemos el sistema de trofeos funcionando y también tenemos un leaderboard visible dentro del juego. Corregimos varios bugs, integramos parcialmente el nuevo "skin" de dungeon con temática de elfos, mejoramos un poco el UX/UI in-game para manejo de los héroes y los controles, refinamos los tutoriales en base al último feedback y redujimos el tamaño de los mapas para facilitar el input con los dedos en el celular, va a ser un trade-off doloroso pero necesario. Finalmente, ¡tendremos la oportunidad de mostrar todos estos avances en la ConCo en la Expo Guadalajara el día de Mañana! Estaremos en el espacio de Ingenia del Gobierno de Zapopan como parte de los estudios invitados a mostrar sus juegos ese día. Vamos a aprovechar para validar todos estos cambios y cerrar el año, espero ahora si logremos minimizar el tema de fricción en los controles a un punto aceptable para poder lanzar el juego.
2
0
TactiCarum - Dev Updates
Dungeon Sweeper- Feedback
Ayer comenzamos con el primer test de Dungeon Sweeper para PC (móvil estamos terminando la versión de iOS y Android, tuvimos una falla pero avanzamos con la versión web)https://demontrail.com/games/dungeon/ Hemos tenido muy buen feedback y ya estamos implementando algunas cosas, pero seguimos recabando más data. Los invito a que calen nuestro juego en PC.
Dungeon Sweeper- Feedback
1 like • 12d
Ya lo probé por acá también y tengo algunas observaciones. La primera no es relacionada al demo en si no mas bien a lo que le precede. Creo que es importante dar contexto de lo que está probando la persona en términos de qué lo que es (¿es un vertical slice? ¿O es un MVP? etc) sobre todo para evitar que se fijen en cosas que son irrelevantes (tengo arte o UI placeholder y lo que me importa es que me den retro del GameLoop o el Fun Factor etc). Es una excelente manera de mejorar el "signal vs noise" ratio en las retros. Todo lo que tu si sabes que vas a cambiar y que no es relevante para lo que te interesa validar es ruido, pero el tester se puede perder en el ruido porque no lo sabe. Por ejemplo el tipo de arte, mi feedback va a ser diferente si es placeholder (no hay feedback) o si es ya la idea del producto final (si hay feedback), tampoco se la "distancia" que existe entre tu visión final del juego (en cómo se debe de ver) y lo que estamos viendo ahorita, etc. Entonces, mi recomendación a la hora de presentar el demo es arrancar con algo como (asumiendo un escenario, desconozco si el demo es lo que describí o no): "Esto es un prototipo muy early de mi juego donde sólo tenemos aterrizado el core game play y parte del game loop. Tiene poco juiciness y la UI es un placeholder para poder navegar y entrar a lo que me interesa: el juego. El arte si está pensando en pixeles pero no tenemos claro el tamaño de retícula ni la paleta de colores. Por lo pronto estamos usando placeholders. Me ayudaría bastante si lo juegan y validan lo que para mi es más importante en este momento: el fun factor. ¿Es divertido el juego? Y si no, ¿cuál es la fricción que tiene para que sea divertido?" ¿Cómo se sienten los controles? etc etc. Sin todo ese contexto va a ser más probable que recibas mucho ruido de la gente que lo pruebe. Entonces, va ya sobre el juego (con todo y ruido seguramente): 1. La pantalla inicial tiene unos errores de perspectiva en las torres, tanto en los ladrillos como en la parte alta de las torres. 2. En lo individual el estilo de arte de la pantalla inicial creo que puede funcionar pero ya con la propuesta del resto de juego siento que no hace tan buen equipo. Lo veo como un estilo muy único: es ilustración con brochas de pixeles pero es tan pequeño el pixel que en un dispositivo móvil no se va a diferenciar de una ilustración intencionada. Lo complejo de eso es que quedas en un punto medio en donde no es tan fácil de identificar como pixel art, no luce como tal, pero tampoco como ilustración natural (te quedas con algo de los drawbacks de los dos mundos y se pierde fortaleza de las ventajas de los dos mundos). 3. Lancé un juego en 2020 para Android y IOS (ShootyQuest) y te puedo dar info de primera mano de cómo nos fue (spoiler alert: no muy chido). Mis dos temas fueron los controles complejos y el pixel art. No se cómo estén las cosas en 2025 (casi 2026) tal vez ya cambiaron pero si siguen igual, te invitaría como a mi me invitaron (aunque yo los ignoré desgraciadamente 😅) a darle una revisada a profundidad a ese tema para mobile. Quizá ya cambió todo y ahorita si hace sentido. Y si sí hace sentido y es la visión y camino que quieres seguir con tu juego, te comparto este recurso que es un "must have" para artistas de pixel art https://michafrar.gumroad.com/l/pixel-logic?layout=profile es realmente imperdible. Si quieres mas detalles sobre ShootyQuest mandame DM y con gusto te platico todo. 4. El core game mechanic para hacerle justicia y apreciarlo bien creo que tendría que jugarlo en el celular. Por experiencia con el juego que yo estoy haciendo, el mismo juego solo por los controles se siente muy diferente en mobile vs en PC.
1 like • 12d
@Eduardo Chaidez Creo que hay muy poca UI como para poder darte una buena opinión. Igual la pantalla de play/sweeper cumple porque solo son los dos botones que permiten la navegabilidad sin fanfarria. Como muchas cosas pueden cambiar a futuro sobre eso, ahorita no importa si están bien acomoda esa pantalla o no solo que funcione y sea clara para navegar. Lo que si pueden mejorar ya ahorita es en el contraste entre la ventana de Sweeper y el fondo. Las dos son azules y no hay un contraste fuerte que distinga entre "esto es fondo" y "esto es ventana" mas que el la diferencia de color que a mi parecer no es suficiente. El marco blanco que usan en otros elementos puede funcionar ahí. La idea de las 3 tarjetas en una sola pantalla para explicar el juego me parece adecuada por el momento (porque si se entiende a la primera con los testers en general ya se ahorraron el tutorial). Tiene poco texto y la gente no lee casi (así que bien con el mix de imagen + poco texto). Lo que si, no entendí la de los combos. No entiendo a qué se refiere. Esa parte no se si puedan explicarla mejor. Como no se qué son los combos o como se logran tampoco se cómo se podría explicar mejor. El feedback de cuando recibes daño creo que puede mejorar, si veo como que flahsea la pantalla en rojo un poco pero siento que todavía no se siente lo suficientemente bien... Como todo es rápido no es tan claro que pasó que te hizo daño, solo sabes que recibiste daño porque ya vez la pantalla roja. Sobre el concepto (fun factor) si lo veo como un time killer con potencial de que agarras el celular y lo puedes juegas mientras esperas algo. Por el formato del juego lo complejo creo que sería la parte de monetización (si es un free-to-play con ads ó va a traer paywall) por el tema de que tienen dos plataformas distintas y el perfil de jugador es distinto.
Qué pasaría si tu próxima ventaja no fuera tu juego sino tu estructura?
Daré esta platica el viernes en Ameriké, pero si quieren un dia la hacemos por aca en un miércoles o día de evento mensual y la cotorreamos! Nuevos trailers y reel del studio aqui! Inmensa presentacion por los videos pero bueno. Abrazo. Ahuuuu.. vip.jorgesuarez.com.mx Sorry lo dejo en pdf no cupo con videos :/ luego los paso. O lo convierto en curso para el tier de Biz/VIPs aqui!! Abrazo. Y.
Qué pasaría si tu próxima ventaja no fuera tu juego sino tu estructura?
1 like • 14d
Es buen tema y en lo personal estoy muy de acuerdo con el tema de la plática.
TACTICARUM - Dev Updates
Estuvimos haciendo haciendo avances en varias áreas de desarrollo para tratar de cerrar filas lo más que se pueda antes del fin de año. - Nuestro back-end se despliega en servidores de DigitalOcean y para hacer los builds & deploy de los servicios usamos GitLab (con scripts de Ansible). Un problema frecuente que teníamos era que cada que había un cambio importante ya sea en los protocolos de comunicación entre servicios o en el formato de algún archivo de juego (mapas del juego sobre todo) teníamos errores raros en varios lugares. Las razones de eso fueron caches que no se actualizaban (de los mapas pvp) y servicios que no estaban en la última versión (mismatch de protocolo). Arreglamos el tema del caché e incluimos una mejora en los builds para que ahora los servicios tengan la información del hash & commit. De esta manera el ejercicio de validación se vuelve trivial: ver que si estén todos los servicios en lo último desarrollado. Falta agregar esa información a los dashboards web; ahorita es solo un archivo de texto en el folder del servicio. - Aterrizamos gran parte del sistema de trofeos para todo el tema de matchmaking&ranking. Ya contamos con un sistema sencillo para darle (o quitarle) trofeos a un jugador al terminar una partida PVP. Falta meterle "juicyness" a la parte de la app con animaciones y aterrizar una UI que haga sentido para los trofeos. Ahorita solo tenemos algo como placeholder para mostrar trofeos dentro del juego. - Estamos trabajando en un nuevo "skin" de mapa, el actual es un calabozo típico, el nuevo está pensado para ser algo inspirado en un setting de "elfos". Early WIP. - Igual un WIP, estamos dándole a mejorar del sistema de comunicación entre servicios debido a que hay instancias que requieren que un servicio en un extremo de la "red" se comunique con un servicio en el otro extremo. Hacer eso ahorita requiere mucha "plomería" y estoy intentando simplificar eso (que la complejidad se mueva a la capa de comunicación de forma interna y fuera de la capa de desarrollo). Si el grafo de conectividad entre servicios es ServicioA -> ServicioB -> ServicioC -> ServicioD quiero ser capaz de comunicarme con ServicioD desde ServicioA sin tener que escribir plomería en servicio B y C. - Varios bug-fixes y mejoras producto del feedback de nuestros "play testers".
4
0
TACTICARUM - Dev Updates
1-8 of 8
Carlos Jiménez
3
42points to level up
@carlos-jimenez-2409
Fundador de "OneMageArmy" estudio de videojuegos. Estamos trabajando en un multiplayer competitivo en tiempo real, para dispositivos mobile.

Active 2d ago
Joined Oct 28, 2025
Powered by