Macromedia Flash

[Dave_K.]

Why aren't more people using Macromedia Flash to write their shmup games on? Flash has decent enough 2D (and even 3D) capabilities to handle any type of shmup. Its practically platform independent, no install required when run in a browser, and online ranking and multiplayer seems a short step away if people already have to be online to play it. Plus you can build a nice community around your games with website/forums/whatever.

For a perfect example of pixel based flash games which rock (although not a shmup), see http://www.pixeljam.com/. Heck, even their entire website is flash based with tons of little pixel animations everywhere.

[Pixel_Outlaw]

Because time spent learning Flash ActionScript could be better spent learning a programming language and concepts that will last a lifetime. As far as creating software Flash is certainly not the industry standard or even popular among professional game developers.

[Dave_K.]

Because time spent learning Flash ActionScript could be better spent learning a programming language and concepts that will last a lifetime.

And what about those of us who have already coded for a lifetime and just want to make a game that can be easily accessed/played by as many people as possible?

As far as creating software Flash is certainly not the industry standard or even popular among professional game developers.

My bad, I was not aware this forum was for industry standard professional game developers only. Someone better tell Alluro he is wasting his time with Game Maker.

Seriously now, I'm not debating what is the best programming language to create games on. I'm asking why more people *here* haven't been lured to code their shmups on flash due to the advantages I stated previously?

[Twiddle]

Pixel Outlaw prefers Chacker

[Pixel_Outlaw]

I assumed Dave was asking the question on a personal level so I answered for myself and myself only.

I've not used their product, but my main concern is calculation speed and power. A few Cave worshipers may be let down when they can't fill the screen with bullets.

Do what needs to be done to get your ideas out.

[Ed Oscuro]

Pixel Outlaw prefers Chacker

and Java has been under threat of being exploded from time to time, as IBM and Sun's dealings with Java are complicated (and now IBM is once aside competing with Java's owners).

I'm sure old Java apps would've worked just fine on new JREs regardless of the name, but funny business can happen in any system.

[Udderdude]

Flash games suck for a number of reasons, biggest being it's just too damn slow. Another is you need joy2key to get any sort of joystick support. It's really easy to make flash lag, and while you can detect the FPS drop to make sure people aren't intentionally lagging the game to make it more playable, it still sucks for people with slower PCs.

[320x240]

No vsync, low fps and low priority from the cpu is the worst things about Flash. I certainly wouldn't want to make a shmup with it.

That said, I recently finished a small metroidvania-clone with it. Platformers work out okay even at smaller frame-rates. My own game has an upper-limit of 33. If only potential sponsors could see the beauty of it...

[Dave_K.]

Thanks for the feedback guys. This is what I was wondering about. I seem to remember similar sentiments about speed and cpu priority when it came to early Java game programming. I'll admit I had some slowdown on my Mac with a few Flash games before, but I just upgraded to Flash 10 and all slowness seems to have gone away. Anyway, I've never coded in Flash's Action Script, but have been seriously considering it after seeing a few excellent examples.

Best example shmup I've seen is Arcanacra Black Label which happens to now be open sourced! Runs at a 40FPS on my macbook pro and is quite manic. There is an online ranking, where a few shmup members spent some time to ALL it, so it must be well respected. [edit] Holy crap, there is even a replay feature where you can replay any of the internet high scrore runs! MrMonkeyMan's replay is insane! [/edit]

Arcanacra was built on CannonML which seems like quite an achievement to do in Flash given its micro threading, barrage convination, bezier-spline motion, and gravity motion. Leaving me with the impression that Flash/Action Script is a lot more sophisticated and extensible than a simple scripting language (sorry Pixel_Outlaw).

I guess I was hoping to hear if more people here were trying out Flash and creating some common shmup libraries.

[Pixel_Outlaw]

I'd like to see more players here making games in anything. Probably the best tips for fast computing are doing simple rectangular or circular collision checking and pre computing paths and other trig heavy operations. I know that a lot of artists use Flash and they may not be using the best coding practices. So perhaps a seasoned programmer can do better. I think it becomes a matter of knowing the limits of the software and precalculating expensive and redundant operations. This will use some more memory but it will keep the calculation load a bit lighter.

This may be a bit elementary for some but I'm going to post anyway.

Bullets:

NO
x = x + cos(direction) * speed
y = y + sin(direction) * speed

Rather

x = x + x_step
y = y + y_step

function adjust_direction(direction)
{
x_step = cos(direction) * speed
y_step =sin(direction) * speed
}


So in that way you only use trig when changing the direction of your shots. Otherwise movement becomes a simple addition per cycle. The direction changing function is only called when needed, not every cycle.


