si juansito es programador, entonces yo soy dios. pídanme lo que quieran hijos, que yo los complaceré

Dame una novia con una voz angelical, hermosa, con piel suave y tod… digo, estenmnmn nada, tiene futuro el juego este, creo va a estar bueno.

Nada no se de programación y recién aprendo edición de audio así que no es mucho lo que puedo aportar. pero aún así le veo futuro a este proyecto y muchísima suerte en el mismo. Espero probarlo en un futuro así sea una veta. buenas vibras

me gustaría participar. no soy el mejor dev, pero se algo de Python y de sonidos se también un poquito xd

¡Oh, muchas gracias a todos por su disposición a ayudarme!

Tendría que revisar entonces en la carpeta system32 a ver.

Aunque voy a ver también un poco sobre el uso de ese módulo que me recomendaron por aquí, synthicer.

sería bueno que el juego estuviera en bgt, por que apenas estoi usando bgt y piton

hacer algo en bgt es tirar piedras contra tu propio tejado.
No hagas caso a esta criatura.
El problema de Synthesizer (espero haberlo escrito bien) es que la documentación es bastante... extraña.
Es una librería potentísima, porque tiene mil opciones, audio binaural entre ellas, pero da una lata...

bueno, si esto va en serio, no tengo ni un carajos de conocimiento de programación en python, pero, ser uno de los tester ahora que tengo tiempito libre, también sé un poco de edición de audio que no es mucho, pero bueno eso.

hola! a mi me encantaría ser beta tester y, aunque no dispongo de sonidos comprados, creo que puedo conseguir algunos y hacer algo interesante. por ahora noi ando activo en wpp pero si puedes mándame permanente i vemos :)

Amigo, yo lo estuve desarrollando precisamente en bgt.

Sin embargo, tomando en cuenta que bgt está obsoleto, además de que en la actualidad no hay ni un sólo rastro de bgt en su página oficial, me vi en la obligación de cambiarme a python, ya que es mi lenguaje favorito y, además, aunque en python no tengo la misma cercanía con las herramientas de soporte de accesibilidad como en bgt, cosas muy complejas como los menús, mapas, interfaz y demás cosas resultan mucho más fáciles de implementar en python que en bgt. Además, ¿por qué entrar en un mundo del que todo el mundo prácticamente se está saliendo?

postéo, a petición del autor del hilo

oo, es verdad, bueno se que no ai noticias de el juego pero sinenbargo espero que lo que estes desarrollando te valla de lomejor

che, por las dudas subo hilardo

¡Hola amigos!

Gracias por postear en este ilo. Ahora, les voy a contar un poco sobre como voy en cuanto al desarrollo de live history.

La verdad es que, aún continúo desarrollando el conjunto de módulos para acelerar el desarrollo de este y futuros juegos, como live history 2 y live history 3.

Pero, me gustaría contarles que estoy trabajando en el desarrollo de uno muy importante, y de echo uno de los más complicados pero fundamentales para la interfaz del juego. Me refiero concretamente al módulo de la audio interfaz, que cumple una función similar al módulo audio form de BGT, pero a su vez combina mecanismos de WXPython, como la forma de añadir los controles (aquí llamados objetos).

El módulo audio interfaz admitirá los siguientes objetos por ahora:

*botón
*casilla de verificación
*lista
*cuadros de edición simples, multilínea y de contraseña.
*cuadro de texto de sólo lectura.
*barras de estado
*barra de progreso.

A diferencia de audio form, cada uno de los objetos mencionados arriba se deberán añadir en un objeto panel, lo cual significa que los objetos en un diálogo deberán ser sólo paneles. Ya que los paneles son objetos contenedores, es aquí donde se pueden añadir los objetos mencionados arriba. Este módulo tiene algunas excepciones incorporadas, entre ellas la excepción error_de_objeto, la cual es lanzada cuando se añade a un diálogo un objeto que no sea un panel.

Así mismo, aquí no se podrán anidar paneles, de momento. Pero sí se pueden añadir múltiples paneles en un mismo cuadro de diálogo, facilitando la navegación por secciones en un cuadro de diálogo.

Existe además un par de objetos contenedores de los objetos mencionados arriba, las listas y las barra de estado.

La diferencia que más destaca entre estos 3, es que los paneles pueden añadir cualquiera de los objetos admitidos, mientras que la lista y las barras de estado de estos solo puede contener botones y casillas de verificación.

En cuanto a los cuadros de edición, los comandos de lectoescritura y de selección son muy parecidos, con algunos cambios en las reglas de selección de texto.

En primer lugar, cuando se selecciona texto, sólo se puede seleccionar texto en una dirección al mismo tiempo. La deselección de texto es más agresiva, ya que, por ejemplo, si yo selecciono texto a la derecha, y después pulso la tecla direccional izquierda, junto con la tecla shift incluso, el texto seleccionado no se deselecciona carácter a carácter, sino que se deselecciona por completo.

