Fangame: Weather Factory Meltdown!

[HereComesTom 2,266]

EDIT:  I'm excited about my latest release; it adds equippable items to the game.  I mean, how many 2-D platformers do you know that actually show the items you equip on your characters?  Well, mine does!  And considering that it's got an editor that'll let anypony make their own games with their own equippable items, I think this has a lot of potential!

 

Here's a video that provides an overview of the latest features:

 

 

/EDIT

 

If you've ever wondered, "In a world where weather is manufactured by magical ponies, what happens if the union goes on strike?"...wonder no longer!

 

https://gamejolt.com/games/weather_factory_meltdown/272615

 

Battle your way through six floors of a factory infested with gem golems and evil rainbows to reach the emergency shutdown, so that you can prevent a flood from getting any worse!

 

This game is the result of over seven years of my hard work---a labor or love.  I could throw a wall of text at you about how I got the idea for this game and how the concepts evolved, but...well, why put you through that when I have a perfectly good set of videos explaining it?  https://www.youtube.com/playlist?list=PLYN-6Fdr9Mpq9cdsSC85d-Tuu6jaQbNis

 

Also, I would love to turn this project into a collaboration!  The game, while fun as-is, could be so much more than it is now.  Imagine if it had a dialog system, an inventory system, support for minigames, equippable clothing, and other features!  Even now, the game has a level editor that allows anyone to create and share custom levels!  I made tutorial videos for how to use the editor if you're interested in trying that out:  https://www.youtube.com/playlist?list=PLYN-6Fdr9Mpqwg2jBON_jpP0MgYN_vD4q

 

Please, let me know what you think of the game, the editor, and the idea of making this into something more interesting, more epic, more efficient, and more fun!

EDIT:  here's a thread in the Creative Resources section where I'm trying to find people to help me make this a collab:  http://mlpforums.com/topic/114399-seeking-help-for-an-epic-fangame-collaboration/

 

 

Edited December 15, 2019 by HereComesTom
new version with new features

[pocketshotgun 39]

If you've ever wondered, "In a world where weather is manufactured by magical ponies, what happens if the union goes on strike?"...wonder no longer!

 

http://staticvoidgames.com/games/WeatherFactoryMeltdown

 

Battle your way through six floors of a factory infested with storm elementals and evil rainbows to reach the emergency shutdown, so that you can prevent a flood from getting any worse!

 

This game is the result of over two years of my hard work---a labor or love.  I could throw a wall of text at you about how I got the idea for this game and how the concepts evolved, but...well, why put you through that when I have a perfectly good set of videos explaining it?  https://www.youtube.com/playlist?list=PLYN-6Fdr9Mpq9cdsSC85d-Tuu6jaQbNis

 

Also, I would love to turn this project into a collaboration!  The game, while fun as-is, could be so much more than it is now.  Imagine if it had a dialog system, an inventory system, support for minigames, equippable clothing, and other features!  Even now, the game has a level editor that allows anyone to create and share custom levels!  I made tutorial videos for how to use the editor if you're interested in trying that out:  https://www.youtube.com/playlist?list=PLYN-6Fdr9Mpqwg2jBON_jpP0MgYN_vD4q

 

Please, let me know what you think of the game, the editor, and the idea of making this into something more interesting, more epic, more efficient, and more fun!

EDIT:  here's a thread in the Creative Resources section where I'm trying to find people to help me make this a collab:  http://mlpforums.com/topic/114399-seeking-help-for-an-epic-fangame-collaboration/

So I downloaded the game, played it and have a few thing's to say, good and bad:

 

Things that were done well:

 

The game runs smoothly and provides logical gameplay that makes sense to someone new to the game by combining a good control scheme and sensitive controls.

 

At first I thought that being able to switch characters at any time would not turn out well but I was quite wrong, allowing the player to change characters at any time provides a good base for strategic thinking and problem solving.

Engaging the player to embrace different styles or "classes" of gameplay. For example rainbow dash is fast - like a scout class, applejack is strong - like a heavy class, rarity can heal - like a medic class, fluttershy allows player to hit enemies that are usually in unreachable locations and pinkie and twilight both provide fairly balanced gameplay.

 

The music is fast paced and was a good choice for the an action/adventure genre game.

 

The mane 6 all look good and are animated well, and the attack makes sense for each character.

 

I must also congratulate you on creating your own engine with java, as you probably know by now I program games too but I have never even attempted to program a specialized game engine.

 

Things that could have been better:

 

​The background in the game is rather bland and repetitive.

 