Now it is very expensive to have spline based paths calculated at every cycle. Instead why not use an array to store the points for each cycle before the game starts? This way the path following becomes a simple addition problem rather than a high level mathmatical function. You just need to: A save the points to an array, B specify the x and y offset to add during the actual game.

Also, if image rotation is a heavy burden you can make an animation of a bullet having about 36 rotations and then just select the one that fits best. It won't look too bad.


As I said before it is almost crazy to be using pixel based collisions for most shmups. A simple rectangle to rectangle collision has a worse case scenario of 4 "if" statement checks. The circle to circle is usually a bit more expensive but can also be very fast.

If the bottleneck with is Flash is drawing speed then there is really little you can do about that.


Just some basic ideas to help take a load of the CPU.

[Dave_K.]

Good tips. I'm sure keim (author of arcanacra) is a veteran and does lots of pre-calculating/optimizations. I don't know if the bottle neck is drawing, as there are a shit ton of bullets in the boss battles.



I checked out his blog, and he still seems active in Flash, writing an example arena shooter in 100 lines of code! (note: this may not be a good example of optimization )

[Udderdude]

I checked out his blog, and he still seems active in Flash, writing an example arena shooter in 100 lines of code! (note: this may not be a good example of optimization )

It's certianly possible to make quick and dirty programs in Flash. That is one thing it's good at .. rapid prototypeing of 2d game ideas.

[Ex-Cyber]

I've been meaning to play with Flash/ActionScript for a while, but I just haven't had time with homework constantly kicking my ass. ActionScript is a dialect of JavaScript/ECMAScript, which is actually a much nicer language than you'd expect from something used to do so much annoying bullshit on web pages. It superficially resembles C or Java, but if you look past that it actually owes a lot more to languages like Lisp and Smalltalk.

[SandtouchLC]

Pixel Outlaw prefers Chacker

LOL.

Chacker was not written in straight Java, anyway. It uses the beta MMF2 Java runtime (and has from day one). As we have squashed our bugs and Clickteam has improved the product--they are legendary for addressing customer concerns--the performance has gotten better, but the hit for using Java is still about 3x native speed (plus you have an additional hit from the MMF2 runtime, although that one is comparatively small and still getting smaller with each update Clickteam issues). So, we are still on the fence about a flash or AJAX port simply for performance's sake. (Before you scoff at Javascript, notice that someone just requested a DSi Javascript shmup.)

Why not just go native? (Especially since we are already using MMF anyway?) As Dave suggested, Java and Flash have an advantage as far as accessibility goes--not just accessibility to the developer (who is not limited to language/api X proficient programmers) but also to the user. There is a large portion of the population who will not download anything that ends in ".EXE." There is a growing portion of the population that cannot download anything that ends in ".EXE"--Mac and Linux users, to say nothing of those with an iPhone/iTouch/any portable device. And as we all know from Vista, Windows is not necessarily consistently compatible with itself.

You could get the best of both worlds by using something like pygame on top of Python or another interpreted language. If Sandtouch was not in need of a "language" that can easily be shared with mere mortals (i.e. conservationists and bird watchers) we might have gone that route. But although Python is very portable, it is not as well supported on portable devices as AJAX, which mitigates the future-proofing quite a bit.

Because time spent learning Flash ActionScript could be better spent learning a programming language and concepts that will last a lifetime.

That is the conventional wisdom. But the advent of AJAX and cloud computing, and the corresponding decline of the desktop, compel you to put a "?" where you have a "."

Edit: Fiks teh gramer n portayble stuf.
Second edit: For tone/typos.

[the2bears]

...but the hit for using Java is still about 3x native speed...

That's just not true. Maybe at one time, quite a few years ago, but not now. With JIT compilers Java code approaches (within 10%) native code, and in some cases exceeds compiled C/C++. Add in a binding for OpenGL and you're close enough to native that it really doesn't matter in a shmup style game.

Bill

[SandtouchLC]

With JIT compilers Java code approaches (within 10%) native code, and in some cases exceeds compiled C/C++.

In terms of CPU performance, yes. But....

Add in a binding for OpenGL and you're close enough to native that it really doesn't matter in a shmup style game.

Assuming the host computer has a decent GPU, and is not using Vista, and that you are willing to either put up with pixelation or ship with huge textures (not feasible for a free download game). That's why, in terms of performance, Aerith couldn't outrun Sephiroth to save her life.

Otherwise, you are stuck in Java2D and are at the mercy of the CPU to resize your sprites.

[SandtouchLC]

As I said before it is almost crazy to be using pixel based collisions for most shmups. A simple rectangle to rectangle collision has a worse case scenario of 4 "if" statement checks. The circle to circle is usually a bit more expensive but can also be very fast.

Rects are very fast, but as you imply, you need circles to handle spherical enemies. (Look at the bubble stage on Gradius III to see what happens when you have rect collisions but spherical enemies. In Konami's defense, the SNES couldn't do floating point calculations, therefore couldn't do pi, therefore couldn't do circles, but still.)

