Más que hacer un juego "pequeño", deberías empezar haciendo un juego "sencillo".

A nivel semántico, decir "un juego pequeño" es un poco engañoso, porque ¿Pequeño en qué? ¿Duración? ¿Contenido? ¿Número de mecánicas? ¿Tamaño de archivo?.

Hay juegos que son pequeños pero complicados, y otros que son amplios pero sencillos. También al revés: amplios y complejos (A lo Baldur's Gate 3 o cualquier RPG) y pequeños y sencillos.

Tomó de ejemplo a Alva Majo y su primer juego exitoso: Majotori, un sencillo juego de preguntas y respuestas PERO con historia que cambia según tu desempeño. El juego es mucho más grande que cualquier juego de Jam, pero la mecánica principal es tan fácil que cualquier novato lo podría aplicar. Ese es el punto. Creo que Buckshot Roulette es bastante más corto que todo Majotori y aun así su mecánica principal, aunque sencilla en apariencia, es bastante más profunda. Sandtrix, un juego de Tetris donde las piezas se deshacen como la arena con físicas realistas, es nada más y nada menos que eso, un juego de Tetris, pero la ciencia detrás de las físicas de la arena y la lógica en interacción de los colores seguramente llevaría a la locura a cualquier estudiante de letras. "¿Y si quiero hacer un juego de Pong de un 20 minutos donde se aplique la Teoría de la relatividad general de Einstein?", a ver, eso técnicamente sería un "juego pequeño", pero creo que tu salud mental no merece tal castigo ¿No crees?. En lugar de romperte la cabeza recreando la mecánica de los testículos de los caballos de RDR2 o el sistema némesis de los juegos del El Señor de los Anillos, haz un Pong, un Break Out, un Space Invaders o un Mario con un giro único pero sencillo, y partir de allí decide cuanto contenido tendrá el juego, si será amplio o pequeño.

Muchos de los mejores juegos jamás hechos nacen de mecánicas fáciles de aplicar, lo que da espacio a expandir sin mayores complicaciones. Eso es un poco la filosofía que llevo con mi Proyecto Further: la mecánica principal del juego es tan sencilla que literalmente pude crear un prototipo jugable en menos de 4 días usando Godot en Android (Que tortura). Eso me da la posibilidad de agregar más contenido y expandir el proyecto hasta donde me sienta cómodo. Hacer un juego "pequeño" que no sea para una Jam, a nivel personal, no me sirve de mucho para los objetivos que me planteo.

Creo que lo más complicado del desarrollo es el mantener la perseverancia en ese transcurso entre tener un prototipo a un juego competente. Ello resulta más complicado si la mecánica que quieres implementar necesita conocimientos en física de partículas para llevarla a cabo. También que los Bugs son ineludibles, el estado natural del código es el caos, que no funcione nada. Tu tarea como desarrollador es crear orden y que las cosas no exploten, y eso es difícil si necesitas 3 doctorados para entender lo que sea que hace tu código.

Según mi limitada pero valiosa experiencia, el desarrollo es un 10% crear mecánicas y un 90% crear todo alrededor de las mismas para que funcionen y sean divertidas. Es por eso que existen los géneros jugables, donde las mecánicas principales son compartidas por varios juegos, pero su aproximación a las mismas es muy distinta por como construyen todo a su alrededor. Hay un millón y medio de FPS, pero hay una gran diferencia entre un COD y un Doom. Hay un sin fin de Plataformeros, pero es muy distinto como lo hace Mario que como lo hace Sonic. El mayor logro, creo, está en esa construcción, ya que, así como a cualquiera se le puede ocurrir una "buena idea", cualquiera puede pensar en una "buena mecánica", pero ¿Implementarla y que sea divertida? Ese es el reto.

En fin, que el punto sigue siendo el mismo: "menos es más", solo que en este caso es "Menos complicación, más diversión".