Así es, la dejé en el mensaje anterior.

La repitió el compañero más arriba.

Una cosa, os recomiendo consultar el documento ayuda.html antes de jugar a este juego, por razones que descubrirán muy pronto.

Donde se coloca la contraseña? no me sale ningún cuadro para colocarla

cuando bas a desconprimir, te aparese elcuadro

no xd, no me aparese

No, es que aparentemente cuando descomprimes hay un archivo que ese sí tiene contraseña. Intenta...

bug encontrado. al parecer, no aceptas resultados con comas, o números flotantes o cosas por el estilo, epro el juego si hace operacions que dan resultados con decimales como por ejemplo 69/93
que da: 0,7419354838709677

Si la operación da un número decimal, no utilizes la coma, utiliza en su lugar el punto.

Por ejemplo, si te da un resultado como 0,7, escríbelo como 0.7.

sí que tiene bug el tema decimal. una operación me dio en 0.25XXXXX pero ni como 0.2, 0.58 .25 me dio resultado. en todas error. una opción para poder controlar, o eliminar los sonidos estaría bueno... pero me guśto, es entretenido.

mmm, tendría que revisar esa parte con más cuidado para corregirlo.

Pero, ¡qué bueno que te encanta jugarlo!

Sí, esa es una de las características que añadiré tal vez en la siguiente alfa. o quizá en la primera beta.

¡Hola amigos!

¿Cómo han estado?

Les cuento que ahora mismo, estoy intentando corregir bugs en la funcionalidad de los cuadros de edición, para así poder continuar con el resto de las funcionalidades del resto de objetos o controles en el módulo de la audio interfaz para así dar tan pronto como pueda por terminado dicho módulo. Entonces, dejo por aquí una consulta para aquel que me pueda ayudar: ¿Alguno conoce las reglas de edición de texto o, concretamente, la norma que determina en qué posición se inserta cada carácter ingresado según qué posición del cursor y una idea de cómo implementarla en python con pygame correctamente para que el texto que escriba no se escriba desordenado?

Una vez más les diré que este es uno de los módulos más importantes para mi audiojuego, ya que una vez lo tenga listo podré prescindir casi en su totalidad de WXPython. Quiero prescindir de WXPython porque, como los que ya han probado el juego matemático llamado Math Basic Operations pudieron observar, es demasiado pesado para las pocas funcionalidades que tiene, y esto es porque aunque la interfaz del juego está construida a base de WXPython los sonidos se cargan y reproducen con pygame, además de que WXPython por sí sólo es mucho más pesado que pygame, por lo que podrán imaginar.

Aunque ciertamente voy muy pausado, no me detendré en cuanto al desarrollo de este proyecto se refiere, ya que me gustaría que este proyecto esté disponible pronto, o al menos una versión de demostración o alfa del mismo.

Por cierto, perdí el número de los que me habían contactado por WhatsApp para ayudarme, esto debido a que cambié de teléfono. Pero, ¡muchas gracias a los que han querido ayudarme! Me gustaría que esas personas pudieran contactarme nuevamente, ya que a todos los que me han ayudado quiero colocarlos en una lista; Los que estén en dicha lista les daré un privilegio, cuando salga el juego les diré. Por supuesto, el juego está aún muy lejos de estar terminado, pero eso es lo que menos me detiene para seguir.

Estás reinventando la rueda. WXPython es pesado? Por qué? ¿En base a qué?

El paquete es muy pesado en el sentido de que ocupa mucho espacio en el disco, y el espacio que ocupa se suma al que ocupa el resto de paquetes y demás componentes y archivos multimedia del juego.

Entonces, es por ello que estoy desarrollando un módulo que haga exactamente lo mismo que audio forms en bgt.