If your enemies are all rects or spheres, then that works, but if you have irregular bullets and enemies (e.g. birds), then you really don't have much choice but to go with pixel to pixel collisions, at least to test the player's bullets striking the enemies. If you give the enemies hitboxes, you are left with a swearing and cursing player decrying your poor hit detection when her shots graze. OTOH, it's OK to give the ship a hitbox so that the player has the margin of error in her favor.

This is probably why the ENEMY bullets in Cave and other danmaku shmups are always spherical or elliptic, but the PLAYER bullets are not.

[Danbo]

Or you could have a larger-than-sprite hitbox for the enemies when it comes to bullet collision. Or multiple hitboxes.

[null1024]

Or you could have a larger-than-sprite hitbox for the enemies when it comes to bullet collision. Or multiple hitboxes.

Larger-than-sprite hitbox: bad, this is the problem with rect based collision for circular enemies.
Multiple hitboxes: very good, minimizes excess colliding area.

[Danbo]

For a manic game that does not care about player-enemy collision, I can't see anyone complaining that their bullets are unfairly hitting the enemy. But it would be very frustrating if the game killed you for colliding with an enemy ship...

But as far as I know, for irregular enemies, multiple hitboxes are what's generally used. As was stated, rect collision is very simple to implement and very fast, and per-pixel collision detection is very slow unless you do something wacky like try to bitwise-AND the respective pixels. Honestly, per-pixel is never really such a great idea anyway - who likes dying because one pixel of their wing brushed one pixel of a tiny bullet?

Circle-based collision detection is even simpler, compare the distance between centers to the sum of the radiuses. But what this means is that you have to have either all circles or all rects, you can't have a mix of both. Rects are just more expressive.

[Pixel_Outlaw]

As I said before it is almost crazy to be using pixel based collisions for most shmups. A simple rectangle to rectangle collision has a worse case scenario of 4 "if" statement checks. The circle to circle is usually a bit more expensive but can also be very fast.

Rects are very fast, but as you imply, you need circles to handle spherical enemies. (Look at the bubble stage on Gradius III to see what happens when you have rect collisions but spherical enemies. In Konami's defense, the SNES couldn't do floating point calculations, therefore couldn't do pi, therefore couldn't do circles, but still.)

If your enemies are all rects or spheres, then that works, but if you have irregular bullets and enemies (e.g. birds), then you really don't have much choice but to go with pixel to pixel collisions, at least to test the player's bullets striking the enemies. If you give the enemies hitboxes, you are left with a swearing and cursing player decrying your poor hit detection when her shots graze. OTOH, it's OK to give the ship a hitbox so that the player has the margin of error in her favor.

This is probably why the ENEMY bullets in Cave and other danmaku shmups are always spherical or elliptic, but the PLAYER bullets are not.

The you should not need pi for circular calculations.


Given

R1 is the radius of the first circle
R2 is the radius of the second circle
x1,y1 are the x and y of the first circle
x2,y2 are the x and y of the second circle


From geometry hypot = sqr (a^2 + b^2)

if ( sqr(((x1-x2)*(x1-x2))+((y1-y2)*(y1-y2))) < R1+ R2 )
{
return true;
}


There is even a faster way to do this, but I won't get into that. It involves not using the actual distance. Basically a circular collision check involves finding the distance between the two points and then seeing if that distance is larger or smaller than the sum of both circles' radii. If the distance is larger then they simply cannot collide. No pi there. This forumla should work for int values too but it will be very slightly off.

If a shape is complex you are better off using multiple collision squares. They do this in many shmups including Gun Bird 2 and some of the Gradius games.

Also I remember finding out that some Cave bullets are indeed square. There was a topic here if I recall. The smaller the bullet the closer the square collision box is to the round one.

Motorherp wrote a VERY good collision checking tutorial on shmup-dev. He is a professional game physics programmer so he knows his stuff.

http://www.shmup-dev.com/forum/index.ph ... 635.0.html

[SandtouchLC]

Pixel_Outlaw,

Thanks for the info.

Since Java sqrt performance stinks (and because we already have a very fast collision engine that can use pixel or rect)* we can't use spherical collision for Chacker, but we will keep this in mind for future projects. Thanks!

* We cannot claim credit for it -- it is the stock MMF2 collision engine. If we really wanted to we could write a Java extension to have our own collision engine, but it's probably not worth it given the less-than-native performance of the sqrt and other trig functions.

[worstplayer]

Pixel_Outlaw,

Thanks for the info.

Since Java sqrt performance stinks (and because we already have a very fast collision engine that can use pixel or rect)* we can't use spherical collision for Chacker, but we will keep this in mind for future projects. Thanks!

