I'd love to, but I've a paper due the very next day. Grad studies has really taken the wind out of my sails when it comes to making games. Mostly because I can't manage my time for shit.

Ah the good ol days. You can look at my GH commit history and see when I finished grad school lol.

I'll be on vacation and traveling unfortunately. I'm having fun using Heaps though, and I'd like to make something soon.

I feel so overwhelmingly happy having joined the recent Newgrounds egg jam. It's already so much fun to do game jams in general and work with a team of very talented individuals, and have full creative ownership over your work, and release it the next day to an audience of thousands, which is something I hadn't gotten in a while.

But there's also just such a beautiful feeling of a lasting, awesome, supportive community. Watching @Figburn and @Eli 's stream (https://www.twitch.tv/eiiart/videos) was just so awesome. I honestly expected they'd just cap it at like 2-3 minutes per game or something but they went for 10 (!!!!!!) hours total giving each game as much time as it needed and pointing out everything they love about it and overall being so positive and supportive and it was just wonderful.

It was also super cool seeing a lot of games have like cameos of famous NG characters, and that's one thing that made it all feel like such a cohesive and tight community.

Seeing our game be played on stream was super fulfilling, and it kind of makes me think about how awesome that'd be as a regular thing for game jams. Almost feels just as nice as any prize to see that. Although I can imagine it being very difficult as the number of entries grows.

I was speaking to a couple of people a short while ago and the topic of programming came up (they were not programmers but other creatives - artists, musicians, etc.) and their remarks on it had reflected a common viewpoint I'd encountered multiple times, and it was usually some sort of "programming sounds great, but I can't do it/don't know where/how to get started" which is understandable because, well it's intimidating as is every other new skill that people try to pick up.

I've been of the opinion that anyone can program - that if a dunce like me could then surely more talented people out there would be able to, too. Unfortunately, the intimidation factor is very real as most of y'all probably already know. There's a lot of things to learn before you can actually see the results of it pay off, and some people might take to it less easily than others for various reasons. In my limited time TAing a programming course for non-CS students, programming seemed to have instilled a sort of fear in students, where they'd take one look at the task at hand and go "that's too hard".

And it's understandable; I tried to learn how to draw sometime midway last year and I dropped it, tried to pick it up and dropped it again because of that. There were so many concepts I'd have to learn before I could actually get started drawing the good stuff, if the course I was using at the time (drawabox.com) were any indication I'd have to have drawn hundreds of boxes before I could even begin drawing my first portrait. And no, no amount of "well you can do both you know" could convince me to stray off the beaten path; I'd rather stop making progress entirely than try to stray away from the course, even if it would have helped me make strides in my ability to draw.

I've seen quite a few programming courses also fall into the same path of "start at the basics, then build your way up to the more advanced concepts" which utterly SUCKS when it comes to those who like instant gratification. I'm not going to make any generalizations here, but I'll just say what worked for me was NOT starting from a blinking cursor in a console printing out "hello world". That was mind-numbingly boring to me when I started out programming, and was the same story even when I had experience programming and was trying to learn a different programming language. To this day I haven't done more than simple console applications in C++ because I haven't gotten a need to do more. If I were put to the task I'd most likely be able to step up but the comfort zone is like a black hole; damn near impossible to escape for me.

Why do I say all this? Because (visual) game development was the thing that got me to take programming more seriously. It was effectively like drawing, but with text - seeing things move before my eyes based on what I typed was an allure that was hard for 10 y/o me to resist when I first got started. (I didn't know what I was doing for quite a while but that's a story for another day.) It presented a clear and achievable goal that was yet flexible as well - making a game that was as simple or complex as I could make it, but the end goal to have fun. Didn't matter if it was an objectively shitty tamagotchi game, if I had fun playing it then it was mission successful. That was in contrast to the only other endeavour I could have had at the time, drawing, where I subconsciously nitpicked at the final result if it wasn't just perfect, because a lifetime of using my eyes made it easy to pick apart the flaws (and no, the same could not be said for my brain LOL)

I'm still unsure whether the tool I used at the end of the day (Flash) mattered or not. Because I'm biased, I would say it absolutely made a huge difference, because I would have had to futz about with building and other things that were not the actual game development itself, or I would have not received a canvas-like feedback (and instead more banal text-based stuff), or I would have been too intimidated by the API (there's a reason I didn't try out AS3 until a few years later), or it was just a case of right place and the right time (I had been introduced to Phrogram, CeeBot, CeeBot-Teen and Alice much before that, when I was around 7 or so but none of it clicked at the time).

If you've made it all the way through this post, then you might be asking where this is all going. Consider this a lead to the next post, or an ode to Flash, both, or just a long rant.

To lead off from the previous post, I'd been thinking about how this reflects on newgrounds as well. While the site's slogan is "everything by everyone", a lot of people tend to pigeonhole themselves into certain defined positions - either they're a programmer, or they're an artist, or they're a musician. I don't have any data to back this up, but I'd wager that those who play more than 1 role are probably in the minority of users on this site, purely due to how difficult it is to switch gears and pick up a new skill and to do it consistently to the point where they're equally good in both.

It's a lot like being bi/multilingual; there's not much of a need to speak more than one language if you're getting by fine with just the one, so those who learn a new language probably do so because they have a specific goal in mind, be it to converse with others around them, or with the intent to eventually use it - very few do so for purely academic reasons.

Way I see it, it's because of the comfort zone - as long as the job gets done, you'll probably always expend the least amount of effort. This is a good thing! People collaborate because no one individual can do everything, and even if they can, not under the time constraints imposed, and/or not to an adequate enough degree. However, this does mean that things that could be accessible to others are locked away behind an invisible barrier of sorts - of one's own making. As a corollary to "if you don't use it you lose it", why would you learn it if you never use it? You'd just end up losing it eventually!

Combining the things from the previous post and this one, what if people who were used to fulfilling a certain role (programmer/artist/musician/etc.) were instead thrust upon another role, and had to collaborate with others to get up to speed? In the format of a game jam, this could be motivating enough to get people to finally start the ball rolling, as that's the hardest step. By giving people an ultimate goal (making a game), those who are weak in something - be it drawing, programming, animating, composing, etc. - can use this opportunity to see what kind of progress they can make - with the knowledge that everyone else is also in the same situation, it's less likely that people will care about what the end result will be, because at the end of the day what's important is that people tried out something new, and that'd be a bigger win than any prize, the way I see it.

Pardon the triple post; this was a lot of words to essentially say that I'm thinking of a game jam where "newbies" would be in charge.

TL;DR/Details:

Provisional name: "role swap" jam

Team/Solitary: Team (individual submissions not allowed, see notes)

Concept: Those who are X (artists/musicians/programmers/etc) should be in charge of Y (where X != Y)

Time frame: Obviously, nobody can be expected to learn anything worth a damn from scratch in a weekend, so I'm thinking this would be for a week, a fortnight or possibly even longer.

Notes: Collaboration would still be key here. Instead of each person doing what they're good at, though, the goal would be to get them to do what they're the worst at. This would involve - theoretically - a lot of collaboration amongst individuals in a team to effectively teach/mentor the others so that they can learn quicker than if they were left to their devices.

When: If this were ever done, I think a good time would be sometime when traffic to the site is high so that more people would get interested - I don't see this being too effective if it mainly involves users who have already participated in previous game jams as there'd already be some experience carried over from them. Not that they can't participate (indeed the opposite - see below) but I think it'd be best when traffic to the site is high.

As for how the roles would be picked out, I suppose it's best if it's on the honour system - someone says they're going to do X, they can do X as long as it's not blatantly obvious they're already mainly working with X. For those who are involved with everything, they're free to choose as they please (a suggestion would probably be doing something they have least done, e.g. more art if they've submitted more games than art, for example).

Obviously, this would be more demanding than previous game jams because of the complexity involved - it would effectively be up to the programmers (who are working on audio/art/etc.) to manage expectations, scope and all on behalf of those who are trying out programming, and vice versa. Setting expectations would be a huge hurdle to get through because nobody starting from scratch has a good enough idea of what's realistic in a given timeframe ("I want to make an MMORPG where do I start plz", anyone?), not to mention that mentoring in itself would be very time consuming in itself.

If this were picked up for serious consideration, then it'd probably be best to a) compile a list of resources for people to start out before the actual jam occurs (so that transitioning roles becomes smoother than just starting from scratch on the start date), and it'd probably require buy-in from the already experienced people in the art/animation/gamedev/programming forums who are interested in participating (because if the experienced users don't participate, it'll probably be a shitshow of the blind leading the blind.)

I'd love to hear your thoughts on this, it's been something I've thought of for the past couple days so there's likely to be lots of glaring holes in this plan. Reading it again, there's probably some stuff I've plain forgotten to include but I might remember it later. It's 2am and I'm probably in heavy need of shut-eye because this became way longer than it was ever intended to be, but I appreciate you if you've read through all this.

I really like the idea of an "out of your comfort zone jam," but programming is the hard part. I can be the worst artist or composer on earth and still export a valid PNG or OGG at the end of the day, whereas I'd be a little surprised if every non-Windows person could even install Haxe correctly within one week.

I'm not familiar enough to know what a "safe" option would be, like a guaranteed non fucked up game by the end of the jam. Maybe a "template" game or a few that everyone can swap roles and make assets for, and the brave souls who want to try programming can have at it? In Flixel with JS export? Not sure if it can be any more accessible than that (no Visual Studio, game works by default, maybe NGAPI thrown in that you can fiddle with, fantastic docs).

(I forgot to mention this earlier, but I decided to reply to MSGhero in a separate thread so as to not hijack this one.)

ok well make a flash game in 2021

Let's play a game: what does this Qt webassembly demo remind you of?

Any AS2 veterans still around? I need some help with a this little particle fountain I'm dabbling with. I followed this basic ball physics and particle fountain tutorial on YouTube and combined the two, but the particles generated from the fountain (i.e. mouse cursor) just keep bouncing higher and higher unlike the instances already onscreen which eventually stop bouncing.

Here's the raw .fla file. Can anyone tell me where I went wrong?

This doesn't completely solve it but you could move the incremental gravity to be above the y adjustment, like this:

doStuff = function() {
	//particle code
	this.ySpeed += gravity;
	this._x += this.xSpeed;
	this._y += this.ySpeed;

In your current code, you are increasing the Y speed after you've moved the object, so when the object reaches the bottom of the screen, it's speed is already 1 faster than what it took to get there. When it reverses it now has a little more speed going up, making it go a little higher each time. This change doesn't totally fix that though, curious if someone else has an exact solution.

If you want objects bouncing less high each time in general, you could multiply the y speed by -0.9 or whatever each time it bounces, too.

Holy Jesus, thanks Tom. I'm gonna' try this when I get back home to my computer.

Best first post to a long-running thread ever

I think it’s awesome. I think the reg lounge moved when Tom wanted to sparce out the forums to dev and art?

Fractured into a million lounges

True. I’ve talked to him years later and there’s still a mutual respect I think.

I was an arrogant 16 year old - sorry for the years of being a knob :)

To be fair, that's how the Internet was back then wasn't it? Felt like part of the charm, even if it was just general assholery.

i forgive you Ninja-chicken

I can never remember username changes. The only ones I know off the top of my head in this forum are @4urentertainment -> @OmarShehata and @sasuke2910 -> @MintPaw.

I'm guilty as charged though, I went through like 5 of them in the past before it became automated.

Any AS2 veterans still around with some free time? I got lucky and found another old tutorial about shooting projectiles that had trigonometry code I could play around with. I created an enemy spawner that summons enemies on click (because I still haven't figured out how to make it go automatically without spawning more than 8 enemies onscreen) and attached a skull graphic over the red hitboxes being summoned, but instead of being right on top of them, they just lag a couple pixels behind them.

At one point, I had the code set up like this, which had the skull graphic following and covering the red hitbox completely. It was a movement function contained within a function that created the skull and hitbox onscreen.

	Enemy1.onEnterFrame = function() {
		if(Enemy1._x <= 600) {
		Enemy1._x += 10;
		Enemy1._y += (Math.sin((Enemy1._rotation)*(Math.PI/180))*10);
		Enemy1._rotation += 10;
		skullGraphic._x = Enemy1._x;
		skullGraphic._y = Enemy1._y;
		}else if(Enemy1._x >= 600) {
		Enemy1._x += Math.cos(Enemy1._rotation*(Math.PI/180))*20;
		Enemy1._y += Math.sin(Enemy1._rotation*(Math.PI/180))*20;
		Enemy1._rotation += 10;
		skullGraphic._x = Enemy1._x;
		skullGraphic._y = Enemy1._y;
		}

Then later, I thought, "Hey, if I set up this movement function outside of it, then I could reuse it for different enemies instead of typing the same chunk of code in every function that creates them." So I moved that code outside of that function, and now it looks like this.

function enemyMovementz() {
	if(this._x <= 600) {
		this._x += 10;
		this._y += (Math.sin((this._rotation)*(Math.PI/180))*10);
		this._rotation += 10;
		}
		else if(this._x >= 600) {
		this._x += Math.cos(this._rotation*(Math.PI/180))*20;
		this._y += Math.sin(this._rotation*(Math.PI/180))*20;
		this._rotation += 10;
		}
}

The code that creates and attaches the skull on top of the hitbox now looks like this in the create function.

	Enemy1.onEnterFrame = enemyMovementz;
	skullGraphic.onEnterFrame = function() {
		skullGraphic._x = Enemy1._x;
		skullGraphic._y = Enemy1._y;
	}

Originally, it looked like this, but that would make the skull spin while moving.

	Enemy1.onEnterFrame = enemyMovementz;
	skullGraphic.onEnterFrame = enemyMovementz;

Below are the raw fla files. 3.2.1 is where the skull graphic covers the hitbox completely, and 3.2.2 is where the skull graphic lags behind the hitbox. Could anyone tell me where I went wrong?

3.2.1

3.2.2

(P.S. Requires Flash 8 or higher to open.)

My guess is this comes down to which order the movieclips are running their functions. So the skullgraphic is running its function first instead of second, resulting in it matching the hitbox X and Y BEFORE the hitbox moves, resulting in it always lagging a frame behind.

To avoid worrying about the order the functions run, I instead removed the function completely from the skullGraphic and replaced it with:

Enemy1.skullGraphic = skullGraphic;

Now the enemy can refer to it's art, rather than the two acting independently. In the enemyMovementz function I added:

this.skullGraphic._x = this._x;

this.skullGraphic._y = this._y;

This makes sure the X and Y of the graphic gets set after the hitbox has moved.

Full code:

function spawnEnemy1() {
	var Enemy1 = _root.attachMovie("skullhitbox", "Enemy"+NuNum, enemyonedepth);
	Enemy1._x = this.createdSpawner._x;
	Enemy1._y = this.createdSpawner._y;
	Enemy1._width = 65;
	Enemy1._height = 65;
	Enemy1._rotation = _root.createdSpawner._rotation;
	
	var skullGraphic = _root.attachMovie("skulltemp", "skulltemp"+NuNum, skullgraphicdepth);
	skullGraphic._width = 75;
	skullGraphic._height = 75;
	skullGraphic._alpha = 60;
	
	Enemy1.onEnterFrame = enemyMovementz;
	Enemy1.skullGraphic = skullGraphic;
	
	NuNum++;
	enemyonedepth++;
	skullgraphicdepth++;
	enemiesOnscreen++;
	trace(enemyonedepth);
	trace(skullgraphicdepth);
}


//makes enemy move in a sinewave then eventually a circle
function enemyMovementz() {
	if(this._x <= 600) {
		this._x += 10;
		this._y += (Math.sin((this._rotation)*(Math.PI/180))*10);
		this._rotation += 10;
		}
		else if(this._x >= 600) {
		this._x += Math.cos(this._rotation*(Math.PI/180))*20;
		this._y += Math.sin(this._rotation*(Math.PI/180))*20;
		this._rotation += 10;
		}
		this.skullGraphic._x = this._x;
		this.skullGraphic._y = this._y;
}

Like @TomFulp said, it's probably due to order of execution - since they're running in two different onEnterFrames, it's possible that the skull graphic lags because it updates its position before the Enemy1 clip does, thereby referring to the last known position rather than the current position.

I don't have a copy of flash with me right now to examine the FLAs, but I would hazard that shifting them into one single onEnterFrame and looping through all the clips would get rid of this problem as well. For example, have one loop/stage where you only update the enemy movieclip(s), and then another where you update the graphic - all within the same onEnterFrame. This way, you can clearly control the order of operations based on how you define the central onEnterFrame function. Alternatively, you can combine them into one loop as it's technically more efficient, although there are arguments to be made for it being either way.

Something like this:

function moveEnemy(enemy:MovieClip):Void {
	if(enemy._x <= 600) {
		enemy._x += 10;
		enemy._y += (Math.sin((enemy._rotation)*(Math.PI/180))*10);
	}
	else {
		enemy._x += Math.cos(enemy._rotation*(Math.PI/180))*20;
		enemy._y += Math.sin(enemy._rotation*(Math.PI/180))*20;
	}
	enemy._rotation += 10;
}

function updateSkullGraphics(skg:MovieClip, enemy:MovieClip):Void {
	skg._x = enemy._x;
	skg._y = enemy._y;
}

// main frame script
var allEnemies:Array = [];
var allSkullGraphics:Array = [];
onEnterFrame = function() {
	// update enemy positions, then skull graphics for that enemy
	// assumes that allSkullGraphics.length === allEnemies.length
	// and that the skullGraphics[i] matches with allEnemies[i]
	for(var i:Number = 0; i < allEnemies.length; ++i) {
		moveEnemy(allEnemies[i]);
        updateSkullGraphics(allSkullGraphics[i], allEnemies[i]);
	}
}

And of course, to accommodate the "spawn enemy" function, you'd have to add it to the array when creating an enemy:

function spawnEnemy1(allEnemies:Array, skullGraphics:Array):Void {
	var Enemy1:MovieClip = _root.attachMovie("skullhitbox", "Enemy"+NuNum, enemyonedepth);
	Enemy1._x = this.createdSpawner._x;
	Enemy1._y = this.createdSpawner._y;
	Enemy1._width = 65;
	Enemy1._height = 65;
	Enemy1._rotation = _root.createdSpawner._rotation;
	
	var skullGraphic:MovieClip = _root.attachMovie("skulltemp", "skulltemp"+NuNum, skullgraphicdepth);
	skullGraphic._width = 75;
	skullGraphic._height = 75;
	skullGraphic._alpha = 60;
	
	allEnemies.push(Enemy1);
	skullGraphics.push(skullGraphic);
	
	NuNum++;
	enemyonedepth++;
	skullgraphicdepth++;
	enemiesOnscreen++;
	trace(enemyonedepth);
	trace(skullgraphicdepth);
}
// and call...
spawnEnemy1(allEnemies, allSkullGraphics)

A few minor things worth pointing out about the code:

• You don't need two different depth trackers (enemyonedepth and skullgraphicdepth). You could, for example, just add 10,000 to the 'enemyonedepth' to get the skullgraphicdepth for that Enemy1 instance. (Adjust the constant as necessary, but I doubt you're going to have 10,000 enemy units on screen simultaneously, so it seems like a good place to start)
• Initializing properties is ideally done by using classes. Create a class for "Enemy1" (with a preferably more readable name) and set the properties such as _width, _height, _alpha, etc. in its constructor. That way, the initialization function can be more compact, especially if the properties don't affect much outside the scope of the class. The same goes for the skull graphics as well.
• Pass parameters more often, even if they're already known. Personally, I find it's best to pass them explicitly than implicitly, so that you don't have to chase implicit references. The likelihood of side effects occurring decreases when you know that a function operates only on the things passed to it, rather than a combination of things in its environment (this, _root, etc.).
• If you're using arrays to keep track of enemies (like above) then you can get rid of the "enemiesOnscreen" variable - since allEnemies contains all the enemies on screen, allEnemies.length returns how many there are at a given time! The only downside is that you need to update the array to remove all the dead enemies as well - so wherever you use removeMovieClip(), you also have to call allEnemies.splice() and use the index of the enemy to remove it from the array. Since AS2 has no proper Array.indexOf() method, you'll have to loop through the array yourself, but this is more or less boilerplate - you might find there's a negligible performance impact even with the added overhead of keeping track of it yourself.
• Having a single enterFrame may even speed it up compared to if there are dozens of them in the file! If you're targeting Ruffle, though, I'm not sure whether this point applies as much; it likely makes a bigger difference if you're targeting the actual Flash Player.

I'm a little confused by this, but does that mean I could apply the same logic to a player character or anything else that moves onscreen?

Okay, I'm definitely confused by this. I still haven't figured out how classes or for loops work yet, but I bet it'll make life much easier once I do.

Other programmers will hate hearing this but I don't actually use classes. I do use a lot of arrays and for loops, though.

Think of an array as a list if items. You start by creating the list and specifying the max number of items, so it could be:

aEnemies = new Array(20);

or you could do this:

nMaxEnemies = 20;
aEnemies = new Array(nMaxEnemies);

I like to put a character at the start of my variables to specify what sort of variable it us, like an array, number, string, object, movieclip, etc... Makes it easier to know what my code is referring to later.

When you create a new enemy movieclip, you can add that movieclip to the array like this:

aEnemies.push(mEnemy);

Then if you want something like the player's bullet to check all of the enemies:

for (var n=0; n<aEnemies.length; n++){
	var mEnemy = aEnemies[n];
	// Do your collision check with the enemy here.
}

If your enemy array length is 3, it would end up checking these slots:

aEnemies[0]

aEnemies[1]

aEnemies[2]

That's why you cap the loop at < aEnemies.length and not <= aEnemies.length, because you're including zero in there, so three spaces goes from 0-2.

For removing things from an array, you could make a function like this:

function f_Pop(mClip, aArray){
	for (var n in aArray){
		if (aArray[n] == mClip){
			aArray.splice(n,1);
			return;
		}
	}
}

So you could stuff like

f_Pop(mEnemy, aEnemies);

However you wouldn't want to do that inside the loop I wrote above, because you're changing the array as you're still moving through it. If you want to remove an enemy while inside a loop, you should run it in reverse:

for (var n=aEnemies.length-1; n>=0; n--){
	var mEnemy = aEnemies[n];
	// Do your collision check with the enemy here.
    // Removing enemy from the array here? Do this:
    aEnemies.splice(n, 1);  
}

This way, you're removing things from back to front... You can also ignore the f_Pop function here since you are already looking at a specific spot in the array here.

I hope I wrote all that correctly!

Old habits die hard, eh? :P But yeah, there's no requirement to using classes.

Personally, I use OOP because I find it's easier to reason about abstractions with it. One can argue, though, that I find it easier with OOP because I'm used to it, and they'd be entirely correct. @Nabella: Apart from OOP, there's also procedural programming (which is more what Tom is talking about here, I suppose) and also functional programming (but that's not supported by AS2, you'd have to look to AS3 or more....modern languages if you want to have any serious FP support)

Minor nitpick; it's correct but in the context of the tutorial, for those reading: you should not be initializing the array with a predetermined length and then push elements onto the end. That can go pear shaped very quickly, especially if you forget you initialized the array with a predetermined length:

var nMaxElements:Number = 20;
var array:Array = new Array(nMaxElements);

// do NOT do this!
array.push(createEnemy());

...as that means the first 20 elements will be undefined and the enemy will actually be located at position 21!

Also, the type system in AS2 infuriates me. I declare types for every variable and function (as a holdover from other languages) and instead of flagging compile time errors, it just results in more headaches due to silent type coercion which converts to undefined. And even in the rare instances where it shows an error (during runtime no less) it's nondescript and quite a big pain point. Nevertheless, I included it in the code sample above as it's a good habit to cultivate for those who plan to move away from AS2 in the future - it'll be less jarring of a change.

D'oh, stupid off by one errors. The enemy will be located at position 20.

Thanks for your help guys. I'm still trying to process your replies about arrays, for loops, and general proficiency in Flash. It still hasn't really clicked with me yet, but I managed to add actual graphics to the enemies and fixed the parallax scrolling, so I've made some progress at least.

I saw this recently that reminded me of your and @DiskCrash's post, apparently all done in shaders.