No soy experto en Python, pero hacer un módulo basándose en audio form de BGT no es recomendable, teniendo en cuenta las limitaciones tanto visuales como de rendimiento que podría tener comparado con WX que, siendo una librería especializada para GUI, ya tiene todo para que funcione perfectamente, incluso si pesa mucho o no (sin saber cuánto pesa exactamente).
Sí, la curva de aprendizaje es alta pero vale la pena totalmente, te lo digo con experiencia ya que hice exactamente lo mismo que tú junto con un amigo solo para testear lo difícil de un porteo y mi propio conocimiento (soy de aprender a la brava) vaya que no salió como esperaba.

wx pesado? y ¿con pocas funcionalidades? pues te equivocas un poquito, te digo yo que tener tiene todo lo que necesites y más. en cuanto a sonidos, si, puedes ponerlos con pygame pero ya el peso no es algo que puedas gestionar.

Con los ordenadores actuales, preocuparse por el peso de pigame y wx es absurdo. Estás haciendo un audiojuego. si lo terminas, llegarás al giga si acaso. Y un giga no es nada para un juego, tirando por muy alto.
siempre va a ser más eficiente wx que lo que sea que reinventes. No te lo tomes a mal, pero WX tiene un equipo detrás, pruebas unitarias de software y mil movidas más, tú no.

además échale un vistazo a los juegos de hoy en día. 152 gb, 69 gb, etc. enserio crees que un audiojuego que carece de los relieves que un videojuego tiene puede llegar si quiera a la mitad de eso? xd

hoygan, en cuanto a pocas funcionalidades me refería al pequeño juego que desarrollé, no a WXPython porque sí, sé lo extremadamente potente que es este gran kit GUI.

Y sí, sé que los juegos de hoy en día son súper pesados, tal es el caso del mfs o el forza. Pero, una cosa es lo pesados que son, y otra es por qué son así de pesados. En el caso de esos 2 juegos, y como muchos productos de Microsoft son así de pesados por la enorme cantidad de recursos que utilizan para la enorme cantidad de funciones sofisticadas que tienen dichos programas, por ejemplo las imágenes tal vez 4d o qué sé yo para mostrar las cosas de un modo más realista a los jugadores sin discapacidad. De echo, yo justifico que un audiojuego pese 1 GB como el A Heros Call, que tiene nó sólo sonidos de muy alta calidad sino también voces grabadas de la misma calidad, siendo ese contenido multimedia lo que constituye la mayor parte del peso del juego, mientras que en el caso de math basic operations no me parece bien visto que pese más de 100 MB cuando en realidad tiene sólo unos pocos sonidos y un sólo fondo musical, por lo que las librerías del lenguaje más el paquete WXPython son en su lugar las que constituyen la mayor parte del juego. Es esto último lo qué, para mí como desarrollador, no me parece correcto, aunque de todos modos tengo pensado ampliar más la funcionalidad del juego Math Basic Operations en un futuro.

Pero en resumen, como dige al principio, cuando decía que es demasiado pesado para las pocas funcionalidades que tiene me refiero a las funcionalidades del juego, no a las de WXPython.

Y la verdad es que con pygame no me ha ido tan mal, incluso puedo decirlo aunque tengo una pc que hoy día se considera de pocos recursos. Donde sí he notado golpes de rendimiento es a la hora de correr ese mismo programa echo en pygame bajo GNU / Linux, pero imagino que el problema en sí es de la distribución en sí, porque de verdad que desarrollar juegos para GNU / Linux es en ocasiones algo problemático, imagino que es por eso que no hay muchos juegos para GNU / Linux. Y hablando de eso último yo quería lanzar la misma versión alfa para GNU/Linux, pero al probar la versión compilada me decía a mí mismo que si lo hacía, los usuarios de GNU/Linux hiban a tener una pésima experiencia de juego, lo cual obviamente no me hiba a alegrar para nada. Es por ello que, a lo menos por ahora, lo dejo para windows nada más.

Pésima experiencia de juego por qué?

porque en primer lugar, al resolver una operación correctamente el cuadro del enunciado de la operación no se actualiza, y en segundo lugar aunque agregué al código las instrucciones respectivas para cambiar la voz de espeak a español, muchas veces como que el intérprete ignora eso y los mensajes del juego se siguen anunciando con la voz en inglés, lo que además me preocupa especialmente en cuanto a esto último por el echo de que no sé cuan difícil será liberar live history para GNU/Linux.

