Newgrounds.com — Everything, By Everyone.

At 2/2/13 11:29 AM, MantisSuperior wrote: Hello everyone! I have one question and i think you now what. Why a lot of game developers (i tell about PC and console game developers) don't use AS3? Super meat boy was written on C++, Castle crashers - C++. Grafics were drawing in Flash and why programmers didn't use AS3? Because AS3 is very stupid or uneffective? Who can give me answer? If i want create game on console i must learn c++ for example and forgot about AS3? (i tell this because i found a lot of lessons for creating games on AS3 and it will be very sad if it can't help me with my education) Please help me.

Performance, hardware access and distribution ease, most likely. As far as I'm aware, Castle Crashers was originally created using AS2 and then parsed as C# for distribution on XBLA (If only it was as easy as that sentence was to write).

AS3 is a great language (and more often than not a good development environment) for prototyping ideas. In addition, learning a language is never a bad thing and will only further help you as a programmer.

If you want to create games for consoles you have to abide by what can actually run on them.

At 2/2/13 08:27 AM, FlyingColours wrote: Upon re-reading, I realised PSvils was being ironic too, and he wasn't really confusing AS and C++ stuff. Well, no wonder why you smiled.

By the way, I looked at the code again and there was only one real error in it:

Is this still part of the joke?

I don't get it.

At 2/2/13 08:11 AM, milchreis wrote:

At 2/2/13 07:38 AM, teejay-number13 wrote: And no where did I state that I didn't want to remove all the children

I wrongly assumed you have some additional code in the loop checking for the death of the player.

If all you want to do is empty the container, then there's no need for any loop.
http://help.adobe.com/en_US/FlashPlatform/reference/actionsc ript/3/flash/display/DisplayObjectContainer.html#removeChild ren%28%29

Yeah. OP - looping through all your children to remove them assumes you have extra code that you want to be executed for each child in the container, I was trying to keep my example as minimal as possible. If your sole purpose is to remove all children in a container and nothing else, removeChildren is obviously a better choice. Perhaps my example was too simple?

At 2/2/13 02:18 AM, teejay-number13 wrote: by running the for loop several times

That's completely unnecessary. You need to understand loops to a better extent because iterating backwards isn't a hard feat:

for (var i:int = numChildren; i >= 0; i--)

I can try and elaborate on what milchreis is trying to say. Dry running your code (that is, running the logic in your head through before allowing it to run) can work wonders. Think about any container - a sprite for example that has many children you want to remove.

We can assume for an example that it has 4 children all together. These are indexed as children at: 0, 1, 2, 3. And each child has a method called remove that removes itself as you have. The loop might look like this:

for (var i:int = 0; i < enemyContainer.numChildren - 1; i++)
{
        getChildAt(i).remove();
}

Let's think about what happens during each iteration of our loop.

FIRST ITERATION:
for i = 0 to numChildren length of 4-1
    remove child at position i

SECOND ITERATION:
for i = 1 to numChildren length of 3-1
    remove child at position i

THIRD ITERATION:
for i = 2 to numChildren length of 2-1
    remove child at position i

END OF LOOP: i has met its condition and the loop is terminated

So the highest i ever becomes is 2. But, we have 4 elements in our array that are indexed like this: 0, 1, 2, 3. What happens to the element at position 3? It doesn't get checked and therefore not removed. This is why iterating forward to a changing condition is a bad idea. If you had iterated backwards it would look like this:

FIRST ITERATION:
for i = numChildren length of 4 - 1 to 0
    remove child at position i

SECOND ITERATION:
for i = numChildren length of 3 - 1 to 0
    remove child at position i

THIRD ITERATION:
for i = numChildren length of 2 - 1 to 0
    remove child at position i

FOURTH ITERATION:
for i = numChildren length of 1 -1 to 0
    remove child at position i

END OF LOOP: i has met its condition and the loop is terminated

Personally, I find a while loop at be a cleaner way of removing all children from a container sprite.

while(myContainer.numChildren >= 1)
{
    myContainer.removeChildAt(0);
}

Working with loops and container classes (whether that's a display object with children, an array, dictionary or vector) is really powerful and pretty much essential in making any game.

At 1/31/13 07:40 PM, Inglor wrote: So, it has been another year and I was wondering if anyone here still remembers me :)?

Yes, yes I do.

At 1/28/13 12:43 PM, Mattster wrote: on (release){
var apple:Map = new Integer("Multiplayer")
parent.parent.parent.root.parent.gotoAndPlay(apple, "start")
duplicateMovieClip(this)
}

Make sure you put that code somewhere on a button nested within a MovieClip called "superbutonst4rt" or else it won't work.

Brilliant.

1) Write most of game
2) Decide idea is bad
3) Scrap game

