Day 78: Today a plumber went to see the damage. He couldn’t do anything and should be coming back on tuesday. On the news my headache still persists. I fine in the morning but it started coming back in the afternoon. That’s really annoying.

Daily interesting stuff:

• Reddit post about addictive systems. What was funny was that one guy cited Raph Koster a theory of fun. And the actual Raph Koster responded linking to two of his talks.

• Article about not watching the news. I actually found this yesterday while waiting for my kindle to charge. It’s not related to gamedev but since I don’t really like news I thought I should share it.

• Raph Koster “games are math” talk. I won’t lie, I didn’t understand everything. But it was still interesting.

• Gamasutra article about 2016 gamedev industry trends. It’s totally subjective, and there no data to back this up. But it was still interesting.

Tasks done:

• Worked on the Update System. I’m pretty much free rolling on this one. I don’t have precise tasks written (except for “do an upgrade system”). I thought it wouldn’t take a lot of time to implement this because I thought about how to do it for quite some time yesterday. Turns out that my vision was far from being complete. This shouldn’t surprise me since it’s always like that. But still, I got a big chunk of it done today:

  • I got the base class working pretty easily. It’s just data and two abstract methods.

  • Then I worked on the specific stats upgrades. It’s the upgrades that will modify the ship’s stats ingame. I used reflection so that I can just have a field string property in the upgrade. That way I can have only one class that work for each stat update. DRY is the coding principle I follow the most.

  • Then I had to find a way to save the data that I need to persist. I started by adding the appropriate variables in the save class.

  • After that I worked on the shop. I had a bit of trouble getting the buy function called. Since the items are procedurally generated, I needed to do the same with the buy. I just add a listener to the onClick of each button when the item is created.

  • Then the shop checks if the item is buyable. I needed a bit of work for that too. It required a lot of data. Stuff like weight, price (which is multiplied each time you buy an upgrade), number of upgrades etc…

  • If the item can be bought, then I start the save data modification. Adding weight, removing money. But most importantly calling the specialized modification in the Upgrades. This is where polymorphism comes in handy.

  • I thought I was done, but I was wrong. Then comes all the feedbacks updates and the equip/unequip specificities. Because if you can unequip stiff, it would be unfair to have you pay the whole price when you want to add it back.

  • After many tests, and fixes, I got all of this working correctly. And then I thought of making the unEquip feature. Thinking that it would be trivial given all I’ve done. I was wrong again. Because if I have a “click” event that work for buying, there’s no event for “pressing the return button while having the item selected”. And that changes things. But since it was already late, I decided to call it a day and leave this for tomorrow.