Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - zez

Pages: 1 [2] 3 4 ... 11
help / Re: Overlap and Animation?
« on: Wed, Jul 28, 2010 »
ack, yeah, I was editing my last post as you replied, check and see if that helps.

help / Re: Overlap and Animation?
« on: Wed, Jul 28, 2010 »
 addAnimation("dead", [7, 7, 3, 7, 7], 10, false)

You also may be having trouble because you testing for finished in the playstate, try sticking if(frame == 7 && finished){FlxG.state = new playstate();} in your player class, or possible if(frame == 7 && finished){dead = true;} in it, and if(player.dead = true){FlxG.state = new playstate();} in the playstate, if that first suggestion doesnt fix it.

chat / Re: Shmup lovers!
« on: Wed, Jul 28, 2010 »
Both ideas sound good, but you shouldnt make your procedures PURELY random. Stick in stuff to generate waves of enemys (possibly random types of enemys that have similar movement patterns but not necessarily the same shot patterns) in different formations, and then just trigger the different waves or origins of waves randomly, that way you get the best of both worlds.
One key thing that separates good shmups from so so ones is how enemys and shots end up being placed and moving. This is more obvious in the bullet hell variety, with shots often moving in ways that almost resemble a dance, and cause still shots to appear as abstract vaguely geometric art. A good example of what I mean, taken to an extreme would be this an example of doing it wrong, would be this

You want readable patterns, but I like the idea of the patterns being triggered randomly.

help / Re: Beat 'em Up collision checking
« on: Wed, Jul 28, 2010 »
Nothing is wrong with it being an object extending FlxObject, I was operating under the assumption that it was. It could EVEN just be public var hitbox:FlxObject; in the player class. These are all being made in the overrides of update that Im assuming are already being used (given that to do pretty much anything with flixel, you want to override the update and stick your code in there,) with the exception of the callback function.

The problem with using collide, first and foremost, is that collide will never be called. The reason for this, is 'manually' placing two objects ontop of eachother DOES trigger overlap, but collide is only called when the collision boxes enter the same area as a result of changes in there velocity or thrust. The other problem, is that if you magically got the hitbox to collide with the enemy, by say placing it on the player and then modifying its velocity to make it move where you wanted it to, calling collide will trigger the usual collision correction code, pushing the enemy and hitbox away from each other, and that will prevent things like combo's and throws from being feasible.

... also, there is no reason any of the code I posted would force him to call update himself, or call super.update (isnt that the same thing?)

help / Re: moving a tileMap and collide problems
« on: Wed, Jul 28, 2010 »
are you calling collide after refresh hulls? Also, does the player move useing velocity/acceleration/thrust, or are you manually altering there x & y coordinates?

help / Re: Beat 'em Up collision checking
« on: Wed, Jul 28, 2010 »
zyxstand has the right general idea, but probably your best bet for getting the sort of callback you want is
Code: [Select]
//in the player class
if(frame > something && frame < something else)//check to see what attack animation and or where in the animation the player is
hitbox.x = player.x - whatever + (double whatever * facing);
hitbox.y = player.y + or - whatever;
hitbox.height = whatever;
hitbox.width = whatever;
else if(frame > sometihng else && frame < something else)//samething for another attack or part of attack
setup the hitbox again
else if (etcetc)
else //when the player is not doing any attacks
hitbox.height = hitbox.width = hitbox.x = hitbox.y = 0//make the hitbox have no dimensions and stick it in the top left corner of the game world

// then in the playstates update
FlxU.overlap(hitbox, enemy group, attack function);
// then the attack function
public function attack function(hitbox:flxObject, enemy:probably flxsprite, or your enemy class):void
if (player.y > enemy.y - some offset && player.y < enemy.y + some offset)//make sure the player and enemy are near the same Y axis, seeing as beatemups basically use Y for the Z axis. You need to modify this slightly if you plan on having jump attacks. You could get away with just having a shadow sprite that represents where the player is on the z axis and testing against that, or using an int that represents the players z cordinate and testing against that or something
combo += 1;
//do whatever else you need to do when the player connects, including things like
if (player.frame > this && player.frame < that)
do the magic this particular attack just connected code

