[as3] Advanced Weapon System

[pradvan]

Hi All,

I'm here to plug my latest AS3 game script: Advanced Weapon System.

Quick overview:

Multi-barrel turret support
Projectile weapon
Laser weapon
Collision detection
Weapon manager
OOP - easy to extend

See complete list of features, and preview, here:
http://www.freeactionscript.com/2011/08/
advanced-weapon-system/

[zerosky]

Cool demo!
Although I won't have much use for something like this I'm sure someone else could.

[bikinigames]

Great job! While beginners and such could certainly learn from this, I'd be excited to see someone with a bit of experience make something cool with this!

[PSvils]

At 8/31/11 09:37 PM, bikinigames wrote: I'd be excited to see someone with a bit of experience make something cool with this!

Nobody will, because this thing is fuuuucking slow dude! I just had to click the mouse a few times and the FPS got killed...demolished...obliterated. And for the small amount of stuff that was happening on screen, that shouldn't happen...

Before you consider this useful, you gotta optimize it way way more, otherwise in a game environment this thing will kill everyones computers. You must be doing something very wrong in the code...collision detection?

P.

[Sandremss128]

My computer didnt had any problems with it (even if I opened the link 4 times). That being said I've looked at the code and found out that it overuses OOP constructs. It bloats a little bit. And you dont use constants for the types, so you have:

if (type == "laser")

In small projects this works fine but if you mistype the code could fail silently without you having much chance finding the origin. Better would be to have a constant like LASER for it, you cant mistype or you get a compiler error.
For example your 'removeWeapon' function in the WeaponManager is not optimized:

public function removeWeapon(weapon:AbstractWeapon):void
		{
			// loop thru array
			for (var i:int = 0; i < _weapons.length; i++)
			{
				// save a reference to current object
				tempWeapon = _weapons[i] as AbstractWeapon;
				
				// if found in array
				if (tempWeapon == weapon)
				{
					// run garbage collection method on weapon object
					tempWeapon.destroy();
					
					// remove from array
					_weapons.splice(i, 1);
					
					// remove from display list
					container.removeChild(weapon);
				}
			}
		}

Better would be:

public function removeWeapon(weapon:AbstractWeapon):void
		{
			var i:uint = _weapons.indexOf(weapon);
			weapon.destroy();
			_weapons.splice(i, 1);
			container.removeChild(weapon);
		}

And the removeBullet function:

public function removeBullet(bullet:DisplayObjectContainer):void
		{
			var i:uint = _bullets.indexOf(bullet);
			Bullet(bullet).destroy();
			_bullets.splice(i, 1);
			container.removeChild(bullet);
		}

You dont need to loop trough the entire thing if you already know what element you are removing, this goes for all the things you remove.

Also you use tempWeapon allot for a temporary reference, when you assign a new reference you dont need to explicitly cast it as AbstractWeapon, you are already implicitly casting it so you dont need to put 'as AbstractWeapon' after the assignment, it just takes extra CPU.

Also you dont make use of interfaces, which are necessary when you write code that other people are going to use.

And your update system doesnt work when you have moving objects, consider this:
updateBullets();
updateEnemies();

The bullets are now using the not-yet-updated positions of the enemies if you are using them for your collision. Better would be to first update all the positions of all objects in the game, and then check for collisions.

And I see you use hitTestPoint for the collision detection which is probably the reason why its so heavy on the CPU, its good for demonstrating purposes but you should leave it out on the real thing.
Apart from some other bloats there is a fundamental thing that is wrong with your weapon system: its directly connected to the graphics!

In bigger projects programmers like to keep their visual and abstract data completely separate, so your game will work and react to user input but that way that that data is displayed doesn't bother the abstract game, it just does its job. This is really nice because there is no dependency on the graphics, and this means that classes have less load so they can work faster. AND this means that graphics only need to be updated when they are told to do. If you have 2 objects and you change their positions it directly takes CPU when they are displayobjects, if they are not they just change a variable.

I dont think this is fundamental enough to be seriously used in a project, but I do think its good that you work on something and share it with the world.

[pradvan]

Thank you all for taking the time to look at this. Your input is highly appreciated.

PSVils,
I'm sorry you are having performance issues. What type of system/browser/machine are you testing this on? Any additional info might help me improve this and iron out any performance issues.

Sabdrenss128,
Thanks for the in-depth analysis and constructive criticism! I love to get this sort of detailed feedback from a fellow developer. Please allow me to explain some of my design decisions.

