Today's notes.
1. In terms of trying to reduce UI elements, that's something I'm always in favor of, when feasible -- I definitely start with that premise and then start thinking about how to get the UI to work. You might notice that our UI in general is a lot smaller than many comparable games. That said, when it comes to health bars I don't see any way around that for this game that would be clear or even technically feasible. Minecraft is using cubes for everything, so that means that they can just layer a second texture -- damage texture -- on the side of said cube. It doesn't get any easier than that, technically speaking -- Minecraft is quite technically impressive in many ways, but it's also design-wise impressive in its elegant simplicity.
When you move away from cubes into more complex 3D objects, the damage maps are still possible, but more complex. When you move to sprite-based graphics such as what we have, doing that becomes really challenging, because of the need for alpha masking, etc. There are some shaders that actually would let us do some on-GPU damage masks that would basically poke holes in objects, but the quality of that is likely to vary heavily, and it would also raise the system requirements substantially for that one feature.
Suffice it to say, I don't think it's feasible, which is why I put in the health bars. Originally for things like plants we just had them flash red instead of doing a health bar, but I found that a lot more immersion-breaking than the health bars. I think that health bars are such a common trope that to your average gamer they're as invisible as score popups. They are to me, anyway. Right now that's not really the sort of thing I can focus on anyway, I have to add, because actually finishing the game and getting to beta has to take precedence over something like this unless it happens to be easy, or is really jarring in the case of something like the action popups (which definitely need to be addressed, as formerly noted). It's always a case by case basis, but for now I can't think of anything better for the health display, at least.
2. In terms of the bosses, most bosses will look different enough that you will know it's a boss simply by what it looks like. In-game, the music will actually be different for bosses, too, letting you know one is there. The only ones where there would be any question are with the micro-bosses (as opposed to mini or full bosses) like the skelebot bosses you saw (or rather missed) me fight. All that said, we will have little icons by the health bar showing things like elemental resistances/weaknesses and such which will be boss-specific, and that should basically add that final visual clue that you're looking for.
3. Yes, it's definitely a dungeon
graph, not a dungeon map. Scale has no meaning in it, etc, it's all about showing relative connections. I was wondering who was going to mention that first.
It's the most compact, efficient, clear way to visualize the data, I've found -- I tried using more complex visualization methods that would allow scale to persist, but that then interfered with directionality and increased the size of the graphs by 500-4000%, thanks to the vagaries of graph untangling algorithms. Good eye!
4. In terms of the player movement, there was discussion on that, but I don't think here -- I think that was on Youtube or the blog, actually and I think reddit, too. What I've done in the latest build is speed up the character acceleration 2x and then a further 1.75x, so that it feels a lot more snappy to start moving (that was annoying even me, though it hadn't raised to the level of consciousness yet), and then there's now a deceleration that is equal in rate to the acceleration. It definitely feels
much better. In terms of a visual sliding motion, I might do that later on, but for now the visuals work well enough there and I have bigger fish to fry -- the acceleration/deceleration tweaks themselves were definitely really important, though.