The key difference here, is you REALLY dont want to use collide, first off because overlap gives you a callback function, second, calling collide wont do anything but frustrate you if you are manually setting the x & y of the hitbox (you should be if you want it lined up with the player,) and third off, because calling collide with modify the velocity of the hitbox and the enemy you hit in ways you probably dont want. Not that knockback is bad, just that I imagine you want some control over it.

help / Re: help Scattered bullets/Shotgun
« on: Wed, Jul 28, 2010 »
okay, quiiick tutorial for you
Code: [Select]
var shotdirection:point;

shotdirection = Point.polar(speed, (angle in degrees) * 0.017453);
shotdirection = Point.polar(speed, angle in radians);
shot.velocity.x = shotdirection.x;
shot.velocity.y = shotdirection.y;
You can then either manually set the angle, or better yet, pass a function to it to determine where the shots should go randomly, and then just run the function multiple times in one event (5 is a perfectly good number, possibly even the best number, EVER,) for multiple shots.
something along the lines of
Code: [Select]
shotdirection = Point.polar(something + (FlxU.random() * something), ((-80 - (FlxU.random() * 20) + (facing * 180) ) * 0.017453);should do wonders for getting you some good angles.

Quick bit of explanation on what this code is doing.
First of, point.polar is creating a new point that is whatever distance you specify (as the speed) from (0,0), at the angle you pass it. This is useful, because velocity is also a point from (0,0) so the new point will be a valid velocity, in the direction you pass it. The reason in my second bit that I passed a random speed to it, is pretty straight forward. The shots will move at different randomly determined speeds. The angle bit is ever slightly more complicated, but not by a great deal. The first thing to realize, is that -90 is left, and 90 is right. The second thing to realize is that a flxsprites facing value is actually a uint, where LEFT = 0 and RIGHT = 1. So, we start at -90 for facing true left, then we add 180 * facing to that. 180 * 0 = 0 so the shot will be moving -90 + 0 = -90 if the sprite faces left. If its facing right, it will be moving -90 + (180) = 90. The reason I used -80 instead of -90 is so that when I subtract flxU.random()*20 I get a value between -80(being slightly upwards and to the left) and -100 (being slightly down and to the left) and then flip it if its facing right, getting a value between 80 and 100.
You then run that however many times you want bullets, and you get X amount of shots, all moving at slightly different speeds in slightly different directions, but in the general direction you are facing.
NOTE that this is assuming the player can only move left and right, and the angle code will have to be dealt with differently if that is not the case.

help / Re: Correct switching between states
« on: Wed, Jul 28, 2010 »
Dont worry about your embedded objects, they are all loaded into memory the second the game loads (thats the whole point of the preloader,) and kept in the cache. Your private variables for the state MAY come back to haunt you when it isnt garbage collected, but given that those are all just references to other things, and not the things themselves, I wouldnt worry about it, especially sense it will be garbage collected by the time its an issue. You only really have to worry about the garbage collector during render and update calls, and flixel has been optimized in such a way that its actually harder to get an object garbage collected then just not to call it till its needed, so thats kind of a moot point.

chat / Re: Shmup lovers!
« on: Wed, Jul 28, 2010 »
Variety is the spice of life. Throw in some enemys with different attack patterns, and some upgradable/tweakable player ships and Ill be pretty stoaked. After that, epic boss fights never hurt, especially if the force you to think and not just react.
My favorites of the genre are R-Type, Tyrian, and Ikuruga. Of these, Tyrian did the best job with player variance (the RPG element to ship design really helped that game. A lot.) Ikuruga pretty much won on enemy/boss variations (different movement patters? Check, Different shot sprays, Check, Requiring you to take advantage of different ship types for different situations.... half check.) an R-Type was kind of a happy medium between what was great about the two (Some degree of ship customization, and some degree of enemy variation, along with EPIC boss fights.)

help / Re: Many sprites performance
« on: Mon, Jul 26, 2010 »
okay... well shoot. Try making everything in one object instead of multiple objects extending flxsprite, then make all your animation calls simultaneously like so
Code: [Select]
if (velocity.x != 0 || velocity.y != 0)
Also, you can shave at least one object by making everything inside of the body sprite, and dropping the character class.
Just be sure to set up all your parts in the constructor of the body, basicly the same way you are now (sept, you know, legs=new flxsprite(x,y); legs.loadGraphic(legimg,size); legs.addAnimation(animation); etc etc etc.)

music wise - audacity, pxtone, musagi, buzz machines All awesome.

sound effects wise, the standard is pretty much - sfxr

I personally recommend going with audacity + sfxr for sound effects, that way you can further edit the sound effects afterwards.

I use a combination of sfxr, MaxMSP, protools, buzz machines, and fruity loops for my stuff, but you will note most of that isnt free, and has a fairly steep learning curve.

help / Re: Many sprites performance
« on: Mon, Jul 26, 2010 »
you should only add the body once, and you should get rid of the calls to angle. If you need everything to flip upsidedown, make a new set of frames thats the body upsidedown. Given that you are only using 180 degree rotation, there is no reason not to just double the frames and use facin to flip it on the x axis and animation to flip it on the y. The reason for this, is when flixel uses rotation, it has to use draw to render all the objects, and this considerably slows things down.

help / Re: Making scale.x/y work properly
« on: Sun, Jul 25, 2010 »
cool, just make sure to change your width and height as the sprite changes size. You also probably want to keep your origin and offset values the same to avoid some headache.

help / Re: do HTML elements effect flash performance?
« on: Sun, Jul 25, 2010 »
That depends, does running a bunch of applications at the same time affect other applications performance? ... the answer is yes. The more stuff you try to get a computer to do simultaneously, the more processing power and ram the computer is using, throw bandwidth into the calculation and you have a whole new can of worms.
I dont think there are strictly speaking guidelines, the elements to use are the ones that are the least system intensive, and ones that dont change the window's focus.

help / Re: Making scale.x/y work properly
« on: Sun, Jul 25, 2010 »
Yup, much easier. Wanna fight about it?  ::)
Your way is fine, but it gets a little tricky if your dealing with a sprite that is changing size over time, and ends up only working if you make a 1x1 sprite, then in the update set up
Code: [Select]
boundingbox.x = x;
boundingbox.y = y;
boundingbox.origin.x = offset.x;
boundingbox.origin.y = offset.y;
boundingbox.scale.x = width;
boundingbox.scale.y = height;
and mind you, thats after the three lines to set up the thing in the first place, and means you have one more object (a temporary one, admittedly) that is being scaled all the time, and will pretty much kill your render. This isnt a huge deal, really, and honestly scaling or rotating sprites currently breaks showBounds, (it will fix itself if you are updating the height and width afterwards,) but assumming you dont use the gamepad option or any of the mobile stuff, there is really no reason not to just use the beta and downgrade later if you decide you hate it. Everything should still work, and the beta is fairly stable.

