Remember, "on overlapping" is just a condition. =) You can give it many actions from there, including re-positioning.

Most of that will be handled with animations, but the move function could be handled a few ways.

You could use LERP when the bad guys overlap a vacuum hitbox sprite.

"badguy" is overlaping "hitbox" > set X to (self.X, player.X,5*dt)

set Y to (self.Y, player.Y,5*dt)

Adjust 5 in 5*dt to a number that fits your sprite size and scale, it's the speed the bad guys will move.

Or you could use bullet behavior on the badguys, which is closer since you can control acceleration. Set the default speed to 0 and the acceleration to about half what speed will be. (say 30?)

now when the bad guy overlaps, you can move it toward the player with increasing speed as they are trapped in the vacuum longer. For this, I recommend an invisible control sprite, since you'll need to control the angle of the badguys, and you may not want to spin the actual animated sprite. A control sprite is really recommended for most actors in a platformer with any complexity.

Check out some platform tutorials if you're lost on the basics, but I'm happy to help as well.

In the case of bullet behavior:

"BadguyController" is overlapping "Hitbox" > set angle toward (player.x, player.y)

set bullet speed to 60

"Object": is overlapping "Object" > "Object" destroy.

Alternately: > set "object" x:self.x+somedistance (Ie self.x+32)

No loops, variables, or arrays. =) Often used for top down SHMUPs.

Also, don't forget to destroy your objects if their Y becomes greater than viewport:bottom! =)

megatronx This sounds intriguing, though I'm not entirely clear. Could you elaborate? Would you be saving via localstorage and loading when needed...?

As an aside, it seems the functionality is missing due to the way C2 finalizes and exports your game. Object names are not saved (with good reason).

https://www.scirra.com/forum/viewtopic.php?t=68324&start=0

This isn't supported because as part of minifying and obfuscating your project on export, object names are removed to make it even more difficult to reverse engineer a project.

Allowing creating objects by a variable would then force C2 to include the original names of all objects, possibly making it easier to reverse engineer the project. TBH I think the best solution is a series of subevents like you've shown.

Ashley what about using a UID in place of an object name?

If I come up with an efficient way to do this, or even an event template, I'll post it as a Tut.

While I'm looking for as much functionality in Vanilla C2 as I can get, there's a plugin that may work well for you.

As rexrainbow pointed out last night, the Nickname plugin lets you add some extra functionality to spawning instances, and some other cool things. I also recommend having a peek at some of the other plugins on his page.

Nickname can be found here:

http://c2rexplugins.weebly.com/rex_nickname.html

(you may need to past that into your URL bar until I get some more posts under my belt.)

I'm very behind on doing this, but hello!

Been in games, animation and music industry for a long time now, and decided to give C2 a whirl a little under a year ago. Since then, I've prototyped a lot, and come to rely on C2 as a valuable tool. Outside of C2, I've worked on many games with many teams and worn many hats, from art, to music, writing, production, a bit of code, a bit of everything really. In my spare time, I'm going to try and see just how complex a game can be made here, and over what platforms. Excited for the day MS and Sony adopt full HTML5. Can't wait to see what you're all working on, and I hope I can offer assistance anytime I'm able. Looks like a great community here. See you all in future posts!

Been working on a similar issue this evening, and after lots of research (as you may also have already figured out) the issue comes from setting position of a sprite (or worse, pinning) to another sprite WHICH ALSO has its position set to an object. For instance, an invisible, rectangular controller sprite handles collision and movement. To this, we set the position of the visible player sprite (containing the animations). For accuracy, we set image points to the visible player sprite (as the invisible collision sprite is often smaller, and will not have a visual guide for where to set the image points). Then, we set the second sprite (sword, gun, shield, shadow, etc.) to the visible sprite's image point, and therein lies the problem. We have "pinned" (through events, not behavior) s sprite to a sprite to a sprite, and C2 HATES that.

