Day 110: Today, I finally went back to coding. I thought I would then return to a full speed productivity level. I was wrong. I didn’t do much. I keep asking myself what would be best for my career. To finish this game as soon as I can and then move on to other things, or take some time to do other things (like portfolio and C++). It’s hard to work like that.
Daily interesting things:
Reddit post, quote of John Carmack. Basically get it done is more important than anything.
Reddit post, why being broke is actually good for developing a game. It’s all about how being limited makes you focus on the important stuff.
Tasks done:
Responded to the potential artists. It was shorter than usual. I think we agreed on dividing the tasks. I’m waiting a bit to see if I get a response from the other that didn’t respond yet. Then I’ll set up a group chat, where hopefully we’ll be able to iterate faster than reddit PM and emails.
Fixed the weapon cooldown behavior when there’s more than one weapon. There was two problems. First, when one weapon was in forced cool down, the UI bar would become red and blink. But when you switched weapon, you would still see the blinking bar, and not the cooldown bar of your weapon. Second, when you used a weapon, the other one completely stopped. This is the intended behaviour, except for one thing: it’s not cooling down anymore. So if your were at say 50% and then you go use the other weapon, when you came back you would still be at 50%. This was a bit frustrating while playing. It wasn’t obvious as well. But you would get the feeling of always being in forced cooldown. Solving the two problems wasn’t too hard. First I checked if I wanted to show the blinking bar each time I switch weapon. If the current weapon is in forced cooldown, I show it if not I don’t. For the second problem, I changed the way I deactivate the weapons during the switch. Instead of disabling the Update method (enabled=false), I used a custom bool to check is the weapon is active. Then, the cooldown is updated at each frame regardless of the active state.
Fixed an issue with the bomb. Due to how it was coded, the bomb required to know in which room the player was. Then it would be able to access a list of the containing enemies and do the appropriate behaviour. But since the bosses aren’t technically in rooms (it just looks like they are), it didn’t worked. And I couldn’t just make the boss rooms to be actual rooms. Because rooms are supposed to be created by the dungeon and need to be inside the map coordinates. Plus the mini map shows all rooms as soon as you’re in one. And I didn’t want the player to know the boss rooms are actually just object placed in the main scene but away from the dungeon. So I rewrote the way the bomb deals damage. I used a physical approach instead. There a built in method in the physics engine that returns all the colliders that overlap with a circle. So all I had to was to provide the center point (the bomb pos), a radius (created a variable), and a layer mask. The layer mask is important because it enable me to specify in which layer the overlapping objects need to be. So I just add the specify that I wanted to test against the Bullet layer and the Enemies layer. And voila! I got my list of object I need to deal with. The bomb code is now much more short and clear. I don’t think it as any overhead, since it’s done only once and at the player request.
Worked on my portfolio. I really didn’t thought this would take me so much time. It’s been weeks since I started. But it’s hard to find time to dedicate to it. So I took a few hours to work on it. I finally have all the content now. But there’s still a lot of things left to do.
0 comments