chat / Re: Whats my motivation?
« on: Sat, Jul 24, 2010 »
The gender ratio being slightly skewed towards females is actually kind of a neat idea. The Main character stays male, however, mostly because I already have a mind boggling amount of frames of animation for the main character (He can aim in 8 directions, well running and jumping. He can also wall jump, dash, double/triple/etcetc jump, and has a tun of melee attacks...)
That being said, I did already stick in some code that randomly assigns a sprite sheets to the enemys with the express purpose of having male and female variants of all the standard enemys, so tilting the gender scale wouldnt be hard, and I could probably work it into backstory, maybe. Its definitely food for thought, although if I did that I have a theory making sex the primary motivator is kind of out the window, seeing as males will be in high demand....

Im currently leaning towards food, but Im not sure how long that leaning will last. I was originally going towards the cancer thing, but it seemed like far to much of a downer. I suppose I could do sex + food, seeing as both would be most sane peoples motivators, and well, it worked pretty well for "City Hunter" (<3 Jackie Chan,) along with almost everything to ever come out of japan... hmm....

flxg.state = new yournext level.
If you want to be awesome, just restart the playstate, and have the playstate contain multiple levels that get loaded based on a variable. I recommend using flxG.level as the variable, seeing as thats what its there for.

help / Re: Making scale.x/y work properly
« on: Sat, Jul 24, 2010 »
or, use beta and set flxg.showBounds = true.... thats way easier.

