No hagas esta suposición de tus jugadores

Playlist completa sobre desarrollo -https://www.youtube.com/playlist?list=PLc38fcMFcV_uH3OK4sTa4bf-UXGk2NW2n

GMTK es posible gracias a los mecenas de Patreon - https://www.patreon.com/GameMakersToolkit

En este episodio, llevo mi juego a la GDC en San Francisco y obtengo algo de feedback. En el camino, aprendo algunas duras lecciones acerca del proceso de playtesting y acerca de suponer cosas sobre tus jugadores.

Prueba la demo por ti mismo - https://gmtk.itch.io/untitled-magnet-game

=== Créditos ===

Music By: LAKEY INSPIRED @ https://soundcloud.com/lakeyinspired
License for commercial use: Creative Commons Attribution 3.0 Unported "Share Alike" (CC BY-SA 3.0) License.

Biblioteca de audio de YouTube

Música y efectos de sonido proporcionados por Epidemic Sound - https://www.epidemicsound.com/referral/vtdu5y (Enlace de referido)

=== Subtítulos ===

Contribuye con subtítulos traducidos - TBA

Hola, mi nombre es Mark y estoy haciendo un videojuego sobre imanes.

Okay, pues este era el plan: tomar todos los
niveles que hice en el episodio anterior,

juntarlos en una demo, meter esa demo
en una Steam Deck, volar a San Francisco

y darle la demo a las personas que asistieran
al evento Game Developers Conference.

Pero a sólo una semana antes de mi vuelo, le dí mi

demo a un playtester importante y NO le gustó.

Le pareció frustrante y tediosa
y se rindió antes de siquiera terminarla.

Y fué en ese momento cuando me dí cuenta de que
había cometido un error enorme y bastante común

al momento de plantear el nivel de dificultad de mi juego.

¿Qué fué lo que hice mal, y críticamente hablando, sería

capaz de corregirlo antes de volar a California?
Bueno, quédate para averiguarlo.

[Música]

Okay, déjame ponerte un poco más en contexto.

En un episodio anterior, te mostré
cómo usé una matriz de puzzles

para ayudarme a generar ideas para
apróximadamente 26 niveles diferentes.

Luego, después de publicar ese episodio, empaqueté
dichos niveles en una demo bastante robusta de una hora,

incorporando tres mundos variados, diferentes
imanes y un puñado de mecánicas distintas;

como paneles que cambian de color,
rayos láser, plataformas móviles,

cajas con ruedas, interruptores giratorios y demás.

Como siempre, las primeras personas en probar esta demo
fueron los mecenas del Patreon de GMTK a través de Discord.

Me dieron montones de feedback, consejos, bugs descubiertos,

exploits, molestias e inconsistencias.

Como de costumbre, estoy enormemente agradecido por su ayuda.

Entonces, de forma completamente inesperada, recibo
un email de un tal Patrick Traynor, el mismo que

hizo Patrick's Parabox, el brillante juego de puzzles
que mostré en un episodio previo de esta serie.

Me agradeció por incluír su juego en mi vídeo
y me deseó suerte con mi juego de imanes.

Yo respondí: "¿Quieres jugar una demo?"
Él, muy amablemente, respondió que sí

y luego, unos días más tarde, recibo un email con una sola frase:

"¡Ya lo jugué!" y un enlance a un vídeo de Youtube:
una sesión de dos horas jugando al juego.

Ahora bien, si te preguntas qué hago titubeando:
él no me dió ningún indicio de si le gustó

o no el juego, por lo que iba a tener que sentarme
y sólo verlo jugar y evaluar el juego en tiempo real.

Y así, si llegaba a odiar el juego, iba a tener
que quedarme ahí y simplemente ver a alguien

decepcionarse progresivamente más y más de mí,
y pues, ya sabes, Para eso ya están mis padres, ¿no?

Pero finalmente, reuní el coraje para reproducir el vídeo,

