domingo, 27 de marzo de 2016

Mini-juegos terminados! | Mini-games finished!

Español | English

Luego de tanta tarea y tanto estudio pude volver a trabajar en mi juego para continuar donde había dejado antes, en los mini-juegos. El problema que tenía que resolver era sobre buscar una forma de que las opciones en los mini-juegos de preguntas y respuestas tomen lugares aleatorios cada vez que se cargaba una nueva pregunta.

Uno puede pensar que esto es sencillo ya que le debemos decir al juego que agarre cualquier elemento de la lista de opciones utilizando la herramienta Random.Range(), lo cual es casi acertado ya que hay una sutileza, si utilizamos esta herramienta en el Update() del juego, va a realizarse todo el tiempo. El efecto que crea es que, cuando se carga una pregunta, las opciones se estén cambiando constantemente.

Luego de mucho pensar sobre esto, encontré una sencilla solución que era restringir la función para que ocurra una sola vez, entonces al cargar una pregunta, la función agarra cualquier elemento de la lista de opciones y se lo asigna a un botón, una vez que ya le asignó a todos los botones, se detiene.

Pero esto trae nuevos problemas: ¿Qué pasa si justo se elige el mismo elemento para 2 botones distintos? Como la función es aleatoria, esta probabilidad era bastante grande, por lo que tuve que crear una función que analice si la opción que tiene el botón es única, si es repetida, que la opción se genere de nuevo.

Con esto ya todo solucionado pudimos terminar este inconveniente pero nos quedaba la última complicación, las preguntas se podían repetir. Al igual que con las opciones, las preguntas son elegidas aleatoriamente de una lista de preguntas. Para solucionar esto lo que hice fue crear un listado, en el cual iba a contener como elementos las preguntas que ya se hicieron, de este modo, al generar una nueva pregunta, primero debe analizar la lista para ver si la pregunta no se hizo antes, en el caso de que ya se haya hecho, se genera una nueva pregunta.

De este modo entonces se resolvieron todas las problemáticas que surgían con los mini-juegos, que eran principalmente dadas por utilizar métodos aleatorios para seleccionar los elementos. Lo único que quedaría por mejorar sería la transición de una pregunta a otra, aunque para esto se puede crear un cartel que diga "Correcto" cuando uno acierta, mientras, en el fondo, se genera la nueva pregunta. 

Ya que tengo los mini-juegos creados, una de mis próximas entradas será una guía técnica sobre como crear un tipo de mini-juego en Unity con todas las mejoras y "trucos" que conté en esta entrada.

-L

----------------------------------------------------------------------------------

English


Finally, after a lot of homework and after studying, I could came back to work on my game to continue from where I left it, the mini-games. The problem that I had to solve was about finding a way in which the options of the quiz mini-games take random places whenever a new question was loaded.

One can think that this is simple as we can tell the game to grab any element from the options list using the Random.Range() tool, which is almost true but there is one little problem, when we use this tool on the Update() function of the game, it is going to be done all the time. This creates the effect that, when a question is loaded, the options are constantly changing.

After giving it a lot of though, I found a simple solution which is restricting the function so it is done only once, so, when the question is loaded, the function will grab a random element from the options list and assign it to each button, once every button has its own option, its stops.

But this brings new problems as: What if the same element is chosen for two different buttons? As the function is random, it is very probable that this could happen, so I had to create a function that analyzes each if  each button's option is unique, if it is not, make that option to be generated again.

With all this solved, there was one last problem, the questions can be asked twice. As with the options, the questions are picked randomly from a list of questions. To solve this, what I did was to create a new list, on which, each element are the questions that were already made, this way, when generating a new question, it first needs to analyze if the question wasn't ask before, if that is the case, a new question will be generated.

By these means, all the problems that came with the mini-games are solved, which were mainly caused by using random methods to select the questions and answers. The only thing that could be done better is the transition from one question to the new one, which for this I could use a message that says "Correct" one the player when one succeeds, meanwhile, in the background, a new question is generated.

As I have all the mini-games created, one of my next entries is going to be a technical guide teaching how to create quiz mini-game in Unity with all these fixes and "tricks" I've mentioned.

-L

domingo, 20 de marzo de 2016

