oh, yes. I forgot to mention. The game is insane. It's terrible. But there was something about the game that kept me going. Maybe it's the wacky ideas.

Rocket chicken, Machine gun squirelle, chainsaw panda.... and of course Doom Unicorn.

I think with a little more work and longer game. I think this could be a strange success. Good job sir.

I agree this is not a point and click adventure.

Check out games of Kings Quest, Space Quest, Maniac Mansion, Curse of Monkey Island, Sam and Max. These are point and click adventures.

Bit Dungeon looks like The Legend of Zelda. Which is more of a topdown action adventure game. Yes I've seen some Zelda'esque games around.

Actually a game like this basics is pretty easy. I suggest checking up on some tutorials :)

A.

countdown = time + X

if time > countdown

GAME OVER

B.

on game start(however everything starts

sub event:

-> WAIT 60 seconds

-> whatever game over stuff you have

A will give you options to modify the countdown timer.

B will end the game after the period time no matter what.

Time scale will affect both of these time results.

BluePhaze

Based on how you want to proceed your taking your project backwards and ultimately going to use a lot more memory space.

Spriter plugin system handles animation for you. You don't need to export to sprite sheet, unless you specifically need spritesheets. That's also very unlikely for the purpose of animation. So let's go over the post.

"My goal is to have an ouptut similar to a sheet like the one for teh main character in the jungle platformer sprite pack."

Do you actually need a sprite sheet? So far I only know that you need animation. What exactly do you need the spritesheet for? Spritesheets use a lot more memory and storage space than a Spriter object.

"So I put all the pieces of the monster together, use the bones to get the overall structure and movement done, "

Not entirely. This will only achieve a non moving object. This is the first step to using Spriter.

" create my keyframes, then export the keyframes of the entire creatures movement (as opposed to sheets for each component of the creature) frames.

"

This is not how spriter works. Keyframes are positions and angles for 1 part of your monsters part. ie it's one position of the leg at one point in time. The next key frame could be the last position in time in the animation. A keyframe is not an animation frame. It's point A and B locations at differnt points in time. The animation will move the objects position and angle from A to B during the animation process.

A(0time)- - - - - - - - B(10seconds later)

X - - - - - - - - - - - X

The above has Keyframe A and B. B is set to 10 seconds later and 200 pixels away from keyframe A. Let's ignore angles.

When the engine animates in game or tool the X sprite. It's going to create 600 "frames" or animation positions. You as the monster designer do not have to actually animation anything between time keyframe's A and B.

That's the point of keyframes and this form of animation.

"As long as Spriter can do that for me, then I am all set when I buy it."

Lucid says it's coming, and if you need it. Then sounds good :) Spriter makes animation easier even if you want to use spritesheets.

"Other wise I can just screenshot each keyframe, and put those screen shots together into a spritesheet I guess"

nope. Keyframs are not the same as a sprite sheet animation frame. They represent a part of the objects in a different place and time in a animation.

You can if you want animate and take as screen shot, but your overcomplicating your game design.

My suggestion is to try using spriter and watch the tutorials. Watch how many keyframes it takes to make an animation and how it all works. It seems by your posting that you might not know how key frames work in animation. All we want is for you to make the most informed decision.

youtube.com/watch

youtube.com/watch

But if you actually need individual frames. It will work and good luck :)

No, i believe this is about doll makers, avatar and changing equipment.

I suggest image points and pins, lots of PINS. pin pin pin.

ok. here is a suggestion

there are a couple of ways to do this in C2 native. It depends on the depths of animation you need. If it's just 2d angles(left/right platforming). This solution is easy to do.

Create 1 sprite sheet for heads. Create 1 C2 sprite. Each frame is a head. When you want the player to change heads. change the frame for the head. Repeat and rinse for every object.

Create(or manage) a master sprite with numerous image points. Each IP is for each body part. when the player is put together pin each part.

I would also suggest using Spriter for this as animating all the parts is easier than sprite sheeting each frame and the image points :|

