Llevamos desde 2009 usando Unity, un motor de desarrollo de juegos muy versátil con el que hemos creado todos nuestros juegos y con el que seguimos trabajando a diario.
Si quieres empezar a hacer juegos con Unity en C#, tenemos en YouTube una serie de vídeos con los que pasarás de una escena vacía a un prototipo de juego de tiros CON ZOMBIES (vale, cubos verdes, pero son como zombies) en unas pocas horas.
Son videos cortos, de no más de 10 minutos, y encontrarás ejercicios en sus descripciones. Si tienes dudas sobre algún tema o quieres conocer otro en profundidad, ¡aquí nos tienes!
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!
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.
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.
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:
“A System that does more than one thing can be probably divided into many Systems”, which follows the SRP (single responsibility principle)
“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:
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:
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!