My 3¢ about c2 and c3

Stuff like units pushing out of object, to be used in games like rts or hack and slash etc.

• what if you use something like Spring RTS engine uses? each unit has it's own thread and a bit of time (yes it's really cpu dependant, but still around 1000 units runs pretty well, maybe even more, since i've done some games in spring). (i know spring RTS uses lua for scripting but.. )

Everytime when I see post like that instantly I'm seeing UE4 blueprints in my head. There is really no point to compare epic to scirra (hundreds of hands vs only few couples) but they have nice system with object blueprints and level blueprints working together.

So maybe this is a thing worth do some tests. Not only to make events more clear - you could have object events on objects only and everything else on level events, but maybe level events could work on 1 cpu and objects on another etc.

And on the other side this kind of system have more sense, at least from my point of view. Even for beginners who tends to make one huge and messy event sheet with everything on it. "Double click on sprite to add some logic to it" feels more natural and most engines are using similar approach. You don't make just one text file full of code for entire game to compile.

But I'm just a user, so I'm just saying what I see xD

In regards to advanced memory management and multi-core threading, I think it would be cool, but first the basics need to be nailed down.

Also, there is plenty of other weird quirks. Right now I have object that uses rotate plugin, and it is suppose to shoot every x seconds and when is in between angles. It does shoot, however the projectile with bullet behavior only moves at 180 degrees instead, even thought of having the angle of motion set to spawning objects angle. What to do? Sorry to say, but this is irrational.

Use set angle on your projectile rather than set angle of motion. There's a few things like that which once you figure it out, it's understandable why.

Let me take a screen from my own example, I hope it makes sense:

https://halfgeekstudios.files.wordpress ... /09/00.jpg

It's a shotgun, 8 round blast in a cone from the gun.

> Also, there is plenty of other weird quirks. Right now I have object that uses rotate plugin, and it is suppose to shoot every x seconds and when is in between angles. It does shoot, however the projectile with bullet behavior only moves at 180 degrees instead, even thought of having the angle of motion set to spawning objects angle. What to do? Sorry to say, but this is irrational.

>

Use set angle on your projectile rather than set angle of motion. There's a few things like that which once you figure it out, it's understandable why.

Let me take a screen from my own example, I hope it makes sense:

https://halfgeekstudios.files.wordpress ... /09/00.jpg

It's a shotgun, 8 round blast in a cone from the gun.

Thanks. But I figured out it was due to collisions being turned off! So collisions need to be turned on, otherwise bullet just goes at 180 degrees if another object is pinned to it.

Anyway, don't want this thread to turn in to "how to fix it" kind of thing. <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

megatronx

Hehe, you live and you learn, that's how it goes!

I keep trying and testing to get features to work exactly as I want, even if its unorthodox or "hackish".. I only care about the end result.

I know the engine already does this per layout, but the option to do it manually for a sprite that we want when we want it is what allows more flexibility. Sure, people can mess up if they don't know how to use it, but that's a poor excuse to not have that level of control at all.

Completely agree with this. Its no different in my opinion than people can screw up loops, that doesn't mean that loops should be removed as well. Almost everything can be screwed up if done wrong, but what matters is the ability to be able to do something when its actually needed and to use it where it doesn't hurt performance, which should be a decision made by the person designing the game and not those making the software, because sure in some cases it would be a bad idea, but that doesn't justify that then its bad in every single case and therefore shouldn't be an option.

Everytime when I see post like that instantly I'm seeing UE4 blueprints in my head. There is really no point to compare epic to scirra (hundreds of hands vs only few couples) but they have nice system with object blueprints and level blueprints working together.

So maybe this is a thing worth do some tests. Not only to make events more clear - you could have object events on objects only and everything else on level events, but maybe level events could work on 1 cpu and objects on another etc.

And on the other side this kind of system have more sense, at least from my point of view. Even for beginners who tends to make one huge and messy event sheet with everything on it. "Double click on sprite to add some logic to it" feels more natural and most engines are using similar approach. You don't make just one text file full of code for entire game to compile.

But I'm just a user, so I'm just saying what I see xD

Maybe that makes sense, given that Blueprints also evolved like that. The Kismet predecessor only had global level scripts, then the system was extended to be (optionally) object oriented with Blueprint.

Maybe it wouldn't need anything complex even to make this useful. Simply being able to assign event sheets to objects could be helpful already, with no major difference other than defaulting to "pick all instances of this object" for all events in such a sheet. Allow sheets to be assigned to more than one object and you even have reusable sheets that work on different object types, which would not be far off from adding behaviours. Perhaps also add an abstract object type to hold data and/or events only, so Sprite doesn't have to be abused for this.

Another thing I'd like to see is an evolution of the Function object, perhaps by creating a function behaviour that can be assigned to objects to create "member" functions. So we could do something like MyObject.Function.Call("MyFunction"), which triggers MyObject.Function.OnFunction.

The only issue with that (and Function in general IMO) is that the syntax is really cumbersome, so why not make Function a first class feature of the editor, with its methods exposed by each object? Then you could just write Call("MyFunction") or MyObject.Call("MyFunction") instead of Function.Call("MyFunction") and MyObject.Function.Call("MyFunction") respectively.

I don't believe those changes would make the editor significantly more complex if you don't need those features, but provide a pretty significant quality of life improvement for more complex development.

One of primary goals of my post, was to add features and plugins that would do what we all do when making our games - stuff that is pretty much always made same way, to save us time and hustle, simultaneously expanding plugins with new functionality, while taking care of fixing glitches of the software and it's plugins. And only after those basics are fulfilled I think the talk about multi threading and other hardware related features could be included.

eli0s

#4: check

Anyway...

If C3 does not have a way to make plugs via events we really need to shim up the javascript side of plug creation.

There's little info for beginners to go on.

There should be forums dedicated to scripting, examples, object types, behaviors.

We have an sdk that's absolutely cryptic to a novice.

This contains some gem ideas. My 3 cents:

Add a tween behaviour. I know there's a couple of 3rd party plugins, but I mean something a bit more substantial... One you could incorporate into a sprite/variable animator (like the one in Godot engine or a better version of the animator in Unity). Imagine an animation behaviour where you could easily animate anything, with tweening. Because that's what I want to use and have to create every time I want to do something in c2, even if it's just to animate a button effect or a layer opacity.

Oh, and give us access to full box2d because the demo physics plugin is OK for creating a quick game demo but, strewth, it's frustratingly limited.

And what newt just posted too. I would love to create my own plugins but if I'm going to bother to learn to write code then that defeats the point of using a no-code engine. Just imagine a Blueprints style of plugin creator... Mmmmm.

Colludium I think what it needs is like what eli0s said

6) An animation timeline to create key-framed animations that can be triggered with actions!!!

If that could be a little curve editor with key frames, beziers etc, then it will sort out every animating property needs: position, rotation, opacity, scale.....

shinkan - yes! An animator with curve adjustment. That's exactly what Godot uses: everything can be animated by simply using it in the editor.... I support eli0s ' suggestion!

I'm totally up for making plugins with events, animator editor with curves and tweens, but also for expanding vanilla plugins with more functions and fixing its current existing issues and limitations.

megatronx exactly, Like I wrote in some post in the past, plugins and behaviors should be all compatible with each other, should do what you expect them to do and every single parameter of the plug/beh should be visible in ACE to be set or modified.

Solid is probably the best example here. You would expect that it will block every other solids no matter what, unfortunately Solid only works with selected and very specific other behaviors. It should be the other way, if I set Sprite to be Solid then it is solid for everything - drag and drop, bullet, 8dir etc.