Ésta es la historia de creación de un app que participó en el Reto BlackBerry, contada por su propio desarrollador, un joven estudiante de la carrera de Ingeniería en Computación de la ESIME Culhuacan.
Planeación, como fue!
El evento de apertura fue el día 9 de junio de 2012, donde previamente me inscribí al reto vía Internet, me entere gracias a unos compañeros de la escuela ESIME y previamente platique con un compañero de la escuela ESCOM y con otro compañero de la escuela UPIICSA, los 3 relacionados con carreras de ingeniería en computación, informática y sistemas computacionales, hicimos equipo bajo la mesa para poder obtener cada uno una Tablet, pues si hacías un equipo dentro de la pagina 7bberries la cual sirvió como un foro de ayuda y control para los datos de vendedor e ID de aplicación, se nos fue entregada una USB la cual contenía los programas que utilizaríamos para poder programar, digamos, los programas mas básicos para poder realizar un videojuego en las plataformas propuestas por el reto.
Training actionscript
Decidí hacer mi videojuego en AS3 (actionscript 3.0) utilicé archivos flash previamente programados y exportados al compilador flash builder con extensión SWC, se utilizo el SDK de adobe AIR.
El aprendizaje fue complementado con tutoriales de Internet, dependiendo de lo que deseaba hacer, tomando en cuenta el tiempo que me quedaba tras cada día que transcurría y lo que había logrado el día en curso o los días anteriores, el avance fue medido cautelosamente para poder obtener un videojuego aceptable pues fue este el primer videojuego que había realizado, y aun mas, en una plataforma de dispositivos móviles, y aun mas, sin saber as3 ni un manejo de la paquetería multimedia de adobe. Fue realmente un reto alcanzar una aplicación finalizada siendo que no sabia nada en lo absoluto de como es que se realizaba un videojuego.
Hubo hackatones en los cuales contábamos con asesoría para saber acerca de los temas que podíamos investigar conforme a los problemas y paginas de Internet.
En un momento todo fue ocurriendo naturalmente, el desarrollo, la programación y el diseño se complementaron hasta poder obtener el videojuego, realmente no se tuvo una planeación muy especifica ni determinada pues el tiempo estaba comiendo la ampliación del videojuego.
Diseño gráfico
Para el diseño se utilizaron programas avanzados en diseño gráfico como photoshop, Fireworks, flash, audacity, format Factory entre otros, los cuales uniéndolos y utilizándolos de forma complementaria me sirvieron para poder hacer ediciones, animaciones, creación de imágenes, sonidos y canciones, botones, y muchos otros elementos dentro del videojuego.
Desde lápiz y fotografías e imágenes hasta pincelazos en programas digitales las imágenes se fueron formando para poder formar parte de botones, animaciones, fondos de pantalla, etc… En la edición de estas se utilizo photoshop y Fireworks para poderlas adaptar en su mayoría a animaciones exportadas a flash y en la mayoría de los casos pre- programadas en flash para posteriormente volverlas a exportar como archivos swc al compilador flashbuilder donde eran nuevamente programadas para su uso final en una implementación de ideas previas.
Los sonidos fueron editados y creados desde mezcladores de Internet y aplicaciones gratuitas donde se obtenían archivos de audio para posteriormente editarlos en audacity, ya fuese cortar la duración, armar nuevos sonidos o simplemente insertar efectos sobre estos; esto fue en su mayoría una combinación de todos estos elementos mencionados.
Código
El código fue bastante interesante, este lenguaje AS3 es un derivado de java según lo que los expertos desarrolladores de BlackBerry mencionaron, este lenguaje de programación permite hacer animaciones por medio de código lo cual fue en mi opinión un detalle muy importante, elemental y útil para la realización de movimientos en el juego, se utilizó otro tipo de comandos igual interesantes que no se encuentran propiamente en java o algún otro lenguaje, incluso en el AS2, este lenguaje (AS3) es una mejora del AS2 pues es una continuación de este mismoEvaluación tiempo
El tiempo fue evaluado de forma gradual, no se tuvo un plan determinado tan serio a seguir nunca, se sabia que las capacidades para realizar el videojuego no iban a ser profesionales por el tiempo ni por la experiencia pues en ese momento era nula, entonces conforme se avanzaba se iban tomando en cuenta aspectos extras del videojuego sin olvidar que el objetivo era hacer el videojuego y no solo quedarse en los menús por decir algo.
Hubo muchas trabas para poder lograr lo que se logro, pues el conocimiento de como se hacían ciertas cosas no estaba presente, lo cual retrasaba las expectativas de un videojuego competitivo frente a una selección final como ganador regional.Compilación
La compilación del videojuego se hacia en el programa flash builder el cual nos decía los errores de sintaxis y los errores de semántica salían conforme no se obtenían resultados que se pretendían obtener, igualmente con este programa se firmo la aplicación con claves únicas especiales las cuales se deben pedir a BlackBerry para que el programa contenga información principalmente de identificación por parte del desarrollador y un numero de identificación único de la misma aplicación.
CONSEJOS
¿El mejor consejo que podría dar?, es que las cosas se deben por lo menos intentar, pues a los dormidos les gana el sueño en esta vida, el hecho de intentarlo te da probabilidades de poderlo lograr, y esas probabilidades aumentan cuando te apoyas con gente que busca lo mismo que tu, tal vez que no sepan, pero que quieran lograrlo, con eso es suficiente.
En días pasados, la compañía BlackBerry nos visitó en ESIME Culhuacan para invitar a los jóvenes estudiantes al ‘Reto BlackBerry’ el cual consistió en desarrollar una aplicación en la categoría de ‘Juegos y Entretenimiento’ para Black Berry. Tuvieron 3 meses de cursos, soporte, herramientas, contenido para la aplicación.El evento inició el 9 de Junio, y finalizó el 3 de Seotiembre. Héctor Alonzo Romero Valdes, alumno de Ingeniería en Computación de ESIME Culhuacan (turno vespertino), participó en este evento.
Reto BlackBerry
Héctor Alonzo. ESIME Culhuacan. Ingeniería en Computación
Una vez aceptado el Reto . . . . todo inició así :
[Reto BlackBerry México - Evento Inauguración ]
En la escuela hubo cursos de actualización para quienes decidieron aceptar el Reto Blackberry patrocinado por Sferea .mobi
Aula Siglo XXI ESIME Culhuacan
Alonzo desarrolló su app que aparece en la página BlackBerry
Hubo 2 finalistas de ESIME Culhuacan que participaron en el Reto BlackBerry
el otro compañero es Everardo Sánchez de ICE. Felicitaciones Everardo!!!
Se realizaron 2 Hackathones , este es el vídeo del primer Hackathon
sin lugar a dudas un evento en el que se construyó conocimiento.
Reto BlackBerry México – 1er Hackathon
Alonzo se hizo acreedor de una Tablet, siempre nos dice en clase: “El conocimiento sin compartir, no sirve. ”
Alonzo nos cuenta . . .
Este videojuego que hice llamado Tuga Tacon trata de una tortuga indefensa la cual debes proteger de unos enemigos inventados que se llaman SLIPS c: ; fué algo complicado el proceso de cada etapa de realización del videojuego, mencionaré algunos programas que utilizé para la realización:
Photoshop; Fireworks; Flash; FlashBuilder; todo esto de Adobe; Audacity; FormatFactory; entre otros
Estos fueron los principales programas donde aprendí y reafirmé algunas cosas como hacer animaciones, edición de imágenes, creación de imágenes, exportar tipos de archivo SWC cosa que no sabía siquiera de su existencia, edición de sonido, saber el proceso de cómo se sube y hace una aplicación, firmado digital de aplicaciones, ID de producto y de vendedor, creación de más de varias cuentas para hacer sus tramites x), lenguaje de programación actionscript 3.0
En fin, aprendí demasiadas cosas, invertí en este proyecto unas 400, 600 horas sin mentir, pues el proceso de cada detalle es demasiado tardado, y aún mas la implementación de algo que no sabes como hacer, requiere demasiada búsqueda e investigación.
Asistí a “hackatones” los cuales surgen de california, EUA ; estos tienen como fin una especie de maratón de programación, donde nos daban asesoría con dudas o simplemente, nos prestaban la tablet para probar en vivo nuestra app , incluso entre a la comunidad de desarrolladores de BlackBerry, donde hacemos pequeñas conferencias, nos ayudamos entre nosotros, etc. Esto es nuevo en blackberry.
En la apertura de este evento sólo eramos unos 30, estuve en Internet buscando tutoriales e información como jamás lo había hecho, el código fuente del videojuego tiene de 2000 a 3000 lineas, dibuje en papel algunas cosas, las pasé a la compu y mejoré ahí, en fin invertí todo mi tiempo libre en vacaciones a esto y pues espero y alguien mas se anime a preguntarme algo, lo que sea.
Espero que el evento se repita para el siguiente año para poder hacer una aplicación que compita para el primer lugar, igual alguien que quisiera aprender algún detalle de la aplicación, no se LO QUE SEA QUE QUIERAN SABER! igual puedo enseñarles a hacerlo, para eso estamos, la aplicación tiene modos de idioma, español por supuesto, inglés cosa que no puede fallar, alemán idioma favorito ? y francés idioma que pretendo empezar a estudiar no en mucho; si es que todo sale como se supone que saldrá y obtengo la tablet les enseño el videojuego a todo color y en vivo.
Porque el conocimiento sin compartir, no sirve.
. . . OH Si xD cada evento era en el hotel Sheraton sobre reforma, nos trataban como reyes c: nos daban comida y desayuno cada hackaton o cada evento, y los panes con relleno de chocolate fueron lo mejor hahahahha , en verdad una experiencia única, espero que si este evento se repite el siguiente año, se animen a participar, igual y hasta hacemos equipo :) .
Es una simulación del uso de GIT, está en inglés pero está fabulosa
Ideal para el desarrollador autodidacta (casi todos lo son)
Según wikipedia:
El diseño de Git resulta de la experiencia del diseñador de Linux, Linus Torvalds, manteniendo una enorme cantidad de código distribuida y gestionada por mucha gente, que incide en numerosos detalles de rendimiento, y de la necesidad de rapidez en una primera implementación.
Entre las características más relevantes se encuentran:
Fuerte apoyo al desarrollo no-lineal, por ende rapidez en la gestión de ramas y mezclado de diferentes versiones. Git incluye herramientas específicas para navegar y visualizar un historial de desarrollo no-lineal. Una presunción fundamental en Git es que un cambio será fusionado mucho más frecuentemente de lo que se escribe originalmente, conforme se pasa entre varios programadores que lo revisan.
Gestión distribuida. Al igual que Darcs, BitKeeper, Mercurial, SVK, Bazaar y Monotone, Git le da a cada programador una copia local del historial del desarrollo entero, y los cambios se propagan entre los repositorios locales. Los cambios se importan como ramas adicionales y pueden ser fusionados en la misma manera que se hace con la rama local.
Los almacenes de información pueden publicarse por HTTP, FTP, rsync o mediante un protocolo nativo, ya sea a través de una conexión TCP/IP simple o a través de cifrado SSH. Git también puede emular servidores CVS, lo que habilita el uso de clientes CVS pre-existentes y modulos IDE para CVS pre-existentes en el acceso de repositorios Git.
Los repositorios Subversion y svk se pueden usar directamente con git-svn.
Gestión eficiente de proyectos grandes, dada la rapidez de gestión de diferencias entre archivos, entre otras mejoras de optimización de velocidad de ejecución.
Todas las versiones previas a un cambio determinado, implican la notificación de un cambio posterior en cualquiera de ellas a ese cambio (denominado autenticación criptográfica de historial). Esto existía en Monotone.
Resulta algo más caro trabajar con ficheros concretos frente a proyectos, eso diferencia el trabajo frente a CVS, que trabaja con base en cambios de fichero, pero mejora el trabajo con afectaciones de código que concurren en operaciones similares en varios archivos.
Los renombrados se trabajan basándose en similitudes entre ficheros, aparte de nombres de ficheros, pero no se hacen marcas explícitas de cambios de nombre con base en supuestos nombres únicos de nodos de sistema de ficheros, lo que evita posibles, y posiblemente desastrosas, coincidencias de ficheros diferentes en un único nombre.
Realmacenamiento periódico en paquetes (ficheros). Esto es relativamente eficiente para escritura de cambios y relativamente ineficiente para lectura si el reempaquetado (con base en diferencias) no ocurre cada cierto tiempo.