Lamentablemente, en GNU/Linux no existen muchas opciones de sintetizadores de voz, además de que sólo existe un lector de pantalla medianamente funcional que es el lector de pantalla orca y, desgraciadamente, ni accessible_output2 ni accessible_output3 dan soporte a este lector de pantalla, raíz de muchas de las carencias de accesibilidad en GNU/Linux.

Entonces, es por ese motivo que para poder liberar este o cualquier otro juego para GNU/Linux al momento de compilarlo nó sólo debe incluir accessible_output2 o 3, sino que por lo ya mencionado también debe incluir entre sus componentes un paquete llamado en GNU/Linux python3-espeak, que no tiene otro propósito que hacer disponible el sintetizador espeak en el propio intérprete. Este paquete es necesario instalarlo, ya que accessible_output en GNU/Linux cuando se utiliza el módulo auto es a este motor al que recurre por defecto.

no te centres en todos los mercados cuando no tienes abordado ni uno. primero haz las cosas bien, y seguras. reinventando una nueva interfaz no es lo mejor, ya que te puede traer muchos bugs en el camino si es que no tienes una gran experiencia. creo yo que el problema de almacenamiento de wx python es un microproblema, por no decir que no vale para nada la pena dejarlo a un lado. si tu producto es de calidad, y accesible. con accesible no es la famosa palabra que sea para lectores de pantallas o así, si no que sea algo fácil de usar. algo que ya esta integrado fuera de los juegos como por ejemplo para el campo de texto. creo que me estoy enredando con mis palabras, pero si le das un par de leídas lo podrías comprender, y si no, puedes escribirme a mi privado.
primero crea el producto para windows por ejemplo. luego salta a mac, y así. si empezamos abarcando todo desde el inicio nos puede aorrar trabajo a futuro pero muchos problemas al principio, y si eres alguien nuevo no quieres esos problemas al inicio.

no no, por supuesto que no me gustaría que hubieran bugs en el camino.

Lo que sucede es que no quiero utilizar 2 librerías al mismo tiempo, es decir utilizar WXPython para toda la interfaz del juego y pygame no más que para los sonidos, como hize con Math Basic Operations. Sé que WXPython tiene su propio objeto de sonido, pero me di cuenta que ese objeto de sonido del módulo wx.adv sólo es compatible con el formato wav, mientras que el del módulo pygame.mixer admite todos los formatos, incluyendo el formato opus utilizado por WhatsApp para los mensajes de voz. Y no quiero convertir todos los sonidos y música del juego a ese formato, ya que hacerlo significaría que el juego ocuparía muchísimo más espacio, lo cual me preocupa especialmente a mi porque nunca se save qué tan rápido será el internet a la hora de publicarlo, especialmente porque aquí en Venezuela el internet es muy lento, lo digo más que todo por el internet Cantv que es precisamente el que yo uso.

Entonces, fue por este motivo que escogí pygame solamente, ya que me gustaría comenzar con algo especialmente diseñado para los juegos, pero además me gustaría aprovechar al máximo la funcionalidad de pygame o, a lo menos, lo que nosotros como programadores ciegos podamos aprovechar, además de explotar al máximo las características del propio lenguaje, lo cual he logrado al implementar un módulo para los menús y para la historia.

Sí, por supuesto que me encanta WXPython, pero en cuanto a utilizarlo para Live History1 nó por ahora, tal vez sí en live history 2 o 3. Más de una vez me sentí tentado a cambiarme a ngt, pero me he dicho a mí mismo que no ya que es un proyecto nuevo y poco conocido, además de que tendría que cambiar de lenguaje otra vez, lo cual no quiero hacer en pleno camino de desarrollo como hice con BGT.

creo que le das muchas vueltas al tema, pero bueno, es tu proyecto. yo solo usaría Pygame en lo personal para la ventana y eventos de teclado. en la parte de audio, no me combence para nada.