Al fin de vuelta a trabajar! | Finally back to work!

Español | English

Finalmente pude crear un hueco en el que pude trabajar en mi proyecto, decidí enfocarme en solo 1 aspecto para resolver ya que tengo que seguir estudiando, por lo que elegí arreglar la aleatoriedad de las opciones que se muestran en los mini-juegos.

El problema: Ya hablado varias veces, el problema era que siempre se mostraban las mismas respuestas en los mismos lugares. Lo que quería hacer era modificar la función que asigna las posiciones para que cada opción sea única, pero esto no era posible (o no he encontrado la forma) ya que se trataba de un ciclo For, por lo que no podía tratar a las opciones por separado sino que todas juntas.

La mejor opción que se me ocurrió (que era la solución que esperaba evadir) fue de crear una función que evalúe a cada opción, en caso de que la opción A sea igual a la opción B, que la opción A se genere devuelta y así para todas las opciones.

No quería utilizar este método ya que tanto escribirlo y como procesarlo es largo, ya que son varias estructuras If, por lo que traté de evadirlo lo más que pude pero al final resultó ser el método más efectivo para solucionar este problema. Ahora el resultado es como planeaba, las opciones se muestran en posiciones aleatorias cada vez que se abre el mini-juego.

-L

---------------------------------------------------------------------------------------
English

Finally I could create a gap where I could work on my project, I decided to focus in only 1 aspect to solve as I have to keep on studying, so I decided to fix the randomness of the displayed options of the mini-games.