The enemies design is not very creative (although I probably couldn't think of better).

 

Recommendations:

 

Although it was a good idea to allow the player to play as each character or class, what if the game was multiplayer and people could work together to solve different levels, each player could pick their favorite of the mane 6 and they could communicate through a chat system (I don't know how good of a programmer you are so this might be out of the question)

 

A better and non - repetitive background.

 

 

That's about all I can say at the moment. You have done a great job so far for most parts of the game and I hope that you continue to produce quality content and that your games and creations succeed.    

 

-pocket

[HereComesTom 2,266]

Thank you very much for your feedback!

 

For the background:  one of the features I'd like to add soon is multilayered backgrounds.  That could make some areas, especially the larger industrial areas, really come to life and give the game world a sense of depth and activity.  Of course...ideally, I'd be able to collaborate with some artists who could draw those backgrounds for me, so that I could spend more time coding and less time building the world; then I could add more and more features to the game, like dialog, an inventory system, and custom NPCs and enemies.  At the moment, I'm working on adding custom playable characters to the editor; I'm hoping to add multilayered backgrounds once custom playable characters are done.

 

For the enemies:  I've heard from more than one source that the enemies need work.  Probably I'll sneak in a few more enemies and another boss or two one of these times I update the game.  To be honest, the enemies and bosses I have now are placeholders---for the most part.  In the long run, I'd like to create a custom NPC/enemy system in the editor, and use that to replace all the enemies with a much larger variety of golems made of gems that turn into collectible treasure.  But maybe in the short run, to keep the game interesting, I should add more enemies that I've hard-coded the behaviors for.

 

Thank you very much for your feedback!

 

...By the by, have you tried the level editor?  I was hoping to get some feedback on how user-friendly it is, what needs work in it, etc.  There's a compressed file attached to my post in the would-be collaboration thread that contains some assets from the game that you could use in the level editor if you wanted to give it a try.

[HereComesTom 2,266]

That's about all I can say at the moment. You have done a great job so far for most parts of the game and I hope that you continue to produce quality content and that your games and creations succeed.    

 

 

 

Have you unlocked commentary mode?  It unlocks if you beat Adventure Mode, but you can also unlock it with the right restore-file.  If you go to the menu and choose "Restore" and then open this fileI've attached in the game, it'll unlock commentary mode, too.  commentary_adventure_start.txt

 

...I never answered your point about multiplayer, did I?  I didn't have multiplayer in mind with this game, but who knows?  I might include it.  Long-term, I want the engine to be able to do a lot of things, so other bronies can use it to ale their own game, so maybe that's a good feature to add to the engine, even if I don't use it in WFM itself...

[Firedog 320]

Really cool game! I'm surprised this doesn't have more views :/ Really nice job though! Game engine is smooth, I like how each character has a special ability. Very fun too, love it!

[SasQ 1,376]

OK, I finished the game in around half an hour, so here's my player's experience.

I'll start from the things which annoyed me the most and which, in my opinion, demand some more work, and then I'll tell you what I think are the strongest points of this game and some of my ideas how it can be made better.

 

First of all, graphics. It looks like someone made it in Microsoft Paint. And I have a feeling that it is 16-color palette, or 256-color at most. Am I right?

 

Then there is physics, a very poor one, unfortunately, since this is a platformer, and platformers begs for better physics The motion is not smooth, but jumpy: either full stop or full motion, nothing in between. No acceleration, no friction etc. This makes it look unrealistic, because real objects have inertia: they cannot stop instantly; when they move, it needs some non-zero time for them to slow down and stop eventually, or reverse their direction of motion. It is especially important for jumping, because in real world, when a body lifts off the ground (e.g. jumps up), it slows down gradually until it stops, and then it starts gaining speed downwards. The trajectory of a jumping body or a projectile is a parabola, not a triangle (as in your game). Also, when in the air, it is quite hard to change your direction of motion or falling down, because momentum is conserved. This is contrary to how it works in your game, where the player can deliberately change the direction of its motion or falling down, which, again, is unrealistic. I know that this rule is sometimes violated to improve the gameplay (especially in platformers where the player needs to maneuver to land on some narrow platforms), but it can be eased down a bit.

 

Oh, and speaking of falling down: It's also unrealistic when a pony falls from some very high place, several times higher than itself, and gets no damage at all, but loses vital points when hit by a snowball

 

There's something fishy going on with the projectiles, too, which sometimes makes them seem to break the laws of physics. I'm not sure yet what it is. First I thought it's something with the relativity of motion (i.e. as if they were just moving relative to the player, but not relative to the world), but then I noticed that they actually move relative to the world, just in a somewhat weird way. Especially Fluttershy's butterflies: they seem to form lines when shoot more at once, but they doesn't move along that line.

 

Oh, and I think it is not good when I can shoot through solid objects such as walls or crates. Some better collision detection system is needed.

 

If you need some inspiration for the physics, find "Jazz Jackrabbit 2: The Secret Files" game and play it for a while. It's a platformer with really well done physics (and a neat game too).

Also, if you need some help with the physics subsystem, feel free to PM me with some questions, I can tell you about some tricks I use in physics code to make it more realistic, and they aren't much sophisticated, just a bit of tricky arithmetics which simulate differential equations of motion They're also quite universal, since then you can apply several forces at once upon your player, to make e.g. force fields, winds, jumping springs, backfire, air/water resistance, floating etc. Introducing inertia and different levels of friction you could be able also to make slippery slopes and ice, which fits well into the scenery of the weather factory

 

Next thing is music. It might fit the dark scenery of Rainbow Factory, or a strike of the workers' union, I guess, but it doesn't fit well to MLP. And it is very repetitive: it plays the same tune over and over throughout the whole game. I was so much annoyed by it than I turned off my sound at all. I discovered that I can turn it off in the game, too, but only after I finished the whole game and there's that info that I can turn on developer's commentary.

 

Speaking of which, it is a nice bonus, but I guess it is what bloats the JAR file the most. So I'd rather make it in a way that finishing the game unlocks a hyperlink to some hidden area of your website where you put this commentary for downloading for those who are really interested in it. Otherwise, the JAR file is unnecessarily big, even for those who aren't interested in the commentary. (It was quite interesting, especially the part about non-electric cooling techniques, but I guess few people will be interested in it.)

 

But back to the music: It would be good to invest into making some more music themes for different maps and fit them better to their scenery. Same with the graphics: It is a weather factory, in a cloud scenery, but these clouds doesn't look much "cloudy" – they look more like solid ice or snow. It would be good to add some variety to them, and some more "fluffiness", so that they feel more like clouds.

 

And lastly the gameplay.

The enemies are just too lame!. They just stand there as a pitchfork in manure and stare at me to get my shots and die. There's definitely something wrong if I could go through the whole game solely with Fluttershy! I simply used her butterflies as a flame-thrower to wipe out all the badasses in my field of view (or even before I get there!) FOOM!Flawless victory! :J I even managed to make a sonic Flutterboom!

 

Is it even possible to die in this game? I couldn't make it to die. There are hearts kicking all around the place, more than I could ever get hit. And as if it weren't too easy already, there's Rarity which can puff up even hearts from killing enemies! Interesting feature, but it undermines the whole gameplay. It could be interesting, though, if there weren't so many hearts already, and if killing enemies would just make some "parts of a heart" (or gemstones maybe?) so that one needs to complete more of them to gain a heart.

 

You have had a nice idea with all the mane six having their different special powers. But you didn't go far with it: They just differ by their healths and shapes of their projectiles & their strengths. I'd go way much further with it.

 

Why didn't you make the Pegasi fly? This could be their real strength, especially with Rainbow Dash. I know that flying in platformers can ruin the gameplay by doing the game too easy if done wrong, but it can also improve the gameplay when done well. For example, you can set the map in such a way that flying won't help the player much, by putting many obstacles there, or low ceilings, or even with spikes! But having wings can help to get into some high places, e.g. high & narrow chimneys, pipes, flying over long chasms etc. For Fluttershy, you can make her a little more bad at flying, so that she could only fly up a bit, or just glide down (but far).

 

For Unicorns, on the other hand, their strength is Magic, of course. Especially for Twilight Sparkle. So she could have a nice assortment of spells, e.g. levitation spells to levitate objects (crates? keys) up from some holes or through some openings in walls, lighting up some dark places etc. Rarity's special talent is not Magic, so her magical skills could be somewhat more limited, but still, she could cast some simple spells (buffing hearts & gemstones might be one of them).

 

Earth Ponies's strength is... well, strength, stamina, durability. They can be slow (not counting Applejack) but strong (especially Applejack who can buck enemies off beyond recognition ;J ). They can also grow food, but I don't know how to make any use of it in your game. Unless it were the food which needs to be collected to make hearts for other ponies maybe?... :> Perhaps Pinkie Pie could also use her talent for cheering up ponies to increase their power levels or something? Or you can make some use of her comic antics (also incorrectly called "breaking the 4th wall).

 

As for the Elements of Harmony: I don't think it is a good idea to use them as their primary weapon. They should be the Real Kicker^TM in the game, which has to be earned by completing some quests. For example, at the end of each level, there could be one of the Elements to find, and when found, it can be used as a special weapon for wiping out more enemies at once, or the stronger ones. Normal weapons should be something lighter, e.g. some magic dust / laser for Twilight Sparkle, bucking or throwing apples for Applejack, balloons or party cannons for Pinkie Pie, thunder clouds for Rainbow Dash maybe?, and The Stare^TM or something like that for Flutters (maybe throwing pine cones? )

 

Their weapons and powers can upgrade with the gameplay, unlocked through some achievements. It would be a nice idea to make them actually learn some new skills during the game, in the same way as they learn Friendship in the show. It would be even better when they could learn these skills when helping other ponies (I saw some ponies imprisoned in cages in your game, but I couldn't set them free in any way, so I could only helplessly watch their misery. Maybe helping ponies would be a good way for gaining new powers?)

 

There's also a little problem with the doors: sometimes I need to fit the pony precisely into them to make them work. Otherwise the Enter key doesn't work.

 

OK, so much for now. I hope my comments are helpful to you. Later I'll try to think some more about the possible ways this game could be improved and some directions it could evolve. But I'll wait with writing about my ideas until you deal with these I described in this (long!) post.

Edited January 1, 2015 by SasQ

[HereComesTom 2,266]

Thank you for the long post; there's a lot of good stuff in there.

 

First, for a little context:  this isn't really a finished product; it's a proof-of-concept and a work-in-progress.  I was hoping to turn this into a collab, but so far the response has been...underwhelming.  (That being said; I've not yet given up on it; at the moment, I'm working on the game editor to add custom playable characters.)

 

The enemies---I'll admit they were cheap.  Since this was a proof-of-concept/WIP, I figured it was okay for them to be cheap for now.  They're placeholders for all practical purposes; I plan on adding a greater variety of enemies, and in the end, they won't look like tornadoes with claws sticking out of them; they'll be golems made entirely out of gems.  And when you defeat them, they become collectible treasure, which Rainbow Dash will refer to as "swag" (as is obligatory).  Long-term, I want to make a feature in the editor that lets users create their own enemies and bosses, but that entails a lot more than you'd think.

 

The music, I'll admit, got repetitive for me, too.  ...I was about to play the "It's a WIP" card, but I'll sound like a broken record if I keep saying that.  So I'll say that I definitely want multiple different tracks, probably a different track for each floor in the factory.

 

The commentary---I see what you're saying.  I know I'll want to redo the sound system in the game in general; the java sound API I'm using is probably over 15 years old.

 

As for the physics, I understand what you're saying.  To be honest, I wanted to keep the game and its engine simple, and I figured that, as long as the gameplay was fun, it didn't matter much whether the jumps are like triangles or parabolas.  (I was actually considering doing a compare-and-contrast video between this game and Fiends from Dream Valley, and discuss how FFDV actually has physics, and my game doesn't.)  I know I'll want to add a lot of things to this game before I call it "done", and beefing up the physics engine can be one of those things; I'm just not sure whether it'll be worth the effort or not.  My game design philosophy is that, if it doesn't add worthwhile fun for the player, it's probably not worth adding to the game.  I figure adding real physics could go either way; I might just take you up on the offer for seeing your physics code.  (I kind of expect it'll be about tracking the velocity of each object and changing it based on collisions, keyboard input, wind/ice conditions in the environment, etc.)

 

Shooting through walls---I pretty much did that so that I wouldn't need to make any collision-detection happen for the bullets except for the player and the enemies.  I could see that being changed in a future version of the game, or even for some characters or enemies to be able to shoot through walls and not others.

 

I know I want to add better diversification for the characters themselves long-term, too---it's just not a feature I've started to work on, yet, and I can really only work on one feature at a time.  What I'd like to do is add teleport and Magic Missile spells for Twilight (maybe some other spells, too), and Rarity would be able to cast spells onto gems, and then she can place those gems on the ground to act as land mines:  an enemy walks over that gem, and poof! the enemy gets silenced!  I also know I want to add flying to the game eventually, but it's a plot point that they can't fly in this level because of the deteriorating weather conditions (though I also plan to add one or two ways around that problem eventually).

 

There's also a reason why the Elements of Harmony are their main weapons---and I use the term "weapon" very loosely:  eventually, the game's plot will be a little more involved, and will take place after Season 4, probably before or during Season 5.  Twilight will have given up most of the real Elements to the Tree of Harmony:  the gems have been taken out of the sockets and replaced in the Tree, but she still has the gold settings.  She figures she can use those settings, some regular gems (which she's learned have some inherent magic in them), and good old alicorn magic to re-create the Elements.  Unfortunately, the only thing these artificial Elements can do is fire small magic bullets that literally do nothing but break spells; they have no effect on non-spelled living things or on inanimate objects.  That's only useful if there's an invasion of golems!  ...Which is exactly what happens to the Weather Factory.

 

The graphics...yes, they were done in Paint, pretty much the only graphical tool I have or that I'm good with at this point, using entirely the Windows XP default colorspace for GIFs.  I don't know how many colors that is, but 256 wouldn't surprise me.  At the time I was making this, I didn't think I'd be able to use BMPs in Java; if I had known that I could've used BMPs, I might've gotten more colors into this game.  Again, I was hoping to turn this project into a collab and get some real artists with real graphical tools to help me in this area long-term.  Short-term, though...well, here's my roadmap for the near future:  once I get custom playable characters out there, I'm hoping to add more types of enemies and bosses to the game engine and the factory, and after I've gotten that in place, then I hope to add multilayered scrolling backgrounds.  Incorporating multilayered scrolling backgrounds into the game pretty much means I need to redraw the whole factory, and I could add more colors while I'm doing that.

 

Redoing how the player interacts with doors should be something I can do pretty easily; when I release the custom PC features, I'll try changing the collision-detection for doors---maybe if the player character's center is inside the door at all when the player presses Enter, they go through the door?

 

SasQ and Firedog, thank you both very much for posting about this.  The response so far for this game has been underwhelming, and I hope I get to have more discussion about it and further improvements down the road---though, sadly enough, since I'm the only one working on this and I have a day job, it could take a while for real changes to the game to materialize...

[SasQ 1,376]

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

First, for a little context: this isn't really a finished product; it's a proof-of-concept and a work-in-progress.

Oh. This changes a lot. When I read that you've been working on it for two years, I thought it is a finished product.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

I was hoping to turn this into a collab

Does it mean that the source code is available somewhere?

I'd be glad to take a look at it perhaps at some free time.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

but so far the response has been...underwhelming.

Then I hope you didn't see my reply as harsh or condescending. I just tried to give you a honest feedback about what is good and which parts in my opinion needs some more work.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

That being said; I've not yet given up on it

Good to hear that. This game has some potential in it, it just needs a bit of work to make it evolve.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

The music, I'll admit, got repetitive for me, too.

At least you made an option to turn it off I would enjoy this game with the same level of fun (or a bit more) even without the music and just some sound effects. Game music is like background music in movies/TV shows: it is there to induce certain emotions & mood, not just to "fill the silence". So it is worth to use it wisely. There are lots of brony musicians, I'm sure you'll find some who will want to help you with the background music. Maybe it just doesn't necessarily has to be from the VIPs (like Wooden Toaster). Less horse-famous brony musicians can make good music too.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

I was about to play the "It's a WIP" card, but I'll sound like a broken record if I keep saying that.

It's enough to say it once I get it now.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

The commentary — I see what you're saying.

Don't get me wrong. This commentary is interesting (for me it was, since I'm a game development enthusiast, a programmer, and I'm interested in science), it's just not necessarily interesting for anyone. So it's worth to make it an optional bonus available somewhere for those who like such things, but employ the motto used by C++ programming language: of not needing to pay for what you don't use.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

I know I'll want to redo the sound system in the game in general; the java sound API I'm using is probably over 15 years old.

What API it is?

And what graphics API you use? It doesn't seem to be hardware-accelerated, since it frame-drops on my computer every other second. I know that CPUs of today are as fast as GPUs of the past, so software blitting can suffice sometimes. But let's think ahead: once you add multi-layered backgrounds etc., it might become insuficcient and the rendering might slow down. Delegating the graphics rendering to the GPU which is better-suited for that job could save you some CPU cycles.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

As for the physics, I understand what you're saying. To be honest, I wanted to keep the game and its engine simple

As Albert Einstein once said, "Things need to be as simple as possible, but not simpler". Implementing realistic physics doesn't need to be much more complex than what you perhaps do already. But the effects might improve dramatically.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

and I figured that, as long as the gameplay was fun, it didn't matter much whether the jumps are like triangles or parabolas.

Sure, I once had an old Atari game console, and I enjoyed playing those 4-bit squary characters jumping along straight lines. But back then, there was no better alternative. Today we have this alternative.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

I'm just not sure whether it'll be worth the effort or not.

It depends on the "effort" you think of.

As I said, implementing these features I described previously is not so hard – it can fit into several lines of code, but the profits are astounding. And they can improve the gameplay if used that way (e.g. those slippery slopes, ice floors, wind blows, flying etc.).

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

I might just take you up on the offer for seeing your physics code. (I kind of expect it'll be about tracking the velocity of each object and changing it based on collisions, keyboard input, wind/ice conditions in the environment, etc.)

Quite.

 

In every frame, I start from applying forces to objects (including the player's character). Then, having a list of force vectors, I simply sum them up to get one resultant force.

 

Then I use the 2^nd law of Newton, a = F / m, to calculate the acceleration a from the total force applied F and mass m of the body. This way, the more massive is the object, the more force is needed to change its motion; or the less is this change caused by the same force applied.

 

When I have the acceleration vector, a, I add it to the current velocity vector to get the next velocity vector v (the updated one; since acceleration is just change in velocity): v += a * dt. As you can see, I also multiply it by the time passed, dt. This way it is independent of the framerate. I just need to keep track how much time has passed since the last frame.

 

The last step is to calculate the new position. Here I add the velocity vector to the position vector to get the next (updated) position vector r. Again, the formula is very simple, and very similar to the one for acceleration: r += v * dt.

 

The fun thing is that when you do it this way, all these vectors can point at different directions at the same time, so, for example, when the force is perpendicular to the current velocity, it makes the body to change its direction and follow a curved path. In other words, you get all those parabolas and circles for free! You just prepare the "set of rules" in a form of those simple differential equations of motion, and apply them in each frame, and voilla, the body figures out its path, no matter how complicated, all by itself

 

If you want to make wind, just apply a constant force sideways. If you want the character to jump, just give it a short impulse of force upwards to make it bump off of the ground. Or a constant lift in case of flying. The constant force of gravity directed downwards will do the job for you to make it jump along a smooth parabola when you pass it through these equations of motion. Friction (including air/water/ground resistance) is just another force Ff, which is proportional to the current speed of the body, and in the opposite direction to the velocity Ff = - T * v (T is just some constant of proportionality, which says how much friction there is for that particular speed; no friction = sliding on the floor as on ice).

 

After calculating the new position, there comes the time for calculating collisions. Here I check if there are any obstacles along the path from the old position to the new one. (So it is good to have the old position vector stored somewhere for comparison.) I don't just check if the final position is inside the wall or something, because for fast motion it can sometimes happen that the "before" position is on one side of the wall, and the "after" position is behind the wall, but both are "in the air" (no collision), so it can cause a bug: the obiect will pass through the wall when fast enough! This is a common mistake being made over and over by game developers. I hope you're smarter, and you do what I would do myself: to calculate the path of motion from the old position to the new one, and then check if this path crosses some wall or other object. If it does, then the last position before hitting the wall has to be calculated (a simple linear equation) and the motion must go no further. Also, the so-called "normal force" has to be applied to bump the body off the wall and change its motion to the opposite direction.

Notice that when you do it this way, you'll get the law of reflection (the incident angle being equal to the reflection angle) for free! The body will bump off correctly no matter the angle it has impacted the wall, and the angle of the wall itself. Just make the normal force to be normal (that is, perpendicular) to the wall.

 

Long story short:

 

dt = currentFrameTimestamp - lastFrameTimestamp;

Ff = - T*v;

F = F1 + F2 + F3 + ... + Ff + Fn;

a = F / m;

v = a * dt;

new_r = v * dt;

// Then do the collision detection on the path between old_r and new_r.

// After that, new_r becomes old_r and you render the frame's graphics.

 

Simple as that!

I think this is a little cost for so much improvement of realism.

 

If you don't use any vector class, you can still simulate this by doing the above calculation for all two (or three) dimensions independently. Just use ax and ay for a, and the same with other vectors.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

Shooting through walls — I pretty much did that so that I wouldn't need to make any collision-detection happen for the bullets except for the player and the enemies.

Sure, then it was a good decision for starters. It's always better to simplify some things if it saves some CPU cycles.

 

Just in case you wanted to implement some more sophisticated collision detection anyway, here's how I do it:

 

First I do a rough collision test (just AABBs, or Axis-Aligned Bounding Boxes test, which boils down to a couple of coordinate comparisons) for all the objects visible on the screen (or those which needs updating in the game world but not seen). In this step I make a temporary list of objects which potentially may collide. Then I do more sophisticated collision detection (such as pixel-perfect one for bitmaps, or polygon intersection for vector graphics) for those objects which were on the list from the previous step (potentially colliding).

 

This might seem a lot of calculations to check collisions of everything with everything (quadratic complexity!). But if done correctly, you can reduce the overhead easily. First, if you make a n×n table for all the objects which may collide, you should notice that the diagonal of this table is collision with itself, which you don't need to check. Also, you only need to check one half of this table (over the diagonal), because the other half (under the diagonal) are just the same pairs of objects. This reduces the amount of computation from n² to n×(n-1)/2 or (n² - n)/2. Still quadratic, but reduced by linear and halved.

 

If you want even more reduction, there's one more trick which can reduce the amount of computation even further, optimistically making the problem logarithmic (which is even better than linear!), and still having collision tested between everything, even for a lot of objects of different sizes on the screen. There's a clever algorithm which partitions the space shared by those objects and tests intersections for whole groups. If you're interested, I can tell you some more about it. It's useful for games with lots of objects on the screen, such as projectiles or particle systems. I once used it for a simulation of atoms represented as little balls of different colors, which could collide with each other, a whole lot of them! And it worked quite fast and smoothly.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

I could see that being changed in a future version of the game, or even for some characters or enemies to be able to shoot through walls and not others.

This might be an interesting idea. I thought of suggesting this myself last time, but I decided to withhold it.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

I know I want to add better diversification for the characters themselves long-term, too — it's just not a feature I've started to work on, yet, and I can really only work on one feature at a time.

Good. Then it would be informative if you wrote some about your priorities for this project.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

The graphics...yes, they were done in Paint, pretty much the only graphical tool I have or that I'm good with at this point, using entirely the Windows XP default colorspace for GIFs. I don't know how many colors that is, but 256 wouldn't surprise me.

Yes, GIFs are 256-color.

But a limited color space is not always so much a limitation. Older games could handle that somehow, so it is benefiting to learn from them. "Low color space" doesn't need to mean "poor graphics", if only all these colors are chosen wisely and exploited to their extreme. Here, for example, are some screenshots from "Jazz Jackrabbit 2" I mentioned before, which was also 256-color, but you can hardly notice it:

 

 

 

 

More screenshots you can find on this website.

 

The key is to use a different palette for different levels, particularly prepared for this particular scenery. For example, in a forest, there will be more greens and browns in the palette. In a volcano, there will be more orange and black. In a castle, there will be more gray for stone walls, etc.

 

Also notice how in many levels the tileset is made in such a way that the tiles can blend with each other smoothly in many different combinations, and their shapes are irregular, so the map doesn't seem as if it were made of little boxes (which is too much noticeable in games such as Mario Bros).

 

Also, this game has a level editor bundled with it, and it has multi-layer parallax scrolling for backgrounds. So you can find some inspiration there too, I guess.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

Again, I was hoping to turn this project into a collab and get some real artists with real graphical tools to help me in this area long-term.

This would be a great idea. Then you could focus on improving the engine, and your fellas would make a beautiful graphics for it.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

then I hope to add multilayered scrolling backgrounds. Incorporating multilayered scrolling backgrounds into the game pretty much means I need to redraw the whole factory, and I could add more colors while I'm doing that.

Not necessarily with the colors. But definitely there will be more graphics needed in the tileset.

 

Oh, just don't go overboard with it. Backgrounds are, as the name suggests, backgrounds. Cluttering them with details may make it harder for the player to focus on its character and enemies. Don't let the background draw the player's attention from the foreground. I already had this problem in your game, when there was some quickly-moving machinery in the background, because it confused me if I should pay attention to them or not. (It turned out that I shouldn't, because it doesn't influence the gameplay at all, but it managed to easily break my concentration.)

 

In case you needed some help with parallax scrolling code, tell me know too.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

Redoing how the player interacts with doors should be something I can do pretty easily

That's what I thought. Good to hear that.

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

when I release the custom PC features, I'll try changing the collision-detection for doors---maybe if the player character's center is inside the door at all when the player presses Enter, they go through the door?

Any technique will be good if I will not have to position the pony precisely on the door to go through it. I think a simple AABB collision would suffice. It's a matter of comparing two ranges of coordinates, easy as a pie. (With a clever logic expression it can be reduced to three ifs).

 

HereComesTom, on 01 Jan 2015 - 8:35 PM, said:

sadly enough, since I'm the only one working on this and I have a day job, it could take a while for real changes to the game to materialize...

Yeah, I hear you with this one. I have this problem too. (Well, kind of: I don't have a day job. But still my time is somewhat limited by other things.)

[HereComesTom 2,266]

Your review did seem a bit scathing at first, but given the amount of time you're putting into making them, I could tell you had every intention of enlightening me about how to do this correctly, and I appreciate it.  It was all better said than unsaid.

 

To answer your questions:

 

At the moment, I'm using the javax.sound API.  It's not got a lot of features:  no way to let the developer change the volume on a given clip, etc.  If there is compression in javax.sound, I can't find it.  If there's a better way of doing things, I definitely want to hear it.

 

One thing I might do for the commentary is add one version of the game with commentary and one without.  I'm not sure static void games will let me do that on their site, but if worse comes to worse, I could just call the non-commentary one another game altogether.

 

As for graphics, I'm using Graphics2D and drawing all the game elements onto a BufferedImage, and then every time I draw a frame, I call paintImmediately to get the BufferedImage drawn onto the JPanel.  This is a technique I learned from Killer Game Programming in Java by Andrew Davison.

 

Your quote from Albert Einstein---shoot, I heard that from a consultant on Agile Development a couple weeks ago.  I think his name was Adam...  In any case, I totally get where you're coming from; it doesn't look too hard to apply forces and movement vectors to the player character.  I'm not sure how soon or how late I'll try it out, though; I feel like beefing up the enemy repertoire is my next step, and after that, I'll either try parallax scrolling backgrounds or applying force and velocity to the player character.

 

EDIT: (Firefox crashed while I was typing this up)

 

I hope that gives you some idea of my priorities; once I get parallax scrolling done, probably my next step will be things like an inventory system, and later a dialog system.  At some point, I know I'll want to add custom player character abilities---a magic system and flight would fit right in there, and I might do that once I have parallax scrolling and before the inventory system, too.  Then again, player abilities might end up relying on inventory (e.g. my Rarity-casts-spells-on-gems idea), so they might have to go in together.  And with the dialog system, I know I want to add the ability for designers to use the Editor tool to make their own NPCs, and to make them with whatever behaviors I can think to make available to them---i.e. they'd be able to use that system to make enemies and bosses as well as stationary NPCs to speak with.  ...It's hard to tell what exact order I'll go in with these, but I figure CustomNPCs are a ways down the road.

 

While I'm on the subject of enemies, I'm thinking that, in the near future (i.e. after I get custom player characters but before I start on parallax scrolling), I should replace the graphics, though not necessarily the behavior, of the six palette-swapped enemies that're in the game now.  Perhaps if I use simple gem-golem birds like the gem bird enemy graphic I've attached?  That's just a basic idea or what it would look like; if I keep the enemies' hitboxes the same, then I probably won't use this exact graphic.  In any case, I also want to add more enemy types to the game, too---I've thought of pacers that have actual collision-detection with blocks, a "Bixbite" enemy that looks like a chomping set of teeth made of gems that lunges at you when it sees you, a cloud-enemy that can only move horizontally and fire projectiles downwards, and a few gem-themed bosses.

As for collision-detection, I'm already using the AABB system---I discovered how easy that was on my own, and I kind of expect to stick with AABB collision-detection throughout the development of this game.  I know I'll want to learn more interesting collision-detection at some point so I can make a real physics-puzzle game (not MLP related) with rotation and non-rectangular shapes, but it seems like more than I'll need for this game.

For the player character's collision-detection (which is separate from the bullets' collision-detection), what I do is I find the player's current position, then I find the wall to the left that would serve as a barrier to moving left, the right wall, the floor, and the ceiling.  Based on those, I decide how far the player can move.  I think that's pretty close to what you were describing.  As for the bullets---well, at this point, they never move fast for passing through any object to be a problem.  I'll probably need to revise that in the near future.
 

I'll take your advice to heart not to go overboard with backgrounds once parallax scrolling is in place---you're right; they shouldn't be distracting.

 

Can you remind me which background element was confusing?  Was it the fan that was blowing clouds out the output funnel at the end of the third floor (i.e. the floor that has the refridgerated rooms in it)?

gem bird enemy.bmp

Edited January 3, 2015 by HereComesTom

[SasQ 1,376]

As for graphics, I'm using Graphics2D and drawing all the game elements onto a BufferedImage, and then every time I draw a frame, I call paintImmediately to get the BufferedImage drawn onto the JPanel. This is a technique I learned from Killer Game Programming in Java by Andrew Davison.

Oh. That doesn't sound good. This means no hardware acceleration being used. Just the system graphics APIs which are very slow when compared to hardware-accelerated ones.

 

Have you ever considered using OpenGL rendering for your engine? You can use OpenGL in Java through an external JOGL library. It is a hardware-accelerated graphics library which is very low-level (that is, close to the GPU), so it runs fast as hell even when controlled from Java VM. Its main purpose is 3D rendering, but you can easily implement a 2D blitter on top of it: just draw some textured quadrilaterals on the screen.

 

The bonus is that when using a 3D renderer to draw 2D graphics, you get many cool things for free, such as:

* Full-color display (32-bit).

* Alpha opacity (i.e. semi-transparent sprites).

* Transformations (including rotation and scaling!) for your sprites.

* Lighting (you can modify the diffuse colors of your mesh to tint the sprites with that color).

* Pixel shaders, which allow for even more cool effects (blur, glow etc.).

 

Here's an example Java source and a compiled class file which uses JOGL to render an animated rainbow rectangle in a window at a fixed framerate of 60 FPS:

 

http://sasq.comyr.com/Stuff/Java/JOGL_test/

 

You can recompile it with a command:

 

javac -cp "/usr/share/jogl-2/lib/jogl.all.jar" Main.java

and then run with:

 

java -cp ".:/usr/share/gluegen-2/lib/gluegen-rt.jar:/usr/share/jogl-2/lib/jogl.all.jar" \
  -Djava.library.path="/usr/lib64/gluegen-2" Main

(Just modify the paths to reflect your system's configuration, and make sure you have the JOGL library JARs there somewhere.) See if it works for you, and tell me if it isn't.

 

I hope that gives you some idea of my priorities; once I get parallax scrolling done, probably my next step will be things like an inventory system, and later a dialog system. At some point, I know I'll want to add custom player character abilities---a magic system and flight would fit right in there, and I might do that once I have parallax scrolling and before the inventory system, too. Then again, player abilities might end up relying on inventory (e.g. my Rarity-casts-spells-on-gems idea), so they might have to go in together. And with the dialog system, I know I want to add the ability for designers to use the Editor tool to make their own NPCs, and to make them with whatever behaviors I can think to make available to them---i.e. they'd be able to use that system to make enemies and bosses as well as stationary NPCs to speak with. ...It's hard to tell what exact order I'll go in with these, but I figure CustomNPCs are a ways down the road.

I see. So your current priorities are centered on the gameplay, not the engine.

 

Is the source code available somewhere? Maybe I could take a look at it in some idle time and see if I could help you with it somehow? You said that you plan to make it a cooperative project. So perhaps I could help with the physics and speeding up the rendering? (But I don't promise anything yet; I need to see the code first to check out if it is not messed up too much to work with )

 

For the player character's collision-detection (which is separate from the bullets' collision-detection), what I do is I find the player's current position, then I find the wall to the left that would serve as a barrier to moving left, the right wall, the floor, and the ceiling. Based on those, I decide how far the player can move.

Interesting technique, too

 

I'll take your advice to heart not to go overboard with backgrounds once parallax scrolling is in place---you're right; they shouldn't be distracting.

Good.

 

Can you remind me which background element was confusing?

Pretty much everything which moves too fast in the background. Especially some rotating wheels and fans. The fact that they use bright colors doesn't help either.

 

Look again at how backgrounds are done in "Jazz Jackrabbit": they're all a bit less bright and use more dim colors, so that they blend well. It is a clever use of contrasts which makes the background go to the background, and foreground go more to the foreground, even if it moves quickly. The most bright-colored should be the player, the enemies and the bullets, because they need to attract the player's focus the most. Backgrounds should blend to the background to not distract the player.

Edited January 6, 2015 by SasQ

[HereComesTom 2,266]

I know I need to look at Java Open GL; I'm not 100% sure whether I'll use it in the end or not; I remember reading in Killer Game Programming that there were other ways in Java of using graphics acceleration, but even if I don't go with OpenGL in the end, I know I have to give it a look; thank you very much for showing it to me---I hope I get a chance to try it out soon.  (I hope I find a way to use it with Eclipse; I am not using a command-line to do my programming, so I'm not sure I even can run javac commands...)

 

Shoot---I guess I should've realized that the bright red flywheel on the steam engine should've been recolored to gray; I made it red because the real-life steam engine it was based on had a red flywheel.

 

I thought I had my source code in the JAR file itself; just in case I don't, I've zipped the source code files here---the resources like sounds and images aren't in this ZIP file, but the code is.  The main class is StartupPanel, and that can invoke the main method either in PonyTestDriver (I know I should've renamed that) or in MainEditorPanel, depending on whether you click the Editor or the Game button at startup.

 

I should warn you that source code you'll find in the ZIP file is actually some of the source code I'm currently working on---it contains some features that I'm hoping to get out there in the next week or so, if I can figure out all the bugs in the editor.

 

PonyPanel is the class where most of the fun happens; it has lists of background widgets, enemies, bullets, moving blocks, etc.  There's also a StaticBlockManager that contains most of the data on the static blocks (that's the term I use for blocks that are read out of a file as a map of characters).

 

Most of the collision detection is for the player, and it's done in PlayerSprite.updateVI.  The fact that there's a roman numeral 6 in that method name will tell you that I tried multiple times to get the collision-detection right, but---well, I gave the "I saw the bad game reviews of the late 2000s" speech in my commentary; you've already heard it

zipped source code files.zip

[SasQ 1,376]

but even if I don't go with OpenGL in the end, I know I have to give it a look; thank you very much for showing it to me — I hope I get a chance to try it out soon.

OK But maybe you won't have to (I'll explain in a minute.)

 

In case you wanted to see it in action, though, I finally managed to made a self-contained JAR file with that pink fluffy Pinkie Pie jumping on rainbows Here it is:

 

http://sasq.comyr.com/Stuff/Java/JOGL_test/TransparentTextures/TextureQuads.jar

 

The app should be able to run on Windows, Linux and MacOS X. I didn't support other platforms to avoid inflating the package too much – It's already 5 MB, so I need to think about some way to trim it down. (Perhaps repackaging the JOGL libraries to use only what I really need, or making a separate version for each platform).

 

(I hope I find a way to use it with Eclipse; I am not using a command-line to do my programming, so I'm not sure I even can run javac commands...)

Yeah, it should be able to be used in Eclipse, there are tutorials on the officjal JOGL website about how to do it. It actually should be a bit easier than in command line.

 

I, for one, use Apache Ant for building. It is a build system, similar to GNU Make, but you can write its build scripts in XML text files. I used it to compile it and build my JAR with all the libraries needed.

 

I thought I had my source code in the JAR file itself

Oh, I didn't expect that. It's quite unusual to find all source files intermingled with the classes in a JAR. But you're right, they're really there. I just didn't expect to find them in there.

 

the resources like sounds and images aren't in this ZIP file, but the code is.

No problem, I already learned how to unpack them from your JAR

(It's interesting how much a Unicorn can learn in just a week or two. Before that, I knew Java only a little, and now I managed to write a running OpenGL app and put it into a self-contained JAR )

 

The main class is StartupPanel, and that can invoke the main method either in PonyTestDriver (I know I should've renamed that) or in MainEditorPanel, depending on whether you click the Editor or the Game button at startup. (...) PonyPanel is the class where most of the fun happens; it has lists of background widgets, enemies, bullets, moving blocks, etc.

Yeah, it really looks like doing all that stuff: it's over 4000 lines of code! I wonder how are you not getting lost in it?

 

If my classes start getting larger than several screens, I tend to split them into separate classes. And the same goes with functions: A well-written function should entirely fit into the screen. If it's longer, it's usually a sign that it should be refactored. That's at least how I work with my code.

 

I also keep up to the rule of separation of concerns. One class - one responsibility. It's not good when your class performs the drawing, the physics, the AI, the collision detection, the state machine, world updates, keyboard input parsing, and all that stuff at once. This makes the code less portable and reduces code reuse, because then you cannot – for example – reuse your collision detection for some other character. It also decreases readability and productivity: you can pretty soon get drowned into your own code. (I did, many times, and then I learned how to avoid it by making my code more organized.)

 

Good thing is, I pretty much understand your code at first glance, so maybe I will be able to help you with it from time to time.

 

There's also a StaticBlockManager that contains most of the data on the static blocks (that's the term I use for blocks that are read out of a file as a map of characters).

Good to know.

In game development, it is usually called "tile map".

 

Most of the collision detection is for the player, and it's done in PlayerSprite.updateVI. The fact that there's a roman numeral 6 in that method name will tell you that I tried multiple times to get the collision-detection right

I would never figure that out myself. Nay, I hadn't even known that it is a Roman numeral! "Update vee-eye? What's that supposed to stand for? Visual Interface perhaps?" – that's what I thought to myself when I saw it.

 

Good naming conventions can also improve code readability. If that was supposed to mean a Roman numeral, it would be good to put that into a comment to inform the person who would read that code. (And that person might be you, after a couple of months, drunk )

 

OK, I'll try to look more closely at your code this weekend and see what would be the cost of remapping the drawing code to OpenGL. Perhaps, with a clever interface from my side, it could boil down to changing Graphics into FasterGraphics library written by me?... It depends on what subset of Graphics functions you actually use, so that I could emulate their behavior with hardware-accelerated rendering. We'll see...

 

P.S.: Everytime I see your avatar, I imagine that rock falling onto the Parasprite, smashing it *SPLAT!*

Edited January 15, 2015 by SasQ

[HereComesTom 2,266]

I'll be sure to take a look at your JAR file, SasQ---thank you VERY much for all you're doing to help!  (EDIT:  it doesn't seem to be letting me download it; are you sure there aren't any typos in the link?)

 

I've (finally) uploaded version 0.1.0, with custom characters.  It has better collision-detection for doors, as well as increasing the size of the scoreboard area---hopefully, I'll be able to use that real estate for stuff like a dialog system, an inventory system, and/or a magic system.

Edited January 26, 2015 by HereComesTom

[SasQ 1,376]

Nope, there are no typos, I checked a while ago and it starts downloading.

Did you click on the link or just copy-pasted it into your browser? The forum's software seems to crop it and add some "..." in the middle, but clicking it should work. But in case it didn't, here's a stuffed one:

 

http : // sasq.comyr.com / Stuff / Java / JOGL_test / TransparentTextures / TextureQuads.jar

 

If this doesn't work either, then there might be something fishy going on with connecting with my hosting provider from the USA, since several other people reported that they cannot connect to this server (sasq.comyr.com, hosted at 000webhost.com). Perhaps due to some blacklisting or firewalls, I don't know.

 

But if this didn't work, just tell me, then I'll try to upload it somewhere else.

Edited January 26, 2015 by SasQ

[HereComesTom 2,266]

><  It still says "this web page is unavailable" after it spins and spins waiting for a reply.  Shoot...

 

Anyhow, I'm starting to take your advice for improvements to the game; I'm in the process of replacing the red enemies (the stationary ones) with the gem-golems I'd originally intended; the new graphics for the red ones are pretty simple:  square ruby gemstones at the four corners of its hitbox, with red-to-black lightning continuously arcing between each of the corners.  They look more like destructible obstacles than enemies this way, but that's probably okay, because they pretty much were destructible obstacles as far as gameplay is concerned.  I have another reason why I think it's a good idea to make them look like geometric objects, too:  I think it makes the game a little more friendly to the MLP main demographic when the enemies look less like enemies and more like geometric objects.  (I realize there's some content here and there in the current version that's not particularly kid-friendly; I have plans for addressing that.)

 

In any case, I've attached a screenshot of what the red enemies currently look like.new enemy screenshot.bmp

 

The death animation shows the gems imploding towards the center, and once they get there, I plan to have the four rubies become collectible items and fly off in random directions, bouncing off of walls as they go, and using the physics algorithms you've provided until they come to rest.  That'll let me play around with and get used to having actual physics in the game.

[HereComesTom 2,266]

It's been a long time since I updated this, but I've been working on this project.  For about a year and a half, I was working on adding items to the game.  That release was meant to be a quick one---just a way of getting custom enemies to drop items when they die.  But then I realized that custom items won't be much use unless I add buffs that you can get from consuming the items.  And then I realized that I could have an equipment system that actually shows pixelart of equipped items on your character, if I set things up so that equipped items apply buffs to the characters, and those buffs' animations are carefully synchronized with the character's animations!

...So a classic case of scope creep.  Hopefully I can quickly add foundations for another couple of important features before I head to the Whinny City ponycon in 2020:  custom abilities for playable characters, and custom attacks for enemies!  Once I have the foundations laid, I can add attacks one-by-one and have quicker releases.

[Rikifive 24,154]

Watched the video; Nice additions! 

Fluttershy is still OP, pls nerf.  

[HereComesTom 2,266]

9 hours ago, Rikifive said:

Fluttershy is still OP, pls nerf.  

I'm not entirely sure what I'll do with these ponies if I'm being honest to balance them out.  Maybe FS will still be a glass cannon in the end, but only by virtue of the fact that she's the only one with spread-shots?

[Rikifive 24,154]

57 minutes ago, HereComesTom said:

I'm not entirely sure what I'll do with these ponies if I'm being honest to balance them out.  Maybe FS will still be a glass cannon in the end, but only by virtue of the fact that she's the only one with spread-shots?

Lowering her damage would be one of the options. For example, she throws 3 projectiles for 1 damage each. Other ponies have one projectile, but deal 4 or 5 damage.

That way Fluttershy would be effective against multiple smaller enemies, where other ponies would perform better at focusing on single targets.

Unless you changed something, I recall Fluttershy wrecking everything on her way when I played it, I didn't really use other ponies.  

Another option would be giving her just one projectile like other ponies have, that would automatically balance them out lol. Choosing character based on favorite pony (just for looks; all ponies are the same) isn't a bad option.