"Game Maker" is a 2D game maker too.

Game Maker is also a useless piece of junk unless you learn the GML language. You can't just open Game Maker and make a decent 2D game with their drag and drop interface, let alone a 3D game. And you'd still have to learn all the 3D math. Which as Quazi said, you can do in Construct too if you know what you're doing.

Besides 3D games already have several high-end engines... Construct is focusing on an awesome development platform for 2D while employing hardware acceleration and shaders.

Exactly. If you want 3D there's always Unity, which is probably the most user friendly 3D game dev suite out there. Construct if silling a 2D niche that other programs like MMF and Game Maker aren't. It's trying to advance the playing field for 2D development, and there's nothing wrong with that. The 2D world needs Construct more than the 3D world at this point.

So what features in .99.85 hates WinXP? My thoughts at this point are that it might be Multiple layouts with Include Event sheets? Continuing to test to see what in .99.85 is conflicting with XP.

What is this version 99.85 you keep speaking of? And also, I use Windows XP and I have projects with multiple layouts and included event sheets and I don't have this problem.

0.99.85? Is this game from the future?

Anyway, trying it out now...

Edit:

Okay, I get a blank white screen with music playing after I select my speed. Looks borked. I'm on XP.

Oh, and could you please zip your game files in a folder so I don't have a bunch of loose files on my desktop when I unzip your game?

> Perhaps a Loop setting, for pulsing things.

>

But the sine behavior already does this really well?

So? It's a scaley type scale thing, so why not? It would save having to add a Sine behavior.

Oh, and different loop types would be nice. Like ping-pong, ramp up, ramp down.

And also a linear scaling vs ease in/out option. I mean, if you're going to make a plugin for scaling you might as well go hog wild with features so that it's actually useful to a wider number of people.

look what exactly are you trying to do here thats so difficult that you need a behaviour?

We're past that now. It's going to be made so you may as well embrace it. At this point it's about finding functionality that would justify it's existence.

<rant>

Also alot of users wont use rotate, or fade because they are so limited. plus fade, is.. well not that intuitive... "do I start the fade, or do I set it activated?"

Ugh, tell me about it. I made some fading objects in my tut recently with just one line of code for opacity. Took me about ten seconds and it worked the first time, but it used TimeDelta... which means I have to write a whole long description of TimeDelta for my tuts. So Ash says "why not just use behaviors and avoid TimeDelta?" So I tried the Fade behavior. I'd never used it before. It took me like an hour to figure out what that thing was doing. It seriously needs a revamp.

</rant>

Okay you made your point

Yes, you would still have to set the angle in events to make the bullets fire upward with Bullet behavior. My bad.

so why not ported this for Construct to.

Because that's a ton of work.

And because Construct is a 2D game maker.

Really nice for a work in progress . I'm looking forward to seeing the final product. It's really well polished already.

The controls are kind of tricky to get used to though. After many tries though I finally got up on the high ledge that's out of the water . My record so far is 35 rings.

Perhaps a Loop setting, for pulsing things.

So that's all of my questions answered, so thanks for the help.

Slow your roll there, buddy. We got some things to talk about first.

-Firstly, is there a way to change the 'facing' for an object, without rotating the object itself. For instance, I'm making a shooter, and when bullets are spawned they move in the direction of the facing. However, it seems that the facing defaults to the right, and I want them facing up. I worked around it by drawing up all my sprites facing to the right and then rotating them in construct, but I was just wondering if there was an easier way around this that I was missing.

Yeah, have the same thing going on here since I'm also sort-of making a vertical shmup - always turning the art 90 degrees counterclockwise is a bummer, but I'm almost used to it. Maybe someone will give a solution, who knows.

If you guys mean you want your bullets always facing up then you can draw them facing up and set the Rotation property in the sidebar to "No rotation."

-Lastly, I'm having trouble using the else function. When you destroy a rock, there's a random chance that a powerup will show up. Then, there's a random chance that it will be such-and-such powerup, and then there's a random chance that it will be this powerup, or that one. Or at least, that's what's meant to happen, but I can't get it to work.

Okay, first off you don't need a bunch of "0 = 0" events laying around. It's a useless event. All it's doing is basically saying "True" every tick, which is what the Always event does. Get rid of them.

Next, the reason your blue objects aren't showing up is because you're using Else incorrectly. But more on that in a moment. Let's have a look at a more stable spawning event. This is how you were doing it:

<img src="http://i48.tinypic.com/2ljmgeg.png">

You have two separate events checking two separate random numbers. Unless you mean for both powerups to spawn at once on occasion (which I guarantee they were, you just couldn't see them) then you need to roll the dice just once, so to speak. Set yourself up another variable to hold your random and check it in a condition, like so:

<img src="http://i46.tinypic.com/sb0bat.png">

Now it will only generate one at a time.

Now, about that Else. See, even though the blue powerup was being spawned, the way you had your Else set up it was basically being destroyed immediately in the same tick. Else isn't supposed to be used as a sub-event. It's a special event that you place immediately after the event you want to else. Like so:

<img src="http://i45.tinypic.com/5fitmd.png">

Notice it makes a little pipe connection to the previous event. That's how you know it's working.

Also, you can't Else a trigger event like "On collision." Those events happen in just one tick, so saying Else to them is like saying "Every time it's NOT colliding," which kind of defeats the purpose here. Hence the reorganization of the sub-events. Works fine.

Well, you could give your rigged character a private variable called "type" or whatever, then assign it a name or a number. That way you can use that variable as a condition for picking instances. You could make each sprite that's being used for a bone have several different frames, each corresponding to a different character's costume or whatever, and change the sprite frames accordingly.

Hell, you could even match up the number for the "type" variable with the proper frame numbers and do something like "Set BoneFamily animation frame to BoneFamily.Value('type')"

Well okay then yeah, but if he has more than one layer then uh, you know. Stuff.

Try a canvas on the top layer. Paste everything into the canvas and use the warp effect on that. That way you're just using one shader and one shading pass, it'll help with rendering time.

And yes, using shaders will lower the framerate. There's not a lot you can do about that. Sometimes you just need a faster computer v<img src="http://www.scirra.com/forum/images/smilies/icon_confused.gif">v