shmups.system11.org

This looks perfect. Congratulations, you've already made a better furry shmup than "die because you grabbed an innocuous powerup" Sine Mora or "make your ears bleed" Eight Forces.

Speaking of Sine Mora, is your game defensively designed so it can't be exploited with autofire? Even if you have built-in autofire, if it's possible to shoot 1 bullet per tap of the button it's possible someone will do this and break the game wide open (although in this example the default autofire is hot garbage so who cares, lol). Easiest way to avoid it is probably to do something like Giga Wing and make each button press fire a burst of 3 shots for a number of frames and it keeps firing so long as it receives an input within a given number of frames. There's a lot of little things like this we take for granted as good shmup design nowadays (but if you're not making a game intended to be score attacked competitively then this isn't a big deal if it's exploitable).

Thanks! The auto-fire accumulates frames before firing, so you cannot rapidly tap the key and exploit the firing.

Here are some music samples to give you an idea of what to expect music-wise. Enjoy!
https://www.furaffinity.net/view/47382341/
https://www.furaffinity.net/view/47382374/
https://www.furaffinity.net/view/47382404/
https://www.furaffinity.net/view/47382442/

Note: I haven't been posting updates in a while because I'm working on the spoiler aspects of the game. Peace!

Minor Update: I added warning symbols for boss attacks that are hard to anticipate.

Added 3D effects for certain boss backgrounds:
https://www.youtube.com/watch?v=IAWnpJmGEQI

Story mode is complete! I just need to finish the extras.

Added card hints:
https://www.youtube.com/watch?v=pIqWrqEDCrk

If you want to see more awesome videos and updates of my game, you can follow me on Twitter:
https://twitter.com/SolidSpy24

Have a good one!

I added additive blending to most of the enemy bullets. It looks a hundred times better. I initially didn't want to do this since I was worried it would compromise the 'retro' aesthetic, but it looks too good to pass up, and I feel like it gets away with it just fine.

Hope you enjoy the new look!

looks awesome. I like the style

Thanks!

Challenge levels 1-3 have been completed. Only one more left. There you will meet the most challenging boss in the game.

She awaits you.

RELEASE DATE ANNOUNCED

Congrats on making it to release stage with this project! That's a substantial feat to be proud of. Your work on the game's visual polish shows. Music is catchy, and the 'modern' option is a very welcome feature.

If you can make one small change before release, I'd suggest switching the default controller movement map to use the d-pad instead of the analog stick. The 8-way digital movement of the game feels desirable on a sega saturn pad or steam deck d-pad, but feels cursed having analog input snap to 8-way as with the defaults. I think d-pad defaults will be a better first impression to the average controller user.

Game demo runs good out of the box on a steam deck otherwise. Game maintains a smooth 60fps, but I note that the game speed drops when framerate is manually capped below 60 (e.g 30fps = 2x slower game).

Lastly, demo was a bit easy. I imagine later levels are more challenging, but you may want to consider shoe-horning in a "hard" extra mode that raises enemy bullet speed + lowers player health.

All things considered, you seem to have a fine game set to launch; good job!

Thank you! It's been a blast and the game for the most part is complete. I'm just in the last testing phase and have to update the game manual.

I can definitely switch the default to the gamepad instead of the joystick. I initially chose the joystick because a lot of arcade shmups tend to use them, but if the gamepad is preferable in this day and age I can do the switch.

As for the framerate issue, I'm sorry to say that I've decided to use a fixed timestep for the game logic. I've experimented with delta time steps for making shmups before but always ran into problems with making sure bullets spawn and move in the same way regardless of the delta time value, and that collision detection doesn't get wonky. I've been mulling on it and I think I have a solution, but it will be difficult to shoehorn in at the last minute and I can't make any promises.

Rest assured the game does get more difficult, and there is a hard route in the Story mode you can take.
Also the challenge levels can get quite feisty. I saved the hardest and most challenging for last.

Thank you for the feedback ^^

For what it's worth, arcade joysticks and d-pads are the same thing as far as the hardware and I/O stack are concerned. Some sticks offer a mapping to analog axes for compatibility, but they're digital 8-way inputs first and foremost. It's only outliers like the UltraStik 360 and similar that offer true analog output, and those tend to map back to digital as well.


It's possible to keep fixed-timestep and render at arbitrary framerates if you separate the visuals from the gameplay simulation and interpolate them between the two last known transforms of any given object; the previous transform becomes the 'from' term, the current transform becomes the 'to' term, and the interpolation factor can be calculated by taking the difference between the current timestamp and that of the last simulation tick, then dividing it by the duration of one fixed step.

Doing this does introduce one frame of internal input lag, since the visual interpolation can't occur until there are two gameplay frames available, but it's a nice option in cases where your simulation is already locked in as fixed-step, and relatively easy to retrofit if your objects are standardized. Looks convincing for low framerate sims too, though that's not terribly relevant to the arcade side of things.

Funny enough, Unreal engine seems to have this handled internally for the graphics side. I've run the game with computers using lower-end graphics cards, causing the screen refreshing to become choppy, but the game logic fps is still 60 and time doesn't slow down.

The main issue is getting bullets to spawn at exactly the right time and move in the exact same pattern regardless of delta time.

I'm currently trying to split the delta time into millisecond chunks and so far most of it is working, but I still have to iron it out. I'm testing it with the demo. If I were to implement it with the entire game however, it will definitely be a lot of work.

Holy 3 golden balls. I managed to get the delta timestep finished for the demo. I haven't released it yet, because I want to make sure I can implement it for the full game as well.

Needless to say, it created a lot of chaos and I had to fix a metric ton of bugs. Now the demo is in a stable state, and I've tested it with multiple different kinds of framerates ranging from 15 to 60.

Hopefully I can get it added to the full game in time. Wish me luck!

If you'd like to use the joystick mapping, you should try using analog character movement instead of 8-way snapped and see if it feels good in your game. Users with Arcade-style 8-way joysticks will still move with 8-way snap with their sticks mapped to the joystick, and analog stick users will have a smooth 360 circle of precision movement - the best of both worlds. Unreal probably makes it pretty easy to do this somehow with something like:
May be a nifty, easy way to make your stg feel sleek and modern.


Don't do anything that breaks the game close to launch; your demo wasn't broken, so I'd be very cautious 'fixing' it. The game maintains 60 frames ez so don't sweat it too much. You're prolly better off focusing your times & efforts on promoting ur game's release across the net, then patch in 'performance fixes' update some time after a strong launch.

I don't think UE does any automatic inter-frame lerping, i.e. running a 60FPS fixed tick won't magically render as smooth 120 if run on a high refresh monitor, but it does have machinery to try and run the physics tick at a consistent rate regardless of what the GPU is doing.

If memory serves its behaviour depends on a combination of project settings and arcane console vars, but from your description it sounds like it's probably running a blocking loop of physics ticks to 'catch up' to the OS clock whenever the GPU takes longer than 1 physics tick to finish drawing - i.e. if you're running a 60FPS gameplay tick and the GPU is only running at 15FPS, the engine will do 4 physics ticks as quickly as possible (likely faster than 1/60th of a second, but passing through a 1/60 delta), then send the most recent one to the GPU for rendering.

On the consistency side of things, if you're running a truly fixed tick than spawning and motion should already be deterministic - ex. bullet #543 should always spawn at XY on tick #600 and move N units per tick until it hits something or times out at tick #660.
If that's not the case, then you either have something running off the system clock / variable delta time, or UE is fudging the fixed delta time for some reason (ex. trying to make it land closer to the render tick for purposes of rigidbody physics, or using a fixed minimum but allowing it to vary on fast machines).
It's probably worth putting in an assertion error to make sure the fixed delta never changes, since that would introduce a source of nondeterminism if the aforementioned fudging is happening. Another option is to discard the delta time input altogether and use constant movement rates and frame-count timing a-la old school games - it cuts out a potential source of error, but isn't great if you ever want to come back and change stuff (ex. Hyper Light Drifter's 60FPS patch) since you no longer have global timing control.

Using the physics simulation is also a source of nondeterminism, though kinematic bodies and manual collision checking should be fine. A lot of this depends on how you've actually implemented things like timing, movement and collision, since different approaches (ex. manual position integration, built-in timers, frame counting, animation timelines, physics sim) all have different behaviour and inputs that can affect their determinism.

And you shouldn't need to manually subdivide ticks in a fixed-timestep scenario - that's essentially a more manual way of turning up the target fixed tick rate, and will exponentiate your CPU cost while only reducing existing error margin rather than fixing it at the source. On some level if it works it works, but it's worth mentioning since fixed timestep is meant to prevent finicky timing issues by design - increasing temporal resolution is mainly good for things like complex rigidbody physics where simulation accuracy is tied to how coarse each step is.

Anyway, excuse the info dump - it sounds like you have the situation in hand, but I know from past experience that Unreal doesn't make this kind of nitty-gritty fine control easy, so perhaps there'll be some usable bits of wisdom in there

And I'll echo Verticien and warn against making any risky changes close to launch - framerate based slowdown is perfectly acceptable for an arcade title (perhaps even expected and / or desirable, depending on your POV), so if changing that is going to be a big chunk of work that could potentially go out-of-scope, you can always put it out in a patch.

That's a lot of very good suggestions. There is one thing I haven't brought up however, which was the fear that someone could play the fixed-timestep version of the game at a slightly lower fps (think 55-59) and have an easier time than other players since the game runs slower. Because of this, I find this fix to be absolutely necessary.

Adding it has been very tedious, but even with the full game things are already stabilizing. I'm sorry for not taking your advice, but I still managed to do what marketing I had to, and I already have a backup of the fixed timestep version just in case. I still have plenty of time before I send the final builds to Steam.

I also found this to be a good opportunity to go through all my code and make small fixes and optimizations here and there, as well as get rid of unused variables.

Not to mention, I only have to change a few lines of code to get the game to work exactly as it did before, so if any major issues pop out of nowhere, I can easily revert back by only counting a single frame per delta timestep.

For those who are curious, here is how I compute the fixed timesteps from the delta timesteps. It's very hard to explain with words, but here is my code. Feel free to analyze it to your heart's content. It is called in my GameMode's tick function:



What I love about this, is I can flexibly decide how I want to process certain objects. I can check if processing using a completed frame, and apply the delta alpha (0.0 - 1.0) for non-completed frames to smooth animation much like Lander suggested (especially for enemy bullets, the player, collectables, backgrounds, some enemies, etc).

It also speeds things up significantly because now I cache objects needed for the fixed updates, and some objects don't even need fixed updates so I can ignore them and let them use the classic tick functions with delta time.

I enabled UE4's smooth framerate with a range between 15 and 60, with ideal minimum at 30. I'm assuming it automatically slows the game down in case of a spiral of death when it goes below 15.

Demo has been updated.

That's a reasonable concern for a fixed step game - I've seen some of the Touhou titles include an 'average game speed' percent column in their high score tables as a workaround to delegitimize scores earned under significantly slower / easier conditions.

Though I'd question where such 55-59FPS users would be coming from, since a 2D game like this should be able to pull a solid 60 vsynced on an iGPU (with intermittent one-frame dips to 59 caused by the imperfections endemic to monitor vsync timing), and thus benefit from the slowdown assumptions that fixed-step lets you make. I guess UE does have its share of overhead and weird timing stuff that might throw a spanner in the works there, but it strikes me as odd that you'd see those perf numbers without some significant bottleneck.


Don't be - it's no skin off my back, so sharing knowledge is good enough


Ayup, that's a frame accumulator alright. I guess this occurs downstream of one of the built-in pre / during / post physics tick entrypoints, and FixedUpdate is your top-level game logic tick function?

And goodness, I don't envy having to use C++! Definitely the right way to go for any proper handcrafted UE project, but the engine's rigid structure was always such a pain to wrangle that most of my aggressively-deadlined professional work ended up living inside it as blueprints.


I don't think anyone beyond the original author truly knows what the smooth framerate thing does under the hood, poorly-documented as it is.

After hours of research in various UE forums both official and not, and even their (useless) paid dev support hub, the only solid conclusions I could draw were:
- It tries to smooth out the average framerate by adding variable delay to upcoming frames based on the current level of GPU performance
- Is not able to make any guarantees about minimum frame rate if the underlying code can't execute in time
- And tends to get turned off in the INI by savvy users who tweak GPU control panel settings and employ external frame-time control tools like RivaTuner.

So I always made a point of turning it off or exposing it as a menu option - having the engine arbitrarily drag down already-good frames to make them better fit the average hurts more than it helps for games designed to consistently hit their framerate target. Perhaps it has some use if you're building a high-spec game for low-spec consoles and want to hide bad framepacing / framerate that you know will happen in certain intense scenes, but I have no time for that kind of eyes-bigger-than-belly game development

That, and my view has always been that the graphics driver should be authoritative over GPU timing, since that's where the rubber meets the road for VSync / GSync / FreeSync / etc. Less stuff between your game and the driver means more chance of it working corrently when new technology inevitably gets introduced later down the line.

No worries!

There is in fact a tiny bit of slowdown with UE4's fixed timestep. It's about a quarter-second off by the end of the level. It doesn't seem significant, but I like having timing be perfect, especially since in some levels I have bullets that fire in sync with the music ^^

I also added the new controller defaults and a more visible hitbox.

Lol, I got my ass handed to me trying to beat the final boss in story mode on easy at 15 FPS. Everything is stable now and I've encountered no bugs with FPS. Still gonna test more normally before I release the final build. Thanks again for the support ^^

UE may have support for framerates greater than 60fps too. You may have given your game 120/144+ fps support with your rewrite.

Last addition I'd suggest is some simple controller rumble. Could be as simple as 1/4 second rumble when the player takes damage with an ON/OFF settings menu toggle. Some vibration when bosses die may be neat too. Likely a pretty easy addition that controller users would appreciate.

I'll see what I can do ^^

I know this is too little too late to an extent, but I added a fix to the player's bullets to make them more easy on the eyes.
I added a second sprite in between the bullets that is more faded to ease the flashing effect.

Wish I added it much sooner then the trailer and various gameplay footage of my game would have looked a lot better.
Still, I'm glad to have that fix in.