Re: Malise and the Machine (New RPG!)
When you say you still have a few kinks to work out but should have everything done in the next few days, does that mean what I think it means, or is that just for the lighting system? (which looks great)
Ah, it just means for the lighting. I've pretty much decided on a hard release date of July 1 for V0.02. I'll likely make a post soonish on what all will be included, but the big news for that I guess is I'm highly considering adding a new H skill branch to Vorepups to serve as a demonstration of how the armor damage system functions mechanically (as well as how different characters/outfits can change the behavior of enemies).
Doing this will fill out the content for this release while giving me more time to work on the Tetra Interface for another release cycle, as that's something I *really* don't want to rush since it involves ripping a solid chunk of RPG Maker's battle system out and replacing it. That, and adding the next layer of enemy AI for the armor damage system is something I found I want to tackle sooner rather than later as it will give me a lot more insight on what is and isn't possible for later H attack designs.
Back to the lighting though, a few kinks has turned into more kinks as I'm becoming aware my shadow/light parallax system is ramming RPG Maker's memory limit (since the maps are, for RPG Maker at least, really big, and RPG Maker's memory limit is apparently really low). In an earlier post AltairPL let me know that this was a function of total pixel area being cached, as I was originally running into issues with big enemy sprite sheets. Well, here we have really big parallax layer images (at most 6400x2000 currently).
In short, I need to unexpectedly spend some time addressing how to limit my dependency of big images sitting in the cache (which is something I was going to have to get to at some point anyways if I want big enemy sprites with lots of animation frames).
My current list of solutions include:
1) Get away from caching enemy battle sprite sheets (which are fking huge pixel-wise). This *could* mean some load times, however I could possibly balance it so only sprites for the next battle are cached. To do this I would have to edit the random battle system so that it chooses what battle is next *right after* a battle or when the potential encounter list get updated, and then cache only the enemy sprite sheets for the next battle while the player is derping around on the map/menu instead of loading them the battle starts. Unfortunately I'm not sure offhand how big a project that would be. For evented battles I could manually script that sprite sheets be cached before the battle on a case by case basis, like during dialog before the battle starts or something.
2) This one pretty much has to be done if I want to continue to have big enemy sprites in the future, and that is modify the animated battler sprite system so sprite sheets don't have a ton of unused pixel space (could cut unnecessarily used pixel area by over half). Basically right it has a fixed set of poses for each enemy, meaning a fixed number of rows of sprites per sheet. Well, no enemy is going to use all of them, and some are redundant, so I would add a table that tells the sprite system which row is which pose for each specific enemy.
3) Both of the above.
In addition I need to look for simple things I'm not currently doing, such as forcing a cache dump of all the title screen images and such when the game starts.
Sorry for the wall of text, but I needed to sort these thoughts out anyways, heh.