To test this, create a platform with a sine behavior. Set its movement to either horizontal or vertical. My platform is small, 64x16, so I'll set the period to 3 and magnitude to 32. Size yours as you wish, and use appropriate settings. Now create a rectangle sprite with platform behavior, and place it on the platform. This will be our "Controller", a rectangular collision detector, as is best practice for platforming. Next, we create our hero sprite, a visible, but non-solid representation of the player controlled hero. For this test, it can be a larger rectangle, or add your favorite animated asset. We'll name this sprite "Player". Every tick, set the position of "Hero" to "Controller". (I know this is all platformed 101, bear with me). Now, lets set a new image point on "Hero". Right-click and quick assign it to "right" (unless you're feeling ambitious and used an animated asset, in which case feel free to assign the point to wherever the hand appears). This image point will be where we hold our "object" sprite. I'll name my point "Hand" and my new sprite object "coffee". You can name yours whatever is appropriate. Now I'll create the sprite, "Coffee" and set it's position every tick to "Hero" image point 1 (remember, it's 0 based, and 0 is the origin, so your new point is 1. You can also set the "Coffee" sprite to "Hero" at image point "Hand" if you prefer names over numbers, but don't forget the quotes.)

Alright, lets test it out. Assuming I wasn't sleepy enough to forget a step, you ought to see the "Controller" and "Hero" sprites moving together perfectly, but notice that "Coffee" is always a bit behind, sort of like a LERP effect. This is the lag caused from setting the position of one sprite to a second sprite which is positioned to a third.

Now, try setting the position of "Coffee" to a similarly placed "Hand" image point on our original "Controller" sprite. Magically, they all move in sync now.

This is a bit of a pain, since you lose the visual reference of the "Hero Sprite", and since the origin point and size of your controller and hero are rarely the same, a lot of tweaking comes into play when fine tuning the position of your held object for every animation frame. I'm sure you could find the position of each point on the "Hero", then offset that by the difference in origin points between the "Hero" and "Controller", but again, lots of extra work.

If anyone has any ideas for a non-plugin fix, or method of determining image points without your visual reference, I would love to hear! Or if I've just plum lost everybody, I'll try to clarify. I do hope this has been helpful, and I hope some one comes up with better solutions!

TLDR: Use one sprite to set position of all other sprites, do not set position to a sprite which has its position set to another sprite. A headache, but works.

Apologies for reviving an old topic, but it seems to be unsolved. Also for any errors, it's very late.

Evening, all! I do believe this is my first forum post. Been at C2 for a little while now, and I've been able to accomplish a lot. That said, I'm bringing up a suggestion that I've seen visited a few time in the past (for instance,

--Pardon the lack of a link, still new in the forums so the rep is low).

I'd like to have the ability to dynamically create an object, such as a sprite (though I bet other items such as arrays would benefit from this as well) by checking a variable as opposed to clicking to select it each time. It would serve many purposes that aren't possible without the functionality.

For example: let's imagine a game like Castlevania, SotN. Items may be equipped in either right or left hand, and activated by that button. There are many, many items, and each one holds a fair amount of animation --especially if (unlike SotN swords) you plan to have the equipped item always visible, even when not in use. This means additional animations for walking, jumping, crouching, etc.

The most prescribed method is creating a single sprite object, and creating many animation cycles/frames. This has a number of drawbacks. For one (and this may only apply games containing many items with high res sprites) it goes against best practices as I've come to understand them from a lot of time in tuts. Large spritesheets can cause the loading bar at launch to hang for a bit, then suddenly jump. Occasionally, this can cause a player to think their game has locked up before it's loaded. It may seem Trivial, but it has been suggested that while using spritesheets to cover multiple objects is helpful, it can be overdone.

Secondly, it can quickly become difficult to organize and keep track of player equipment, and lacks automation. Instead of storing your object variables neatly inside their instances, you will need to create separate arrays. Now, while I do love arrays, I think many people will agree that after a certain size they can be difficult to keep track of without separate references outside of the program, like a list or spreadsheet to track object IDs (unless you're good at remembering that "Epic Chicken Slicer Sword of Justice" has an object ID of 73.

Then there's the fact that the sprite can quickly become cluttered with animations. You're loading all of them each time, despite not needing most of them, and tracking them is even more difficult.

Heaven forbid you accidentally apply an image point change to all animations while tired. That can lead to a lot of repair work if not caught immediately.

Consider this:

On equipping an object, a variable is set. We'll say it's the right hand, and call our variable EquipRightHand. Perhaps it's global, or perhaps it's a player instance variable. Let's say you equipped a rapier. The method of equipping isn't important in this example. The result is: set EquipRightHand:EquippedObject. Variable becomes EquipRightHand:WeaponRapier

Now, with one action in the same event, we create new object: Sprite.EquipRightHand at the player's position.

Additionally, if the animation names and origin points of the objects are set to match the player's, you could set every weapon/item sprite to mimic the player's position, animation and frame in one event and have every other object line up from that point on. If the player's animation frame is PlayerWalk02, the Rapier (also at PlayerWalk02) will line up perfectly on top of the player. Change the EquipRightHand variable to Scimitar, and your work is already done, provided the Scimitar's animation names and image points line up. Imagine the amount of animation you would need in one sprite if you did this via frames, and the amount of array reference you could avoid otherwise.

The only other way to avoid a single, very large sprite sheet, as I understand, is to create many, many different events for each object, resulting in a lot of code. (IE: If WeaponEquip:"WeaponRapier", then DoSomeAction. If WeaponEquip:"WeaponScimitar", then DoSomeAction.) For this example, I'm not taking into account plugins, which are useful, but may depreciate as C2 evolves. Also, I love to see how much functionality I can squeeze out of anything in vanilla flavor.

I realize this has been brought up and dismissed before, but I feel the usefulness of this proposed function is there. I use strings all over the place for dynamic coding, and this is one place I am sorely missing that functionality.

One thing I've learned over the years, whether it's code, music, Photoshop, etc. is that everyone has a different method to get from A to B, and there's always something you can learn from someone else. I'd love to see how others accomplish what I'm talking about in a way we maybe haven't considered.

I hope I haven't lost you with the long post!

Thoughts?

Very cute! This style seems popular lately.

Perhaps you should create modules to work with this and sell them individually as well as bundled. For instance, procedural levels, inventory, even crafting.

As for the engine so far, maybe add some dynamic z-sorting for mobs and player? Keep it up!