At 1/22/13 12:00 PM, egg82 wrote:

At 1/22/13 11:15 AM, Sam wrote: Static constants for the height, width, half height and half width are also really useful. Saves the time it takes to look up stage.stageWidth, and the calculation to get half of that.

i'm much less comfortable with that. The stage's size can change, you know.

In fullscreen scenarios and with certain scale modes set, yes. But in any application that's built the constants you may use change depending on what is and isn't going to happen. I'm not always going to need constants for colours. It just so happens that the applications I build rarely have need for fullscreen, and the constants lend themselves really well.

Anything for a bit more performance, eh?

At 1/22/13 06:06 AM, Diki wrote:

At 1/21/13 01:53 AM, MintPaw wrote: "public static var"
Never, never use static.

Never say never.
Static variables are good for storing colour codes like this:

public class Color {
static public const RED:int = 0xFFFF0000;
static public const GREEN:int = 0xFF00FF00;
static public const BLUE:int = 0xFF0000FF;
static public const YELLOW:int = 0xFFFFFF00;
static public const PURPLE:int = 0xFFFF00FF;
static public const CYAN:int = 0xFF00FFFF;
}

And anything else that you'll only ever have one of (such as the speed of light in a vacuum, should your game/app require it).

Static constants for the height, width, half height and half width are also really useful. Saves the time it takes to look up stage.stageWidth, and the calculation to get half of that.

At 1/21/13 07:25 PM, MintPaw wrote:

At 1/21/13 03:02 PM, Sam wrote:

At 1/21/13 01:53 AM, MintPaw wrote: It looks all good from here, but here's a few tips.

"public static var"
Never, never use static.

Bit of a bold statement.

Never!
Well, I mean maybe static helper methods like Math.abs() and junk, but never integrate it into your game as a value the game relies on or anything.

It's often misused but I wouldn't say "never". It's a powerful feature in a language, but the keyword seems to get tossed around for the wrong reasons.

At 1/21/13 01:53 AM, MintPaw wrote: It looks all good from here, but here's a few tips.

"public static var"
Never, never use static.

Bit of a bold statement.

At 1/18/13 12:38 PM, MSGhero wrote: I have Dota 2 to keep me company...*sob*

At 1/18/13 04:28 PM, Glaiel-Gamer wrote: dota 2's so good tho

No shame, DotA 2 is brilliant. On a 7 winning streak in a 5 man public.

At 1/17/13 11:13 PM, MSGhero wrote:

At 1/17/13 10:39 PM, egg82 wrote: i've done shit like that before. You can do a hell of a lot when you have no distractions and no life :P

College has made me realize that you can get a lot done in 5 minutes. And there are so many 5 minuteses in a day, it's unbelievable! Instead of sleeping till like 3pm, I wake up early(ish) to get hw done, and I'm free for the rest of the day. I'm getting more coding done for this game than when I was at home for xmas break

No life helps too

I'm running off such little sleep right now and it's taking its toll. For some reason when night rolls around I'm wide awake and motivated to do things so I just stay up.

At 1/14/13 10:09 PM, Veranan wrote: Hey, I'm having trouble removing a movieclip using removeChild(this); and I cannot figure out why.

I have the MainMenu movieclip which then loads LevelOne when you click Start and then removes MainMenu but it seems to give me this error: ArgumentError: Error #2025: The supplied DisplayObject must be a child of the caller.

Yeah. Because what you're essentially saying is:

this.removeChild(this);

How can a class remove itself? It can't be it's own parent and it can't have itself as a child.

I have tried parent.removeChild(this) but then it gives me the error TypeError: Error #1009: Cannot access a property or method of a null object reference.
which I know means that "parent" is null, but im not exactly sure how to initialize "parent"

