Hace unas días me llegó el anuncio de un nuevo Humble Bundle, el célebre pack de juegos “paga lo que quieras” que sale ocasionalmente. Le eché un vistazo al listado y me llamó la atención uno, Frozen Synapse, una especie de simulador de tiroteos estratégico. Es de los que necesitas pagar más que la media para obtener, pero siendo la media ahora mismo menos de 4€, me lancé (puse $10, de hecho).

La premisa es sencilla, controlas una pequeña escuadra de agentes en escaramuzas contra otros grupos. El juego consta de turnos de 5 segundos, en los que puedes dar órdenes a tus hombres: moverse, apuntar, cubrirse, etc.; le das al play y se desarrolla el turno según las instrucciones.

Las órdenes son relativamente simples y dispones de un modo de previsualización que facilita bastante el diseño de las órdenes… no hay munición, energía, habilidades ni nada; incluso prometen que la simulación es determinista y exenta de azar. Se puede jugar en modo “luz” o “oscuro”, lo que determina si eres omnisciente y ver a tus oponentes siempre o sólo cuando tus agentes tengan contacto visual. Yo sólo he jugado con luz, entiendo que el oscuro lo complicará todo bastante y le añadirá emoción, pero de momento quiero cogerle el truco fácilmente.

Para el aspecto visual, podéis echarle un vistazo al trailer:

, los gráficos son sencillos y atractivos (y como bonus, ¡funciona aceptablemente hasta en mi netbook!).

Debo decir que sólo he echado unas cuantas escaramuzas, las primeras misiones del modo campaña y una partida rápida online, pero de momento me parece un juego fantástico.

Ni cuando tenía mucho tiempo para jugar me atraían los juegos complejos, y ahora que dispongo de pocos ratos para los videojuegos, más aún. Los juegos con mil tipos de unidades, opciones, recursos a gestionar, etc. me cansan y me hacen sentir como si estuviese trabajando de contable más que jugando. Frozen Synapse, en cambio, con muy pocas variables y mecanismos de juego en los que pensar, consigue mucha profundidad táctica. El sistema de turnos le da bastante emoción a la cosa, y de momento parece todo bastante equilibrado. Me recuerda mi parte favorita del UFO: Enemy Unknown, los tensos tiroteos, sin los (para mi) tediosos interludios de gestión de recursos.

Si buscáis un juego táctico sin complicaciones pero con dosis de emoción, creo que Frozen Synapse es una excelente opción… y es tan barato que casi no entraña riesgo.

Hablando de bases de datos relacionales, es común referirse al esquema de datos como la definición de las tablas, vistas, funciones, etc. que conforman la base de datos*. El esquema es sumamente importante, por supuesto, nos define qué datos admitimos y nos condiciona todo código que accede a la base de datos.

Este es un esquema explícito; está ahí, podemos enumerar los objetos de los que se compone y conocer milimétricamente su estructura; podemos saber qué tablas hay y qué columnas tienen, etc.

Ahora bien, supongamos que cogemos una aplicación que usa una base de datos y de repente, ocultamos el esquema. Asumamos por un momento que no podemos saber qué tablas hay, ni qué columnas, ni nada. Aún haciendo este gran cambio, nuestra aplicación seguirá funcionando**. Aún más, si desconectamos todas las restricciones de integridad y admitimos que se inserten valores en columnas que no existen (e incluso los almacenamos)… nuestra aplicación muy probablemente seguirá funcionando correctamente.

La primera observación interesante que podemos hacer es que aquello a lo que llamábamos el esquema de datos puede que no esté ahí, pero los datos que tenemos almacenados seguirán siguiendo el anterior esquema de datos. La programación seguirá condicionada por ese mismo esquema; seguiremos insertando en las tablas y columnas que definía el esquema.

El esquema de datos original que habíamos declarado explícitamente ya no existe, pero el esquema de datos implícito sigue ahí. Los datos continuan cumpliéndolo y el programa sigue regido por él. Existe, por tanto, un esquema implícito que podríamos deducir con bastante certeza observando los datos almacenados y el código que los manipula.

Siguiendo con este experimento, podríamos preguntarnos… ¿no hemos perdido nada, verdad?

Aparentemente, no. En cuanto a funcionamiento, quizá ocultemos y amplifiquemos algún defecto que ya existía (la base de datos aceptará datos inválidos cuando antes los rechazaba, y muy probablemente, no nos daremos cuenta), pero realmente no habremos perdido mucho.

Pero cuando nos llegue el momento de modificar o ampliar el código, sí tendremos un problema: al no poder consultar el esquema, se dificultará mucho nuestra labor. El esquema explícito era eso: explícito, claro, fácil. El esquema implícito sigue ahí, pero está oculto. Lo duro es que antes bastaba con ajustarnos al esquema explícito de los datos, que estaba delante de nuestros ojos, pero ahora seguimos teniéndo que seguir un esquema de datos implícito, mucho más críptico. Tendremos que mirar los datos almacenados o el código para saber cómo se llamaba cada tabla y cada columna, y esta información muy probablemente no esté centralizada.

Por supuesto, hay un caso en el que sí seguirá disponible. Si usamos un algo como un ORM, podremos contar con otro esquema explícito de datos; la definición del ORM -e incluso en algunos casos podremos reconstruir perfectamente el esquema a partir de la definición del ORM- claramente son conceptos si no equivalentes siempre, muy cercanos***. Si este esquema es suficientemente bueno, podría suplir perfectamente al esquema explícito de las bases de datos (e incluso mejorarlo: podría permitirnos expresar un esquema de datos más restringido).

Podríamos decir que el esquema de datos explícito de la base de datos no es estrictamente necesario, pero ciertamente, un esquema de datos explícito es una herramienta muy útil, quizás no tanto para el funcionamiento de las aplicaciones como para su codificación y mantenimiento.

Adicionalmente, es bien cierto que puedan existir datos que no se ajusten al modelo relacional -cuya estructura o restricciones sean sumamente especiales (normalmente por ser extremadamente laxos), pero aunque esto fuera cierto, seguirían teniendo un esquema implícito (o incluso explícito, si la herramienta que usáramos en sustitución de la base de datos lo permitiera o requiriera, o si nosotros  decidiéramos escribirlo) y, igual que en el caso relacional, no disponer de un esquema explícito nos entorpecería las labores de mantenimiento y extensión del código.

Así pues, aunque es posible que un esquema relacional no sea lo más adecuado para nuestros datos, es falaz concluir que la ausencia de un esquema explícito es una ventaja -el esquema implícito sigue existiendo y nos debemos ajustar a él- y es más fácil ajustarse a algo explícito y claro que a algo implícito y oculto.

* en algunos gestores de bases de datos, el término se confunde un poco porque se pueden separar los objetos de la base de datos en “esquemas” para gestionarlos mejor

** las bases de datos permiten a las aplicaciones consultar el esquema [explícito]; hay aplicaciones que utilizan esta funcionalidad (para permitir su personlización mediante la creación de nuevas tablas, etc.); en este poco frecuente caso, dejarían de funcionar, claro

*** lo que nos debería llevar a pensar que uno de los dos es redundante e innecesario

corregido por el de siempre