Sunday, 15 July 2018

The last push! - Raining Blocks

Raining block was a good experience, and although is not a big hit, the objective of getting experience on game-dev world is more than accomplished.

In any case, even when you are a one man company, it's good to have help where you need, and if they are enthusiastic, they can even make you improve your work!

I released last week the, probably, final version of raining blocks. Along the usual bugfixes and minor improvements, it has many things than improve the overall quality even if the core game is the same.

One of these enthusiastic people was Sergio Bellido, from the magazine "Yo tenia un juego" ("I had a game" in English, it's a magazine about old games), that wanted to help improving the game making music for it (for free (, thanks again!) and make a logo for the game. So well, why stop there?

With the new feedback of the game, we did not only add the new music and the logo (with an animated intro with the old-classic "Press A to start"), but we also updated the android version to be the same as the steam version (but the split screen), and added a progression system to unlock the items when you earn a new achievements. This way, people will try everything on the game little by little, instead not knowing what to select.

You can hear the music from, two tracks, the main menu and the ingame music, and the logo and animated logo in the new trailer below, and remember that you can try it for free on the Android version of the game!

Thursday, 4 January 2018

Screenshots of the evolution of raining blocks, now available!

Raining blocks is now live on steam. This is my first game on the Steam platform and I hope that is not the only one, but,  also, I expect to make better games (hiring a 2D designer/animator for example) if I can gain some funds. I already started the prototype of my new game! (Code name: Project K.)

So, this game has been designed and published on Android and Steam / PC (Windows and Linux) on three months (weekends). Both versions where made at the same time (using Libgdx as an engine), but was released first on Android as it was faster to publish, it did not need the split screen mode and an early feedback it's always useful.

Now, I know that there is a very tough competition.. there is plenty of apps on the play store, with hundreds news app everyday, and if you are not a know publisher, or your app is just not a masterpiece, or simply, you don't pay Google for the ads, probably the app is not going to perfom as you like to.

On Steam every day are like 20 new games, and unless you can market the game from very early and appeal to a group of customers the game will also "fail" (for me, this first game, publishing it is a success. Any experience is welcome).

Anyway, the core of this game was done on a weekend. The next weekend the game play was polished and features that just did not work were cut (jumping for example). At the third weekend I did the final menus (at least on the android version), starting the beta testing with friends and on the fourth I implemented google services. And on the fifth, the game went live on android (with bugfixes patch along the two next weeks).

First playable version of the game. Easy mode was way bigger! 

First tutorial of the game! It was a three static images tutorial. Now the game has an interactive one. Also note the first character of the game! (from

Bug reporting from a tester. The infamous "block did not fall randomly" bug. GUI was not finished yet, but the game had now backgrounds!

The (almost) final menu of the android version. Screenshot of a tester, checking that the ad was working. (I should not use my own phones to show adds, or Google will use the ban hammer against me).

The next month I remade the menu with my own GFX that was better suited on the theme of the game. I did the split screen mode and implemented gamepad and SteamWorks to the game. After little changes on the game play (speed changes, sound effects, musics) the game was ready.

An early version of the new menu for the steam version

Early split screen mode (on debug mode, player two can't die so I can test the mode) that it's on the Steam version.

And after two weeks of mandatory waiting on the Steam system, now is live!

Tuesday, 5 December 2017

The projects we love that for some reason, we can't finish (Space Captain, the untold history nobody asked for)

Hello there!

from time to time, we start a project, we dedicated time, we are having fun with that but.. we don't end it. There are many reasons causing it. It can be the sudden lack of time, or we lost interest when the fun part of designing a game and features is done, or maybe we realize that we can do what we want, because we want it to be perfect.

Well, the last time I had one of these "failure" projects was a "I really like it to finish" one. It was a game based on Sid Meier's Pirates! but on a space theme. There was ship battles, duels, trade, exploring a new world, wars between factions.. and you already know why is not finish. It's a big project. And because it's big, where I dedicated a lot of time, I wanted it right, but more on that later.

Space Captain (provisional name)

This game was at more or less 50% finish, talking about code here, it has a random generated system of planets, moons and stations, where the different type of stations trade with each other. You started as a ship captain of one of the faction, with your crew, and like in Pirates! you have a main mission to follow, you could plunder and capture another ships, stations, search for treasures, vanquish other pirates.

It has the following features:

Random system generator

Every time you started a new game, a new solar system was generated. This means that, unlike the Caribbean, every game was different.

Example of an in game planet system

SHIP AI - Station trade system

Well of course! we need ships wandering around, attacking each other and trading away! It was my first AI (I like to say that is an AI but it's just a point system of what to do and when, but, you know, AI).

The AI ships trade with the stations, moving wares from one to another, there was a basic supply/demand system in place, and some stations were richer that others. Trading and pirates could change this though.

Debug mode showing current pathfinding of AI ships. They move on circles near the sun to gain a gravity boost!

Navigation map that a gossiper told us with the probably route of a ship whit tons of future gold (whatever that means)

Entering on friendly stations the player could repair and upgrade their ships, go to get information, talk to the administrator or trade.

Place holder menu of stations

The stations and ship in the game were named with real pirate names and ships (for pirates), early game programmers (for non faction stations), you can see on the last image that the station is called Enrique Cervera, creator of the 1985 Spanish game Phantomas (one of my favourites when I was a child), scientific and science-fiction authors (Galileo, Asimov..) and admirals, ships and horses for the rest of the ships (Blas de Lezo, Rocinante..).

Ships Battles

When you attacked another ship (or you were attacked!) the game entered on a battle mode. The ships had, usually, more than one weapon (lases, kinectings, homing missiles), shields, better or worse engines and power generators. Usually, you never had power to activate all system at the same time, and if your ships was damaged, the available power was lower. 

So the battles was fast paced action where you need to balance the power of your systems, activate or deactivated the shields and capture  (or destroy!) the enemy ships before they did the same to you. The AI of the game could manage the system, and it would attack you if it had advantage, or try to run away if now.. if possible.

Debug feedback of how the AI was managing the power 

Ship battle between two pirate ships (all assets were temporary)

The ships

The ships have engines, power, shields, weapon slots and FTL travel, and depending of the ship's hull can have better or worse ones. A trade ship can't have lots of weapons, and a pirate ships usually are faster, better armed but with less hull hit points.

Early player's ship menu

Other minor features

There was already in place a missions systems with a vanquish pirate mission and treasure hunt, were you collected pieces of information and you look for it on the orbit of moons using a scanner. 

Also a hail system, where you can "talk" with other ships to gather information or to respond to distress calls.

So, why it's not going to be finish?

Yes, a good game, at least for me. It's not going to be finish because I wanted to be perfect, and I needed additional funding (and not only weekends work) to do it. A 3D designer and a 2D artist aren't cheap (also, a sound designer and a music composer would be nice), and even with them there are many things that the game can not deliver (for example, is not something new, space games, pirates games of this kind are not exactly new) and there are more complex games like this and for free (note to self, I was making this game for fun and to play a space game that was simple and fun to play, these complex games are too tedious for me).

And to be fair, you will never get a perfect title, you need to stop at one point. You can always polish, add features, change this, that.. probably the perfect title is when the development was stopped at the perfect time with the maximum of fun features possibles.

Retake the project on the future?

I can't see it. There is a major flaw with programmers. If you left a code for months, the next time you revisit it will be a shock. "What a horrible code", "Spaghetti code everywhere", "Oh my god, change this and that to be nearly good can take months, better START OVER AGAIN".

This happen, always!

In any case, hope you enjoyed reading about that little game. 


Monday, 20 November 2017

Post Morten Diary: Island Survival Disaster (Or how to do things wrong!)


Island Survival Disaster was the first completed I made that was published. The idea of the game was a mix of text game with options for the players that will affect the outcome, and a board game where you discover the map and manage your resources.

It was fun to do, but in retrospective the game has many problems that made the game confusing and tedious. At least, there are a lot of lessons I learned for future games. In no particular order:

Before start coding, define the scope of what you want to do, and stick to it

The game has an event system. This event system tells the player a history, depending on his actual location, stats, friends and their situations, inventory and a large list of parameters. The system is to calculate the possible options the player can take, and their outcomes. In theory is something cool, but it grew bigger and bigger every time I wanted to do a new event and I needed a new check of some sort. "It would be cool to also check for this.."

This lead to a very big system, that in some cases some features were only used once for one event (and we are talking about hundreds of events). Also, the player never know why or what is triggering that action or that event, just clues, making the game very confusing for the player, and very time consuming for the developer because adding features that are not going to be used it only add another layer of complexity on the game that will also make the maintenance of the code and the bug fixing harder.

If you mix  game genres, think twice, and do it right, or don't do it

The game could be a lot better if the game was only a text game or a board game, but mixing both, and trying to add features to the less important of them (adding building, resource management to the exploring part of the game) can be very confusing for the player if you don't split very well both parts. A text game only would be fun, and the board just to move and nothing more was the correct thing to do. Now it's veeery late.

Make every option clear, and do anything you need to the player to understand how to play the game

Even if you have a very simple game, if the player don't know what to do, probably it will unistall the game without even trying. You need to hold the hand of the player even if you need a big interactive tutorial (or other types of tutorial). Mix them in the starting gameplay, as only tutorial screens with a very big "skip" button will be not useful, as the average player, eager to play, will skip it. (This is a lesson I learned on another game, but fits here too)

Don't make a text based game if you are not a writer or you don't have someone that can do the story

What a bad writer I am! And I made a game with lots of text. This lead to many problems. The first one, the player will be "amused" about the level of what is reading, and probably will quit after a while. The second.. is that is very very time consuming. Probably I spent more time writing that doing actual code, and the game needed that extra coding time. Doing it twice (the game was translated to English/Spanish) did not help. (Look at the text of the image, parallelism anyone?, horrible I know)

The GUI is very important

Making menus on a game is not a fun task. But it's a very important one. And in a mobile game it also need to be very clear. Show your progress to someone you can trust, and make changes accordingly. A bad GUI kill any games, because the player will not know what are their options, what that button do, the resources or items he has.. frustrating.

If you are not an artist, at least made the game easy to read

One of the major problems I always have, is that I'm not an artist. I need to borrow from CC or public domain files/textures/music/sound. I can make simple draws or change what I already have to fit my needs, but of course, is not the same that the work of an artist. The game can fun anyway, but please, don't clutter the game and try not to bleed the players eyes (or at least, don't mix different styles, be coherent!)

Final words

Nevertheless, looks like a waste of time uh? Not a bit, I learned a lot, not just on game design, where the major flaws are, but I improved my skills on how to code, architecture, reuse, mobile optimization.. and in my following projects I code a lot faster and cleaner. (Yes menu system, I'm looking at you!). (BTW I unpublished the game from the store a while ago.)

Anyway, hope this help, and have fun coding! If you are not having fun, something is wrong!