The author mentions a lack of a sensation of speed. The main reason for this is relatively obvious if you spend a few moments examining the gameplay footage: The sprites all have a simple traditional 2D drop shadow, where the size of the shadow is the same as the size of the sprite and it's offset by a few pixels. This visually implies that the sprites are very low to the ground, and as a result the slow scrolling speed of the background means that the sprites are not moving very quickly.
Under normal circumstances the cloud layer (moving at a higher scrolling rate - parallax) is a good way to create a sense of motion, but it's really just making it look like the cloud layer is moving fast :) What you really want is to fix the way you're shadowing the objects.
Removing the shadows entirely would probably eliminate the false cue but then you lose a sense of the sprites floating over the terrain.
There's also a related problem in that the player and enemy sprites are effectively floating on their own layer that doesn't scroll. When the enemy sprites are flying along at their own pace this is easier to ignore, but when an enemy appears that isn't moving horizontally at all (or is aligned with a fixed point) it makes it more obvious that the depth and motion cues are wrong.
To be fair, these are all problems that you will see in other games of this type. It's worse when you're using a straight-on top-down perspective like the game in this post.
EDIT: Some relevant examples:
Raptor: Call of the Shadows is an old 2D shooter with a similar perspective (top down), though scrolling vertically. This game does shadowing relatively correctly, where the sprites cast shadows directly on the background layer at a position that scrolls with the layer - so as the sprite advances down the screen, the relative position of the shadow changes. This creates a sense of the sprites and the background scrolling at different speeds, so you feel some depth. (The shadows are nearly as large as the sprites, though, so it still doesn't feel like they're very far off the ground.)
Ikaruga takes an alternative route here: While the enemies are basically 2D objects on a flat plane, they don't cast shadows at all and the backgrounds are effectively just FMVs containing various motion. They use the background to convey a sense of camera motion without tying objects to them at all. This lets you avoid having to precisely align the sizes and positions of your entities with the background (though of course, they end up kind of disassociated)
Hi,
thanks for your interesting feedback :)
In the YT video, the shadow projection are in the wrong direction. It's as if the sun was all over the screen border ;)
But I got your point and I'll work on this
A "sufficient" shoot'em up it's not too complicated to make, you can get an OK-ish engine in a week, but then you have to add content (stages, enemies, different AIs, etc). IMHO hat's the main difficulty of the genre, because a lot of work is required for just a few minutes of gameplay.
I've made myself a couple of these games and they're fun to make, but it's not too rewarding (eg, I made this one in a month: http://www.usebox.net/jjm/flax/ -- and it's ~6 minutes to get to the end of the three stages).
BTW, I did a shmup for Android last year and decided to remove the spaceship altogether because I found it a little bit awkward to move it with a finger:
I did it in just 23 days by sticking to simple pixelated graphics for the aliens and only drawing UI and powerups. I also borrowed music with CreativeCommons license and only created the sfx myself. This gave me time to add various boss levels which is what makes the game interesting (and takes time as you wrote).
Also, powerups can be upgraded between games, so this got me a lot longer playing time than 6 minutes. You play to pass as many levels possible, but also to collect coins to upgrade your weapons which in turn enable you to pass more levels the next time and so on. There are 14 different bosses and you can hardly beat bosses 9+ without upgraded weapons.
There was a good ExtraCredits episode on YouTube explaining game loops (I can't find it now, but I recommend watching all EC episodes to any game developer). I didn't know about it at the time, but Drone Invaders fits great:
- smallest loop: kill enemies in a wave, reload guns
- bigger loop: every 10 waves there is a new boss level
- even bigger loop: when you die, upgrade your weapons and try to go even further
- biggest loop: reach the Fleet Admiral rank but hitting certain score, number of destroyed enemies, level reached and hiscore achieved over lifetime of playing.
I an monitoring the stats (the game sends anonymous usage info at the end of each play), and there are some players playing the game for over a month.
I was willing to use a WebView with Cordova, but Kit Kat introduced a bug (not hw acceleration in canvas 2D!) and I was getting 2 FPS instead of the expected 30.
Crosswalk works pretty well, although has the inconvenient of being a native component.
Not everyone upgrades their phone every year or two. I know plenty of people who still have an Android 2.x smartphone because they have no need to upgrade.
(That said, I don't think many of them would play this game.)
Some people are using devices that are hard to upgrade and are stuck with older versions. According to Google Play stats, I have about 11% of players using Android 2.3 for my game.
I use 2.3.3 as the lowest supported version, since most important features were introduced with 2.3.3. At least, I don't know any reason to require 4.0 to be minimum, so why lose 11% of your users. I was curious if OP used some important feature that would require 4.0.
To be honest, if you are indie developer and you don't have very aggressive IAP like Clash of Clans or Throne Rush, there is no money from people that buy apps. I've seen cool indie games like TripleTown having trouble monetizing. I bet one could make more money from Ads (although I hate ads, I hate them less than whale-catching-IAPs).
My partner and I spent three years making our own 2D game engine and game as well: http://junkyardtom.com
It took so long because we initially built it in ruby, but found it was too slow; then pascal but found out it wouldn't work so well on Android; then finally Java.
It's also not a shoot-em-up -- there's a fair amount of logic involved in the movement of the actors (some rudimentary AI) and way too many game rules. Maybe we should have started with a shoot-em-up...
We're going to release the engine some day (when we have time to clean it up) -- it uses XML files to configure all of the actors and the 'stage' so maybe it will be useful to teach basic parallelism to kids or something...
I've also made a shoot'em up game last year december in a day or 2 to celebrate the silliness of Doge Coin.
I did make use of the moving background to increase the sensation of speed when speed power up is taken( Eventhough i know the background should not be moving at all :P)
Under normal circumstances the cloud layer (moving at a higher scrolling rate - parallax) is a good way to create a sense of motion, but it's really just making it look like the cloud layer is moving fast :) What you really want is to fix the way you're shadowing the objects.
Removing the shadows entirely would probably eliminate the false cue but then you lose a sense of the sprites floating over the terrain.
There's also a related problem in that the player and enemy sprites are effectively floating on their own layer that doesn't scroll. When the enemy sprites are flying along at their own pace this is easier to ignore, but when an enemy appears that isn't moving horizontally at all (or is aligned with a fixed point) it makes it more obvious that the depth and motion cues are wrong.
To be fair, these are all problems that you will see in other games of this type. It's worse when you're using a straight-on top-down perspective like the game in this post.
EDIT: Some relevant examples:
Raptor: Call of the Shadows is an old 2D shooter with a similar perspective (top down), though scrolling vertically. This game does shadowing relatively correctly, where the sprites cast shadows directly on the background layer at a position that scrolls with the layer - so as the sprite advances down the screen, the relative position of the shadow changes. This creates a sense of the sprites and the background scrolling at different speeds, so you feel some depth. (The shadows are nearly as large as the sprites, though, so it still doesn't feel like they're very far off the ground.)
https://www.youtube.com/watch?v=grXkzisSEM4#t=7m30s
Ikaruga takes an alternative route here: While the enemies are basically 2D objects on a flat plane, they don't cast shadows at all and the backgrounds are effectively just FMVs containing various motion. They use the background to convey a sense of camera motion without tying objects to them at all. This lets you avoid having to precisely align the sizes and positions of your entities with the background (though of course, they end up kind of disassociated)