I often get this when I forget to stop the code that triggers the remove (such as forgetting to remove it from an array that's being looped through), essentially, it's trying to remove it twice. But yeah, in your code it would seem that parent is null.

addChild(_levelOne);
removeChild(this);

I'm curious as to these two lines. You're adding a new child to the class, your _levelOne, and then trying to remove the class (I gather from the fact you've tried parent.removeChild). _levelOne will never see the light of day because it's parent will be removed when that second line is fixed.

At 1/10/13 12:35 PM, pirateplatypus wrote:

At 1/10/13 10:17 AM, Sam wrote: but I've been thinking about getting a PS3 for a while now so I may just get one and buy the remastered.

I've heard a lot of people have problems with the DRM on the download versions you can buy of older games. Personally, I'd stick with a PS2. In some areas you can get one of the slim ones with a couple controllers and a memory card or two for < $50 at pawn shops.

I was planning on buying the physical copy for around £25 - but yeah, a PS2 might be the way to go considering the next gen consoles are being released soon and I'm not a massive console gamer anyway. However, a friend's offered me a PS3 with like 20 games and 2 controllers for 170 EUR so that's quite tempting.

We'll see :)

At 1/9/13 04:57 PM, Innermike wrote: Also, my favourite soundtrack, what a unique blend of quirky electronic and orchestral music (the latter is more predominant after the first game): http://www.youtube.com/watch?v=VjGxXK_ltcs

Oh god yes. I still have the first 4 games. I'm really tempted to buy a PS2 just to play them, but I've been thinking about getting a PS3 for a while now so I may just get one and buy the remastered.

Nostalgia everywhere :(

At 1/6/13 06:54 PM, jdproductions321 wrote: I got this error..

ReferenceError: Error #1069: Property play not found on flash.media.SoundChannel and there is no default value.

when I ran ..

MovieClip(root).creditSoundChannel.play();

..within a movieClip.

In an earlier frame in my game, I have the following..

var creditSound:Sound = new creditTheme();
var creditSoundChannel:SoundChannel = new SoundChannel();
creditSoundChannel = creditSound.play();

Can someone tell me if I'm doing something wrong? I'm following the directions laid out by the Republic of Code, and I'm still getting issues, and I haven't found any solutions elsewhere on the web..

Thanks

Besides the fact that MovieClip(root) is an extremely hacky way of accessing the top level (such as _root in AS2), the SoundChannel class literally has no method of "play()". If you're just trying to play the music you need to run a line similar to this one again:

creditSoundChannel = creditSound.play();

At 1/6/13 05:26 PM, Innermike wrote: Yeah so I guess I'm just going to turn this thread into my personal bitching thread.

Sounds like a really weird/interesting problem. Did you rewrite it entirely using Starling before realising the same thing was happening, or just use its input methods? By the way you've described it, it seems like the only thing that could cause lag is the way input is handled. Have you stripped it all down and implemented things one at a time regarding your input code?

I'm not the best at using libraries either. I tend feel a little bit like a cheater or shortcut taker and I feel like libraries such as Flixel and FlashPunk take a lot of the fun out of programming a game. While I know I don't have to use all of the code supplied by the library (such as a camera system or something), it's almost a case of: "I've used most of the engine so why not just use this as well".

I've got back to using haXe after a massive break, I'm back at uni tomorrow and it's taken me the entire Christmas period to get back into the swing of programming for fun :(

De-compile it. Sothink is a popular piece of software.

Not as much of a problem or story, but still annoying:

I just spent 10 minutes trying to figure out a bug when I'd changed a variable name in a for loop and forgot to change it inside the loop itself.

De-compile the SWF

At 12/19/12 01:35 PM, Phable wrote: DUDE. This works perfectly. I was having the same problem on a new high-end computer. I used zero filters, zero bitmaps, and had a small file size. The V-Cam you suggested works perfectly!

Check the dates on threads before you post.

At 12/18/12 08:13 AM, neonpaint wrote: Trying to get the scaling to work in a game I'm working on. The movement for it is here, and it'd be awesome if somebody could teach me how do it. What I'm looking for is described below; when you move to the bottom the sprite becomes larger and smaller as it moves upwards. Thanks in advance!

Relate its y position to its _xscale and _yscale properties. To help you even more, remember that the y scale in Flash starts from 0 at the top and gets larger the more you go down.

At 12/13/12 12:00 PM, egg82 wrote: you exporting from a 7-year-old program on a 6-year-old laptop using a 10-year-old OS.

well, there you have it.

Considering they're all that old, I can't imagine it being a problem.

It's like saying if I boot up Win95 and try and play Diablo and it doesn't run, it's the OS's problem. At any rate Diablo would actually run with less errors than attempting to run it on Windows 7 (which is a pain with my graphics card, apparently).

At 12/14/12 02:20 AM, Krazzygamer3y2 wrote: I always use swf files, what I mean is how to stop Flash from crashing everytime I try to export a swf file.

We need more information to help you. Is it any ActionScript at all? Even a "stop()"?

At 12/13/12 11:32 AM, TheHiddenBlade wrote: Alright, so wait. (Pardon, I'm totally new) As far as I now know you can define stage width with stage.stageWidth and stage.stageHeight, but what about the size in properties? Do they change each other, change the program??? I'm totally lost haha all I want is for the "walls" of my program to be slightly short of the edges of the window.

Perhaps the attached picture will help you understand them. As far you need to know currently, the properties are read only. Let's say I have my document set to 550x400 in the properties panel of Flash, this code won't change anything and will output 550:

stage.stageWidth = 100; // this line didn't actually change anything
trace(stage.stageWidth);

In the picture, the two blue boxes are drawn on the stage. The red outlined box is the stage.width and stage.height values. You can think of it as drawing a box to enclose everything on the stage, and then getting the height and width of that drawn box. The black outlined box is the stage.stageHeight and stage.stageWidth.

So to set up a "wall" that's slightly shorter than the edges of the stage, you wouldn't use stage.width because that can change depending on what's on the stage. Instead you'd use stage.stageWidth - x, where x is where you want the wall to be.

Also, another little question, what do you guys suggest for coding walls? Thus far, I've used a code that turns their directional speed to 0 when they hit a coordinate, and moves their coords back by 1, but this makes it look slightly spastic. When I tried the same without moving them back 1, they sorta slowly pushed their way through the wall anyways.

Rather than resolving the collision once it's happened, you can stop it from ever happening by disabling movement to the left or right if there is a wall ahead of whatever you're testing the collision with.

At 12/13/12 05:10 AM, Krazzygamer3y2 wrote: I hate this

Everytime I try to export my movie with actionscript in it, Flash 8 crashes... when I remove the actionscript... it works perfectly. I run a Windows XP, at least 6 years old and I wan't to know how to fix it.

So the Actionscript is the problem - what do you mean you want to know how to fix it?

At 12/12/12 11:17 AM, egg82 wrote: stage.stageWidth and stage.stageHeight, not stage.width and stage.height

here's a ball with a fun little bounce function in it. It's not efficient, per-say, but I didn't really care.
http://pastebin.com/ak2fyeiT
three guesses as to what it was used in.

As some extra information, stage.width and stage.height gets the bounding box width and height of the children of the stage.

At 10/5/12 04:19 PM, milchreis wrote: Another rushed "tutorial", incomplete, uneditable, barely formatted...

The world was begging for this.

Why not link to existing things that explain it better?

Content isn't bad by any means, however, I agree that maybe a forum isn't the best place to do this. It'd be great to see you set up your own blog/website to do these.

Oh, sorry. Don't mind the "550-EnemyArray[i].width" in the if statement, it was just variables for my development area. Change that to whatever you need.

I played with your code and edited it slightly, I'm not sure what you're accomplishing with your nested for loop (the one using y as it's variable). Your problem goes away when you take your DirectionSwitch call out of your for loop and put it just in the function. I assume alienmove is your loop so it'll work how you want it. Take what you wan't from this code, you can achieve the same with direction as a boolean if you wish (I've used an int), but this saves a couple of if statements:

public function alienmove(e:Event):void
{
	for (var i:int = 0; i < EnemyArray.length; i++)
	{
		EnemyArray[i].x += 2*direction;
		DirectionSwitch();
	}
	
}

public function DirectionSwitch():void
{
	for (var i:int = 0; i < EnemyArray.length ; i++)
	{
		if (EnemyArray[i].x <= 0)
		{
			direction = 1;
		}
		else if (EnemyArray[i].x >= 550-EnemyArray[i].width)
		{
			direction = -1;
		}
	}
}

For future reference, you can use code tags to enclose your code.