2017: a hectic year

To sum it up: lots of time in contract jobs, which is great, but no game of our own – so we couldn’t fulfill our game-a-year goal,  something we’ve achieved since we begun this adventure in 2009…

So what did we do in 2017?

  • Pixel Cuties, the cutest Sokoban-inspired game ever. Unfortunately, by April we handled the code to a different team and it seems the game has not been released yet :'(
  • For the same client, we worked on the update of the iOS and Android Barbie game, and an update of a Steam game.
  • We keep working on Facetopo, an ongoing research project related to facial landmarks mapping and genetics.
  • We worked on three minigames for Cleo, to be released in ClanTV early in 2018
  • We imparted Game Design, and Unity programming lessons in the Game Design and Development postgrade in the University of Las Palmas de Gran Canaria.
  • We keep mentoring attendees at Island Jam, a local 48h Game Jam that takes place at the same time as Ludum Dare, helping groups to develop their games.
  • We’ve been working most of the year in an HTML5 educational platform with minigames and competitions for a multinational corporation. Unfortunately we can’t show it, or we would be forced to dispose your corpse. But feel free to ask us about it in a private conversation!

It’s been indeed an interesting year: working with legacy code; learning Phaser to create HTML5 games; using node with Aurelia, Phaser, Loopback and Postgresql for a full stack web app with minigames (the educational platform); dealing with server security to satisfy our client’s demands… and of course sharpening our Unity skills.

And sure, we couldn’t release a game of our own, but that doesn’t mean we didn’t work on a few prototypes! Plus, we learned how to work with our own Entity-Component-System framework, got acquainted with ScriptableObjects and learned a few shader tricks.

See you in 2018, it’s gonna be an interesting year!

The Heat is On

Something I enjoyed a lot in Battletech games was handling overheat. A well aimed CPP shot could blow a mech up in a blink. CPPs, however, raised your mech’s heat a lot, and an overheated mech would switch off for a while. Installing enough heat sinks allowed you to control heat, but also standing knee deep in water or fighting on icy regions.

Mechwarrior 4
Standing knee deep in a river of PEWPEWPEW!

We wanted something like that, so we created the Heat component & system. Entities that may overheat and malfunction have a Heat component to keep track of their temperature. Laser weapons, for instance.

Heat components store an entity’s current temperature in a simplified way, with values ranging from 0 (operating temperature) to 1 (maximum operating temperature). Their dissipation rate is used by the Heat system to lower temperatures constantly. Any system that may increase the entity’s temperature will do so by adding an operating heat when used. External factors like flying close to a star can increase temperatures too.

We tested it with laser weapons. When triggered they increase the current temperature by their operating heat. If heat raises above 1 the laser weapon is jammed until temperature falls down back to zero.

We also added the LaserWeaponGunner component&system, which are able to shoot laser weapons when certain conditions are met: there is a locked target in the Entity Targeter Component and temperature is low enough in the Heat component. In this example the gunner ignores temperature and jams the laser weapon.

Laser weapon gunner and overheat

And so we have defense satellites!

We like our ECS DRY with a pinch of SRP. Shaken, not stirred.

We are still trying to figure out how to properly work with ECS, still unsure about what makes a good System in an ECS.  So far we are following two rules:

  1. “A System that does more than one thing can be probably divided into many Systems”, which follows the SRP (single responsibility principle)
  2. “If a piece of code appears in more than one System, it’s probably a System on its own”, which follows the DRY principle (Don’t Repeat Yourself, avoid code duplication).

Both or which are two key software principles anyway, so it probably won’t hurt.

Following #1, we separated the system that was previously responsible for rotations and movement into SpaceFlightSystem, which just updates velocities and an entity’s position in three dimensions, and HeadingSystem, which is now responsible for rotations. We also keep track of user input in separate systems and components (flight & heading), so we are able to control entities that move and rotate (spaceships), but also those that don’t move but rotate… like turrets. Here’s an early test:

Manned turret

We also decided that many entities would be interested in ‘going somewhere while heading toward somewhere else’, an action shared by behaviours like traveling, patrolling, chasing or surrounding an enemy. Thus the ApproachManeuverComponent & System were born, which we tested spawning a tracking missile:

Tracking missile

A bit of code refactoring allowed us to simplify the way we check and fetch entity components thanks to C#’s TYPE class. But we’ll write about that when we are sure our ECS implementation makes sense, if that ever happens.

Finally, we took some basic graph theory and built a rough small random galaxy generator. By finding the minimum spanning tree of a bunch of randomly placed star systems and forcing a few cycles and some angle constraints we create the layout the galaxies we will traverse in our quest!


TLP2K13 postmortem

No pudimos salir mucho más contentos de la Tenerife Lan Party 2013, ya que aparte de asombrarnos con la magnitud del evento (increíble el escenario del League of Legends y magnífica la ilusión con la que participa la gente en general) ¡ganamos el premio al mejor videojuego en el Hackfest! Nos llevamos una videoconsola OUYA de la que ya estamos disfrutando, tres meses de servicio premium de Geosophic (para videojuegos móviles), tres sesiones de consultoría para preparar y lanzar el juego internacionalmente (Geosophic) y un vídeo promocional en Videolean.

Durante el Hackfest conseguimos hacer en tres días un prototipo muy sólido de la idea básica que teníamos en mente: un juego multijugador local para tablets en el que cada jugador, desde cada esquina del dispositivo, debe lanzar sus cinco hormigas con habilidad para que caigan y arrastren trozos de comida de vuelta a sus hormigueros. Faltó añadir sonido, algunos elementos de juego más y balancearlo todo, pero quedó jugable y demostró que la idea puede ser muy divertida. Seguramente lo acabaremos publicando cuando esté listo.

La charla que dimos (Logro desbloqueado: 2 años de actividad), en la que contamos qué, cómo, dónde y cuándo hacemos lo que hacemos tampoco fue nada mal. Hubo un momento de modo pánico porque no teníamos público (ni una persona), pero tras una breve espera asistieron casi una veintena de espectadores y respondimos bastantes preguntas. Queremos pensar que porque resultó interesante y no porque no nos explicáramos bien…

Finalmente, el torneo de Oddy Smog’s Misadventure tuvo sus dos ganadores (el primero nunca apareció) con puntuaciones cercanas a los records mundiales actuales. Participaron unas 250 personas, lo que supone un 16% de los participantes de la TLP. Para haberse anunciado con tan poca antelación no está nada mal. Y vaya, que de los mil y pico asistentes con tropecientas cosas que hacer tanto en sus ordenadores como por todo el recinto, 250 jugaran al Oddy… pues ya es una alegría.

Desde luego salimos contentos. Cansados, pero contentos.  ¡Si podemos repetir el año que viene lo haremos!