Further culminations:
-Fade In spawning / Fade Out destruction (sprite-focused. The shrinking here is for visual flare for this attack)
-Easily customizable afterimage creation (hence the bullets leaving a mess here).
-Sound effect and Background music (Trust me on this)
(The seemingly-random spawn of the showering bullets here is just two emitters that are growing/shrinking and rotating at different rates, set to make those "concentrating" shots).
God it's been a while since I touched this.
This one's simple. Just a manager for two Vector2 points that does a simple deltatime translation. The cool thing about this is that it's flexible (as well as pausable through something outside of Time.Timescale, so it can be used for stuff like pause UI animation). Speaking-of, I have some stuff on that too, but since there's not a whole lot other than "it pauses," why make the update? Well, I also got started on audio, but "the player screams when they die" isn't worth a full post imo.
Demonstration: Two emitters with a back-and-forth.
Demonstration: One emitter moving in a diamond-shape.
This can also be used for cutscenes, since the "loop between points" is entirely optional.
I think by now my approach can be seen in making broad components that I can just mash together for whatever specific patterns/applications I want later.
Doing cutscenes flexibly.
The camera handles cutscenes by loading up a text file with simple stageplay instructions. Each instruction has a set type (dialogue change, resume-gameplay, and level end), letting me do all that fun mid-stage dialogue, start, and ending. I'd like to add one to move/show/hide portrait actors, that way I can do stuff like swap characters around in them, but the important thing is I have it now.
Tying it to a central object also means activating it only needs a destroy-on-update object that advances the cutscene stageplay instruction by one, into a dialogue selection (there's a flag to track if the player is in a cutscene, so even if they can move, there's still a pseudo-pause happening.
Demonstration below. Portrait is Fable 4, because I had that laying in my images.
You'll notice the nameplates change character names too. That was intentional to show off that it's one thing changing and moving around, instead of a name for each actor. Then again I might want to change that later...
Powerups and the start of UI.
Looking at a few powerup types. So far these are just here and dropping in.
From top row, left to right, Points (small), Gold (small), Health (small), [Large variants of prior], Attack Power Up, Shield, Damping, Attack Power Up (Large), Shield (Large). The thing on the points is supposed to look like some kind of wheat or flower. I'm aware with the problem in having the coins both be blank, too.
Points will be typical, gotten through player actions. They will be able to be exchanged for Gold and lives at the end of each stage. There's more ways to get it, but it clears if a player restarts a stage.
Gold is gold. You spend it on lives and cards.
Attack Power Up is a bit self-explanatory, but I'll take a moment to explain how damage works here. Rather than just be a flat rate, players have three attack stats, Sword, Ranged, and Magic. I want to take a cue from Imperishable Night and eventually have the possibility of the player swapping characters when they're "focused," since that would explain an ingame movement decrease speed. In addition, individual cards have their own power. So, the damage calculation adds the damage dealing attack of the card's type, the card's actual value, and this modifier. For most enemies, this won't matter, but the additions would make some boss fights easier.
Shield and Damping should probably have their names swapped. When a player is hurt by damage, if there's a shield, then damage is first removed from the shield, and any current damping is removed from damage not absorbed by the shield before being applied to the player. Damping automatically reduces by 1 every 1.5 (or, rather, a damping time) seconds, allowing for lesser-invulnerability periods and temporary invulnerability periods, i.e. after a player respawns. Both of these are actively shown on the UI below the health, spaced out as a percentage against max health.
(Notice that a collision which previously killed the player does not affect them while the blue bar is still active).
I don't think GifCam did justice just what this bar looks like in action
Lol, I should probably make a little more clear what's happening in that... as a feature for the game, not a blog post, that is.
Added enemy health and player attacking.
Right now the samples only use a basic left and right swing in the deck (my partner commented that it looks like a windshield wiper). The important thing is that these are being instantiated based on the card called by the player. 9-health enemy with a 3-damage attack (most enemies will have 1 health, I'm doing this for the sake of bosses and the like. The attack tracks with the player even when it shouldn't logically, and has a slightly larger hitbox than the sprite, but I really don't care. It's better to give the player a bit of an advantage.
Testing the stance system, I set the card to instead use two duplicates, with a 5 second stance cooldown timer. Attempting to use it twice in a row will evoke the cooldown timer.
(Gifcam captured a bit of the earlier one too).
Next will probably be the camera handler and some spawners, even though the seedwork for bosses and powerups are being set.
First devlog update in a while. Have a few things.
Bullet spawn rotation.
Bullet spawners in other objects.
Player tracking of mob objects (locked horizontal position).
Player tracking - aimed bullets
(There's an obvious gap in this one lol)
All of these are handled by the first iteration of the mob class I plan to be using, calling a customizable list of attack and behavior patterns (versatile and makes bosses easier).
Up next is probably player attacking/deck usage.
So, I've been sitting on this for a while now, but something in another community gave me a kick in the pants to start working on this.
Sir Kaninchen is my idea for a Bullet Hell game. In it, players will control the title character, Sir Erich Kaninchen, a super-soldier knight of the Kingdom of Ostfeld in a world where soul-magic guided industry after the age of chivalry, and also eventually Princess Gail Lavendel, after rescuing her from the Legion of Tastinnte. Little do the two know that the rescue mission was a ploy to send the young warrior to his death in a faraway land, far enough to be unable to obstruct a coup of their home kingdom.
Gameplay
Players will dodge hordes of enemies in a near-constant barrage of projectiles. To fight back, players will use cards to activate Erich/Gail's attacks, usually simple things like a slash or a shot, or heavier specials. After a card is used, the character will be in a set stance. If a player's selected card is 'prepped' by their current stance, they can use it immediately. Otherwise, they'll need a moment to drop their stance. I.E. a player from no stance can swing their sword to the left. If the player's next card is 'prepped' by the character holding a sword to the left, they'll attack as soon as the card is used, same as if it was from neutral. Otherwise, the player will take a moment to reset back to neutral before attacking.
Smart deckbuilding will allow players to chain cards and stances for continuous attacks, or, in conventional SHMUP terms, treat the deckbuilding as a means to create/alter the player's shot type. There will be three decks a player has onhand (by default, one for 'unfocused' movement, one for 'focused' movement, and one for specials, although "specials" is not a movement type, so players will be able to put whatever they want in it), with abilities to customize them post-stage if they wish.
Because the player's first available character is sword-focused, aggressive play will be encouraged, though ranged options are planned.
What's here so far.
I've been sitting on a very primitive script for this for probably years, never getting around to it since I wanted to get another project finished. I didn't have time to get the other game I was working on finished, and now that I have time again I don't really care to at the moment. I may go back to Dawnforth.
So far, I have the basics of the Bullet Hell mechanics. Emitters spawn bullets, bullets can kill players, and players can respawn.
I focused mostly on getting emitter options set. The delay between rounds can be changed on-the-fly, along with number of bullets per round and spread angle (singular, 30 degree angle, 90 degree angle, half-circle, circle). I also added in rotation functionality.
(The pauses in the gif are from me changing the values of the emitter in Unity's editor. The low framerate is just to make the gif small enough to upload)
Roadmap
Instead of doing feature-with-stage, I would rather lay out the framework needed to make each stage, then make the stages, so this is just going to be a checklist.
Holy crap it's been a while since I posted on this. I shook up my schedule a bit (got a tablet that I want to do art on, and worked mostly without incremental updates) I think I want to do every other week switching between gamedev to working on a comic.
Anyway, Level 3 is mostly playable from start to end.
Theming is going to be an underground excavation site for some fossils before they're fully destroyed by subterranean heat, hence the roof. Obligatory lava level is obligatory.
The longer I go on, the less I care about the prototype sprites.
Randomization took a crap on me and wasn't giving me anything I like, so I changed it up slightly to go off of a digit in the camera's position. This means that level segments are appearing in the same sequences during startup. I'll need to fix that and add in some other factor, but I like it for this level, so I'll keep it here.
Increased movement speed is a preview of the upcoming glide move. On each frame a player holds shift, if they're not on the ground and if their defense is 0 (read: they're not guarding and/or taking damage), the scroll speed increased. If they've spent 65% or more of the pre-boss level doing this, they get an extra life. Normally they're supposed to only be able to do this after they beat the boss for this level, but, screw it, it's fun so I'm going to give it to them early, because the long expanses are good for playing around with gliding.
Aside: Kind of unintuitive in hindsight I chose to not check if the player was unencumbered before letting them boost-glide, since this also limits if they can flutter. I should change something here...
Bucket drones there don't do anything except maybe scoot sometimes, unless they have a pillar tying them to the ceiling. The movement from them is a glitch caused by the red rocks shoving them, but it makes them something besides just another stupid stationary turret, and it actually makes it easier to dodge, which, given how crap I'm playing here, is a necessity. I like it, so it stays. I'm sensing a theme here...
I'm really rushing it for the sake of getting gifs. Players normally have access to a quick-drop move by now, so it's not like they don't have options.
Boss isn't anything special, at least compared to how annoying the last one was. This guy just latches onto a wall and bursts a short round of bullet hell-esque shots at the player. Hit him, the wall moves back and has a bit of random height. Don't, and he shoves you behind the camera before moving back. Not the most complicated, but given how busy the rest of the stage is, I don't want to overload everything. This is stage 3/7, after all.
TO DO:
Very important update.
Foremost, in terms of control, combo input rework.
In the options, I set the attack delay to a full .5. You can see the delay with the first input after the unpause. This is normal. The updates come from a special bit with the input logging. For a while, potential moves are logged with a recursive comboTree class that logs an input key, children for next combos, a moveID, and lifetime for the move input
Here's a crude diagram of what's set during level 1 (not counting the shield key tree).
Any check against inputs starts at the base of the tree, then, for each key entered in the input queue, moves down a slot if it's available. If there isn't anything, then return the selected ID, and execute the move associated with it. Before, I was (stupidly) just leaving it up to the expiration timer, which meant that if you did something like continually press attack over and over, you wouldn't actually attack until the entire queue was ready. "Why wait on something if the queue is ready?" This behavior was altered to split the lookup into a more simple function that gets called in the input and timer expiration. Now, whenever you press a key, one of three things happens: (1) if the move in the input tree has potential children the player could execute, wait a delay before executing, (2) it's the last key of a branch, and immediately executes that next move, and (3) if the pressed key does not have any associated moves 'down the branches,' execute the current one. All three are in display in the gif in order after unpause (I pressed up on the third one to get it to attack immediately).
Second important update, level transitions:
The coroutine is a bust for now. It was working fine a moment ago, but then I got smart and added in some checks to the fade to black, and suddenly it wants to shutter now. I'll need to get that sorted out. The important thing here is that all levels are mapped (I'm not going through the full display right now) with their place in the build order and 'next' selection, and basically just need to be 'filled in' with enemies, bosses, and platforms in order to be functional.
After buying, the player is able to buy into the level select now. Fading to black in order to access the end-of-level screen nets a credit, beating a boss gets another. I think I'll leave the test-credit in there since buying stage 1 after beating it makes more sense than beating two levels to get the privilege of starting at the first.
Haven't really messed with any options yet since there's nothing to customize. Hating the way these placeholder menus look.
To-do:
-Level 3
--Enemies (3)
--Platforms (3)
--Boss
-Rework platform spawning to be more randomized (hating how many sections repeat)
Endgoal:
Playable level 3 with substantial platform variety.
Level 2 is in a playable state.
Brief display of some more hectic spawning. Seems like it's all-or-nothing with the way these work. Fixed segments (the pillar buildings with the pink 'dropslashers' need more spacing in order to not "pop in." Also have an annoying glitch with the one railspinner (grayshirt) not shooting off. Don't know what I'm doing with the sprite on that one; sweater and khakis just doesn't seem fitting. Need to go full emo instead. Kickflippers (green shirt blue hair) are as harassing as I expect, will probably reuse them for a later level.
Snippet of boss fight against 'Davus.' Didn't realize that GifCam wasn't recording when I did most of the fight. AI is a combination of both enemies, basically. He starts out idle, then when the player gets to close, he attacks. When he attacks, he moves to the left, then when the player gets within his 'near detection,' he starts moving back to the right and launches knife-looking projectiles for a very short duration, then sets a recalibration point to the right of camera. When he gets to that recalibration point, he gets the player's expected y position at the far-read trigger, and moves up/down accordingly (I have code for spawning a rail object when he does this so it looks like he's sliding up/down it, but I'm not worried about adding it back in). If the player moves too far ahead, he shoots to the right more rapidly.
This can be a pain, especially with the kickflippers harassing you when you jump over his attack, which, due to the rapid nature of it also keeps him under you, but it's nothing that can't be managed. Railspinners are set to not spawn when Davus is out.
I'm just going to vary some of the spawn points a little more and start working on the next milestone, since I'm getting tired of looking at green, and I really want to get to "the Furnace."
TODO:
-Screen transitions (enter level, exit level, intermediary, exit to menu)
-Rework in-game menu
-Rework main menu and level select
-Rework timing for button inputs to make three-button combos more forgiving with default setup.
Endgoal:
Be able to transition a player through the first half of the main game without awkward 'jutting,' as well as utilize what they unlock within.
Intermediate update to show I'm not dead, and since "make level 2" is a bit ambitious of an update goal.
Level 2. Issues with the UI not being properly laid out, and not having good overlays that separate each element are very apparent here.
Level theme is going to be primarily an Amtrack-like train running through a shopping plaza (it'll be more apparent once I start working on backgrounds). Kinda like Tower City, except with a color scheme like out of the 1920s. Enemies: Placeholder sprites are placeholder (lol they're just the old enemy placeholder sprites from before). Enemies this time around are going to be parkour/dancers that jump at you from the sides, either on scenery or from the spawned rails. I think it's funny to have the mall ninjas be the enemies on the rooftops and the parkour freaks be enemies in the mall. Since the last batch only really had the "Hoppers" that test you dodging by weaving under/around a threat, these ones teach you about going over/under. "Railspinners" (the mobs with the poles) don't spawn after the boss threshold is met. They're pretty much set as far as behavior is concerned. I think I forgot to give them health. The "kickflippers" (the other ones) are majorly broken right now. I screwed up their player detection. The idea is that they lunge towards you, similar to the Railspinners, except instead of always being a threat, they only activate their attack after they get very close to you, then spin backwards and into the air to try and nail you for carelessly running forward. They can linger after this attack, that's fine, but I overlooked adding in a "reset" for after they ground once they've made their attack, and them spawning multiple hurtboxes is just a major oversight for more reasons than just being able to tear the player apart (there's one part in the gif where you can see two of them just juggle the player). Should probably remove the rotation altogether since that's a bit ugly.
Building spawns are completely busted. I screwed a bit with adding in an alternate way to randomize everything other than Unity's default random function, since I was unhappy with how many times it was just giving me lowrolls (read: ~70% or smth of building spawned were just the first option, and spawns followed a similarly bad odds (BO-RING!)). The chaos at the beginning is not going to survive into the final game, at least not this early into the level, since the only reason it's there is because of a screwup with building spawns. That's going to be my primary focus for the next bit of dev work, with kickflippers being second. Reason being that after I get that finished, since I have a lot of this initialization crap fresh in my mind, I'm going to just get placeholders made for the other 5 stages, since scene templating was a bust, and I have some notes nearby for how to actually re-tie the prefabs together. Next update will be proper.
Lastly, I know I mentioned that I was going to fix the spawning spacing issues, but, honestly, I don't really need to at this point. More spacing around a spawn point doesn't make it much less boring. Why spawn 1-3 enemies around 1 spawn point for each one, when I can change each building to have 3 spawn points that each spawn 0-1 enemies? Save me some work, and help diversify the placements a little better. The "robust" answer would be to have each spawn point become a spawn "range" or sorts, but honestly that seems like overkill for this type of thing.
