While developing I put in some data model classes a little bit of game logic. The game is getting more and more complex, so it’s becoming harder to follow and debug the code. Today I created a couple of helper classes which contain only the game logic, leaving the data model classes clean and readable.

I decided to pack all the armor data in one class. In the original game there are only four types of armor in all scenarios, all with same characteristics (but different prices). Since I’m planning to make the game as more expandable as possible, I’m leaving the possibility that armor types can be defined for each scenario separately. The unit base data model is also expanded with a new armor parameter now.

After I completed the items, tiles and the map, it was time to put also the rest of the data into the first scenario. I had to expand the base scenario model with additional fields like how many levels are available in single player mode, how many credits you get per level / or in two player mode, available units with all their characteristics, which items can be bought and how much they cost, available turns… etc. I’m still thinking about how to define victory conditions for both teams, and event handling during the game.

There is enough data now to start maybe with the player and level selection, armoring and equipping units, and finally initializing the game.

Today I added the protection value parameter to the base tile data model. Some tiles can have a terrain protection value; meaning, when a unit stands on such tile, other units have less chance to hit when shooting on it. So units can “hide” behind bushes, plants or even furniture tiles. In the first scenario the tile that has the most protection value is the “Reed Plant” with a value of 6, following then the “Shower” tile with a protection value of 4. The formulas how those values are affecting the shooting algorithm are, unfortunately, unknown to me, so I must improvise again.

Last couple of days I was busy defining the whole tile set for the first scenario. The map consists of 26 different tiles sorted in categories, and each having it’s own parameters. Again I had to play the game a little bit, to figure out the additional AP costs which some tiles have and need to be added on the basic movement cost. Also, units can hide behind some tiles (like trees and bushes), and I had to test these in the original game and set the appropriate parameter for hiding. The only thing I don’t know is the constitution of the tiles, so I set some values of my own guided by logic.

The representation (“graphics”) of the tiles is not final, some minor changes can occur in the future. When I look at the game now, it reminds me totally on a Rogue-like game. Very nice indeed.

Now the base ammo items are also defined and linked with weapons. There are total of 14 different ammo clips (some of them can be used for more than one weapon). Just as a reminder, although I adjusted the parameters of the ammo items like in the original game, my idea was that weapons can use different ammo types with different ammo capacity or firepower. Therefore every weapon has a list of supported ammo items.

Last couple of days I was busy defining the original Laser Squad weapons set. Very time consuming because the original game has 32 different weapons, each with different characteristics. A detailed table is provided in the game manual and the only thing what’s missing are the weapon prices. To get the prices I had to play the game and all scenarios (different scenarios have also different prices for same items).

Some of the weapon parameters I forgot to implement in the first place like “ap costs in map” (additionally AP’s removed when a unit steps on a item), “skill factor” (how much of a unit’s weapon skill is added to accuracy in ranged combat) and several other parameters regarding the “close combat” mode.

Now this is fun. I added another parameter to the basic tile model and that is explosion strength. If set, the tile has the capability to explode (like computer terminals, video screens, gas tanks… etc). Shooting or throwing grenades at those tiles can lead to chained explosions (more tiles explode at the same time). The feature is implemented, and there is no better way to test it then to plant an explosive in the middle room of the map, where the computer terminals are (marked with an ‘@’).

The final part of the firing method is implemented and that is collision detection. All tiles and units are tested along the bullet trajectory for collisions. At last, units can shoot on each other – of course without friendly fire.

Today I implemented the trajectory calculations for a bullet when a target is missed. The position of the calculated missed tile is marked with a red “X”; the idea is to extend the trajectory line further to the map end to get the full trajectory. Now everything is ready to test all tiles on the trajectory for units or tiles that are unpassable.