As you might, or might not know, this script is a work-in-progress. It started off with this simple projectile weapon script (http://www.freeactionscript.com/2011/07 /projectile-weapon/), which before long grew in to a multi-barrel projectile weapon script (http://www.freeactionscript.com/2011/08 /projectile-weapon-multi-barrel/).

At this point I wanted to add additional weapon types, so I refactored a lot of the code (but not all of it) to make it more and more flexible, and thus created the Advanced Weapon System. Lasers were the latest addition, so I went with the lazy route and didn't use constants for weapon types. I was honestly just trying to get it working at this point.

I didn't know about the _weapons.indexOf(weapon) method! This is little change will speed things up dramatically. No more mindless looping through entire arrays. Great tip! Much thanks!

As far as explicitly recasting vars: there are articles out there with data that proves that recasting these type of vars actually improves performance since flash doesn't have to do a type check when you're setting the var. It sounds odd, I know. But it is what it is. Unfortunately I don't have the link saved. I'll try to look it up.

The update system: although it works in its current state, it could be updated to include your suggestion to be more accurate. I will add this to the wish list.

Optimized collision detection is already on the wish list. What are you suggestions as far as implementation?

Separating the display and data is something I'm keeping in the back of my mind. I designed all weapon system components so that they could be easily turned in to value objects. Using my unconventional development process (which I talked about above), I have not gotten that far yet. Same applies to using interfaces.

Ideally this type of system should be used with a blitting engine, but for now I'll stick with display objects to keep it simple.

Any other suggestions on how this could be improved are more than welcome!
Cheers

[Sandremss128]

At 9/1/11 10:44 AM, pradvan wrote: As far as explicitly recasting vars: there are articles out there with data that proves that recasting these type of vars actually improves performance since flash doesn't have to do a type check when you're setting the var. It sounds odd, I know. But it is what it is. Unfortunately I don't have the link saved. I'll try to look it up.

I give you mine source that shows implicit casting is better:
http://gskinner.com/talks/quick/#46 (use the arrow keys to browse through the pages) (link originally provided by Milchreis)

Implicit casting is better on objects, the only reason why you might want to do it is when you look something up on an array:
array[uint(i)] (next page of the link)

Another link to back me up I got trough google

I've showed you my reference to proof, now I want to see yours ;)

[PSvils]

At 9/1/11 10:44 AM, pradvan wrote: Thank you all for taking the time to look at this. Your input is highly appreciated.

PSVils,
I'm sorry you are having performance issues. What type of system/browser/machine are you testing this on? Any additional info might help me improve this and iron out any performance issues.

The thing is, I AM testing this on a netbook, so the computer itself doesn't have a lot of power. But even accounting for that, your demo ran very slow. Most of the games I've made I test on the netbook specifically to see what resource hogs they are, and I've had much more stuff going on than your demo with very little or no lag, which leads me to believe you are making very bad choices in some of your design.

I can't dig through your code right now, and it's awesome that you're doing this stuff and releasing it to the community, because even in it's current state, there are a lot of people that could learn from this. But just to bring it to a usable level, it still needs a lot of work, most of which might come to you naturally through experience. (Look back at this a year afterwards, and you will probably see all the places you went wrong).

Keep going, but realistically this isn't useful at all to anyone that's experienced, since implementing something of this nature would be < days work for someone who's competent (also, no offense, just putitng things as they are.)

P.

[pradvan]

Finally got some time to go over my code and make some optimizations. In the process found the real reason everything was running slow on slower machines: apparently I forgot to remove very expensive and unnecessary calculations when I added lasers.

Tested the latest version on my phone, and it runs pretty well! The old version certainly did not.

Here is a link to the latest version (not yet released).

Sandremss128, having seen my source on Twitter months ago, I was unable to find the link. That being said, I think it's safe to trust Skinner's test results. I will no longer recast my variables to "improve performance".

PSvils, how is it running on your notebook now?

[PSvils]

It's better. Still dives down to 26/30, and further down to 21/30 after a while, but overall it's much better performance wise than before.

[pradvan]

Sorry PSvils - looks like your netbook is very slow. Even when I add 100's of bullets on the screen, it runs fine on my phone (never dipped below 27fps), where's the old version really lagged (was basically unplayable).

Latest version, 1.1.2, along with source code:
http://www.freeactionscript.com/2011/08/
advanced-weapon-system/
-Includes mostly speed optimizations.

Up Next: guided missiles & lightening gun. After that, new display manager that handles all the graphics.

[pradvan]

Fixed link: http://www.freeactionscript.com/2011/08/ advanced-weapon-system/

[pradvan]

At 9/15/11 12:30 PM, pradvan wrote: Fixed link: http://www.freeactionscript.com/2011/08/ advanced-weapon-system/

Not having much luck with links today :-/

This is the link:
http://www.freeactionscript.com/2011/08/
advanced-weapon-system/

copy/paste if it doesn't work.

[PSvils]

A huuge performance issue I can see with your laser turrets is that you're using stepping to detect collisions (a for loop and checking hitTest()s...)

This is bad bad bad, use raycasting instead!

Despite that though, the latest version does run quite fine.

[Sandremss128]

Did you also got rid of the hitTestPoint statements?

if so I dont have much to say

[PSvils]

At 9/15/11 02:50 PM, Sandremss128 wrote: Did you also got rid of the hitTestPoint statements?

if so I dont have much to say

I don't think so, cause like I said, I noticed he was using stepping for the lasers, which means a for loop with hitTestPoint()'s...