I approached this problem by having the character with a detector at its top to check when it's not overlapping a wall for when the character should start pulling themselves up. When they do that, then play an animation of them climbing. The animation hot spots must be aligned so that technically while the character is pulling themselves up, the sprite isn't moving. What I mean is, in the animation, the character will pull themselves up and away from the hot spot. Once the animation is done, set the position of the sprite to match up where the animation ended up after climbing.

Does that make sense?

Initially they aren't apparent, but as you continue working on a larger game with construct, there are some major speed issues. I realize a lot of these probably can't be resolved in construct one, maybe for construct two they can be fixed.

Opening large event sheets - one of my event sheets has about 3500 events, and it takes about 2 minutes to open the first time it's opened. It's faster subsequent times when I switch back to the layout editor then go back to the events, but regardless still takes a while.

Solution idea: even if the initial loading can't be sped up, after the event sheet is loaded, switching back and forth via the tabs from one event sheet to another is instant. Perhaps if the event sheet was kept "open" in its own window the same way other layouts are kept open in other windows, then it would remain plenty fast to switch between a layout and its events.

Previewing games with large event sheets - my game takes over a minute to preview. Before I realized how much extra time event sheets can add to compile time, it was taking almost two. That was after the graphics had already been cashed. After deleting all of the code from my game and previewing again, the progress bar appeared and disappeared in less than a second. Events, when there are enough of them, take a long time to compile.

I wonder if there is some way to speed up this process, such as cashing event sheets similarly to the way graphics get cashed, except individually, as most of the time that I preview I've only edited one event sheet. I'm not sure how much that would help on large event sheets since AFAIK the event sheet includes simply results in construct pasting the events from one event sheet to another, though.

Maybe if there was some way to be able to cache event sheets so after being compiled once, they can be pasted as a single chunk rather then pasting each and every event, condition and action? Then larger event sheets could be broken up into multiple smaller event sheets, making the whole process faster, since only one of the included event sheets would need to be recompiled. I don't know if there's any other way to optimize the process of compiling events to speed it up, but it sure would help!

Initial preview - since AFAIK in construct 2, games are going to be saved in a way that includes multiple files in one archive, would it be possible to include an option to save the cashed event sheets and graphics as well? It would take up more space, but hard drives are getting so huge these days the amount of time saved would be worth it.

Working with large images - whether it's in the picture editor or how long they take to cache for preview, large images slow down construct a lot.

Undoing on large event sheets - I tried pressing undo on that event sheet with 3500 events. 5 minutes later it was still sitting there undoing. Because of this, I don't use undo any more.

Deleting objects - the biggest speed problem facing construct. I'm not kidding when tell you that when I tried selecting some objects then deleting them, my computer sat working on that for almost 1/2 hour. Because of this, I don't delete objects anymore in the IDE.

Edit: forgot to mention one.

Working in the event sheet - when there are lots of events, edits can take about 2-3 seconds for the screen to update itself with the edit. I recall hearing that the event sheet editor was going to be rewritten in C2 to use hardware acceleration, though, so hopefully that will be fixed.

Can these be fixed for construct 2?

IT...

WOOOOOOORRRRRRRRKKKKKKKKSSS!!!!!

Thanks SO much for fixing this one!!!

Impressive stuff! Though will my 512 MB graphics card be able to play that, or am I going to have to upgrade to 1 TB? (kidding, kidding)

Also, what's up with the .bmps? Use PNG or JPG! Those images are like 5 MB!

Study the work of those who have come before you, then when you're done with high school enroll in animation mentor. It's an online school not only founded by people from places like Pixar and ILM, you are directly taught by pro animators from places like Pixar, Disney, ILM, Sony image works and DreamWorks. I learned more in two weeks at animation mentor than I had learned in two years at another art college. It's cheaper than a normal art college, and better. Since its online, it doesn't matter what part of the world you're in, you can study there. They also don't mess around and make you take irrelevant courses like math or english for an animation career - it's 100% animation. I can't recommend it highly enough.

http://www.animationmentor.com/

What I think is actually going on is that time delta continues while things are loading (i.e, the time delta for the first frame of a layout includes the time it takes to load the layout as well as the time it takes to execute the events and draw the screen) but the event sheet isn't running extra times. That's what happens with my game. How I solved that was in the application properties/runtime properties/advanced, set the minimum frames per second there to something like 30. That way the time delta won't keep racking up while it's loading.

Instead of using a countdown timer based on time delta, what you should use (again, what I'm using) is a tick timer. Basically, if value is greater than zero, subtract one from that value. Every time the event sheet runs, you'll know it by watching that value.

As for a loading screen, you can do that too. Before going to the layout that takes a long time to load, put a black sprite or box across the whole screen and your loading image somewhere as well in the previous layout. There is a trick, however; you have to display that one frame before going to the other layout (let the layout finish running its events), or it won't draw the loading graphics before going to the other layout.

Objects are not fully created until the end of the event sheet. You only have been the event that the object was created in to modify anything about it until the next tick.

event one

conditions

• Create object sprite
• set sprite color filter

event two

• set sprite angle

In this example, the sprite would have its color filter set but its angle would not be set until the next tick.

What he said. Or if that's not possible, maybe simply not draw the icons and have a list of names instead? It's a very small window, that way you could fit more into it.

New version WHOOO

The OBJ object crashes if you load a model with too many polygons on my machine too. Try something with less and it seems to work fine.

Don't use spritefont. It's buggy. Use one of these other examples instead:

Actually, if you only edit an event sheet then close construct, it does not ask if you want it to save.