Moving on with modeling. Basic data model for the map is implemented which holds only the size of the map and the array of tiles. I also made a mock map with floor tiles (.) surrounded by a wall (*), just to test the map renderer.

The unit (o) can also be seen on the map. The class unit contains one more class which holds the map data (position and heading). Basic movement actions (move forward, move backward, turn left, turn right) are also added to this class. Every move uses AP’s depending of the direction of movement and on current tile’s obstacles factor. Each tile has an obstacle factor just to make a difference between easy crossable tiles, like floors, and, for example, furniture tiles. Also collisions with walls are implemented.

Last but not least, in the bottom of the screen I printed out some main data about the current unit, and added a inventory button.

Today I created some basic data models for items, tiles and units. These classes will be extended in the future to offer more and more special functionalities and states to the models.

How it works? You have a basic tile which represents a door on the map. It will be extended to the “door tile” to handle opened/closed states so that the player can perform  these actions on that tile. More complex door tiles can extend the already created “door tile” to handle more states like unlocked/locked, or they can react on a specific event in the game (auto close when an alarm goes off). Same logic is used for items… Weapons extend the basic functionality of an item with parameters used when firing, reloading or priming.

I also created a simple inventory system in the unit class which handles all the taking / dropping of items. Several parameters are checked for these actions like item size and weight if it fits in unit’s inventory. The inventory is also capable to change units action points, because all inventory actions cost AP’s.

Last but not least for today, I worked a little bit on the UI. The main screen is divided to reserve 75% of it for the map which is a simple scrollable text view, and the other 25% for current unit’s data and action buttons.

After creating the project in Eclipse, I took a little bit of time to delete all unnecessary resources that Android wizard puts in your project by default. Also the git repository is ready and set up and the initial commit is there. Starting the app pops out “Hello world”… yey!

Welcome to the “Laser Squad remake” development journal. I must say that this is the first time that I’m giving so much attention to a project of mine and share the whole development process publicly. I’m glad also that this project is actually a game, so I’m hoping that this journal will be also some kind of a tutorial how a game evolves from an idea to, hopefully, a finished product.

Before we start, I wanted to say something about what you can expect to read here. I’m developing this game completely in my free time and only then when I’m not spending time with my family. That leaves me a very small amount of hours for developing and even less time to keep track of everything in this journal. Don’t expect to read everything in detail how the game works; I’ll only cover the basics, share some of my thoughts during the development and provide as much screenshots as possible.

So let’s get things started…

The idea for a remake of Laser Squad for Android came by the end of September 2013. It’s been a while since I wrote my last game (Spacetracks) back in 2009; it’s definitely time to do some serious coding again. Since I wanted to start the project on October 1st, I used the mean time to think about the game mechanics and how realistic it is to finish at least that part by the end of the year. The other thing that bothered me was, should I use 2D canvas or 3D OpenGL rendering, even I knew the game will be definitely 2D; and if I go with 3D should I use version 1.1 or 2.0. It was a brainstormer, and even after when I’ve decided to use 3D, I’ve realized that actually it doesn’t really matter at this moment because the original game works with tiled graphics; meaning it could be represented also in plain text in a simple text view using the default Android monospace font. Suddenly, instead of state of the art graphics, I saw characters like “.” and “+” for the floors, and “O” for the walls… and of course, items on the ground will be temporarily represented with an “X”. What a relief, with this in mind I can set up the rendering basics really fast and concentrate on the mechanics of the game.