Insurgence of Forgotten Fairies

  I'm not quite sure what you mean. I understand the idea behind a border around the game area, but how would borders around the text work?  Just boxes around the text, or something more complicated?

Yeah, just a box/frame around each bit of text.

  I don't really love the idea of a frame around the text, but I did experiment with something similar:

  It looks a bit cluttered right now, but I think with some tweaking it could work. I also edited the 3D background a bit, and it looks a lot nicer.

 I started implementing Potential Shifts/bombs.

 This is Kiyoko's A-type bomb: "Charge Danmaku: World Ender". So far I've got bomb damage and triggering working. I still have to implement a limit to bombs, as well as a way to acquire them.

  It's been a while. I feel a bit disappointed that I don't have more to show visually, but I've been hard at work on the programming side of the game, as well as the music.

  This image might not look that much different, but it's actually running a completely from scratch bullet "engine", if you will, using the Image API. As of this writing, it's a conglomeration of the Image API and ten separate lists, each with a separate value for each individual bullet. I then run through the lists each frame, and update the position and angle of the images to coincide with the values stored in the lists. While it was a bit of a pain to get working, the plus side is that now I only require a single block to spawn a bullet, I have much greater control over what I can do with each bullet, and the framerate isn't tanking because of the sheer amount of actors on-screen.

  It still requires some polish, and there's a few things here and there that I need to optimize to get a fully steady framerate, but I thought that this was a good point to give an update on things.

  Just got back from vacation, and I've gotten a fair amount done!

  I've set up a system that allows me to assign an actor an attack mode, and put that together with an internal timer in the stage scene, and now I have the main stage enemies: fairies! They'll have the widest range of attacks, but are incredibly weak: only a couple shots kills them off.

  There are also new Potential pickups on screen. Along with those, I've also made pickups for Extend, Potential Shifts, and lives, each a different color: light blue, black, and rich red, respectively.

  It's a bit hard to see, but grazed bullets now get a purple/pink tint over them, indicating they've been grazed.

  I've drawn a new portrait for Kiyoko (again, probably for the last time, I'm very happy with her now), as well as the portraits for the Stage 2 bosses, though I'm not totally set on one of them.

  I've got lots of music partway composed, a lot of which will have to wait for another game, as they don't fit perfectly.

  I'm running into framerate issues with bullets again. I'm probably going to have to find another alternative to the Image API, or find a way to use it better, because as it stands now, I can't make the danmaku that I want. merrak gave me a bullet demo over on Discord that managed to run 4,000 bullets before dropping frames on his end, but I couldn't get it to run over 1,000 on mine. I want to get my game running smooth on my (relatively low-end, now) computer, that way I can let the most amount of people have access to it. But at the moment, I'm rather stumped as to how to go about this.

  Otherwise, I'm back again, so I should be able to post here a little more frequently.

It'd be interesting to know the specifics on how (Touhou?) game's engine works. It's not a game I'm familiar with--I just did some browsing on it. You might need some kind of hardware graphics acceleration to bump the bullet limit up significantly higher.

I took a look at some of these games and I'm thinking you'll need to improve the speed of the code I gave you by an order of magnitude to reproduce the patterns I've seen in some of the more elaborate screenshots. The sample I wrote took me about an hour to write, so there's probably some things that can be improved by taking more time... but I'd be surprised if there's enough to speed it up 10x.

It is possible to pass arrays to shaders, which would give you a route to take advantage of them. Shaders aren't something I know much about, but I'm currently looking into using them to speed up rendering in my game. If I come across anything that I think might also help you out, I'll pass it along.

Huh, didn't think of using shaders, but I'll look into them. I've tried to find the specifics of Touhou's engine before, but the guy behind it built it from scratch, so there's almost no documentation on it.

I've had to recode my bullet system once more, as I keep needing more bullets, and default Stencyl functions simply don't have enough power.



