Principios de Pygame Zero¶
Por favor, lee atentamente lo siguiente antes de contribuir.
Debido a que Pygame Zero está dirigido a principiantes debemos tener un cuidado extra para evitar la introducción de obstáculos para los programadores que aún no han aprendido a lidiar con con ellos.
Hazlo accesible¶
El objetivo principal de Pygame Zero es ser accesible para los programadores principiantes. El diseño de la API está, por supuesto, influenciado por esto.
Esto también se aplica a cosas como los requisitos de hardware: Pygame Zero eligió originalmente soportar sólo la entrada del teclado y el ratón, con el fin de ser accesible a cualquier usuario.
Ser conservador¶
Al principio del desarrollo de Pygame Zero, Richard y yo (Daniel) fuimos hacia atrás y avanzamos sobre varias características. Las pusimos, las probamos y las quitamos de nuevo.
Las características deben ser rechazadas si son demasiado experimentales, o si pueden causar confusión.
Esto también se aplica a cosas como la compatibilidad con el sistema operativo: no permitimos nombres de archivos que no sean compatibles con otros sistemas operativos.
Sólo trabajo¶
Pygame Zero envuelve a Pygame casi por completo - pero no exponemos todas las características. Exponemos sólo las características que funcionan realmente bien sin problemas adicionales, y ocultamos algunas de las otras características que funcionan menos bien o necesitan pasos adicionales.
Minimizar el coste del tiempo de ejecución¶
Al fin y al cabo, Pygame Zero es un framework de juegos y el rendimiento es un problema.
Hacer una costosa comprobación en cada fotograma para detectar una posible trampa no es realmente aceptable. En su lugar, podríamos comprobarlo en el momento de la puesta en marcha, o comprobarlo sólo cuando se produzca una excepción para diagnosticarla y dar más información.
Errores claros/explicativos¶
Cuando las excepciones son lanzadas por Pygame Zero, deberían tener mensajes de error claros que expliquen el problema.
Documenta bien¶
Como todos los proyectos, Pygame Zero necesita una buena documentación. Es más probable que los pull requests sean aceptados si incluyen la documentación necesaria.
Intenta evitar frases complicadas y términos técnicos en la documentación, para que sea más fácilmente legible por los programadores sin experiencia.
Minimiza los cambios de ruptura¶
En los entornos educativos, los usuarios no siempre tienen el control de la versión de una biblioteca que utilizan. No saben cómo instalar o actualizar a la última versión.
Es más importante acertar con las características a la primera que en muchos otros proyectos.
