- Jan 30, 2017
- 401
- 1,658
Thank you for the clarification, and no worries, you didn't cause any problems! The conversation shouldn't be playing with the second Alraune, only the first one, so it sounds like I need to look into things regardless.
(The following is (mostly) a copy-paste from our
You must be registered to see the links
If you like what you see,
You must be registered to see the links
) Hey everybody, welcome to the weekly update! This week is going to be fairly non-visual, as Red is still finishing up the Slime CG, Orex is still in the early stages of a new H-scene, and I've moved on to working on stuff like level design. That said, I did add a new obstacle this week that I want to show off!
These are aquatic mines that activate when Alicia gets within range of them. Once active, they'll accelerate towards her in an attempt to collide. They move slightly faster than Alicia does underwater, but as you can see in the gif, their acceleration is rather low, so you can avoid them more easily by jumping and such. You'll want to be extra careful they don't hit you, though, as they do a MASSIVE amount of damage (99 points on normal, which is a full bar of health). They're also invulnerable to standard blaster fire, but once they're armed, they only have enough energy to chase Alicia for about 15 seconds, after which they'll explode without dealing any damage.
--------------------
Now that I have multiple underwater obstacles, I've been working on level design for underwater areas. For those of you not interested in programming, you can probably skip over this entire section - I'll be talking about an optimization issue I faced, and how I got to solving it.
The biggest room I worked on this week was one that has a lot of the underwater currents I talked about last update - creating a larger room using them lead me to realizing that the bubbles representing the current were extremely unoptimized. When the room was complete, those bubbles were taking up about 50% of the game's total processing time in every frame - it still ran fine on my computer, but performance was low enough that it was definitely a problem.
The first and most obvious change was culling bubbles that were outside of the player's view. Naturally, having tons of bubbles outside of the player's camera is unnecessary and wasteful, but I wouldn't be writing a section about this if it were that simple. The biggest problem with culling bubbles outside of the view is that when the current is too large for the player's camera, the bubbles for the current will spawn outside of the camera (since they spawn at the furthest extreme of the current), and then be immediately erased. The current itself will still be active, but the bubbles that visually represent it are gone, which makes it appear as if Alicia is being pushed by nothing. So, a simple camera cull isn't a good enough solution, as it kills the visual representation of the current, so I turned that system off for now.
Next up, I decided to look more thoroughly into what exactly was taking up most of the processing time. The most costly part of the bubbles was checking for wall collisions, which simply causes them to pop when they hit a wall. Running that collision check every frame for every bubble can be naturally intensive; because bubbles are a visual detail and not an actual gameplay mechanic, I was able to dramatically lessen their processing cost by adding a delay to the collision check, so that they would only check for wall collisions once every 5 frames instead, reducing the overall cost of the collision check to 20%. This does have an impact on their visual appearance, of course - they no longer pop the moment they hit a wall, and can instead be delayed by a few frames - but personally, after implementing a fix, I actually like the way it looks better. It makes their collisions appear less homogeneous, and almost gives it a sort of pseudo-3d effect, as if the bubbles are colliding with other parts of the wall instead of only the outermost edge. Perhaps that only works because of the bumpy, uneven nature of the Deep Soil's vines, but whatever the case, it's a nice side effect of optimization.
So after limiting the collision check frequency and doing a number of other, smaller tweaks to their code, the performance was looking noticeably better - but still not good enough yet. Culling the bubbles was absolutely necessary, but it had to be done in a more intelligent way rather than just checking if they were outside of the camera boundaries. The solution I came up with after messing with it for a while was this: when a bubble is created, the bubble first checks its position compared to the camera boundaries, but this time, it also factors in the direction it's going to move. If the bubble is outside of the camera and moving away from the camera boundaries, it deletes itself immediately to not take up any more processing time. If the bubble is moving towards the camera, though, it runs through another collision check - this time, it checks for walls in a line between its current position and the edge of the camera closest to it. If there are any walls between it and the camera, it deletes itself - the wall would prevent it from reaching the camera after all, so it's not needed. However, if there are no walls, then it continues on its merry way, safe in the confidence that it is a necessary bubble. The biggest negative with this solution is that, when a current is exceptionally long and has lots of geometry between the start and end points, there's a point where there are no current bubbles left, just because there are too many walls in the way. I tried a few higher-tech solutions to this, but all of them had issues; at the end of the day, the simplest solution won out, and I simply create manually-positioned bubble spawners behind walls to create more bubbles and continue the current, as you can see in this screenshot.
These are obviously not visible in game, and to avoid bubbles being too concentrated from smaller spawners, the frequency they create bubbles at is scaled based on the total size of the spawner. Altogether, the system ended up being significantly more optimized than before, and hardly any more effort to work with - I'm very happy with how it turned out! Now, instead of taking up 50% of each frame's processing power, the bubbles average out to a mere 13%. Still a little higher than I'd like, if I'm honest, and I do have plenty of ideas for optimizing them further - however, their performance is well within acceptable ranges, and spending too much time on unnecessary optimization would mean no progress on the rest of the game. As long as it runs well for everybody, that's all I can ask for.
By the way, let me know if you enjoy reading deeper dives into my programming work like this; I'm happy to share it more, if it's something people are interested in!
--------------------
Anyway, aside from all that, I worked on a few things this week. The new underwater enemy from last week now has proper animations rather than still frames, and I implemented some much-needed special effects for the destroyable blocks and crumble blocks that you can find in various places within the game. Mostly, though, it's been level design and optimizations, since I've also been working on optimizing the way the game's backgrounds are drawn.
Anyway, that's it for me this week! I haven't been focusing on finalizing my writing as much as I should have, so I haven't sent off scripts to our voice actors yet; that'll be a major focus next week, hopefully everyone will have enough time to get recordings done so the update can come out this month. I don't think I'll have to cancel any streams so I can focus on writing, but if I do have to, now you know why. Hope to see you next week for another round of updates!
