So, let's see.. when the hell did we last update this thing? 2013? Good god, it has been awhile. Let me look back at that post and see what we were even doing at that point... (brief interlude) OK, that was quite a long time ago.
For the last few weeks, we have focused our efforts solely on Molsha. If you have not watched this short, short video, you can check it out here: https://www.youtube.com/watch?v=w7OU7TY4qR8. Molsha, besides being a weirdass name, in many ways, is the culmination of many of the different pieces of the Bevontule development effort, and I'm not gonna lie: setting it up was a bitch.
But, through that particular struggle, we learned a lot. Basically, if nothing else, Molsha taught us that we literally have to start the project over again under a different title. OK, not really, but we did learn a lot. Here is a brief list:
-You literally almost need a dedicated machine in order to bake lightmaps. Briefly, lightmaps are, in a sense, a huge runtime optimization applied at the cost of many, many hours of preprocessing. Lightmaps are often used in lieu of having a dedicated, dynamic light. Essentially, dynamic lighting has to look at every object (actually, the vertices and pixels themselves) in the scene and decide, what is the overall amount of light received by this object? Without going too deep into the calculations, this is a somewhat costly process. Since the position of the Sun in Molsha does not actually change, you could say that the lighting applied to each and every object does not actually change either unless something is obscuring it (aka, the player, but we use something else to handle that). A lightmap, then, is basically a giant texture applied to the entire scene that encodes all of the light contributions without having to compute them every frame. Pretty cool, huh...
-...But this didn't mean shit ultimately, as building the .exe itself caused the lightmap to not be applied at all. This is the reason we had to run the demo within the Unity editor itself. Shameful.
-Recording the actual video was a huge pain, not because we suck at talking, but because FRAPS (video-recording software) hiccuped a lot. Granted, we took precautions to reduce this, but ultimately, all we needed to do (somehow) was restart Andy's computer. Seriously. His computer sucks. I should have suspected that this would be a problem when, one day, we were just programming away, and a piece of fresh toast popped out of what I had previously assumed was his disk drive. We ate the toast; it was good.
-Particle systems use a LOT of computational power. I mean, yeah, this is obvious, rendering thousands of tiny objects is going to reduce the framerate. Fortunately, many of the particle system prefabs were ridiculously overtuned (using 5000 particles over the life cycle of the system, instead of 500 or so.) Reducing these particle emitter counts helped the framerate considerably.
-We implemented a hack to remove the enemy from the scene after you had defeated it in combat. The hack was simple--store the enemy's name before battle, and call SetActive on the enemy with that name once battle has concluded. What could possibly go wrong with this?? I'll tell ya! We were even careful not to have multiple enemies with the same name (that's why each enemy encounter is with a differently named enemy). But, unfortunately, the actual Mesh object parented under the GameObject itself shared the same name. (Why did I do that). In essence, after battle, this disabled the actual mesh and not the gameobect. Hilarity ensued as we wondered why we were able to re-engage with what should've been a non-existent enemy. We suck. We fixed it.
But more than anything, this has taught us that we need to refactor. Imagine that the Bevontule code is a house and we are both the architects AND the people that are building the house. Typically, this is not the case, which sucks in its own way.
So, we started with this:
And then it turned into this:
But, ultimately, we want it to look like this:
Basically, that's programming summed up in a few images. Actually, you don't even need the last image except to display an excessively idealized version of what you want your code to one day look like. (That's what the architect shows you)
The point being, we are going to be quite busy (moreso than before) as we rewrite large portions of our code to better handle the kinds of situations that we are going to encounter. In a nutshell, here is a basic roadmap:
-Rewrite the enemy spawning/saving/loading code to be more efficient, and to anticipate the other problems that will inevitably arise when we get into actual save file writing/reading. Much of this has already been started.
-Rewrite our scene loading code to be more efficient. This will likely involve investigation of other Unity concepts such as asynchronous and additive loading.
-Investigate new lighting/rendering/modeling/batching techniques to get the most mileage out of the scenes we have created. For instance, Cephaline, as it stands, runs at a pathetic 30 frames per second. There are a lot of different reasons for this, most of falling under the category of "trying to walk before you learn how to be zygote" Molsha, on the other hand, ran at around 100 FPS, and is honestly, a much more complicated scene. So, we're learnin. But there is a lot more to be done.
-Vote for Donald Trump
No comments:
Post a Comment