At 10/30/06 02:02 PM, Claxor wrote: Thanks!
Yeah I've noticed that too. I worked for ages to fix it, but it fucked up seriously (can't really understand why), but I'll make sure I'll fix it for the sequel :)

No problem :). It's nothing major that will affect gameplay or anything, i'll add it to my favs, its really addictive. Just a few suggestions for the sequal :-

[#]-If you can find a server, add somwhere that people can add others code and play them, like 'n'.
[#]-Add a charachter editor, so people can add abit more custoisation :O.

Just a few suggestsions, its still great :).

Could somone help me :D.

I'm making my new game, and i've been workin on it for about a day or 2 now, but there's a strange glitch. When you shoot a singlular bullet at an enemy, it hits, kills it, yay :D. But if you fire a stream of bullets at one enemy it bypasses it an hits nothing :(. Anyone know why?

Here's the game :D.

At 10/30/06 02:12 PM, Mogly wrote: Cool game claxor. I feel a little like i'm over gratifying you saying that as it was so simple and the levels were so disordered. But it was fun and kept me distracted for a while, so thanks.

You're very welcome, and thanks to you too :)

At 10/30/06 02:30 PM, Deathredation wrote: No problem :). It's nothing major that will affect gameplay or anything, i'll add it to my favs, its really addictive. Just a few suggestions for the sequal :-

Wow, thanks alot man :)

[#]-If you can find a server, add somwhere that people can add others code and play them, like 'n'.

I have though about that, and I might make it. The only thing is that the server probably would get quite a bit of data, meaning more expensive for me :P, also, all the spam that probably would come in..

[#]-Add a charachter editor, so people can add abit more custoisation :O.

You mean like the ball?

Could somone help me :D.

I'm making my new game, and i've been workin on it for about a day or 2 now, but there's a strange glitch. When you shoot a singlular bullet at an enemy, it hits, kills it, yay :D. But if you fire a stream of bullets at one enemy it bypasses it an hits nothing :(. Anyone know why?

Here's the game :D.

Could you post the code? I'll try to help :D

At 10/30/06 02:30 PM, Deathredation wrote: I'm making my new game, and i've been workin on it for about a day or 2 now, but there's a strange glitch. When you shoot a singlular bullet at an enemy, it hits, kills it, yay :D. But if you fire a stream of bullets at one enemy it bypasses it an hits nothing :(. Anyone know why?

It seems to be only hitTesting the very last bullet you fire, so I'd check the code. Do the bullets check themselves or does one master code check them all? Either way is prone to error, but I prefer the all-in-one-place approach :)

Tom~

At 10/30/06 01:18 PM, Claxor wrote: I actually spent more than a day on a game :O :D

Four'vnd. Man the Under Judgement section moves slowly...
Some of the levels were exceptionally challenging (Rainy Days was a nightmare). Others were a bit too easy thanks to unlimited paint - maybe you can make it so you only have a limited amount of paint in future games?

Well done. Should do well actually - a nice quick minigame that deserves every bit of good press it receives.

At 10/30/06 02:04 PM, KaynSlamdyke wrote: That lets it down so much unfortunately.

oops...

They're exceptionally cool (and I'm guessing take a hellishly long time to drag through, I'm guessing, mentalray), but I'm none too keen on the camera angle and lack of scenary.

Well, that's not the camera angle being used, I just put it there so you could see the stuff. however, I did think it was kind of a cool camera angle for that part, in which the red car is spinning in a circle around the grey car.... so if you don't like that you probably won't like my other camera angles as I'm starting to be disappointed with them myself. The lack of proper background pisses me off to no end as well. However there's not really much I can do about that short of creating an entire city. Perhaps I could put some randomly sized cubes all over the place, so you at least have some reference.. and apply some gay grey shader to them or something. I guess seeing something moving is better than nothing.

ERG I ALREADY RENDERED 500 FRAMES OF THE ANIMATION IT TOOK ALL NIGHT RAWR NOW I MUST RESTART RAWR

The composition seems a bit off - the focus is ambiguious because the car in the foreground (which has the focus) is chopped, and the car in the background has too much of the rest of the screen. And with the lack of background, we can't appreciate flying asphalt and city lighting adding to the effect.

There's no focus, that's motion blur. I didn't want to include depth of field for a number of reasons:
1: I didn't mean for this to be a completely perfect animation anyways... like I said it's something of a test animation... and DOF adds to the already long render time. I've had to cut down quality of everything already. Adding DOF would make no sense.

The model is excellent and the burning rubber effect is fantastic (both are better than I can do), but it just needs that little extra touch for me to have a stroke from seeing something so awesome.

kaykaykaykay i'll add some random-ass cubes everywhere so you can see some movement.

THX FOR THE REVIEW :)

At 10/30/06 02:52 PM, orb wrote: kaykaykaykay i'll add some random-ass cubes everywhere so you can see some movement.
THX FOR THE REVIEW :)

