Hi. The most common problem that I've seen that will cause animations to get 'stuck' is having a flaw in the logic of the event sheets somewhere.

Usually, where it's intended to set an animation upon some state change, but not taking into account that the event will continue to trigger every tick, thus resetting it to the same frame every tick. The same could go for movement, too.

In such a case, one needs to make sure that the event triggered only once while that state remains true.

I can't really think of another reason at the moment.

The site seems nice, and it's a normal thing for good products to have fan sites with news and other content related to said product.

That said, I have to agree with Lucid's point above. Scirra is not the product name. Construct is. Scirra is the name of the dev team, and they may very well publish other products under it. Have a look here: http://www.scirra.com/about.php

Also, nothing's stopping them from going commercial with any of their endeavors, at which point other sites using their name might be more disagreeable. I would have a talk with them before doing such a thing, myself.

Hmm, 'triggers' is a bit ambiguous. Any condition->action group could be considered a trigger.

I'll take a stab at what I think you might refer to. In many games, the player walking over a certain spot might trigger an event, or some similar thing?

For example, a hidden trigger spot can be made by making a sprite to serve as the trigger point, setting it to be 'invisible on start', giving it a private variable 'triggered', then setting a couple of events like so:

+ player: player overlaps trigger

+ trigger: Value 'triggered' Equal to 0

-> trigger: Set 'triggered' to 1

-> (do stuff that only happens once, unless 'triggered' is set back to 0)

OR... for duration effects and such:

+ player: player overlaps trigger

+ trigger: Value 'triggered' Equal to 0

-> trigger: Set 'triggered' to 1

-> (do stuff that only happens right when triggered)

+ trigger: Value 'triggered' Equal to 1

-> (do stuff that keeps happening until you set 'triggered' back to 0 to reset the trigger, or perhaps 2 to make it a one-time only effect)

Anyway, if I'm way off the mark, you may want to explain in detail what you want to achieve.

Hi. Simple fix.

The way that you ordered the events, you were trying to set the frame on the digit sprites before actually creating them, so it changed all of the sprites each time. You have to pick instances of objects somehow if you don't want the actions to apply to all of the instances.

In this case, Construct will automatically pick the 3 new sprites upon their creation, if you put the actions after that, like so:

+ System: Every 5 ticks
-> Sprite4: Set 'DamageValue' to 1+random(150)
-> System: Create object Sprite on layer 1 at (-16, -13) from ene_Baddie 's pivot point
-> System: Create object Sprite2 on layer 1 at (0, -13) from ene_Baddie 's pivot point
-> System: Create object Sprite3 on layer 1 at (16, -13) from ene_Baddie 's pivot point
-> Sprite: Set animation frame to (Sprite4.Value('DamageValue')%1000)/100+1
-> Sprite2: Set animation frame to (Sprite4.Value('DamageValue')%100)/10+1
-> Sprite3: Set animation frame to (Sprite4.Value('DamageValue')%10)/1+1
[/code:1u6u1rcd]

I'm a firm believer that any time one picks up a new programming language or game creation system, especially if one is not familiar with using similar tools prior to learning the new one, one should start out small, rather than jumping into the big 'dream game'. The consensus is usually the same at most software development discussion groups that I've frequented in the past.

Quite often, what happens when one jumps into the 'dream project' without having good knowledge in place beforehand, is that they'll end up at a point where the project can't be sustained by the existing code base any longer due to poorly written code, lack of planning for previously unthought-of features that don't fit well into the current framework, and the hard-to-find bugs that come with working around those limitations.

The good news is that when a total re-write is deemed necessary, the new result will be gotten much more quickly than the original was, and will undoubtedly be better, because of the experience that was gained from the original effort. Unfortunately, some people find themselves discouraged by having to start over, and give up. It's an exceedingly common situation, though, and should be taken in stride.

Bearing that in mind, my strategy has been to learn as many different aspects of using Construct that I can, and to mull over what is possible with it, before starting the big projects that I want to create. Knowing the capabilities at hand helps to minimize the number of roadblocks that one has to break through during the process, and any previous experience will help one lay out a sustainable, expandable framework for the larger projects that seem to grow on their own, once begun.

So, if you can make mini-games out of ideas that may be used within the larger project, or even make some smaller things that also spark your interest in other ways, before you start on the big project, it will definitely help. If you're too impatient for that, then a similar strategy can be used during development of the big project, by putting it on the backburner for a short time while testing out an idea in a separate small project that borrows only what is necessary from the bigger one to work, then once it's tweaked to one's satisfaction, recreate it in the larger project. This can have the advantage of limiting the amount of code changes in the bigger project, and thus reducing potential bugs.

Another piece of advice that I'd give is to try and make the project modular. If you can break it up into modules, it tends to make it more manageable. It helps to document what each one expects (global variables, function parameters, etc.,) what it does with those, and what it returns (if it is a function.) In Construct, managing separate event sheets can help with this, if done correctly. Using the event group functionality can be very handy, as they help organize, AND can also control the execution of events by enabling and disabling them at runtime. Also, using functions is a time-tested method for reducing duplicate events and breaking a project into separate tasks that work together as expected.