y en un todo, realmente la disfrutó.

Se reía y sonreía.

Me felicitaba por algunos de los puzzles y comentaba

sobre el potencial de las mecánicas base del juego.

PATRICK: Estas mecánicas me hacen pensar:
"¿Por qué nadie más ha hecho un juego de
plataformas con imanes como este antes?"

Y cualquier crítica que hacía, iba acompañada
de un brillante consejo o ayuda.

Por ejemplo, que debería dejar más en claro qué puede
y qué no puede hacer el jugador en cada puzzle.

Así pues, si un vacío no está pensado para
que el jugador lo salte, hacerlo realmente grande.

Si una puerta está pensada para dar la impresión
de cerrarse demasiado rápido para atravesarla,

debería cerrarse de golpe inmediatamente, cosas por el estilo.

También me dió otra enorme recomendación,

la cual era que simplificara los niveles, incluso
si eso significaba hacer que el juego fuera más fácil.

Recomendación que ignoré rotundamente,
en un momento hablaremos más acerca de eso.

De cualquier manera, quedaban cerca de dos
semanas para la Game Developers Conference.

Así que decidí usar todo el feedback de mis
mecenas y de Patrick para reformar la demo.

Quité un puñado de niveles que
simplemente no encajaban del todo.

Este dependía demasiado de tener buenos
reflejos como para ser un buen puzzle.

Este tenía un inmenso exploit que me costaría mucho corregir.

También colé un nivel, el cual no era
un puzzle, sino que era únicamente

de plataformeo para ver cómo los jugadores
reaccionarían a ese cambio de ritmo,

pero el feedback fue variado, así que he
dejado ese en el taller de montaje por ahora.

Adicionalmente, hice algunos puzzles nuevos para compensarlo.

Trabajé en mejorar la claridad de ciertas mecánicas del juego.

Por ejemplo, estos íconos, los cuales indican
cuándo un botón está vinculado a un objeto.

Reemplacé también esta especie de
detector de imanes raro con una polea

insertada en un panel, la cual activa un botón
cuando la soga llega totalmente hasta abajo.

También sustituí estos sencillos botones verdes por un
interruptor mucho más satisfactorio estilo Frankenstein.

Hice una cerradura y llave para ciertos tipos de puzzles

los cuales tienen una animación muy
satisfactoria cuando tomas la llave.

Pulí el menú de pausa y añadí una mejor pantalla de inicio.

Y...Ah, sí, hice un sistema de diálogos totalmente nuevo.

Hay sólo una conversación como prototipo
en esta demo, pero con suerte debería

permitirle a la gente a hacerse una idea sobre
cómo podría ser la historia en el juego completo.

Bien, la demo estaba hecha y lista.

Faltaba una semana para ir a San Francisco,

por lo cual, le dí el juego a un playtester importante.

Y como dije al inicio del vídeo, él no estaba convencido.

Por el contrario, estaba frustrado y molesto.

Los nieveles le parecían sumamente complicados y tediosos de jugar.

Y en varias ocasiones, simplemente me pasaba el control y decía:

"¿Podrías simplemente, sólo, completar tú este nivel ?

¿Ese playtester? Era mi padre.

¿Qué dije de los padres y la decepción?
Pero, tan insufrible como fue ese playtest,

pienso que fue también el más importante
de todo este proceso de desarrollo.

Verás, en ese momento, fue como ver a través de la Matrix.

Pude ver exactamente, en qué
y cómo me había equivocado

Y también me dí cuenta de que, si alguna
vez conocía a Patrick en persona,

tenía que invitarle un trago por
haber ignorado su ilustre consejo.

Pues bien, este era mi error:

Cada vez que diseñaba un nivel, acababa con
un esquema bastante simple para el puzzle,

el cual sólo evaluaba al jugador en una
interacción sencilla, cómoda y breve.

Pero entonces, asumía que los jugadores
resolverían el puzzle inmediatamente.

