Thanks, that works perfectly! Awesome effect!

Oddly, it's not either of those. The one linked in the first post is a linear stretch, and the one you linked is a (great) alpha thresholding shader.

The _Threshold effect seems to be something else, but I haven't been able to find it through search.

This looks really cool, but unfortunately I can't open the project, as its missing the _Threshold effect. Does anyone know where that effect can be found?

One extra layer might be helpful, but I've found that I often need more. I'm building some pretty complex levels, so the freedom of being able to add multiple parallax layers or play freely with layer ordering has been pretty helpful.

As far as how I save the levels as text objects: My levels consist of two things, a base tileset object that represents the core terrain, and then a set of 'props' with X and Y positions that represent various game objects. So in my text file, I have to store the state of the tileset, and the name and coordinates of each prop.

In general, the key to this method is creating lists in the text file using separators, and making use of the tokenat function to break up the lists again when you load. I pretty much just choose random character as the separators, but I'll explain it as best I can! Here are my saving events:

<img src="http://i.imgur.com/1B9rOEN.png" border="0" />

I originally tried to save the tileset data using the AsJSON component, but I ran into a lot of bugs and couldn't make it work consistently. I don't recommend that approach. Instead, I save the tile data for the levels by looping through each tile and saving its number, then writing them to a string as a list, with a "." separator between each one. You can see this in the setupTileString function above: It loops through each tile and appends its value to the list. This is then saved into StringToSave. Once I've done this, I add another seperator (a "|"), so I can differentiate the tile data from the prop data.

For the props, I just add each possible prop to a family and give it an instance variable that represents the props name. Then I just loop through each prop in the list and save its name, as well as its X and Y components. Each prop is separated from the other props by a "?", and the data within each prop is separated by ";". You can refer to the code above to see exactly how the string is built. Props could be anything - enemies, items, background objects, whatever you need to have directly placed. Just make sure to give each one a unique name, as this will be important in the loading. You could also add more data parameters here, if you needed to save more about a prop than just its coordinates.

Once the strings are all saved, you write them to a file using the Node-Webkit object, as I've done above. Node webkit makes it very easy to save files using the Open Save Dialog and On Save Dialog OK features. If you look at the two events above it should be pretty clear how that's being done.

In the actual game, the level files are loaded in a similar way. The strings are broken up and separated out (you can do this using the tokenat and tokencount functions), the tilesets are rebuilt, and the props are created and placed based on their names. This is all done on one layout, so I never have to worry about layering issues or mirroring my changes. You can then create your individual levels in your level editor project, saving them as separate layouts, and putting all of the actual behavior in the main game project.

Again, this may not be the best method for every game. For various reasons, it was the best fit for my game, but I only settled on it after some experimentation. Depending on how your game is structured, using a layers/layouts approach might work better for you.

In general, if your project is going to get large I'd highly recommend that you use static local variables within groups as opposed to global variables. The global variable drop-down gets very cluttered very quickly if you are overusing them.

My player's stats are stored this way, and I access them using getter functions.

Very cool! I like the basic mechanics a lot.

Mechanics-wise, it would be cool to see some more things that make use of the hippos weight. With both the platforming physics and the effects you clearly draw a lot of attention to it, but there doesn't seem to be any actual stomping on enemies or affecting things by squishing them. In fact, the combat seems almost the opposite of that, lots of aerial attacks and movement. it might be more cohesive if those two things were brought a little more into line with each other.

It would be nice if the level gave a bit more of a goal, like a clear path and victory condition. I think I just ended up wandering right until I fell off the screen. I imagine that's in the works though.

In general, it seems like a great start. Hope you continue working on it!

I've gone with this approach and it works out okay, but layers remain a big problem. There's an excellent chance you'll need to change your layers in the future, and that's increasingly difficult to do for a huge number of layouts.

Here's another approach:

-Have a separate project for "level building" and build your levels within that project, each on its own layout.

-Write a system for saving your levels to a file - this can be easy or hard depending on how your levels are constructed. A simple approach might simply save the position/name of each object, while a more complex one would incorporate things like tilemaps. Either way, make it so you can press a button to save (the Node Webkit object can help here), and save each level to a text format. If you need to change a level later, change it and then save it again.

-For your game itself, you can put all the game logic and layers onto a single layout. When the game starts or the player transitions levels, you can remove any existing objects and load in the new ones based on the content of your text file, placing all the objects as needed. That way, all the levels can be loaded onto one layout.

Note that this approach is good for certain types of games, and not so good for others. For example, if you need to save changes when transitioning levels (for example: an enemy you killed in a previous layout stays dead if you go back), it might make more sense to use the built in layout and persist behaviors rather than going this route.

This approach has worked for my game, so I thought I would throw it out there. It may or may not suit yours, it just depends on your mechanics.

Another tip: Make almost every variable a static local, and access them through functions if you need them elsewhere. Global variables clog up the drop down menu a lot once you have too many.

What you want for this is an Effect applied to the player sprite, not a blend mode. Effects on a sprite will only apply to that single sprite. You can get a decent-looking white flash effect by putting a Brightness effect on your player objects - set the effect parameter to 200 when the player is hit, then gradually scale it back down to 100 over a second or two. You can get more complicated if you want multiple white flashes, but that's the basic idea.

You can also write your own effects if none of them match your needs.

So I'm using Spriter for my animations, and that has allowed me to create a variety of animations for my character. However, as I add more moves and options, I'm finding that the page which controls the animations I'm playing is getting pretty unwieldy to work with. My current approach started out very simple (ie: If on ground + is moving then set animation to running), but those kind of condition-checks become increasingly large and ugly as the project gets bigger.

I'm not so much looking for specific code help as general ideas. I'd like to find an approach to controlling animations that lets me add new ones for specific events, without having to go back through a bunch of old events and changing conditions to make it all work. Has anyone found a good modular approach to controlling which animations play for complex characters? I'm thinking of doing a queue of some kind with priority levels (so a high-priority animation can override a low-priority one), but I'm looking for other ideas.

Thoughts? How have you handled complex animation controllers in the past?

Is there a way to cause a sprite to cut from the texture when I scale it, instead of scaling the texture?

An example would be a textured health bar. Rather than scaling the texture down, I want to only use 50% of the texture if I set the width of the object to 50%, and cut off the rest.

There's probably some way I could do this with Blending modes, but doing it for each UI object would be pretty complex. Is there a simple way?

So what is the process for re-importing in this current version? When I drag the .scml or .scon file into Construct 2, it seems to find the file for reimporting, but then it gives me an error about how it can't find the .scml file and stops. This happens whether I drag in the .scml or the .scon.

Using r152 of Construct, and the latest build of Spriter and the plugin. All save options enabled in Spriter.

Did a bit of further testing. Each time I save and load the tilemap through the asJSON function, it cuts off the right edge of each rectangular grouping of tiles, regardless of the position of the tiles in the tilemap. It only triggers when I re-save the string each time with the new tilemap, so it's likely some problem in the format in which the string is saved.