Now units can prime explosives; unit must have an explosive-type item equipped in his inventory. Every turn, all items on map and in all units inventories are checked for explosive-type items, checked if they are primed, and if the timer reached zero; if yes, there’s a kaboom.

The tricky part, which I am postponing a couple of weeks now, is the actual explosion. Every explosive has it’s own strength (radius), but what if the explosion is blocked by walls. The strength is weakened by the constitution of every map tile, and the calculations must be done in a circle. I have no idea how this is implemented in the original game, so I must find a way to do it right and realistic.

The other thing what’s missing is chained explosions. In the original game there are also map tiles which explode on destruction, but, if I remember correctly, an explosion on the map can’t affect explosive-type items in units inventory.

Today I changed the UI a little bit and fixed the open, close, unlock, lock actions which worked before. Since that I solved the pickup, drop, change actions with the inventory system, the only actions that left from the original game is firing weapons and priming explosives.

I worked also on the map renderer and implemented the fog of war for all units, which works also perfectly in the LOS mode. I added also a additional menu option to show / hide the tiles that are not in units fov. How all this works can be seen on the screenshots.

Today my Nexus 4 got another update. After installing, I can’t see any difference except that the default buttons look a little bit weird.

I’m still cleaning up that refactored code from last time.

I don’t like to do this often, but the next thing I wanted to implement required refactoring again. It can be very time consuming when you’re implementing features just to test them and then later want to connect these features with the actual gameplay that you have in mind. In my case, I finished first the movement of one unit on the map. Then I added other units and teams. Now it’s time to introduce the cursor on map, the selection mode, which both have an influence which options are shown in the game menu.

The players turn in the original Laser Squad starts with a cursor centered on the map. You could move the cursor and explore the map. You could select an unit, move it, take actions and then deselect it to move to the next unit. A unit is also automatically deselected when AP’s reached zero. Today I finished the cursor moving, unit selecting, unit moving and unit deselecting. The options “next unit” and “end turn” are also working. Now the gameplay works exactly like in the original game, and I’m very pleased about that. The part which worked before, but now it’s not compatible with the new code is that a unit can take actions on a s specific tile. I’ll finish that next time.

Over the weekend I played the original Laser Squad on the Commodore 64 emulator. It has been over 20 years since I’ve played it like crazy, before and after the school clases, on my real C64. Nice to see that single colored tiles and units again and catch some of the original sounds.

I was trying to figure out how all the stats are calculated on each new turn, and how they depend on each other. I took the first scenario, and equipped all units with different kinds of armor and later weapons. Some of the calculations are described in the users manual, but not all of them. I searched the internet also for some detailed descriptions; actually there were some people who tried to make a remake of the game by reverse-engineering the old ZX81 assembly code. It’s not only that you have to analyse the formulas, you must also find a way to parse all the units initial stats for each scenario – not knowing the scenario and unit data models. I don’t know if I may use the informations which I found in these articles, which, again, are totally incomplete. So, I decided to gather all these calculations in just one method and do them by my own, following pure logic and the way I see things in the real world.

Here are some screenshots how I tried to figure it all out with different equipment combinations.

I’m pretty impressed and excited about today’s completed feature. It’s one of this things that makes me think: oh man, coding is so much fun! Remember on day 11 when I worked on the FOV method and talked about how I wanted this to be divided in three, later reusable, steps? Well, with the LOS algorithm (third step) we can check also if a unit sees another unit from the opposite team.

First I created a method which returns all opposite teams from the current team. The original game and original scenarios worked always with two teams. But I left the possibility, that maybe in the future, more than two teams can play a scenario in a death match or in cooperation mode. Then I loop through all opposite teams and units and check if current unit sees one of them. Of course these units are shown then on the map.

Not much time lately for some serious coding, so I decided to take much smaller steps in development. Today I only implemented a flag in units model data to check if this unit is alive (practically, same effect can be achieved by checking if current health is zero). I adapted also the “next unit” method to skip all units that are not alive (logically, you can’t play with dead units).

With the new game instance class, which controls the whole game mechanic, it’s easy to implement now new game features.

Since I made a mock scenario which uses our previously created mock map, I also added two teams and all units from the first scenario of the original Laser Squad game. Then I implemented methods to move to the next unit, that means all units in one team can be moved now; and also methods to end the turn so that next team has the opportunity to move their units. Of course now all units from one team are shown on the map in red color, and the currently selected unit remains white.

Slowly the gameplay is taking it’s shape.

I also included a screenshot of the current options menu. Most of the options are there only for testing and debugging.