Invisible objects and objects with text #69
Conversation
|
Así se vería ahora.
Acá hay un repo que tiene el ejemplo. |
There was a problem hiding this comment.
Me falta contexto para opinar sobre el feature y no conozco cuál es el caso de uso, pero el código parece razonable.
Por mi está OK, aunque yo tenía entendido que eso de que te falle si no le ponés una imagen era apropósito, porque así, si el pibe se olvidaba de ponerlo se lo recordaba (cosa que me parece más frecuente que querer componentes invisibles).
Capaz sería mejor defaultear a que si no tenés imagen siga explotando y darles alguna facilidad para poder crear una imagen transparente, cosa de que tengan que declararlo explicitamente, onda:
method image = game.transparentSi la imagen es transparente la position medio que no importa, con lo cual podríamos seguir requiriendoles ponerla así no hay dudas de dónde dibujar los mensajes.
|
me parecía que cuando no había imagen, el default era el loguito de wollok,
pero no explotaba. No me parece mal que el default sea una imagen
transparente, pero lo del mensaje transparent() también está bueno.
la position es importante en especial para que pueda colisionar, que
entiendo que es el motivo principal de tener visuales invisibles. Un caso
de uso que he visto a veces es rodear de objetos invisibles a un visual,
para que amplíe su radio de colisión.
El mar, 17 de ago. de 2021 a la(s) 19:53, nscarcella (
***@***.***) escribió:
… ***@***.**** commented on this pull request.
Me falta contexto para opinar sobre el feature y no conozco cuál es el
caso de uso, pero el código parece razonable.
Por mi está OK, aunque yo tenía entendido que eso de que te falle si no le
ponés una imagen era apropósito, porque así, si el pibe se olvidaba de
ponerlo se lo recordaba (cosa que me parece más frecuente que querer
componentes invisibles).
Capaz sería mejor defaultear a que si no tenés imagen siga explotando y
darles alguna facilidad para poder crear una imagen transparente, cosa de
que tengan que declararlo explicitamente, onda:
method image = game.transparent
Si la imagen es transparente la position medio que no importa, con lo cual
podríamos seguir requiriendoles ponerla así no hay dudas de dónde dibujar
los mensajes.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#69 (review)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACZRXGZ55VNCY62KFSXAXZTT5LR7RANCNFSM5CCL7HAQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email>
.
|
|
¡Buenas! Creo que dimos por sentado muchas cosas y no explicamos bien lo que estuvimos haciendo. Nuestro objetivo al crear este PR era implementar un feature ya existente en wollok xtext 3. Es decir, ya se había tomado la decisión de que los visuales pudieran no tener imagen (por lo que ahora serían más posicionables que visuales). Los features basados en este PR son los siguientes:
Así se ve en wollok xtext 3:
Y así se ve en wollok ts con los cambios que hicimos:
Como dijo Lucas, un caso de uso posible es querer extender la superficie colisionable de un objeto, así ocuparía más de una celda. Ahora mismo no estoy seguro de qué pasaba si el visual no tenía imagen. Me acuerdo que si el path estaba mal o no la encontraba mostraba el logo de wollok. No recuerdo si explotaba. Si quisiéramos que la imagen sea obligatoria tendríamos que hacer cambios en wollok xtext también. Y ya que estamos quizás esté bueno debatir la idea de reificarla. Se esa manera podríamos tener algo así como su opacidad, lo que permitiría que el objeto sea invisible. U otras cosas de interés, como la capacidad de cambiar su tamaño, espejarla, rotarla, etc. Lo mismo podría ir para el texto. Si lo reificamos podríamos agregar varias características más, como el tamaño de la letra, la fuente, si va en negrita, entre otras cosas. Aunque también se podría seguir por el camino de agregar métodos opcionales que las definan. |
|
@PalumboN Cuando se define una imagen que no se encuentra se muestra directamente el loguito de wko de wollok. Un poco diferente a xtext que te pone un texto encima que dice image not found. Adjunto imagenes: En xtext:
En ts:
Se podría cambiar la imagen pero no encuentro la fotito del wko. Y no sé bien dónde debería agregar la nueva para que se vea como en xtext. |
|
Hice esta imagen para el loguito de imagen no encontrada: Momentaneamente la dejé en la carpeta public, después busco bien como agregarla para que utilice esta como default |
There was a problem hiding this comment.
Hola a tod@s! Dejo algunos comentarios sobre lo que se está haciendo acá:
- Como decían, el mensaje
imagesiempre fue opcional, y lo que pasaba antes era que te dibujaba el logo de Wollok. Esto fue pensado como la imagen default de cualquier objeto, y servía para una estrategia didáctica incremental donde el objeto que ya tenés codeado lo metés al tablero y de pronto se ve (por eso queríamos que se mostrara de alguna manera y no dar la sensación de que no está pasando nada). - Lo que terminó pasando es que la forma en que introducimos WG en clase nunca se hacía uso de este feature. Ya el primer ejemplo está pensado como un juego y ya tiene una pepita con una imagen. De hecho, en el enunciado incremental de WG que estamos diseñando ya comienza con un juego bastante armado que hay que extender.
- Por otro lado, al meter el TP integrador del juego y crear juegos sarpados, a veces les estudiantes necesitaban tener objetos invisibles (por distintos motivos, como las colisiones que comentaban), y era tedioso lograrlo.
- Pero más tedioso era meter textos, donde sí o sí tenían que pasar por una imagen y jugar con eso. Y este es el principal problema que buscaba arreglar Leo en el PR de Xtext.
- Al meter la posibilidad de tener "objetos textuales", lo más probable es que muchas veces no vamos a querer una imagen para estos textos, o sea que habría que configurarlos transparentes. Por eso se decidió cambiar el default de la imagen, y para mí es lo que queremos.
Por otro lado, sí se contempla error cuando tenés un método image() que devuelve un path que no existe, porque posiblemente le estés pifiando a algo, y como siempre tratamos de ejecutar el juego por más que tenga errores, decidimos mostrar el logo de Wollok con el texto de que "no se encontró la imagen".
Esto estaría bueno tenerlo, @ezequielPereyra @AngeliMatias. No sé si quieren hacerlo acá o lo dejamos para otro PR, si quieren cargamos el issue, como prefieran
Dejo data sobre esto:
- Acá está la lógica que busca la imagen a partir del texto y si no existe le pone la de
wko.png. - Esa imagen se encuentra en el repo de Xtext por ahora, pero debería estar en language. Acá es donde se trae las imágenes defaults.
- Si quieren podemos meter la de "Image not found" ahí y usarse, pero en Xtext ese texto se escribe, no forma parte de la imagen :P Si podemos hacer eso genial, me gusta más, sino vamos por la imagen.
Muy buen trabajo gente!! 🚀
Alto PR se hicieron, y tuvieron que meter mano. Les dejo algunos comentarios 👍
src/test/game.test.ts
Outdated
| try { | ||
| gameTest('incomplete visual', 'incompleteVisual', ['games/incompleteVisual.wpgm'], function (interpreter) {}) | ||
| } | ||
| catch(exception) { | ||
| expect(exception).toBeInstanceOf(WollokException) | ||
| } |
There was a problem hiding this comment.
@PalumboN acá nos encontramos con un problemita: Al intentar agregar el visual que explota, explota directamente gameTest, y no llega a pasar a un getVisualState como en los otros. Para agarrar estos casos lo hicimos de esta manera, pero es algo hiper genérico. No se puede llegar a una position sin definir porque es un TypeError. En lang ya hay un test donde se intenta agregar un visual sin position.
There was a problem hiding this comment.
Ahh piola, si eso ya está testeado allá entonces no hay problema. Lo que estaría bueno testear es qué pasa acá con el juego corriendo cuando pasa eso, pero es un test más complicado, lo pensamos después.
Entonces podemos borrar este test y ya estaría para mergear, no?
Resolved #55 based on uqbar-project/wollok#1986