Arrasarían con el puzzle instantáneamente
y concluirían que mi juego era muy fácil.

Y por lo tanto, aburrido; y me considerarían,
por lo tanto, como un ser humano inherentemente inútil.

Así que, iba a ser un poco atrevido e iba a añadir algo de complejidad extra al nivel.

Añadiría una buena cantidad de pasos
que el jugador necesitaría

llevar a cabo con el fin de resolver
el puzzle satisfactoriamente.

Y añadiría ciertas trampas engañosas,
donde si el jugador se equivocaba,

quedaría atascado y tendría que reiniciar el puzzle desde cero.

Y obscurecería la solución verdadera del puzzle
con algunas pistas falsas y otros elementos.

Y al poner en marcha esta retorcida y
maquiavélica artimaña, acabaría con puzzles

que eran confusos, intrincados,
frustrantes y tediosos de jugar en realidad.

Estaba tan centrado en hacer que los niveles fueran
difíciles, que me había olvidado de hacer que fueran divertidos.

Ups.

Y esta es la cuestión:

Nunca comprobé realmente esa suposición.

Dicha suposición de que los
jugadores encontrarían inmediata

e instantáneamente la solución,
¿Era realmente cierta?

Así que, seguí el consejo de Patrick
y rediseñé un montón de niveles de

la demo con la claridad, elegancia
y simplicidad como núcleo del diseño.

Observa este nivel, por ejemplo:

En la versión original, debes usar dos imanes
para accionar dos interruptores simultáneamente,

con el fin de levantar dos brocas, para hacer que
un láser impacte en un orbe y asi abrir una puerta.

Sólo describirlo ya es tedioso.

El auténtico puzzle de este nivel
es, creo yo, bastante bueno

pero está oscurecido detrás de
muchos detalles innecesarios.

Así que lo renové para que se viera así:

Abora requiere sólo un imán,
cuenta con tres o cuatro mecánicas,

es bastante más pequeño y bastante más sencillo.

¿Hallarían inmediatamente los jugadores
la clave para resolver el puzzle?

Bueno pues, literalmente no tuve tiempo de comprobarlo.

Tenía que compilar la versión, meterla en la Steam Deck,
conducir al aeropuerto, abordar el avión,

y luego sentarme en una silla por 10 horas seguidas
igual que un desarrollador triple A siendo sobreexplotado.

¿Me meteré en problemas por hacer ese chiste?

¿Va a haber un montón de gente enojada en Twitter por esto?

Okay entonces, llego a San Francisco y después de unos
cuantos días de turistear - ya sabes, ver Alcatraz,

el puente Golden Gate, los leones marinos en
Pier 39, comer hamburguesas en In-N-Out...

Ugh, Dios, no. ¡Las papas! ¿Pero qué creen que hacen?

En fin, llega la semana del evento y le
doy el juego a tanta gente como puedo:

en fiestas, en encuentros, en
eventos de "trae tu propio juego",

en reuniones y durante desayunos, mientras
comíamos pilas de panqueques americanos.

(Aunque supongo que no es que sean americanos,
sino sólo, panqueques, ya que estoy en América).

Y pues, el feedback de la demo fué muy bueno.

La gente seguía diciendo: "Esto se siente como
un videojuego sólido" y algunos incluso

se negaban a devolverme la consola hasta
que no hubieran terminado toda la demo.

Y para responder la pregunta de ¿Era el juego muy fácil?

No. El juego estaba, de hecho, casi que
en el punto adecuado de dificultad.

En ese puzzle del que hablé hace
un rato, por ejemplo, los jugadores

se atoraban por cuestión de un minuto
o dos y luego daban con la solución.

Y llegaban a ese momento "Eureka!", de abrir
los ojos y decir "Ajá", que yo tanto buscaba

No hubo momentos de confusión ni frustración.

Simplemente les parecía un buen puzzle,
a la par que divertido y satisfactorio.

¿Qué?