Pero es que tal y como lo dijeron arriba, usar varias librerías no es problema, teniendo en cuenta el peso y los recursos en general que ahora usan los juegos. Si quieres usar pygame para interfaz del juego en sí y wx para la gui, no tiene nada de malo, igual vas a usar muchas más librerías en tu camino.
Ahora que si quieres seguir teniendo los beneficios de pygame y su manejo de la interacción con el usuario usa mejor sdl2 o sfml para lo del juego, wx para la gui, openAL/bass/fmod para el audio envolvente, socket/twisted/pyenet (aunque no sé si esta última está muy bien actualizada) para el internet si quieres que sea online, etc.

oye, ¡muchas gracias por las sugerencias!

Sí, sé que es mi proyecto, pero aún así estoy abierto a escuchar cualquier sugerencia por parte de ustedes. Sólo que, yo como programador pienso nó sólo en qué es más potente sino también qué resulta más práctico pero, sobretodo, en qué he adquirido un mayor conocimiento. Pero, hay sugerencias que me han sido de gran ayuda para salir de algunos líos, como por ejemplo el lío con pydub que requiere del conjunto completo de librerías ffmpeg, lo cual obviamente me hiba a obligar a incluir el paquete ffmpeg completo en el juego, lo cuál para nada me hiba a gustar. Entonces una de las que vió mi número de WhatsApp y me contactó por allí me recomendó que utilizara sinthizer para los sonidos, lo cual me pareció mejor idea que utilizar pydub que depende de ffmpeg.

Sólo me gustaría en estos momentos terminar de implementar bien la funcionalidad de los cuadros de edición en el módulo audio interfaz hasta entonces, para luego implementar la funcionalidad de los demás controles, lo cuál para mí es prácticamente un pan comido ya que son cosas similares a las que ya he implementado previamente. Una vez termine este módulo les compartiré un paquete con los 3 módulos que he desarrollado para que los prueben y se diviertan un poco experimentando con mis creaciones y, de ser posible, creen juegos con los módulos que desarrollé, y entonces desarrollaré la parte más compleja pero la que le dará la sazón al juego, los mapas de juego y los objetos del juego, momento en el que haré uso de sinthizer para que sea posible hacer volar mi imaginación con los ajustes de sonido que se pueden hacer con esta herramienta.

Pero donde estoy atascado ahora es justamente eso, los cuadros de edición en el módulo de la audio interfaz.

Oh por cierto, quiero aprovechar este mensaje para contarles que mi paquete de módulos, llamado juego_accesible, depende de varios paquetes, además de pygame también depende de pyperclip para la copia y pega del portapapeles, accessible_output3 para la accesibilidad con lector de pantalla o voz tts y muy pronto también del módulo sinthizer para los sonidos no sólo espacial sino también con tonalidades diferentes así como también otros ajustes, además de módulos havituales como os o enum. Otra cosa, el juego lo voy ha desarrollar offline pero con futuras características online, que por cierto estoy pensando que varias de esas características sean de pago, aunque no sé cuál sería el módulo apropiado para gestionar las transacciones en paipal.

alguna noti sobre el game

¡hola amigos!

Lo que puedo comentarles por ahora sobre el juego es, que el amigo @sanmael se ha puesto en contacto con migo por privado, y me ofreció ayuda ya que el me comentó que el también ha estado trabajando en un módulo de python que hiciera las veces del antiguo audio form de BGT. Hasta entonces, aún continúo a la espera de ello, y mientras espero trato de mejorar una de las cosas más complejas de implementar, hablo concretamente de los cuadros de edición de contraseña, aún no he podido corregir los bugs que me presenta esta funcionalidad.

Y los bugs que aún no he podido corregir es que siempre se escribe un * en el cuadro de edición aunque no haya escrito nada, así como también cuando la contraseña es visible se escriben 2 caracteres de fin de línea, aún no entiendo por qué.

hola que decisión tomaste sobre el hilo?

¿Decisión como qué?

Sobre el ilo, si te refieres a este ilo, mantenerlo abierto para informar a todos sobre cualquier novedad en cuanto al desarrollo de live history se refiere.

