Skip to main content

DevBlog #17 - Game

     These past couple of days have been exceptionally rough. I accidently destroyed my temporary file backup system for the game, and pushed the bad code to GitHub. I then spent 20 hours trying to get everything back. Olex and I where up until 1 in the morning trying to fix everything. Then we shut it down, picked it back up at 6 and continued work. We finally got everything working again, but it was a grind. I then had to redo all of the work and progress that I had made in the past week and a half. In the end though we got it back, and I learned a lot about source control.

    I also made a bunch of progress on the card effect manager script, and realized something about scriptable objects.

    Firstly, the card effect manager. I created a system that would allow us to in the editor customize the exact impact and effect the card would have on the player, and on the board. Then I created a system that would track how long the cards where active, then remove them once they had completed their effect duration.

    Lastly, I also realized a really big plus, and a really big negative about scriptable objects. They can not used the way that I was originally planning on using them. In order for me to use them the way that I wanted to I had to duplicate the scriptable object, then I had to manipulate that duplicate. This would allow me to have the system that I wanted. Since if I adjusted or manipulated the data of the scriptable object, it would remain forever changed and set to that value. This means I create the data in the editor on the scriptable object, then I duplicate and adjust the data if need be.

    Although, just duplicating it was not the only change. In order for the system to work, I needed to rewrite 3 of the other back end systems to accommodate these changes. Furthermore, I rewrote the tech tree to duplicate and adjust the techs, so as not to alter any of the original data. This then changed the way that I was checking required techs and if they where researched. I needed up adding the names of the techs that where researched to a list, then checking to see if the required techs button's tech scriptable object element's name was inside of the list. Sorry for that really ugly statement, I tried :).

    I also fixed some bugs relating to the tech tree spin system, and fixed the closing and opening of the tech tree. I rewrote how terrain objects where deleted and separated them by frames to make the checks function properly. This reduced the terrain anomalies, but did not solve it so I am going to have to go back and check to see where exactly I went wrong.

    In the end, a lot of progress and setbacks, but that is what programming is all about. Bye and see you later!

Comments

Popular posts from this blog

DevBlog #41 - Game

    More progress has been made, and I feel like a million bucks because of this game.     1) Tech Tree Restructuring: I have switched my 1D list to a 2D list so that I can store all of the data about the branches and their different techs in each era. I have made it so that you can smart scroll through eras and through each tech category. Once researching the first tech, settlement, you can then get access to all other tech categories (Military, religious, education, industrial, etc), and each tech in that tree for each era. At the bottom, you can press a button to increase or decrease the era that you want to view. However, you can only increase up to a certain point, either the max of era 3 or the furthest era that branch goes to. This makes the tech tree feel a lot more advanced and less crowded.     2) Auction House: I have now got the viewing system working for all of the cards in the auction house, as well as the system to reassign who it is that is ...

DevBlog #18 - Game

      Today, I spent 10 hours working on the ability for a user to select a card, then a tile, the hit the card again in order to use it if it is tile specific. However, this idea sucks, and I don't like. Tomorrow I am going to go back and change the entire system. Instead you are going to drag the card to where you want it to go, then release it on the tile you want the effect to take place. This will then apply the effect to that tile. This way it is one click and not 3, and is also more interactive for the users. Furthermore, I wont have to convey to the user that certain cards are tile based, and some are not.     I also rewrote the terrain hex map generator script. I made the script completely modular, meaning that in the editor you can create an object to spawn on the terrain just by clicking a plus. You then plop in the model, the name, the description, the spawning frequencies, and the tiles that it can spawn on. Then for each tile that is generated it c...

DevBlog #5 - Game

      Hello, found out a solution to the problem that I was having yesterday. I have discovered the fabled perlin worms. We will use them by starting them off on high terrain values, and going to low terrain values changing every tile it touches into water tiles. This will create the effect of rivers.     Easy money!     Thats all for now, bye!