Lol... No problem. It's miles better than what I'm doing at the moment.
Was only crit for future pieces. I know this is only an unfinished and roughcut version of what you can do - I'm hoping to eventually (give a year or so) to see something that wouldn't look out of place on a Project Gotham game out of you.

For god's sake, don't stop rendering because of me... I'll be killed by the CPU-Cycle Conservation Society... ;_;

At 10/30/06 02:51 PM, The-Super-Flash-Bros wrote: It seems to be only hitTesting the very last bullet you fire, so I'd check the code. Do the bullets check themselves or does one master code check them all? Either way is prone to error, but I prefer the all-in-one-place approach :)

Of course, why didn't i think of that :(. Is there anyway to check all the movieclips called _root["shell"+#]. without using a for Loop? I'd rather not have the lag.

At 10/30/06 02:57 PM, Deathredation wrote: Of course, why didn't i think of that :(. Is there anyway to check all the movieclips called _root["shell"+#]. without using a for Loop? I'd rather not have the lag.

No idea if Flash's OOP supports this, but couldn't you script "Whenever a member of the [bullet] class hits a member of the [enemy] class..." into it somehow?

At 10/30/06 02:57 PM, Deathredation wrote:

At 10/30/06 02:51 PM, The-Super-Flash-Bros wrote: It seems to be only hitTesting the very last bullet you fire, so I'd check the code. Do the bullets check themselves or does one master code check them all? Either way is prone to error, but I prefer the all-in-one-place approach :)

Of course, why didn't i think of that :(. Is there anyway to check all the movieclips called _root["shell"+#]. without using a for Loop? I'd rather not have the lag.

It's not the for loop that lags. The loop itself is relatively light - check condition, perform change, #code, rinse and repeat. The great big hitTests or other bits of code people shove in them - they lag.

If you're hitTesting against lots of movie clips it's going to lag, whether the tests are in a loop or not. If you wanted to be adventurous, you may save processor power by doing it with bitmap data instead of shape flag. Mathematical collision detection, too, should be much faster.

At 10/30/06 01:18 PM, Claxor wrote: w00t
I actually spent more than a day on a game :O :D

pretty fun actually, great engine, it kept me hooked for a while but then i started to lose intrest (but voted 5 anyway)

There were a few problems with it that i could see.

The main problem is that the levels were all too repetitive. I dont really think level design comes into play here, but just the nature of the game makes it so all you really have to do is funnel the ball into the goal. I beat nearly every level (well i stopped after a while, it was getting boring) in one or 2 tries due to the nature of the game. There wasn't too much variety, a few of the levels seemed the same even.

Another problem is the graphics. Yes, they are very clean and fit the game, but after playing for a while they start to seem bland. There's a number of ways you could fix this. Adding a motion trail to the ball would be a great help. Perhaps adding a particle effect or something when you get into the goal. And changing the background every few levels. You'd be suprised how much that helps. With no end in sight, and no apparent goal or reward for beating the levels, I kinda quit. It needs some sort of a goal. It didnt keep track of my deaths, my time, my resets, the current level #, or anything. It just seemed like an engine. Not sure if it told you that at the end, but it helps to know.

