Greetings

Yeah its very easy to learn. Let me know when you use 26 alterable values on an object

Oh and try doing 500000 + 0.1 on MMF2. I'm not sure if they have fixed that yet. But I remember asking the guys in the chatroom why it was giving me answer "500001" and they couldn't work it out. Eventually they started telling me they don't care what i think because "i'm only one customer".

NOTE- Whoever said that wasn't a rep of clickteam.

MMF is only good because of the legends that make free plugins for it so its not so crap. :'(

But anyway, i'll probably pledge allegiance to the first to make a quality online plugin (Comon Ash )

Like many others, I saw some folks stirring up things about Construct, so I took a look. I have it downloaded and installed on my computer and have taken a quick look around to see what its like, and it indeed has its similarities to MMF, however it is only similar to Clickteam's products as Paintshop Pro is like Photoshop is like Corel Painter is like.... And of course I expected to see people raving about how much they think Construct is better than Clickteam's products. You can see stuff like that on just about any other game design website, even on Clickteam-based sites.

In any case, I was wondering if anyone who's used Construct quite a bit and is more used to its features by now can provide me with a list of features this program has that can help me more in designing the things I'd like to take a swing at instead of with MMF2. I looked up a few posts using the Search feature here and saw a few things, so I'll build off what I saw (from ).

I am rather curious as to how the program coding works with Construct. Despite having taken several programming language courses, they just haven't been my strongest points. =/

I've been hearing a lot about pixel shaders in recent versions of all game design programs. Being an artsy person myself I feel the need to do some research on what they are and how they can benefit me.

Again, if anyone can explain to me some features of Construct that make it stand above MMF2, please feel free to inform me. I've had an itch to make a game that is very much like SNES's Secret of Mana with a three man party with interchangeable characters much like Dot Hack games. If its possible that in Construct its easier to make AI pathfinding so characters move around obsticles to keep up with the lead character, that would be great. Or maybe its easy enough in MMF and I just haven't figured it out yet. I used to be rather proficient with MMF, but its been a few years with some lifestyle changes, so I really just ghost around communities. But the urge and desire is still there, just like an old crush.

Things that I'm not really interested in hearing about are...

• Price: I don't care that its free, or that something else costs tens of millions of dollars. I grew up with Clickteam products since I was 13 (now 25) and had the luxory of listening to different users who were of similar age complain about how they couldn't afford $100 or find a way to convince their parents to buy it for them, and that they'd rather stick with their free pirated copy of TGF. I'll probably continue buying Clickteam's products anyway simply to support their cause.

• Interface: Every new program you use has its own design and methods of function, and if we truely desire the power of said program we force ourselves to learn them. Although I do think the event screen in Construct is cleaner than any of Clickteam's products in general, it doesn't bother me that in MMF the Actions menu was to the right of the Tools menu, and you like it better in Construct because its to the left.

• Selling my Product: I've always had the power to distribute and/or sell in the past. I do agree that the people who designed the program who helped me design my self-proclaimed masterpiece should get some recognition, even if they do ask that I include some sort of hard-to-find banner in my game. Though, I do think that if I made something that was truely a masterpiece it would seem rather silly to send my stuff out in mass production with file properties saying "This guy didn't make this, we did. Now buy our stuff and make us money!" unless I paid another couple hundred dollars.

If anyone would like to lend a hand in helping me settle my mind on which tool to use, feel free to post or send a private message. You'll receive my thanks.

Also, if anyone would like some cheapo sprite assistance, let me know as well.

In any case, I was wondering if anyone who's used Construct quite a bit and is more used to its features by now can provide me with a list of features this program has...

Construct is quite differently designed, so the list would be very long! However, a very much non-exhaustive list of Construct's strong points amongst other game creators would include:

• Sub-events
• Re-usable event sheets
• 'For', 'While', 'For Each' loops (in a single condition)
• Designed entirely around a hardware-accelerated engine & pixel shaders; advanced effects like full-display or per-layer zoom, motion blur, skew, bumpmapping, dynamic lighting & shadows, etc
• Flexible behaviors engine (formerly 'Movements'): every behavior is a plugin with unique actions, conditions and expressions
• Containers engine to make picking groups of instances very easy
• Simple expression syntax; parameter editing in a list; useful expression facilities such as string concatenation ('&' operator)
• Function object for advanced eventing (condition aliasing, pick-preserving function calls, expression functions...)
• No limits on variables, objects, events...
• Built-in inline Python scripting
• Proper timing engine for consistent gameplay speed on all computers, even with V-sync and differing framerates - including TimeDelta expression

