Hello readers!
Coming in a bit early for this month’s post but that’s because team phloup is having our first company retreat (AKA holiday that we’ve had planned for a while). We’re heading off to enjoy the cherry blossoms, temples, and what will probably be several hundred thousand internal Japanese tourists being in the same place we are. 
But that’s next week, what have we been up to lately? Would it feel like groundhog day if I told you it was more grant proposals? Because that’s kind of what it has been. Right before my latest shift, we ended up applying for the Screen Australia Emerging Gamemaker Fund grants. These are a lot more competitive, but they do have a history of funding some really interesting games, so we’re hopeful they take a punt on us!
O.K., I promise no more news about grant applications until we actually hear back from one. How about some actual game development? The last week I’ve been testing out how best to perform our collision detection. The great thing about programming is that there’s often a number of different ways to do things depending on how you want to structure your solution. But that’s also the bad thing if, like me, you’re still trying to figure out exactly how to structure your solution. And I know, I know; collisions aren’t exactly an unsolved problem. However, with such a small team, I need to make sure that the solution to each problem is as modular as possible. Or at least try and take into account the fact that at some point in the future we may decide to significantly change the moment-to-moment action of the game.
What do I mean by making it modular? A good example of this is the implementation of an event bus system. Instead of coupling objects together by specifically referencing each other, you instead get them to subscribe to a signal that can be emitted by anything. This is something I’m still trying to get my head around as it turns out there’s a few behaviours/bugs that can affect the use of Area2Ds in this way. There’s a system within Godot that offers roughly the same functionality (but with a little less elegant implementation) in the form of Groups that you can loop through without knowing the instantiated nodes within them.
For example, in the below video, the Player node isn’t aware of any of the other nodes in the scene, and no signals are hooked up to them. When they attack, a hit-box checks if there are any overlapping nodes, and then applies effects based on what group the node has been assigned. Again, it’s pretty basic stuff when you type it out like that, but it took me a few days of experimenting to determine the best combination of area/physics collider box/groups/signals use for us.
The black bar is totally part of our marketing strategy to make the protagonist more mysterious and not us being reluctant to show art assets at this stage 
Oh yeah, some gameplay! This is an early attempt to show what we hope to achieve with the cavern side of the game: exploration of a destructible, procedural dungeon using a combination of powerful attacks sending enemies into (and through) the walls, and regular old ‘punch the walls until they explode’ to reveal hidden mineral deposits. This will be the part of the game during which players earn the cash and resources to spend in the Town to help residents and purchase upgrades. I genuinely can’t wait to reveal more of the art style as we become more confident in it, but for now we’re sitting in the region of The Ferals meets mid-90s Nickelodeon. It’s extremely fun to see Lou exploring it!
Alright, that’s enough from me. We’ll report back in June, sayonara! 
phill.