Una vez live history lo haya terminado de desarrollar, a lo menos terminado de desarrollar y liberar la primera compilación alfa del mismo, entonces este ilo lo renombraré a "ilo oficial de live history", momento a partir del cual este ilo será como el de cualquier otro juego, propiamente tal, es decir, ya no tan sólo un canal donde les informe sobre lo mencionado arriba, sino que donde también puedan realizar cualquier consulta sobre el juego.

¡Hola amigos!

Tanto tiempo sin reportarme por aquí.

Aunque, les cuento, también ha sido porque había pausado el desarrollo de las bases de live history por un tiempo, pero hoy he decidido retomar el desarrollo nuevamente.

Verán, aún me encuentro trabajando en la parte más difícil, o a lo menos una de las partes más difíciles, y es concretamente en los cuadros de edición de contraseña. Hay unos cuantos bugs que aún no he podido corregir, pero he decidido mejor enfocarme en otras cosas, como en la corrección de bugs en los objetos con su funcionalidad ya programada, como en los cuadros de texto de sólo lectura y cuadros de edición multilínea. También estaré próximamente implementando la funcionalidad de los demás objetos que había definido previamente. Todo esto, por supuesto, en el módulo de la audio interfaz del que ya les había hablado antes.

Desarrollar el módulo de la audio interfaz no ha sido realmente difícil, a pesar de las más de 1000 líneas de código que he tenido que escribir hasta ahora, lo realmente difícil es la implementación de todo lo que tenga que ver con cuadros de edición, peor aún los cuadros de edición de contraseña donde los datos tienen que ser ocultos y cada carácter oculto en un símbolo, en este caso por convención decidí usar el * para ello.

Una vez completado este módulo, entonces comenzaré el desarrollo de un subpaquete llamado mundo, que incluirá módulos que añadirán al juego los mapas, objetos, beículos y demás que tenga que ver con el mundo de juego.

¡feliz noche para todos!

¡Hola amigos!

¡tengo nuevos avances qué notificarles sobre el desarrollo de live history!

Me gustaría recordarles que voy muy lento y pausado pero sin detenerme en cuanto al desarrollo de live history, en otras palabras voy a un ritmo asíncrono.

El módulo de la audio interfaz ya está casi terminado, sólo me falta corregir algunos errores menores y terminar de implementar algunas cosas, lo cual les comento a continuación.

En primer lugar ya terminé de implementar los tipos de objetos que faltaban. No sé si recuerdan que la última vez les había comentado que faltaba implementar el comportamiento de las listas, las barras de progreso y las barras de estado, así como también me faltaba corregir errores en los cuadros de edición multilínea y los cuadros de edición de contraseña. Todavía me falta corregir los errores de estos últimos, pero ya tengo en mente cómo hacerlo, pero la corrección de dichos errores implica hacer cambios mayores en la estructura del código, lo cual me tomará algo de tiempo.

Les comento que así mismo ya corregí los bugs que había en los paneles, concretamente en los comandos para ir a los paneles anterior y siguiente. Hay un error en pygame y del cual me dí cuenta cuando corregía esta parte del código, y es que no se puede crear la combinación de teclas CTRL + retroceso, la cual tenía pensada para ir al panel anterior, por lo cual tuve que cambiarla a CTRL + suprimir en su lugar. Intentar usar ctrl+retroceso no lanza ninguna excepción, simplemente no hace nada. Por lo cual aprovecho la oportunidad para decir esto, lo cual quiero que llegue a hoídos de los desarrolladores de sound rts: ¡no actualicen a la última versión de pygame porque sé que utilizan precisamente esa combinación de teclas!

Aún me falta implementar la posibilidad de agregar atajos de teclado a los objetos, y además tengo pensado también agregar un objeto barra de menú, pero eso lo dejaré para después, ya que eso implica agregar muchas cosas.

No me detendré, ¡continuaré hasta terminar el desarrollo de live history y publicar a lo menos la primera compilación alfa!