[quote:jssza63n]I've been hearing a lot about pixel shaders in recent versions of all game design programs

They're just effects, like Monochrome. Add Monochrome to an object, and it appears black & white. This is done at runtime, and uses fancy hardware, so us geeks get excited over it. Most of the effects run very fast!

Good enough for me. Let's have at it then.

Good enough for me. Let's have at it then.

HAHA! This is funny!

It is? I still haven't really gone through Construct much, but I'll hang around here; give you guys a chance to try to persuade me. XD

Well I'm having about the same problems creating things with Construct as I was with MMF2. But I have found some things in Construct that will allow me to throw in some interesting features for gameplay already.

One problem I have is, I have each player character and their shadow. The shadow is the actual moving thing for collision reasons (So if I have a character walk up to a fence, they aren't stopping at the fence at the tip of their heads) and the character sprite follows along and acts out the animations. Err, problem is, when I move around diagonally and make sharp keyboard turns to another direction, the character is often stuck, say, looking left while actually moving up or down. I'm not sure what the best way to correct this would be without eliminating diagonal movements all together.

Another problem is something I'm sure any more experienced coder could figure out. That is, when I hit a key to activate an attack I want to temporarily halt character movements while the attack sequence takes place. In both MMF2 and Construct I've tried to simply say "While animation is playing, stop movement", but in both instances it fails to do what I think it should be doing. I even go so far as to say "Stop movement AND set movement speed to zero AND ignore player controls..." and even that doesn't do anything for me. On the flip side, though, when I enter in "When animation is over, return speed to XX", it actually makes the character move in the direction its facing nonstop, which leads me to believe I've discovered the beginning of some sort of AI-controlled movement for computer controlled party members and monsters to move around with.

But I'm still just an amateur, so what all could I know? =o

You dont sound as asking for help, more as stating facts. But if you list up problems with Construct i have this urge to put in my 2 cents.

If you need help with this, then upload a .cap.

Now i have to assume, and picture myself a way trough how i think your events look like.

So i assume you made a copy of the characters sprite, erased some outer things as "the tip of the head", and this new sprite you use as sensor, in pixel detection mode. I sure can imagine this construction going stuck. Try to figure out a bounding that does the same, if needed 2 separate simple objects, and use the bounding collision method.

I have no idea how you drive the sensor, how you snap the character to the sensor, and how you align your animations. Plz trow in a .cap.

One thing about animations though. I noticed that since the last release, Animations stop playing when you auto-align angles from a angle-sub-animation with more frames to an angle-sub-animation containing only 1 frame. Just go to the Animator, and right click the lonely frames to copy and past. So you have at least 2 frames in each animation. When its a non moving animation, just 2 the same frames, of cours. And all problems with animations not playing are gone.

And about your last point.

The "8 directions" behavior can be set on "ignore keys', if thats what you use to drive the sensor.

Ashley brought "slow-motion" into construct. I have not played with it myself yet. So i have no idea if its possible to slo-mo parts of things. But then again ....

What you describe should not be a problem. If you bring a nice flow into your events.

If you let the keys alter variables, and move, fire, sit, stand, according those variables. Then you only need 1 global variable that represents the state your games is in.

Then if you organize all your events in nice event trees,

All you have to is open a tree with checking the global " FloW variable".

Like ...

key 'fire' pressed

_______ set the flow to fire

'flow'' set to fire ?

_______ is the thing allowed to fire, yes or no

'flow' not equal to "fire"

_______do all the moving stuff

'flow' equal to 'fire"

_______do all the fire stuff, and when done set 'flow' back to moving

Its easy to drive a complicated game on only 2 "flow" variables.

Greetings : ) ( to stay on topic )

Didn't realize there was more than one way to center a sprite on a point based off another sprite. You'll have to explain this to me some time.

The collision detector is merely a black circle at the character sprite's foot that represents its shadow. So instead of having the whole sprite collide with the obsticles, I only have to deal with the little circle that is slightly larger than the character's feet stopping it from moving.

There's no real need to show anyone my program file, because there isn't anything to look at. =D

I just need to figure out how to do what I want to do properly.