Resultó que, hacer más fácil el juego fué-

¡Por Dios!, esa sí que es una araña enorme.

Emm....

¿Dónde me quedé?

Resulta que, hacer el juego más fácil
fué definitivamente la decisión correcta.

Y a decir verdad, todavía me
faltaban detalles por pulir.

Había un nivel en la demo que
seguía siendo bastante engorroso.

Un americano entusiasta se refirió
a él diciendo: "Diablos, este está difícil".

Y hubieron también unas pocas mecánicas
básicas y fundamentales en el juego

que nunca le había enseñado a los jugadores
apropiadamente, lo cual causaba que tuvieran dificultades.

Cosas como ser capaz de usar el imán para subirse a una

plataforma más alta o la posibilidad de
cambiar la polaridad del imán desde lejos.

Eran cosas que sentí que eran tan
obvias acerca de mi juego, que no creí

que fuera necesario explicarlas dentro
de un puzzle o mediante un tutorial.

Pero alguien que nunca antes ha jugado mi juego,
sencillamente no tiene ni idea de dichas cosas.

Así que esta es la gran lección de este vídeo:

la cocina americana es bastante mala, pero
sí que saben cómo hacer un buen desayuno.

Un momento, no, perdón. Vídeo equivocado.

Esta, es la gran lección de este vídeo: cuestiona
siempre las suposiciones que haces de tus jugadores.

Yo asumí que los jugadores hallarían
mi juego de ser muy fácil,

y así terminé haciendo que los niveles fueran
más frustrantes, complicados y enrevesados.

También asumí que la gente
sabría cómo jugar mi juego,

y de esa manera, me olvidé de explicar
casi la mitad de las mecánicas.

Sin embargo, no me siento tan mal porque sé que

ese es, en realidad, un error muy
común al momento de diseñar.

Es tan fácil asumir que los jugadores
tendrán las mismas habilidades, conocimiento

y entendimiento que tú: el, eh, desarrollador que
lleva jugando al juego todos los días durante meses,

que conoce literalmente todas
las soluciones de todos los puzzles

y que literalmente escribió las reglas del juego.

¡Mark, insensato!

Por lo que no es sorpresa que los desarroladores
acaben ajustando el juego para que sea difícil

o para no comunicar apropiadamente
algunas de las mecánicas del juego.

Y como desarrollador y diseñador de
videojuegos, es una de tus prioridades

controlar ese impulso e intentar de verdad
ponerte en los zapatos del jugador.

Así pues, quiero cerrar este vídeo
con algunos consejos y técnicas

que he aprendido para
desenvolverse mejor en este oficio.

En primer lugar, el creador de Mario, Shiheru Miyamoto,
suele decirle a los diseñadores novatos que intenten

jugar los juegos sujetando cada
lado del mando con la mano opuesta,

lo cual debería darles la experiencia
de ser un jugador novato.

Ese consejo es bastante excesivo, pero tal vez
tú puedas pensar en formas de simular la experiencia

de ser alguien que no tiene las mismas habilidades,
ni el mismo conocimiento del juego que tú.

En cuanto a Patrick, al final sí nos vimos
en el evento y le invité ese trago.

Patrick me aseguró que ponerse en la piel del jugador es
una habilidad que se desarrolla y perfecciona con el tiempo.

Y como he mostrado en este vídeo,

pienso que la mejor manera de conseguirlo,
es ver a otras personas jugar tu juego.

De ser posible, procurar estar junto a ellos cuando lo hagan.

No hay nada más aleccionador que
sentarte junto a una persona que

no entiende en lo absoluto de qué
rayos se trata tu juego siquiera.

También deberías jugar con gente con
cualquier clase de experiencia y habilidades.

Algunos de mis mejores playtest vienen
de mis sobrinos de siete y diez años,

sin embargo tengo que saber interpretar sus comentarios.

MARK: Jack, ¿Qué piensas del juego?

