Not much has changed since last video, in terms of new features. I've added a few more materials and added trees and doors to the game. Also I'm still struggling with my lighting system. In the video below you will notice a bug after the house has been build and I place the first torch. This bug is now fixed. I am still not happy with the lighting system, but at least I'm getting closer to a solution- But for now I've benched the lighting issues so I can continue to add new features.
So the trees was a bit tricky to import to my game. Since everything is tile based I try to create everything as tiles. For the trees I "broke" that rule. The trunk of the tree is tiles, as it should be. But the tree top is a different story. Since the treetops aren't really supposed to influence the game in any way, I decided to draw the treetops as a full picture, and place it at the top trunk tile. So basically the treetops are just an image placed strategically to make the trees look whole.
Currently trees will be drawn in front of any background tiles, but behind any "solid" tiles.
A side effect of "forcing" the treetops onto the topmost trunk tile is if you don't chop down the entire tree (i.e. you chop at the middle trunk tile) the treetop will simply be drawn on the new topmost trunk tile- thus making it look like the tree is shrinking. For now I will keep it this way, since I kinda like it.
When I generate a tree, the 3 bottom tree tiles are always the same. Then for each trunk tile upwards, I randomize what to draw by changing the tiles Orientation enumerator accordingly. This gives a slightly varried look for all the tree trunks.
As I mentioned above, I try to handle everything as a tile, which I did with the doors. I ended up using a quite messed up way of doing it, and I will surely rewrite it in the future. For now I'm pushing ahead to get more stuff into the game, and then take a week now and then where I will clean up code here and there.
So the reason it got messy is, that a closed door takes up 3 tiles, and an open door takes up 6 tiles. (2X3). A door can open both left and right, meaning it can touch a total of 9 tiles. This also means that since everything is drawn as a tile I will need to have an image to represent each tile, in each door state. Meaning 3 tiles for the closed door, and 6 for each of the open ones, so a total of 15 different tiles. Each tile in the world, has an enumerator which holds the type of the tile, like Grass, dirt, stone, tree, etc. Every tile also has an enumerator holding the orientation of the tile (Top, bottom, centered, free (not surrounded), etc.
I decided to use a combination of the type and the orientation to keep track of what to draw. So basically a closed door would consist of 3 tiles of TileType.ClosedDoor. Each tile would then have their own Orientation like Orientation.Top, Orientation.Middle and Orientation.Bottom. Since it would not make sense to use any other orientation, I decided to create 4 additional TileTypes to handle the door. OpenDoorLeft01 and OpenDoorLeft02 for a door opening to the left, and then do the same for the right direction. By using the orientation each door type would then hold the top, middle and bottom part of a door, but since the open doors consist of 6 tiles, OpenDoorLeft01 is one half of the door, and OpenDoorLeft02 is the other half.
A solution could be to simply break/bend the rules of keeping it all as tiles. It would be no problem to add the door as one entity (as long as I maintain the correct size) and simply draw the door as open or closed, based on either a bool or maybe an enumerator (DoorState.OpenLeft, DoorState.OpenRight, DoorState.Closed) and reserve the tiles in the world accordingly.
This would also save me a lot of (imo rubbish) code.
But enough from me for now. Here's the newest video I've made where I chop a few trees, and build a small house. - Note that the there is still no crafting system, so the materials was spawned prior to recording the video.