Huh, that did work. Well, that's egg on my face, then. Disregard the email, then.

Just a heads up, Lucid, I'm getting a Javascript error just from starting up a file:

"Javascript Error!

Uncaught Syntax Error: Unexpected token <

localhost/, line 1 (col undefined)"

I'm sending you the cap now via email. It's just the original platformer essentials animations except with the head shrunken down to something far less ridiculous.

Still, integrating techniques like that could potentially be a hassle.

Terrain mapping might also pave the way for stuff such as, say, automatic tile blending, with each terrain having a set of 'edges' that, when bordered with another tile, the terrain automatically 'blends' in a certain fashion (for example, 'man-made' tiles will simple sit side-by-side, most natural terrain will blend with each other, water washes over most stuff, etc). Not sure how feasible that would be, but it would be interesting.

I know Ashley has mentioned that he doesn't quite see the point in reinventing the wheel when it comes to certain tools from Tiled, but there is one rather big reason why having terrain mapping might be a good idea, and I realized it when the newest update included the ability to modify tilemaps at runtime.

I mean, with tile maps, inevitably, you're gonna be seeing people using it in level editors and games where you can modify the terrain in some fashion. Aside from making life a lot easier for those people if they want tiles to 'blend', it would also open up interesting possibilities for naturalistic tile-based terrain that can also be modified in-game, and I imagine there could be settings to identify which 'terrain' a tile properly belongs to, for the sake of games like Terraria, where you break blocks to gather resources, and stuff like that. And you can probably have terrain tiles that exist in cases where they don't 'blend' with the surrounding tiles.

tl;dr: Terrain mapping has plenty of in-game potential as well as being useful for editing. Food for thought.

The moment the long-awaited tile-map plugin was introduced, I couldn't help but notice the questions about how to go about handling collision. Well, I do have an idea that could make life easier for everyone...

Have a separate 'tile palette' that contains a set of generic shapes scaled to the size of the tiles, such as full squares, rectangles that partially cover the tile, triangles for slopes, etc. These are 'painted' over the graphical tiles, and don't appear in runtime (unless you want them to for debugging purposes), and represent collision polygons. That way, you can enable static tile collision that can be individually shaped for each tile. Hell, you might even be able to make your own collision tiles for your own needs, depending on what's possible.

Sure, it's not perfect, but at least you won't have to create collision sprites for individual tiles. I'm not sure if it's doable in terms of the technical details, but it's worth suggesting, at least.

That's really only workable if you're only working with a single layout, anything more and things start becoming a hassle. This is especially true if you want any kind of 'storage' system for party members you're not using at any time, and you don't want to have those party members active all the time.

The main advantages of a "List object" are convenience, being able to keep track of multiple "Lists" (even multiple lists associated with the same family) at a time, organize and add to them, and keep them active across layouts without having to muck about too much with events.

Say you want to add a new item to an inventory list object - just tell the list to check if the item isn't already there, and if it is and you've got a 'quantity' value, just increase the value by one, and if there isn't any in the list, just add the the object to the list. Simple.

This might seem a tad complicated, and I'm not sure if there's actually a way to do this already, but let's see:

Considering families are akin to classes in traditional programming, when working with classes, not only can you create singular objects, you can also create arrays of them, or lists. Each object in an array/list has its own named methods/functions and variables, and the array/list can then be modified and sorted, and interact with other objects/lists of the same class.

However, to my knowledge, C2 lacks similar functionality. To get a better idea of what I'm asking for, let's look at an example, from, say, an RPG with any number of possible party members, such as Pokemon:

• Say you have a 'List' object that has to be associated with a Family. The Family, and by extension, the List, describes Party Members, with all their relevant variables, such as their name, stats like HP, attack power, etc, stuff like equipment, EXP, level, and so on.
• During play, each object's variables can be accessed by name, rather than the designer having to remember which index number is associated with a variable like they would an array. As well, objects can be deleted from a List, the List can be sorted by a specific variable with limited hassle, and an object can be transferred to another List, like, say, you want to put a party member in 'storage' and swap them for someone else.
• In-game, each object in a list can be associated with a visible object in-game via events that graphically represents the party members.

This would also do wonders for stuff like inventories, for example. I imagine there's some things I'm missing from this that would make List objects even better, but I think I've gotten my overall point across. Arrays and Dictionaries are neat, but they do have their limitations.

Awesome, nice to know you're gonna address that issue. And... Holy cow, those animations are amazing.

Also, lucid, there's another suggestion I'd like to make, mainly for Spriter in general - a 'prototype' animation art pack. Nothing complicated, just an animation set with a detail-less manikin or crash test dummy, for 'prototype' animations for game testing, basically. Just something usable, it doesn't even really have to be good looking as long as people can use it :p

Hey, Lucid, when it comes to Spriter objects 'attached' to another object, I've noticed that the Spriter object still experiences some nasty 'drift' when the object it's attached to is moving, such as with a platform movement. This is actually kind of an issue, and while it's mainly a visual issue, it's still an issue that I'd really like to see fixed.

Example .capx

— Yeah, as I mentioned, I'm heavily considering splitting the character-specific events into two sections each - the 'general' events that don't need to be in the For Each loop, and the control-based events that require the loop in order to distinguish between players.

— I'm mainly talking about stuff like animation triggers for the platform behaviour (On Stopped, On Landed, etc.), though in hindsight, most of that stuff might be able to work in a separate group outside of the "For Each" loop(s), as they generally don't come into contact with the control-related events that need to be in the loop.

This is something I've had to tear down to its most basic elements in order to strip out all the fat from my experimental stuff, and I want some help on making this work.

What I'm trying to make is basically:

• Multi-purpose platform engine that can support any number of gameplay styles
• Can support both custom controls and AI control
• Supports multiplayer

How I have it set up so far:

• Two families, "PlayerAI_Platformer" and "Platformer_Skins", to handle both the actual player objects and 'skins' representing actual characters. The former contains general variables that usually apply to most characters.

• Four objects for each player:

-- The "Plat_Stats_General" object, which is the 'base' Player object, storing variables that are more 'universal', such as health, money, etc. This always persists for any given player.

-- The "InputPlayer" object, which is contained in the object above, which handles the input for that specific player with a large set of variables. Is persistent.

-- The "platforming" object, which handles all the platforming for a given character. Contains the relevant character 'skin', and character-specific variables. Can be destroyed to be swapped out for another character.

-- The character 'skin'.

Now, the main problem I'm having right now is that the only way I can get the separate players to respond only to their respective controls is to use 'For Each' loops. Problem is, the loops prevent me from using triggers as sub-events, and believe me, there's a lot of triggers involved in creating a fully-functioning character. But using picking conditions doesn't seem to be nearly enough, unless I'm somehow doing it wrong. Is there a better way I should be going about all this?

*Cap link removed for the time being*