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

No hay comentarios.:

Publicar un comentario