Adding perhaps different color balls and different color holes could help vary it up too, maby even coins or keys to collect before reaching the goal. It would help keep the levels fresh so it's not just "Funnel the ball into the goal".

Don't let these comments make it seem like it's a bad game or anything, i still voted 5. It was an excelent game and hooked me for a while. Just I'm very picky when it comes to this stuff. I hate seeing a great concept under-developed. So my suggestion: Make a sequal. Good stuff though, it will probably fair well in the portal.

At 10/30/06 02:51 PM, KaynSlamdyke wrote: Four'vnd. Man the Under Judgement section moves slowly...

Thanks :)
Yeah, it's slow. I remember in the good old days when you could submit a game, do something else for an hour, and then it was through.

Some of the levels were exceptionally challenging (Rainy Days was a nightmare). Others were a bit too easy thanks to unlimited paint - maybe you can make it so you only have a limited amount of paint in future games?

Yeah, I'll probably make it like that in the next game :)

Well done. Should do well actually - a nice quick minigame that deserves every bit of good press it receives.

Thanks again :)

At 10/30/06 03:05 PM, The-Frosties-Kid wrote: If you're hitTesting against lots of movie clips it's going to lag, whether the tests are in a loop or not. If you wanted to be adventurous, you may save processor power by doing it with bitmap data instead of shape flag. Mathematical collision detection, too, should be much faster.

Good ideas. By mathematical CD i'm guessing you mean:-

if(_root["shell"]+i._x==_root["enemy"+i]._ x){
//Die >:D.
}

Or do you mean somthing else?

I don't have enough knowledge of BitmapData to do it with that, if somone could teach me, i'd be glad :) Or link to a good BD tut, it's hard to find any good ones, i've googled, but i can't find any good ones :(.

At 10/30/06 03:07 PM, Glaiel-Gamer wrote: pretty fun actually, great engine, it kept me hooked for a while but then i started to lose intrest (but voted 5 anyway)

Heh, thanks :).
I didn't really expect people to play through the whole game. My record is like 22 minutes, and I've played the game quite a few times :)

The main problem is that the levels were all too repetitive. I dont really think level design comes into play here, but just the nature of the game makes it so all you really have to do is funnel the ball into the goal. I beat nearly every level (well i stopped after a while, it was getting boring) in one or 2 tries due to the nature of the game. There wasn't too much variety, a few of the levels seemed the same even.

Yeah, I'll add more stuff in the sequel, so it doesn't get so repetive.

Another problem is the graphics. Yes, they are very clean and fit the game, but after playing for a while they start to seem bland. There's a number of ways you could fix this. Adding a motion trail to the ball would be a great help. Perhaps adding a particle effect or something when you get into the goal. And changing the background every few levels. You'd be suprised how much that helps. With no end in sight, and no apparent goal or reward for beating the levels, I kinda quit. It needs some sort of a goal. It didnt keep track of my deaths, my time, my resets, the current level #, or anything. It just seemed like an engine. Not sure if it told you that at the end, but it helps to know.

Thanks alot, I'll keep that in mind. Graphics isn't really my main area, so..
And it does tell you the time at the end :P, after 126 levels

Adding perhaps different color balls and different color holes could help vary it up too, maby even coins or keys to collect before reaching the goal. It would help keep the levels fresh so it's not just "Funnel the ball into the goal".

Once again, thanks alot for the tips

Don't let these comments make it seem like it's a bad game or anything, i still voted 5. It was an excelent game and hooked me for a while. Just I'm very picky when it comes to this stuff. I hate seeing a great concept under-developed. So my suggestion: Make a sequal. Good stuff though, it will probably fair well in the portal.

I'll definately make a sequel, with your comments in mind. And I in no way take your comments offensive or anything, after all, someone saying "AMAZING GAME!!!1111" wont really help me develop :D (though that kind of reviews are also kinda nice :P)