However you choose to proceed, good luck!

So say you had a game where conversation was between 2 people and depending what what action was taken. Would you have more than 1 Time Line?

And if so when you came back to the fist Time Line? would it pick up where you left off?

In other words can this be a little more dynamic?

From what I've seen so far, I'd say that if you want conditional branches in dialogue, you'd probably have to set up multiple timelines. Then, start a new timeline at the end of each timeline, based upon the player's choice.

Maybe the timelines could go like so:

1 ends with a question with 2 choices

2a continues with choice 1

2b continues with choice 2, which ends with 3 choices

3a ...

3b ...

3c ...

Could get pretty complicated that way...

As for just having more than one character involved, with no branching dialogue, I made just a few modifications to David's original .cap to show one way to deal with that. There are a few ways to handle that, but I chose adding a second parameter to each entry to indicate the character number that it came from. Could also use different time period names, though that might get a bit more tricky in conditions.

I ended up creating and destroying the text object for each message with the intention of allowing multiple messages to display simultaneously, but just left it at only allowing one for now. Basically, for what I ended up with, I could have just moved the text and panel for each message. Some more changes to the events would be needed for the former option, and I've got other things to work on. Here's the .cap:

http://dl.dropbox.com/u/5868916/Multi-M ... System.cap

That's very cool, David. Thanks for that example. That's much simpler than I thought it could be! I guess I should study the Timeline object, soon.

Great to hear, David! That will make a big difference to many users, I'm sure.

There are certainly many ways to do almost anything in Construct.

If I had more than a small amount of dialogue in the game, I'd probably go for something a bit more dynamic than that. I've never used the timeline object, so I'd probably go for my usual solution of creating variables of some sort to control it.

Since the complexity of dialogue systems in various games can differ greatly, it's hard to say how well what I'd do would fit your game, but I'd most likely load all of the dialogue into an array from a separate file. Then I'd create another array that contained the indexes of the start and end of the dialogue for each segment of the story progression. If there are more 'speakers' than one, then that would also have to contain an index for said 'speaker' with each segment.

With that in place, one can build an 'engine' to activate, display, handle input, and deactivate dialogue, so that a function call or enable group (or whatever) could be used for dynamically handling any point in the story progression.

I made a quick mock-up of the idea here:

http://dl.dropbox.com/u/5868916/dialogue.cap

It's very basic, and could very well be optimized quite a bit, but it gets the point across, I think. It doesn't handle story progression, but just displays whatever array entries you tell it to, when the global variables 'DialogBeginIndex' and 'DialogEndIndex' are set to something other than zero.

It handles instant display of the text when the spacebar is pressed during writing in much the same way as you did, but doesn't have to have duplicate text in the event sheet, because it's stored in a variable already.

Anyway, I'm more of a hobby programmer than a game designer. The first idea is usually not the best, in my experience, so don't be discouraged at the idea of re-writing portions of code if you come up with a better way. Maybe a mix of timeline and other variables to control things may work, too.

You can often avoid using sub-events with just several else statements in line, each grouped with another condition. Works just like if-elif-else conditionals, and has worked fine for me in Construct. Something like this should work:

+ if(play_death_animation == true)
-> play appropriate death animation

+ else
+ if walking
-> walking animation

+ else
+ if jumping
-> jumping animation

+ else
+ if falling
-> falling animation

+ else
-> idle animation[/code:2jd4j6v1]

Could also set the speeds to the playerdude's current speed + the force speed if you want to be able to boost normal jumps or running speeds.

You can also set ratios by adding multipliers, like the 0.85 below. This would limit higher combined total speeds, so that the resulting speeds are closer together between a standing and jumping boost.

+ Force: Force overlaps ForceDetector -> PlayerDude: Set horizontal speed to PlayerDude

[Platform].VectorX * 0.85 + Force[Bullet].VectorX * 10

-> PlayerDude: Set vertical speed to PlayerDude[Platform].VectorY * 0.85 + Force[Bullet].VectorY * 10

One consideration if you increment the speed instead of setting it to a static speed is the 'overlaps' condition used. Depending upon the settings used, this could be true for several ticks, causing the playerdude to keep increasing speed and rocket away. In that case, you may want to switch to 'on collision'. Or not.

Thanks a lot for helping me again. I tried the animations and it works properly now but theres one problem; When I test the game, the animations only work if I hold the 'Action' button. I want the animation to run when I 'press' the 'Action' key and will continue until it finishes.

Appreciate your help.

Well, I only made those two modifications to the file that you posted in the original post above. It played the animation once only after each key press. Perhaps you made another change in the meantime that messed it up. Here's the original .cap with those modifications, but it's saved with Construct 0.99.9:

http://dl.dropbox.com/u/5868916/prototype1%284%29.cap

The animation has to be set to not loop, which is as it was, and the action key check needs to check for key press instead of key down, which is also as it was. I'm not sure what else might interfere.