* We cannot claim credit for it -- it is the stock MMF2 collision engine. If we really wanted to we could write a Java extension to have our own collision engine, but it's probably not worth it given the less-than-native performance of the sqrt and other trig functions.

You don't have to use sqrt for circle collisions.
just do something like (pseudocode)

if (x1-x2)^2+(y1-y2)^2 < (r1+r2)^2

You can speed it up even more by having one object's radius already "pre-multiplied" and other being a simple point, making it

if (x1-x2)^2+(y1-y2)^2 < r1

but that requires some changes in game design.

[keim_at_Si]

Good tips. I'm sure keim (author of arcanacra) is a veteran and does lots of pre-calculating/optimizations. I don't know if the bottle neck is drawing, as there are a shit ton of bullets in the boss battles.

Thanks for introducing .
Flash and ActionScript is not too bad choice for 2D shmups, but it still has some disadvantages.
The performance is one of the biggest issue in my mind. Its possible to create bullet hell on the browser but it needs meticulous tunings than C/C++. And there are no choices if you want 3D effects.
Input devices is another big issue. The joy2key is not bad, but it has latency. Or the mouse operating shmups is hideous solution.
Another considerable point is the image of "Flash games". There are so many Flash games in the world but most of them are only a "mini" game with mouse operation. The fact shuts many shmups players away from Flash.

By the way, http://wonderfl.net/code/338bb2c5f00587 ... fa4f80309a is better example for shmups on ActionScript. We hope you find it informative.

[Dave_K.]

Thanks for introducing .

Thank you keim for coming here to post your thoughts! You're Cannon ML and flash examples are a great resource! I'll look closer into the LCD render example, cool game and quite difficult.

[louisg]

That's just not true. Maybe at one time, quite a few years ago, but not now. With JIT compilers Java code approaches (within 10%) native code, and in some cases exceeds compiled C/C++. Add in a binding for OpenGL and you're close enough to native that it really doesn't matter in a shmup style game.

Is this true in practice though? It seems that whenever Java is involved with an application I am using, that it is much slower than it should be.

Dave, for quickly getting a game together, I actually like using Allegro. It's a C game programming library with many convinience functions and it supports OS X, Linux and Windows.

[the2bears]

That's just not true. Maybe at one time, quite a few years ago, but not now. With JIT compilers Java code approaches (within 10%) native code, and in some cases exceeds compiled C/C++. Add in a binding for OpenGL and you're close enough to native that it really doesn't matter in a shmup style game.

Is this true in practice though?

Yes. I was commenting from experience and not conjecture. The point is especially true for shmups, due to the 2D game play requirements. The only time I've experienced anything close to slowdown (<60FPS) was when I put real-time fluid dynamics (Riders on the Storm) into the game loop. Certainly more graphics effects will add complexity, but on the other hand I've never done any optimization with the OpenGL pipeline I'm using today.

Bill

[RegalSin]

First things first. In terms of speed, you could lower the quality of FLASH. This will give it that NES look,or even Sega Saturn image look, if you choose. It makes the FLASH on my system run super fast.

I have thought about using flash as a demo, to show off things about my game I am working on. Flash is good for concept, but never fully releasing. Especailly when they keep upgrading the flash, and making flash designers think, the flash interface they use is no longer up to date. FLASH stopped around version six or seven.

Some flash games, I see does the exact same thing, but other things are replaced. Try running newer 2d flashes with older FLASH installments, and you will see the missing images.

In fact the FLASH video file, ( like the one used on Youtube ) has been upgraded. The original file could play on my computer, while the newer file, is slow and forces me to download. I try upgrading but with all the designers ( the art people ) using flash to make advertisments. I keep getting error messages.

About Java. I want to forget about Java. For the Iphone/ Symbian OS, I could see Java applications being used all the time. That is the only reason to look at JAVA. To make applications for cell phones. Also I still have, had a chance to upgrade my Java, knowing the new Java, has changed various things in it's complier. There is also the same fear of flash.

------------------------------------------

In terms of programming, it goes from

FLASH
Game within a game ( game maker, RPG maker, etc make your own FPS, etc )
java/C/LPS ( or any high level langauge via complier )
ASM ( Assembler via complier )
machine code


The problem with flash is that, while I could run a flash game really great on a G4imac, there is people
still running a W98 machine, people who would like to see the game in DOS, or refuses to use the game
on another system. Why not DOS? Dos is just 16-bit word size versus your 32-bit ( or even duo/qudro
64-bit systems ).

I beleive FAKK 2, and MDK can run, stand alone in DOS mode. Those games are 3d.

[ViolentAJ]

I make games in Flash. I'm not the best programmer (some of the optimization tips here helped me out). and I'm certainly not a great artist, but it can be done and it can be profited from.