chat / Whats my motivation?
« on: Sat, Jul 24, 2010 »
Alright, so for about a million years, I have been working on this totally rad game. Its super gritty and set in a post-apocalyptic dystopian future, where WW3 happened a good while ago, all government fell, France got nuked by America, and pretty much all that remains as far as controlling forces go is one mega corporation and a few rival street gangs.
As far as backstory goes, Im set. As far as actual game plot goes, Im also set. Both are full of twists, deception, and heart break, and all tie together rather nicely (there are branching plots depending on how you play. Whoopdedoo.) I have motivations and origins for the supporting roles, but one is pretty much totally lacking.

The Main character has no name, and no reason whatsoever to be interesting or part of the game, other then that the player controls. That being said, he quickly gets swept up the course of events right after he takes a job for the last remaining mega corporation.

So, why the hell does he take the job?
The options I have given thought to are
1. Someone he loves is dying of cancer. The mega corporation have a cure (this part is totally true regardless of why he took the job.) He takes the job, cancer goes byebye. Game ends up being a tragedy.
2. He's totally motivated by getting the green. Fairly self explanatory, he wants the good life, american dream and all that. He's some sort of ruthless mercenary, cue anti-hero.
3. R-E-S-P-E-C-T find out what it meaaans too....
I dun really like this option to much, to be honest. Im not really sure how to write a character who's sole motivation is what other people think of him. Sounds like someone I would probably slap.
4. Sex. Yup, plain and simple, nookie is in short supply, and taking the job will get him laid. Kinda like Mario rescuing the princess. Thats cool. Kinda simple, but fairly relatable.
5. Hunger. For food. Yummy food. Dude is broke and starving, and this payoff could buy him a lot of taco's. I kinda like this option, mostly because (spoiler alert) he never gets payed, and could then spend most of the rest of the game trying to get food, and complaining in the midst of important dialogue about being hungry. Pretty much kills the gritty feeling of the rest of the plot, but thats not all bad. Plus, then I can make the game end with a hero's feast and everyone feeling good about themselves.

You can check out my devlog (theres a link in my signature) to get some clue about the rest of this here game... I dun have a playable build anymore, as I didd some silly stuff to make it easier to load levels into the game engine for testing, and as of such nothing loads if the permissions arent set up right, but its FAIIIRLY far along, just missing levels, some slight tweeking, more enemys, and the dialogue.

help / Re: pixen
« on: Thu, Jul 22, 2010 »
I dunno diddly about Pixen, but you want to embed, and you can save your images as 8 bit pngs in most programs. If you are going for the 8 bit console look, depending on how faithful you are trying to be, there are some thins you want to do.
1. Use a pallet supported by whatever console. Limiting your colors to this pallet ALONE may give you the desired affect.
2. When you start your game, set the scale to at least 2x. This will give it that pixelated look.
3. The NES had some kind of brutal restrictions. You want to build everything in 8x8 squares, first off. You can totally use more then one for sprites, meanin 16x8 or 32x32 even is okay, but makes sure the dimensions are such that they could be 8x8 squares.
4.more NES. Use 4 colors total per square. Alpha counts as a color, meanin you only have 3 colors for sprites generally (Mega Man gets around this be having 5 squares for the character sprite, one being JUST his face, most games just had 3 color sprites.) You also only have 4 total pallets for the sprites. The background tiles can have 4 colors, and no alpha, but they generally should be the same 4 colors, as you only have 4 background pallets for the whole friggin cartridge. There are games that got around this in creative ways (mostly using sprites for background stuff) but generally this means you are working in one color + black or somethin for most tiles, just so you have enough of a pallet to make different objects that appear distinct from one another.
5. The NES resolution is 256 x 224. Thats pretty small. Upscale yo.

Pages: 1 [2] 3 4 ... 11