I’m back after a 10 day pause. Yes, I’ve somehow managed to survive this period of time without coding. I was busy practicing for my german language exam and I played a little bit an extraordinary ascii (what a coincidence) rpg game called “Candy Box 2”.

The funny thing is, while I was doing some research how to implement the FOV algorithms, and how to procedurally generate levels, I’ve stumbled upon a game genre that was invented in the eighties and I (an experienced gamer) didn’t have a clue about it. “Rogue-like” games. I never heard that term before. So my idea of making first a ascii version of my game, wasn’t so original after all.

Enough talk… let’s get back to the FOV. It looks nice, but there’s still that third step missing we’ve talked about (seeing only tiles in front of the unit). That’s easy to implement for the unit’s basic headings (north, south, east, west). What about 45 degree headings (north-east, south-east, north-west, south-west)? The answer is simple and can be achieved with a little bit of advanced mathematics. We extend our origin (unit’s current position) in both directions diagonally with a length of our FOV (radius) divided by two, and get two origin points instead of one (the original origin is in the middle of the line between these two new points). Then we simply calculate the cross product with the third point which is our tile position that we are testing.

To test this third step, I created a new mock map which contains only passable (visible) tiles.

             

 

I spent the whole evening debugging the LOS algorithm. The problem was that the last (unpassable) tile was not drawn. The unit can’t see behind a wall, but still, he is able to see the actual wall blocking the way, and that part didn’t work as supposed. Well I’m glad that this is now fixed.

I must admit that hidden tiles around the unit boosts the game atmosphere significantly. This is also the principle how fog of war works in games.

 

Before I move to the next step, let’s do some theory about the next topic. A field of view (or vision) is actually what the player (current unit) sees on the map from his current position. I will implement the whole FOV calculation in three steps, because every step method can be used also later on to add more interesting mechanics. The steps are:

• Show only tiles which are around the unit’s current position for a given viewing distance (radius). Practically we must construct a circle around the player and show only tiles that are inside the circle. Interesting features can be added here; for example, unit’s viewing distance is longer when the unit has a equipped flashlight. The same method will be used later to calculate the radius of a explosion.
• Do not draw tiles which are behind unpassable tiles (walls, closed doors… etc). To do this we construct a line from the unit’s current position to the tile’s position that we are testing using the Bresenham’s line algorithm. If we find a unpassable tile on our way, the destination tile can’t be seen from unit’s position. The same method will be used later to detect if a enemy unit is in our line of sight.
• Do not draw tiles which are behind the unit by taking into account unit’s current heading. Well, this is self explanatory.

Today I managed to implement the first method and I tested it by blowing a part of the map (finally some action). The line algorithm for the second step is also finished and successfully tested.

 

The day started with the implementation of actions for weapons (firing guns and priming grenades). Firing is not finished of course, only the basic AP calculation for given fire mode is done. I’m leaving the actual firing direction / consequences calculation for the future.

I wanted to take a break from actions, items and stuff that I’ve done last few days. I wanted to do something more exciting; for example analyzing unit’s surroundings further mode. I’ve thought about unit’s field of vision, line of sight, fog of war, and more exciting things like blowing away the map with grenades. Now that’s fun!

For the purposes of the upcoming features, I added quickly the first option in the menu – selecting a tile. It’s needed of course for firing weapons in a specific direction, but I’m going to used for now to simulate / debug something specific on that tile, like a enemy unit standing or triggering a explosion.

Now for all this funky stuff, I need a bigger map with more walls, doors and even furniture tiles. I build quickly a “char array to tiles” parser and recreated the map (at least the basics)  from the first scenario “The Assassins” from the original Laser Squad. With bigger and more detailed maps, the rendering all in white became boring, so I implemented some basic shading.

 

Today I basically cleaned up the code from the last two days. Now it’s very easy to define simple and complex doors. I left some todo’s for the future that a door can be opened with a event in the game (by pushing a switch for example).

Also I extended the basic item to make a ammo item which is holding just one more parameter – firepower. The idea is that one weapon can be loaded with different ammo clips which have different firepower.

The packages in the project started to look a little bit messy, so time to clean up and reorganize.

I wanted to see if it is difficult to extend basic functionalities of tiles. So, we had a simple tile which was extended to a simple door. Now I extended this simple door tile to make a more complex one – a door that can be also locked / unlocked (I). Works like a charm! The unit can now walk across the map, take a key from the ground, unlock and open a door.

Now, the mechanism that tiles can contain items is working (items laying on the ground), and tiles can also be in a specific state (locked, unlocked, opened, closed). Why not make a tile called, for example, crate (c), and program it that the items are visible only when it’s in the opened state. Again, works like a charm! Now the unit must unlock and open a crate before he can see and take what’s inside. Of course if the unit is over cumbered, items from the inventory can also be placed and locked inside the crate.

I’m pretty blown away what I’ve achieved after only 8 days of coding in my free time. There’s enough features to build a nice labyrinth game with lot of mazes and doors. Even now the game mechanics looks so powerful and unlimited expandable.

For the end of the working day, I’ve extended the basic item to make a extendable weapon item with all necessary extra parameters.

 

Today I completed the inventory dialog and added logic for all actions: equipping / unequipping, taking / dropping items.

Yesterday I didn’t had the time to cleanup the unit map data class, so I did it today. To wrap things up, with all these refactoring, it’s much easier to access the tiles on the map and alter their states.

“X” marks the spot! Items are also shown on the map. The simple menu dialog which handled unit’s inventory so far can’t be used anymore for more complex operations. Therefore, I decided to build an inventory dialog which consists of two lists: unit’s current items and items laying on the ground (tile) where the unit is located. The dialog has buttons for all necessary actions: equip / unequip, take / drop items. Info line where current unit AP’s and burden (encumbrance) is also shown.

 

Several improvements regarding AP calculation when turning and moving forwards and backwards were done. The next feature that I’m going to implement required that I do a little bit of refactoring of the unit map data class and methods for movement…

…and the next feature is analysing tiles which are in front of a unit. Now we can look at the tile in front of us and see what actions can be performed on this tile (for example open / close actions for doors). For testing purposes I created a new mock map with some walls and doors.

The unit inventory class needed refactoring and cleaning up too. I’ve also used the time to comment all the code done by now.

     

I added next to the unit’s info also a list of mock actions that an unit can perform on a tile in the game. Also there is now a button which opens a simple menu dialog allowing us to select one of the actions. Same menu dialog is used temporarily to display mock items in unit’s inventory.