The above is a successful experiment on whether or not the tilemap class runs on Stencyl. There are 400 separately rendered 32x32 tiles, each with their own velocity, each bouncing off the edge of the screen. The low framerate is because I have been testing on Flash for a faster compile time. What I find the most interesting is that all four unique tiles are taken from a single image in the "extras" folder. The code then slices that image up, and renders what we see on screen.

From here, I'm planning on attempting to add support for this, but I've had very little luck so far. I think that I might have it in an extension, I'm just blissfully unaware about how to actually access it...

  I've dropped the idea of using CannonML, and I'm now coding my own system from scratch again. So far, after a lot of referencing OpenFL API's I've managed to piece together enough code to make this:

_{A la a certain nuclear crow.}

  I can't count how many bullets are on that screen, but it tends to hold a relatively stable 59 fps, which is amazing news. squeeb requested a demo scene with the bullets in it, so I'll probably also release that in the Shared Resources section for anyone who wants to makes a ton of bullets/particles/whatever.

  I've also added a Potential Shift counter and limit, which functions, so you can't spam bombs all the time, as well as a life counter, which is functional as well, but there is no game over event yet, so dying has no punishment as of yet.

  There's now a border around the game area, as JeffreyDriver suggested, and it makes it pop quite significantly.

_{Stage Design!}

  I've solved a very strange lag problem with MakuTile that only seemed to affect the first bullet in a series created. I now create an invisible bullet before every series of bullets, so that the invisible bullet lags, and all the rest are fine. I'll try to update the public release of MakuTile relatively soon to add this functionality, as well as a few more quality of life additions (e.g.: a custom block that creates rings of bullets, with customizable amount and angle range.)

  And with that, I think that the bullet system is finally complete. I might add stuff as I go along, to make things easier, or more efficient; but at this point, I can start focusing on other parts of the game. There are still 5 more players to code, and 3 more to animate. There are tons of dialogue portraits to draw. There's still quite a lot of music to be composed. There are 5-6 more backgrounds to be modeled and textured. So on and so forth, but at least I can actually start working on those, without the bullet system weighing me down.

_{The first named attack in the game.}

  I've polished up the health bar a bit, so now it has a nice slight gradient towards the bottom. It required me to draw 7 different rectangles at once, but it looks pretty nice now. This is the first time I've posted on the journal with the new boss sprite artstyle. I'm also working on a redo of the player's sprite, but that's not done yet.

  This screenshot also made me realize that I need to alter the bullet sheet a little. If you look closely, you can see other bullets "bleeding" into the bullet image. It should be able to be fixed simply by separating each bullet by a pixel, and then reflecting those changes in the bullet defining code, so it's nothing horrible.

  This is also the first named attack I've made since I remade the bullet system. I've also set it up so that it gets slightly harder when the boss is at low health.

  Not really an update per se; I just wanted to post this side by side picture of my first game and this game, since this is my first game's first anniversary.

_{Some improvements have been made...}

_{Some improvements have been made...}

Impressive!

_{The full spectrum.}

  I've updated my bullet sheet to have 36 different colours for each type of bullet, resulting in a total of 108 unique bullets so far. This will be important in the future when I code the final boss.

  However, at the moment I believe that I need to look back into optimization again. If you look closely, you'll see that each bullet is not a uniform distance apart. This is because the game is stuttering a bit, dropping below 60 fps for a fraction of a second, before running smoothly again. MakuTile has no lag compensation (which I don't intend to implement, either; I have no idea where I'd even start for that), meaning that every frame drop causes the bullets to stop for a tiny amount of time, messing the entire pattern up just a bit.

  I've got some places that I could start, for optimization. For instance, the health bar at the top is made up of several rectangles, being drawn every frame. I could turn it into an actor that just rescales itself based on the bosses health (like the bar beneath "Potential"). I could also bake some of the text on the HUD straight into the HUD sprite, as the words never change, so they don't need to be drawn every frame. I also heard that you can apparently draw text using the Image API, and it's apparently faster than a drawing event, so I might look into that as well. I could also store the 3D backgrounds frames into an Image API list, so that it is being drawn by the Image API instead of being a very large actor. I have less faith that that will do as much as the other options, though...