By playing the original game, I remember that you can’t end movement with one unit when another friendly unit is placed on the same tile. The game had some sort of caching mechanism, remembering the last “safe” position for units while they move. That worked perfectly in every situation, even if you pass by multiple units and try to end movement. But, to simplify the caching, the original game allows not also to take any actions (open / close doors, firing / priming weapons) when a friendly unit is on the same tile.

Well today I implemented these two simple features, so now you can’t stack multiple units on a same tile. To be honest, I never tried that before while testing just to see what happens.

Today I implemented the logic for firing a weapon for a specific fire mode. Again, the unit must have a equipped weapon in inventory. Each weapon has also different fire modes (auto, snap, aim, throw), so the player must choose one from a list. The whole feature is not completed yet, because the actual calculations where the bullet is going are not done. It shouldn’t be so tricky to implement that part either, but I must leave it for another day.

Units can also now load weapons; of course for that action, units must also have an equipped weapon in their inventory. For that specific weapon, the inventory checks if there are compatible ammo clips which are defined in the equipped weapon data model. I’ve left the possibility that one weapon can use different ammo clips (more rounds in clip or different firepower). If multiple ammo clips are found in inventory, the player can choose which one he wants to use. After that the ammunition of the equipped weapon is reseted and the firepower parameter is updated.

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).