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.

   

This morning I finally got the Android 4.4 KitKat update for my Nexus 4. Today, instead of coding, I’ll explore the new features; for now, the game is working fine with the new OS.

Yabadabadooo…!!!

 

Few days of development and I finished the basic scenario model, which holds now the map data, and can also hold unlimited number of unit teams with unlimited number of units. It was time to do some refactoring again and to put all classes in the right place. Finally, I created the main game class, which is a singleton. This class will hold all necessary game data and it’s totally separated from the renderer. The class implements also methods for loading and decoding game data from a source or saving and encoding data to a destination – although I didn’t finish this part yet.

I also made that diagram mentioned before which shows how the classes are organized and how they depend on each other. Helps a lot when I need to implement something new and overall when designing main game architecture.

After 20 days of development I finally noticed that I didn’t changed the background of the whole activity to black. Now the map looks much better.

I changed the color parameter of tiles to hold RGBA values; before the colors were temporarily represented with a string. Now with real values, color manipulation is much easier. I was excited about the next little thing that I’m going to implement, and that is advanced shading. Since the FOV method returns also how far away is the current unit from a tile that we are testing, this value can be used to calculate the color of the tile, so that far away tiles are logically much darker.

Again, it boosts the whole atmosphere of the game even more; here are some screenshots with enabled and disabled line of sight.

         

Today I fixed finally the rendering performance of the map. The map renders in a textview and to get colored tiles I added HTML spans with colors and loaded the whole map as a HTML into the textview. I read on the internet that HTML in a textview, with many applied styles, has a huge impact on the CPU because the whole content goes through a XML WebKit parser. That’s wasting of precious time we don’t have, so one solution is to use Androids spannable strings instead, which apply only basic styling for a text.

It took me some time to adjust and cleanup the renderer and after a short time I got things up and running again. Unfortunately, there wasn’t a huge performance boost as I expected – from 2 seconds to 0.4 seconds for the whole map. Obviously something else is wrong, so I added log messages with timers for each block of code in the rendering function. There was a huge bug; for every tile I was going through the whole map, reseting all tiles to hidden by default. I added this for FOV purposes, but it was also used when the FOV option is disabled, and after all, it’s called totally at the wrong place. With that fixed now the whole map is rendered in 0.04 seconds.

I’m so glad also that I got rid of this HTML WebKit parser.

Although I’m brainstorming almost every day for at least 15 minutes what to do next, I used the whole time today not for coding, but for mega brainstorming. The game is doing well and even now it’s fun to play, or should I say, fun to test.

I must admit, it still amuses me when I think about these Rogue-like games and how the hell I didn’t heard of that genre. Since I discovered and played RPG games in my childhood, I wanted always to make my own RPG game in my own fantasy world. I’m thinking about to use this engine that I’ve build so far maybe for a new RPG game with ASCII graphics. It’s still just an idea. So, I’ll focus in the upcoming days on features that can be used in both games. First it’s time to fix the renderer. I didn’t mentioned it so far, but the performance of the renderer, when shading is on and FOV is off, is killing me (and it’s killing the system too). The other thing which is on my mind is to finish the “explode” algorithm. Right now, it explodes tiles on the map ignoring the constitution factor, which is obviously wrong. We must make a difference between exploding a table, a door, or a concrete wall. Last but not least, I planned to make a “game” class which will hold all info about current game: main event handler, scenario, objectives, map, tiles, players, units… etc. Just to make things more pro I’ll make a diagram out of this class.

The first version of the pathfinder is working. I added a new option menu to calculate the nearest path from unit’s position to the selected tile for testing purposes. Now tiles which contain the nearest path (if this path exists) are marked with “#” and tiles which were processed during pathfinding are marked with “:” (useful info for debugging). Here are some screenshots how it works with normal and diagonal movement.

     

Today I build the necessary data models and interfaces for the pathfinding algorithms. Since the A* is working with heuristics, I added the Manhattan and Euclidean ones that are mostly used. With interfaces everything is extendable and I can add later maybe more interesting things to the algorithms.

On the way I discovered a bug that units can move through the window tiles. Well, that’s not possible in the original version of Laser Squad, so I added one more parameter to the basic tile model, and that is “viewable” – meaning, a unit can see through a tile, but can’t pass it. That fixed the movement and line of sight bug once and for all.

Today I only cleaned and commented the FOV code. I also tested unit’s movement with a normal map. It works perfectly; and the fact that a unit can see through window tiles like in the original game is awesome. Time to do some research again for the next feature that I’m going to cover, and that is pathfinding.

What is pathfinding? To put it in simple words, it’s an algorithm which calculates the path from one position on the map to another, avoiding unpassable tiles (walls, closed doors… etc). It’s used for the computer AI and I have so many ideas how can I make it smart and configurable. For example, each computer unit, depending on the scenario, will have main objectives (patroling, guarding, attacking… etc). So, if a player eliminates a computer unit in the game, the other computer units are aware of this, and will automatically go to this position; but not if they have important main objectives, for example guarding another unit or something on other specific positions. All movements will use pathfinding, or how to get quickly from one position to another.

The most common algorithm that is used in games like this is called A* (A star). It’s fast, it can be configured, it supports moving in 4 or 8 directions, it takes also into account costs per move (how many AP’s do I need to get there) by analyzing surrounding tiles, which is very convenient because all of the tiles on the map have already the obstacles factor. There are also many tutorials, pseudo / source code how to implement this algorithm.

  

Today I improved the FOV third step even more. The first version worked for 180 degrees in front of the current unit. Well, that’s nice but not so realistic; maybe if you are a fish and have eyes on sides of your head. In real life, human FOV is about 90 degrees in total.

That means actually that calculating the 45 degrees headings (north-east, south-east, north-west, south-west) got easier, because we check the appropriate quadrant in our FOV. But now for the basic headings (north, south, east, west) we must calculate two cross products to get what we want.

Of course I had to test this new method on my meadow mock map, and I’m pretty satisfied with the result.