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.

After couple of days thinking about how to implement this feature, the first part of the algorithm is finished – the destination tile is marked where the bullet or the item (in throwing mode) could end up. What’s missing is testing tiles between the origin and the position for anything that could interrupt the calculated trajectory (units or concrete tiles). That part can easily be done by including units position testing in the LOS algorithm.

How it all works so far? First a random number is generated between 0 and 100. Then the accuracy of the weapon fire mode is taken and aligned in the middle of the range; meaning if the accuracy is 30, we consider that the target has been hit if the generated number is in the range from 35 to 65. If our generated number is in that range, target tile has been hit (handling different unit sizes is not implemented yet). If our generated number is lower than 35, we are missing the target tile to the left, or if greater than 65, we are missing it to the right. In case when we are missing the target, the units heading is also valued to determine if the missed target tile is horizontaly, verticaly or diagonaly away from the tile we actually fired on. At last, when we know the coordinates of that missed tile, we are extending the trajectory further until we hit the end of the map in that specific direction. Now the calculated trajectory is completed, all we have to do now is follow that trajectory and test if the bullet is hitting anything on it’s way.

Today I implemented the target selection before choosing the appropriate firing mode. The cursor is represented with a red dot, and when the player finally chooses his target, the already existing LOS algorithm is used to test if the target tile is in units line of sight. Again, the original game is using a 90 degrees FOV/LOS (my impression when I play the game), although the user manual says 45 degrees is used.

Time to do some brainstorming again. I talked already about how some enthusiasts tried to figure out how all the ingame calculations are done by reverse engineering the original code. Well, two things are bothering me the last couple of days, and if I could look into the original source code, I will definitely look how these two thigs are implemented – firing weapons and explosions.

I’m thinking about firing and how to calculate the trajectory of a bullet from one point to another. The Bresenham line algorithm which I am using already for the LOS can be used in this case also, but with much higher precision. If I remember right, the “Cyber Hordes” scenario in the original game introduced units that are different sizes (three of them in total), so even if your bullet is flying to the correct destination tile, there is a chance to miss the enemy unit if this unit is 1/3 of a tile in size. All these calculations should be also mixed with random numbers depending how precise the weapon and the chosen fire mode is.

The second thing are explosions; a real brainstormer. Right now when it comes to explosions all the tiles are blown away. That’s very nice, but that’s not how things work in the real world. Each tile has the constitution parameter which absorbs the total power of the explosion. For example, doors and walls have greater constitution than floor surfaces or furniture tiles. One more problem is that the power of the explosion should spread radial, and if you want to make it very realistic, the power of the explosion, when blocked by concrete tiles, should spread in other “free” directions – like moving fluids.

I think my head started to hurt.

Today I wanted to implement the map auto scrolling feature. It’s the next logical thing to implement when you have a large map and the zoom factor set to maximum value. The idea was when a unit is moving, it has to be always centered in the middle of the screen; also when you select the “next unit” option, the map should auto scroll to this unit. This is how the original game works.

Unfortunately, something is not working right. When I pass moving events to the text view, it’s not scrolling at all. I googled a while, trying to find a reasonable explanation or example, but with no success. This is the first feature in this project that isn’t working, and I can’t find a working solution.

Well, I’m skipping this one, hoping that I’ll fix it some other day.

In the last couple of days I hadn’t so much time for coding, so I’m trying to concentrate on little tasks which are optional but not crucial for the actual game play.

One of these tasks is map zooming; almost every strategy game has this feature. It’s of course very easy to implement because our map is only a text view, and we can zoom by changing the font size of the text view. The original game had a window which could only show 13 x 11 tiles; of course you could scroll around. In my personal opinion, when the graphics are looking good, showing smaller numbers of tiles on screen makes the whole sneaking situation much more exciting.

This is my first coding day in 2014, after a week off during the holidays.

I implemented the firing weapons feature earlier, well, at least choosing between fire modes and appropriate AP calculation for that specific fire mode. Later I noticed, in the original game, that all items can be actually “fired”, because throwing items is also one of the firing modes. It was a little bit tricky, but I managed to fix this little issue in one day. Several classes needed to be changed which is actually good because I discovered two bugs in the unit inventory class and item data models.