JACK: Le doy un millón de puntos -- ¡Me encanta!

MARK: ¡Gracias!
Rory, ¿Qué piensas tú de Untitled Magnet Game?

RORY: Me encanta.
MARK: Gracias.

Ese es, desde luego, un buen
recordatorio de fijarte más en

el cómo juegan tus playtesters
antes que en lo que dicen.

Uf, debería poner esa frase
en una camiseta o algo.

Otro consejo es pensar cuál
es el público objetivo de tu juego.

Hazte una idea de qué clase de personas son,

el tipo de habilidades, su nivel de
experiencia y qué juegos les gusta jugar.

Ten eso presente y asegúrate al diseñar,
de que el juego se ajusta a ese público.

Y procura elegir candidatos adecuados para probar el juego.

Una gran parte de mi problema se debió a que estaba
preocupado de que los fanáticos de los puzzles,

personas que han jugado y completado
Stephen's Sausage Roll y Baba is You,

que esos expertos jugaran mi juego y pensaran
que es muy simple, ordinario y mediocre.

Pero ellos no son el público objetivo al que va dirigido mi juego.

Quiero que este juego apele a un grupo de gente
mucho más amplio y a jugadores que han disfrutado

de aventuras de puzzles más suaves como
Toki Tori, Box Boy, Inside, Limbo y Portal.

Tener un público objetivo en mente, es una
excelente manera de mantener tu diseño sobre rieles.

Y, por supuesto, hay maneras de apuntar
a una audiencia más amplia igualmente.

Si has diseñado un juego realmente difícil,
podrías incorporarle un modo de asistencia.

Si has diseñado un juego muy fácil, podrías introducir contenido
opcional de mayor dificultad o contenido post-final del juego.

Y finalmente, no tengas miedo de empezar
las cosas otra vez desde cero.

Cuando estás creando un nivel, hay implícito un montón
de descubrimiento en el proceso, y eso a menudo acaba

contigo acumulando montones de añadidos y basura,
mientras defines siquiera la identidad del nivel.

Mi recomendación, por lo tanto,
es empezar el nivel nuevamente, pero

aplicando los conocimientos que has adquirido
cuando hiciste con prisas ese borrador inicial.

Sin duda alguna, acabarás con una versión
del nivel mucho más elegante y coherente.

Quiero decir, yo siempre hago eso con
los episodios de Game Maker's Toolkit.

El guión atraviesa cinco o seis revisiones
diferentes antes de que yo lo grabe.

¿Por qué no estaba haciendo eso mismo con el
diseño de nivel del juego?

De cualquier modo, volví del evento GDC
con mucha motivación

y buenas ideas de por dónde encaminar
el juego, y también con un terrible jet lag.

Quiero darle las gracias a todos los que me
saludaron o pasaron tiempo conmigo en el evento.

Fué asombroso conocer a tantas personas
que siguen el canal Game Maker's Toolkit,

participan en las game jams o me acompañan
en este viaje de desarrollo de un videojuego.

Incluso fue genial conocer a aquel chico
que estuvo mostrándome sus NFT's.

Eso es genial, amigo; lo estás haciendo muy bien, bro.

También me hicieron sentir parte de esta
maravillosa comunidad de desarrolladores

y es por eso que ya ansío volver el próximo año,
ojalá con un juego terminado

o algo que al menos esté más cerca de
estar terminado de lo que está ahora.

Hasta entonces, mi próxima tarea será
dar otro paso atrás y hacer una demo

que explore conceptos incluso más básicos
y fundamentales de mi juego

y luego poner esa demo a disposición de
personas que pertenezcan a mi público objetivo.

Por el momento, si quieres jugar cualquiera
de las tres demos que describí en este vídeo,

están disponibles sin ningún costo en itch.io.

Ya no estoy recibiendo más feedback de esas demos,

pero podría ser interesante
ver qué tal está saliendo el juego.

Muchas gracias por ver
y nos veremos de nuevo pronto.