1. Objects are ignored if their bounding boxes are not overlapping which is an almost instant test, so collisions do not generally cause any framerate impact.

2. You don't need to worry about this for Sprites. For Tiled Backgrounds it helps them tile seamlessly, and they need to be exact powers of two (e.g. 16, 32, 64...)

ok, so if I have 500 sprites and I'm colliding them on other 2 objects. There is no slowdown for collision checking. The reason I'm asking is because my game is about creating 1 more object on every touch. So the objective is just lots'f of objects. I've put a cap on it to not crash the system, but I'm wondering once it starts hitting 200+ it will slow down even if they aren't activly colliding, but just need to constantly check for collision.

I'm refering to this article and the section

"Technical limitations

Due to the way graphics processors work, images are usually actually held in memory in a power-of-two size (e.g. 128x128, 256x256, 512x512, etc). For example a 150x150 image will have to be placed on a 256x256 surface, with the rest of the pixels transparent. Notice that means it uses a lot more memory: out of the whole 256x256 area, only about a third of the pixels are actually used for the image. The other two-thirds is simply wasted, but still sit there taking up memory! If you have a long animation with 150x150 frames, it can end up wasting several megabytes of memory - and just for one animation."

but if there are no concerns about it. then i'm fine with it :) as at this time i've been setting all my sprite sizes to the power of 2, just not sure if I needed to set for a 0/1 as the base count size.

1. Is collision of objects based on brute force or is this a more complicated method(binary or qaud tree)

2. When creating image objects and based on how graphics memory works. Should my images be based on 0 or 1 starting size count.

Should I be using 7,15,31,63... or should I use 8,16,32,64.... for my steps of 2.

That may be a helpful too. Also to add to this suggestion. Would be relative angle distance between two objects. AND a new angle() function that only require to pass the obejct like angle(object1, object2) instead of passing x.y, x.y. I do think the angle assistence would be great. I like this gauge idea :)

Also as a peeve.

I dislike TLDR; and I don't mean the poster. I dislike when people actually come to a topic by a poster. then only post TLDR. Sometimes the posts aren't even that long. OP, your on a developer forum. I suggest that you don't need to add a TLDR. Just a friendly suggestion. I am fortunate that scirra forum site doesn't have a lot members that do that :)

edit: oops this towards C-7 problem.

I know what's going on here. I'm just not entirely sure how to fix it.

What's happening is that when the animation sprites change the old versions are being left behind. I suppose what you can do is make sure they are hidden. I haven't used Sprite in C2 yet although I plan too. Sorry I can't help more, but your capx is for 115 and for me I avoid using beta's until there is a required feature for my game.

um. If you can't hide the last sprite change you can try spoofing the problem by pushing the last draw of the last sprite frame to the outside of the layout. Then start back to it's proper position the next frame. That way the sprites of the last direction are still there, but wont' be seen. However, this is an ugly hack job :|

It's notation for why it's listed as such.

Also now that your using touchid.

You can. remove variable puck.takingshot.

Instead of the "is taking shot" and "is in touch" you can check to see if puck.tchID > -1

instead of "setTakingShot to false". you can change to "set puck.tchID = -1" so that the value is removed and not compared.

This will reduce your events and variables by 1. Since your using a form of on off variable with touchid. Might as reduce reduncencies.

Good luck.

part of the problem as I understand angle in C2. is that what your looking for is relative angle to the ship, but angle itself is always going to be determined based on angle that 0 is always point to the right.

If your relative angle math doesn't come out right your going to get some strange results or no result at all. This is why I suggest the easy way. It increase your object count, but it is easier to implement.

dl.dropbox.com/u/14087254/lazyshipturn.capx

sorry. But I spent about 20m tinkering with the method you want. I decided I didn't want to pull out the calculator and figure out relative angle trig when there was a vastly easier way to do it.

Go with which ever way you want, but don't forget that angles are -180 to +180. Where as your post only looks like it's going from 0 to 180.

I don't see what's wrong with compare two valuess for what your doing.

however you can use inline if statements.