Thanks for all the help, and thanks for the 5 :)

At 10/30/06 03:10 PM, Deathredation wrote: Good ideas. By mathematical CD i'm guessing you mean:-

if(_root["shell"]+i._x==_root["enemy"+i]._ x){
//Die >:D.
}

Or do you mean somthing else?

That's a little basic. You need to use inequality comparisons (>, <), really. You can do rectangle on rectangle detection like:

obj = _root["enemy" + i];
if(_x < obj._x + 10 && _x > obj._x - 10 && _y < obj._y + 10 && _y > obj._y - 10){
blong;
}

Or circular detection:

obj = _root["enemy" + i];
if(((_x - obj._x) * (_x - obj._x) + (_y - obj._y) * (_y - obj._y)) < (#distance * #distance)){
blong;
}

That should be faster than shapeflags, as it's based around relatively simple mathematical functions.

At 10/30/06 03:10 PM, Deathredation wrote: Good ideas. By mathematical CD i'm guessing you mean:-

if(_root["shell"]+i._x==_root["enemy"+i]._ x){
//Die >:D.
}

Something like that. I'd go with something more like:

xd = _root["shell"+i]._x - _root["enemy"+i]._ x
yd = _root["shell"+i]._y - _root["enemy"+i]._ y
if(xd < 30 && xd > -30 && yd < 30 && yd > -30){
if( _root["shell"+i].hitTest(_root["enemy"+i], true)){
// Codez
}
}

Just extend or shrink the size of the quick range check to suit, I would imagine its faster :)

Tom~

At 10/30/06 03:19 PM, The-Super-Flash-Bros wrote: xd = _root["shell"+i]._x - _root["enemy"+i]._ x
yd = _root["shell"+i]._y - _root["enemy"+i]._ y

Yeah, having your differences saved to variables is probably faster too.

Incidentially, is there much difference in speed between saving multiple related variables to an array and to numbers?

At 10/30/06 03:16 PM, Claxor wrote: Thanks alot, I'll keep that in mind. Graphics isn't really my main area, so..

that shouldn't be a problem. Lots of people make due without great graphics. Particle effects can be godly in this area. Look at a bunch of JMTB's stuff, look at paths, look at many other games out there made by scripters.

Masking can also be cool too. You can do really neat effects with combinations of these 2 things.

At 10/30/06 03:19 PM, The-Super-Flash-Bros wrote:

At 10/30/06 03:10 PM, Deathredation wrote: Good ideas. By mathematical CD i'm guessing you mean:-

if(_root["shell"]+i._x==_root["enemy"+i]._ x){
//Die >:D.
}

Something like that. I'd go with something more like:

xd = _root["shell"+i]._x - _root["enemy"+i]._ x
yd = _root["shell"+i]._y - _root["enemy"+i]._ y
if(xd < 30 && xd > -30 && yd < 30 && yd > -30){
if( _root["shell"+i].hitTest(_root["enemy"+i], true)){
// Codez
}
}

Just extend or shrink the size of the quick range check to suit, I would imagine its faster :)

Tom~

I wonder... for my custom collision codes i usually do Math.abs(_x-tgt._x)<number same for Y

Is it faster to do it your way or is using ABS faster?

At 10/30/06 03:29 PM, Glaiel-Gamer wrote: I wonder... for my custom collision codes i usually do Math.abs(_x-tgt._x)<number same for Y

Is it faster to do it your way or is using ABS faster?

Or is squaring everything faster?

Crap Glaiel. Now that I checked your particle effects in paths it has gotten stuck to my brain, and I can't figure out another way to do it than to copy you >:(

Ah well, I guess I'll just have to wait until I forget how yours looked and come up with my own :)

Thanks SFB and The-Frosties-Kid :D. (Scary Name Btw :O).

This is the code, but i can't get it to work, am i right in putting dx, dy, dx2, dy2 in a onEnterFrame? So they check the distance constantly, not just when the for loop starts. I changed it to check for 2 types of enemy, but i'll change that to use in with thr for loop soon, its just a temp.