Los comandos para copiar y pegar también serán los mismos aquí.

Además, todos los objetos tendrán la capacidad de admitir 2 funciones, función activar que sería la función primaria y función que es la función secundaria de cualquier objeto.

para que arquitectura será el juego?

Será para ambos equipos, además tomando en cuenta que lo estoy desarrollando en un equipo de 32 bits.

genial, de echo yo igual uso 32 bits. espero probar el juego cuando esté listo y suerte con el proyecto.

Perfecto amigo, ¡muchas gracias!

OYE BRO @BALBINO, TU COMO APRENDISTE PROGRAMACIÓN? Y UNA DUDA, POR CURIOCIDAD. ESO DE LOS MÓDULOS QUE TENDRÁN BOTONES YE SO, SERÁN COMO ACCESO DIRECTO PARA PONERLOS TÚ O ALGO ASÍ? O ESO SE PUEDE HACER?TIPO CREAR UN MENÚ DE CONSTRUCCIÓN DE LOS CLONES PERO SOLO PARA TI PARA AÑADIRLE BOTONES O ALGO ASÍ?

será interno, no todo es clones.

Yo fui aprendiendo a programar leyendo la documentación en el caso de python, aunque en el caso de BGT aprendí un poco mientras iba traduciendo la documentación, pero dándome cuenta de que python es más sencillo de aprender incluso que BGT, la verdad preferí aferrarme más a python.

Además, también tomé el curso de píldoras informáticas y leí el libro "inventando con python" El cual también me ha enseñado mucho, o mejor dicho, me ha hecho poner en práctica lo que he aprendido leyendo la documentación.
Y, cuando comencé a desarrollar algo que fuera accesible con pygame y accessible_output 2 y 3, me di cuenta de que podía sacarle aún más probecho a python. De echo, quería desde un principio hacer la transición de python a BGT, lo cual, después de algunos años de aprendizaje más tehórico que práctico, ahora este deseo ya lo estoy haciendo realidad.

Y en cuanto el módulo, te lo describo en pocas palabras.

Si conoces bgt y también audio form, sabrás que la forma en la que se muestran los botones, cuadros de edición y otros objetos es que solo se escuchan, más no se pueden ver en la pantalla, mientras que la forma de agregarlos es como en WXPython.

si, se ponen como en wx python, excluyendo la declaración de una clase para hacerlo pero en fín xd. por otro lado, accesbile output 3? ¿que hace eso? yo conocí la 2 y no sé, existe una 3?
en fín. eso de crear botones desde un menú lo veo altamente innecesario. es como. ¿Dónde quieres que salga el botón? ¿tamaño del botón? ¿uso para el botón (código python)? y tendrías que hacer def on_button(self, event) y poner más código, quitando la plantilla que ya tendrías que hacer para que eso funcione. casi mejor invertir el tiempo en algo para poder crear no sé, bots, armas, o lo que sea que se necesite desde la gui, o si es online, una plantilla para crear menús usando txt, o cosas así que se puedan implementar rápido para poder añadir cosas más rápido, y en la obtimización. osea, no deberías añadir demasiado, sin obtimizar bién lo antiguo. el resultado sería algo muy parecido a EVM, que le pones 4 jugadores jugando y disparándose y obtienes mucho lag

En ningún momento yo mencioné que se agregan botones desde un menú.

Lo que sí había mencionado, es que uno de los módulos que había desarrollado es para hacer las veces de dynamic menu, pero no tiene nada que ver con botones o formularios.

al igual que accessible_output2, accessible_output3 es una emboltura de python de accessible_output3, una librería vinaria escrita en c si no me equivoco, la cual es para darle soporte de accesibilidad a nuestras aplicaciones y o juegos, de tal modo que puedan enviar mensajes para que sean leídos por nuestro lector de pantalla (si este es soportado) o con algún motor tts de no ser así o si no se utiliza un lector de pantalla.

che, alguna noticia sobre eso desde la última?

ostia, tienes algo para dynamic menu? me interesaría, la verdad, ese módulo. escríbeme al privado y lo hablamos si eso. por otro lado, le respondía al mensaje de @zamasu.

me apunto para tester si aún queda cupo

¿noticias sobre qué?

Sobre el juego y los módulos, supongo

En cuanto al juego, todavía me encuentro desarrollando los módulos para acelerar el desarrollo del mismo.

El módulo en el que estoy trabajando ahora es el módulo de la audio interfaz.

Por qué reinventas la rueda si ya está hecho? Paséate por developer rooms en forum.audiogames.net
Vivirás más feliz cuando veas que mucho de tu trabajo lo puedes descargar de github.