FX-Unit Yuki: The Henshin Engine for TurboGrafx-16/PC Engine

[nodtveidt]

Just posting a quick update: we're now officially in beta testing. There is still work to be done, as a couple of substages aren't quite finished yet, but this should only take a few more days to complete. Here's hoping anyways. Last week of dev coming up.

[touko]

i like it,and this evil transformed MD is excellent .

[Black Tiger]

i like it,and this evil transformed MD is excellent .

Since it was my last chance to design a boss, I wanted to do some kind of mecha Mega Drive, but also reference Shockman.





I also made a more traditionally shaped player ship in the Shockman style.

[NightWolve]

Awesome!

[turboswimbz]

That's Great BT. I really like it,  can't wait to buy this one.

[nodtveidt]

Unfortunately, the original design for that boss didn't work due to the PCE's limitations.

[Zero_Gamer]

This game is gonna be epic, but when can I order it?

[nodtveidt]

I believe Saru has an order thingo on his website.

The Megadrive boss didn't work out as originally planned for a couple of reasons. First of all, there were too many sprites in the arms and it caused large amounts of flicker. So, I opted to remove the arm pieces and have the hands fly independently, similar to the second phase of the end boss of Dead Moon. Secondly, in the comic, Yuki transforms into a fighter jet in this scene, so that part had to be altered in the game too.

Damn sprites-per-line limit...

[touko]

Since it was my last chance to design a boss, I wanted to do some kind of mecha Mega Drive, but also reference Shockman.

Wahou, those bosses are really beautiful 
Same thing for backgrounds, very colored (with taste) and detailled,they remind me commercial games quality,good job .

The Megadrive boss didn't work out as originally planned for a couple of reasons. First of all, there were too many sprites in the arms and it caused large amounts of flicker

Arf, damn 
May be you can only deploy the boss's arms at a certain moment and one at a time when he don't fire to limit flickering .

Damn sprites-per-line limit...

It's time to go on SGX then 

[spenoza]

The way to get around that limit is to just make sure the arms are far enough apart vertically, and if they cross each others' path it's at an angle. You could also use alternating flicker on the arms, much like many NES games do on projectiles and whatnot.

[Black Tiger]

The way to get around that limit is to just make sure the arms are far enough apart vertically, and if they cross each others' path it's at an angle. You could also use alternating flicker on the arms, much like many NES games do on projectiles and whatnot.

Using a minimal number of segments that don't necessarily touch one another is something else that was often done.

The problem with this scene is that it's a horizintal shooter, where you're lining up your ship and bullets with another ship and its bullets.

[gilbert]

How about making the segments flickering on purpose? Such as some games use flickering to display more bullets. This would keep flickering of the other stuff on screen to a minimum.
You may get away with it by making those segments made of something like "energy beam", "electric" or whatever.

[spenoza]

The problem with this scene is that it's a horizintal shooter, where you're lining up your ship and bullets with another ship and its bullets.

Yeah, and that makes it more difficult to orchestrate, but certainly not impossible. Then again, this is a homebrew development and not a commercial studio endeavor (in the classic sense), so I understand if the programming attention and skill necessary to orchestrate that well is prohibitive.

[Black Tiger]

The problem with this scene is that it's a horizintal shooter, where you're lining up your ship and bullets with another ship and its bullets.

Yeah, and that makes it more difficult to orchestrate, but certainly not impossible. Then again, this is a homebrew development and not a commercial studio endeavor (in the classic sense), so I understand if the programming attention and skill necessary to orchestrate that well is prohibitive.

I think that the biggest factor keeping things from being reworked until they're ideal instead of jusy shooting for something that is fine and should work as-is, is just the restriction of available time to do it.

This was all done in our spare time and not only are there a lot stages, many of them alone have more assets and misc under the hood than most entire homebrew PCE games.

Remember Aetherbyte's ambitious goal with Insanity, to complete a PCE homebrew game within a year? I still can't believe how close this came to being complete in about a year once things got moving full speed and it'll likely be published within a year and a half. Even on a dev friendly console like Sega Genesis, it would be a big deal conpleting a game of this scope within the same time frame.

This is of course independent of whether or not the game is any good. But I'm excited about PCE homebrew continuing to become more ambitious.

[Zero_Gamer]

The problem with this scene is that it's a horizintal shooter, where you're lining up your ship and bullets with another ship and its bullets.

Yeah, and that makes it more difficult to orchestrate, but certainly not impossible. Then again, this is a homebrew development and not a commercial studio endeavor (in the classic sense), so I understand if the programming attention and skill necessary to orchestrate that well is prohibitive.

This may have been done on a hombrew budget, but it sure looks like studio quality.