Sorry for all the questions, i haven't done flash for roughly 2 weeks, so i need to jog my memory :(.

onEnterFrame = function () {
xd = _root["shell"+i]._x-_root["Enemy1"+i]._x;
yd = _root["shell"+i]._y-_root["Enemy1"+i]._y;
xd2 = _root["shell"+i]._x-_root["Enemy2"+i]._x;
yd2 = _root["shell"+i]._y-_root["Enemy2"+i]._y;
};
for (i=0; i<50; i++) {
if (xd<30 && xd>-30 && yd<30 && yd>-30) {
if (_root["shell"+i].hitTest(_root["Enemy"+i] , true)) {
trace("hit1");
}
}

if (xd2<30 && xd2>-30 && yd2<30 && yd2>-30) {
if (_root["shell"+i].hitTest(_root["Enemy2"+i ], true)) {
trace("hit2");
}
}
}

If you can help, it'd be great :).

68 pages? This is getting pretty ridiculous, even though I've been gone for over a month and it went from page 1 to 7 within a day or so of being created.

Just dropping in :/

At 10/30/06 03:44 PM, Deathredation wrote: code

onEnterFrame = function () {
for (i=0; i<50; i++) {

xd = _root["shell"+i]._x-_root["Enemy1"+i]._x;
yd = _root["shell"+i]._y-_root["Enemy1"+i]._y;
xd2 = _root["shell"+i]._x-_root["Enemy2"+i]._x;
yd2 = _root["shell"+i]._y-_root["Enemy2"+i]._y;

if (xd<30 && xd>-30 && yd<30 && yd>-30) {
if (_root["shell"+i].hitTest(_root["Enemy"+i] , true)) {
trace("hit1");
}
}
if (xd2<30 && xd2>-30 && yd2<30 && yd2>-30) {
if (_root["shell"+i].hitTest(_root["Enemy2"+i ], true)) {
trace("hit2");
}

}

Maybe?
}
};

onEnterFrame = function () {
for (i=0; true; i++) {
if(!_root["shell"+i]){
break
}

xd = _root["shell"+i]._x-_root["Enemy1"+i]._x;
yd = _root["shell"+i]._y-_root["Enemy1"+i]._y;
xd2 = _root["shell"+i]._x-_root["Enemy2"+i]._x;
yd2 = _root["shell"+i]._y-_root["Enemy2"+i]._y;

if (xd<30 && xd>-30 && yd<30 && yd>-30) {
if (_root["shell"+i].hitTest(_root["Enemy"+i] , true)) {
trace("hit1");
}
}
if (xd2<30 && xd2>-30 && yd2<30 && yd2>-30) {
if (_root["shell"+i].hitTest(_root["Enemy2"+i ], true)) {
trace("hit2");
}

}

}
};

I fucked the last one up. Also, this wont lop more times than necessary

Hey everybody, today's my birthday. PM me for my paypal and send me some money

It's going towards my computer fund.... plz =D

It's not my birthday, but i also have paypal ;)

I was gonna get paypal, but then I read the bit about having to be 18+ and chickened out :)

At 10/30/06 03:32 PM, The-Frosties-Kid wrote:

At 10/30/06 03:29 PM, Glaiel-Gamer wrote: I wonder... for my custom collision codes i usually do Math.abs(_x-tgt._x)<number same for Y

Is it faster to do it your way or is using ABS faster?

Or is squaring everything faster?

Speed tests: (x1000 loop)

My method (basic 4 part box detection) - 1100ms

Squaring method - 640ms

Math.abs method - 1740ms

A clear winner for squaring then :)

This inspires me to do a comparative speed table for some of the basic blocks of actionscript, do you reckon it'd be useful?

Tom~

At 10/30/06 04:02 PM, The-Super-Flash-Bros wrote: This inspires me to do a comparative speed table for some of the basic blocks of actionscript, do you reckon it'd be useful?

Tom~

delta already did that but i cant be asses to find the link