The problem: As I've mentioned several times , the problem was that the same options were displayed on the same positions. What I wanted to do was to modify the function that assigns the positions to each option so each option is unique, but I this wan't posible (or I hadn't find the way) as I was dealing with a For function, so I couldn't treat the options separately but all together.

The best option that ocurred to me (which I was trying to avoid) was to create a function that evaluates each position, in case that option A is the same as option B, option A will be generated again and so on for every option.

I didn't want to use this method because both writing it and process it is long, as they are several If structures, that's why I tried to avoid it the most I could but it in the end it turn out to be the most effective method to solve this problem. Now the result is what I've planned, the options are shown in random positions every time the mini-game is started.

-L

sábado, 19 de marzo de 2016

Ocupadísimo | Very busy

Español | English


Primero que todo pido perdón por no haber escrito nada desde hace ya varios días, el motivo es que estoy sobre-cargado con tarea de la facultad que debo priorizar antes que el juego.

Por suerte estoy cerca de terminarla y si todo sale acorde lo planeado, mañana podré dedicarle tiempo a mi juego para arreglar las cosas de las que mencioné en mis ultimas entradas.

Parte del tiempo de desarrollo que había planeado, lo había pensado que cosas como estas podían pasar, por eso había planeado un lapso de 3 meses, de los cuales, contando días de desarrollo, el juego tuvo un poco más de dos semanas, por lo que vamos bien encaminados.

Hay que recordar también que las cosas que nos faltan no son muchas! Como hablé en la entrada anterior, falta corregir y agregar un par de cosas para tener todos los elementos, una vez que estén todos, quedaría darle la forma final al juego y crear todo le arte.

Pero por ahora, de vuelta con el estudio para poder seguir con mis planes y mañana poder seguir trabajando en mi proyecto.

-L

--------------------------------------------------------------------------------------------

English
 
 
First of all I apologize for not writing anything from several days ago, the reason is that I'm overloaded with homework of the University which I must to prioritize before the game.
 
Luckily I'm close to finish it and I everything goes as planned, tomorrow I'll be able to dedicate some time to the game and fix all those things I've mentioned on the previous entries.

Part of the development time I've chosen, I've chosen it knowing things like this might happen. That's why I've chosen a time lapse of 3 months, from which, counting development days, the game has a little more than two weeks, which means we are ok.

What we need to remember si that there are few things remaining! As I've mentioned on the previous entry, I need to fix and add some few things to have all the needed elements and when they are all set, all we need is to shape everything and start creating the art.

But for now, I go back to study so I can keep up with my plans and tomorrow be able to get back on my project.

-L

miércoles, 16 de marzo de 2016

Análisis de Sistema de puntuación para Nerdy Run | Nerdy Run score system analysis

Español | English



Como hoy tampoco pude dedicarme a trabajar en mi juego, me tomo el tiempo para planear las cosas que voy a hacer o analizar los hechos para aprovechar el tiempo. Un tema que puede ser un poco discutible sería sobre que sistema de puntuación usar.

Esto depende totalmente del juego, para mi anterior, lo que se me ocurrió fue utilizar la distancia en X que el jugador recorrió para medir la puntuación, que llevó a que el objetivo del juego no sea juntar mayor cantidad de puntos posibles sino recorrer la mayor distancia posible. En otros tipos de juegos podemos utilizar el tiempo o directamente crear objetos o acciones que nos den puntos y en base a cuantos objetos recolectamos, depende nuestra puntuación.

El juego va contener varios elementos de distintos tipos de juegos, tenemos el Infinite Runner, tenemos objetos que podemos agarra para acumular puntos y tenemos los mini-juegos. Aunque como hablé antes, los mini-juegos puede estar para limitar nuestro avance, haciendo que el jugador pierda si pierde un mini-juego. Pero dado todos estos distintos tipos de elementos tenemos que elegir por un sistema que nos permita puntuar al jugador de una manera lógica, tampoco queremos que el jugador por pisar una piedra gane +1000 puntos.

Lo que se podría hacer entonces es de nuevo tomar la distancia en X recorrida por el jugador pero a esta, modificarla. Podríamos hacer algo como distancia * Time.deltaTime , lo que va a reducir el valor total de la distancia a valores más pequeños de 100, que luego se pueden sumar con otros puntos que obtengamos al agarrar objetos.

También podemos tomar otra perspectiva y no hacer que el jugador gane puntos a medida que avanza sino a medida que agarra cierto objetos y/o cuando el jugador gana un mini-juegos. Lo que no me gusta mucho de este tipo de puntuación es que la puntuación es lineal, refiriéndome a que da "saltos", de la anterior manera, utilizando la distancia recorrida, la puntuación varía constantemente.

Teniendo estas dos posibilidades (hay mas posibilidades, pero estas dos son las que más me agradan para mi juego), queda por analizar haciendo pruebas, viendo si utilizando la distancia nos da valores no muy altos ya que no queremos una "inflación" de puntos, haciendo que en una partida promedio el jugador gane más de 10.000 puntos. Por lo que un par de pruebas con los dos sistemas resolverían este debate, aunque mi apuesta iría hacia utilizar la distancia recorrida ya que, como dije antes, el valor de la puntuación varía constantemente en vez de en forma lineal.

-L

-------------------------------------------------------------------------
English



As today I couldn't dedicate any time to the game, I take this time to plan the things I'm going to do in order to save time. A topic that can be a little bit arguable is which scoring system should the game use.

It always depends on the game, on my last game, what I decided to do was to use the reached distance of the player along the X axis to measure the score, which led the objective of the game from being to collect the highest amount of points available towards reach as far as you can. In other type of games we can use the time or just using objects or actions which will gave the player points and depending on how many objects we collect, we get our score.

The game will contain many elements which belong to different types of games, we have the Infinite Runner, we have objects to grab and add points and we have the mini-games. Although as I spoke before, the mini-games may be only to limit how much we are going to advance, making the player loses if he/she loses the mini-game. But for all those elements, we need to find a common system which let us give logical scores, we don't want the player to score +1000 for stepping on a rock.

What I can do is to use again the distance travelled along the X axis and modify it. We can make something like distance * Time.deltaTime, which will reduce the total value of the distance to values smaller than 100, which I can then use to add more points with the objects we grab.

We can also take another perspective and don't make the player earn points as long as he/she advances but if he/she grabs certain objects and/or when he/she wins the mini-games. What I don't like too much about this scoring system is that the score is lineal, meaning that it leaps, with the previous way, using the travelled distance, the score varies constantly.

Having these two alternatives (there are more possibilities but these were the those which I though were more suitable for the game), all that it's left is to make some tests, to see if using the travelled dinstance gives us values not too high as we don't want a score "inflation", meaning that we can't make the player earn 10.000 on an avarage game. For which some tests with each system will solve this debate, although if I would bet, I would bet on the travelled distance method because, as I said, the value of the score varies constantly rather than in a lineal way.

-L

martes, 15 de marzo de 2016

Explicando problemas de aleatoridad en Nerdy Run | Explaining problems with the random factor on Nerdy Run

Español | English

Hoy ya que no pude trabajar en el juego, dedico esta entrada para explicar con más detalle el problema que tengo y en el cual me había trabado. Se trata sobre la aleatoriedad de las preguntas en los mini-juegos de preguntas y respuestas. Estoy cerca de crear el tan prometido tutorial de como crear el mini-juego de preguntas y respuestas pero para eso primero quiero resolver esta problemática que se puede evitar fácilmente o no dependiendo el caso.

Lo que tenemos es obviamente una cantidad de preguntas, cada una con sus respuestas y la función que llama a las preguntas. Esta función debe ser aleatoria (a menos que se busque un patrón específico de preguntas) ya que en este tipo de juegos siempre vamos a querer preguntas nuevas para el jugador.

Lo peor que nos puede pasar (que es la situación en la que me encuentro yo) es que una pregunta se muestre dos veces seguidas, "regalandole" un punto extra al jugador. O también, que las respuestas estén siempre en el mismo orden, ya he hablado de como afecta esto, si las preguntas son siempre las mismas y sus respuestas están siempre en el mismo orden, el juego se convierte en un juego de memoria.

Pero como mencioné antes, esto puede no ser un inconveniente si contamos con una gran cantidad de preguntas, haciendo que la cantidad sea tan grande que la posibilidad de que se repita una pregunta sea muy poca. Hacer esto requiere tanto a pequeña como a gran escala una gran necesidad de almacenamiento en donde guardamos estas preguntas y sus respuestas. Si bien me pueden argumentar que a pequeña escala se pueden usar grandes variables de tipo Array, esto también nos genera un aumento en el peso del archivo total, además la cuestión de si la lógica del juego es muy "larga" en el sentido de que debe checkiar si la respuesta es correcta dentro de (ej) mil respuestas, se va a crear una gran dependencia de procesamiento. 

Lo que veo más conveniente a pequeña escala es el uso de algún tipo de lógica matemática que reduzca las chances de que se repita una pregunta. Aunque pueda ser difícil de pensar, para un mini-juego de aproximadamente cinco preguntas es una solución muy viable. Todo esta dificultad surge por el hecho de que no tenemos control sobre la aleatoriedad de la función cuando le decimos al juego "elegí una pregunta de entre estas 5". Tanto la rotación de las preguntas como de sus respuestas son una gran característica que disminuye la repetitividad de un juego.

-L

----------------------------------------------------------------------------------
English


As today I couldn't work on the game, I dedicate this entry to explain with more detail the problem that I'm having and where I got stuck. It's about the random factor in the quiz mini-games.n I'm close to write the much promised tutorial of how to make a quiz game, but first I need to solve this problem which can be easily avoided or not, depending the case.

What we have obviously is a set of questions, each one with it's possible answers and the function that calls the questions. This function needs to be random (unless what I'm looking for is to create a certain pattern) as for this type of game we will always want new questions for the player.

The worst thing that can happen to us (the situation where I'm currently at), is that the same question is shown twice, giving away an extra point for the player. Or also, having the answers always be shown in the same position, I've spoken about how this is bad before, if the questions are always the same and the answers are on the same position every time, the game beomes a memory game.

But as I mentioned before, this shouldn't be a problem if we rely on a big quantity of questions, making the database so big that the chance for a question to repeat itself. Doing this requires both for  big or small scale a high need of memory, where we will store the questions and their answers. Although one can argue with me and tell me that we can use huge Array type variables, which they will also make a remarkable incraese on the APK's file size. Also, if the logic that the game uses is too "long", as to make the game check the answer between a thousand possible solutions, it will create a big need of the processor.

What I think it's more suitable for small scale is to create some sort of mathematical logic which will reduce the chances of making a question repeat. Although it could be hard to think of, for a small quiz mini-game of about five questions, it's a very suitable option. All this difficulty comes from the fact that we don't have control over the game random decision as we are telling the game "choose one question between these five". Both the rotation of the questions as the rotation of the answers are a big characteristic that reduces the fact of repetitivity of a game.

-L