My 3¢ about c2 and c3

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.

Yes. I agree that plugins should work together and I've been thinking of that even back at the cc days.

eli0s: items 2, 3 and 4 sound like they are already possible, 5 and 6 via existing third party addons (e.g. Spriter). It sounds like you're underestimating what's already possible.

Game is on layout the size of single screen, and enemies fly trough it, but there no way of bouncing off bullets of the borders of the layout

This sounds pretty easily solvable with events.

If we had control over loading into vram, we can specify which sprites to load on start of layout or between transitions, and when they are called, there's no stutter.

Placing an object in the layout view is how you tell the engine to load it in to VRAM on startup. If you don't need it on startup, just destroy it on start of layout - it still gets its textures loaded and can be created without stutter. So I think you already have the control you need?

[quote:3rplp7ai]Multi-thread is difficult to get it to work well, big engines have it and little engines don't.

It's not that simple. For the reasons outlined in the blog post, even big engines run a lot of their core logic on a single thread, because due to the architecture of modern computer systems multithreading it would have either little or negative effect. The blog post explains why this is the case.

I wrote that blog post specifically to combat this perception that "C2 sucks for being single threaded and needs to be made multithreaded pronto", but it seems to have been ineffective! There is unlikely to be any real-world performance benefit to multithreading events. And again as the blog post describes, significant parts of modern browser engines are aleady multithreaded, and that is already in effect today with all your existing games. I think that is underappreciated.

> Game is on layout the size of single screen, and enemies fly trough it, but there no way of bouncing off bullets of the borders of the layout

>

This sounds pretty easily solvable with events.

Yes it is possible, and I've made it. However, it is that hacking I am talking about, and it is waste of time. There should be a ready made options for that and more scenarios that all work together.

Spriter is excellent for animating your main character, but it's a 3rd party program: so small adjustments have to be reimported into c2 to be tested (time consuming, convoluted save and import process) and, also, the Spriter animations are super-demanding of cpu time (my pc can only run a few scml objects on screen at any one time before it frame drops!!). Having a built in animation keyframe/timeline editor would have been simply outstanding for c3. Sigh... I take it that c3 will not have such a feature....

On the bright side, Godot Engine is open source, has a robust animation editor and a simple native desktop export...

Also would like to remind about the fact that interacting with black borders around the canvas still make things happen in game. Atm, in my rts project, when I click on black border, the units just go to the edge of layout, then press themselves against it, and some of them gets stack in there forever.

eli0s

#4: check

Yes, I am aware of this method, but it is very restricting, it only affects stuff that exist on the same layer, or on layers that are stacked together. What I am asking is vastly more powerful, because you could use any sprite to cutout (or mask in) any other sprite on any other layer! Multiple sprites/layers included! Now, the only way to achieve something like this is to have multiple sprites everywhere. And the applications graphic-wise are many, to name a few: decals (from explosion burns to blood stains), reflections, shadows that affect some parts of the image and can be controlled from the mask to reflect z-order changes etc...

eli0s: items 2, 3 and 4 sound like they are already possible, 5 and 6 via existing third party addons (e.g. Spriter). It sounds like you're underestimating what's already possible.

I am sure I underestimate what is already possible, because I am not proficient with coding/programming and I can't even imagine what can be done when someone is! I have a clear idea however, every time I see a capx made by R0J0hound I stand in awe, feeling like a slightly evolved monkey!

However, my point is that most of these features should be included and be easily accessible by default. For example, I know that R0J0 can make an amazing multi-lighting system just by using his canvas plugin, but I can't, it's too convoluted for me and it shouldn't be like this. I know that pathfinding's nodes can be used to create a grid based system, but it is also somewhat complicated, even considering the fact that I was lucky enough to see lolpaca's LinearPathfinding.capx. Masking also leave a lot to be desired, as I wrote above.

As for the text, I know that rexrainbow had made behaviors that add some of those functions, but shouldn't those be already implemented by default? And I can't see how I can change part of the written text to be bold, an other color

or an other size

... Something basic if you want to emphasize some parts of a dialog for example.

Finally, I own Spriter, but as Colludium already stated, it's too time consuming and convoluted to design and work like this. I don't mind using Spriter for extremely complicated character interactions, but I would very much like to be able to move any part that exist within my scene, record this movement with keyframes, apply easing and call these animations with events, in any order, at any time, at any rate! And this, ideally, should be done and previewed within the editor!

I know, I might ask for too much, I am sure that most of those things are insanely difficult to program, never the less from my point of view, as a creator, seem essential to have!

> If we had control over loading into vram, we can specify which sprites to load on start of layout or between transitions, and when they are called, there's no stutter.

>

Placing an object in the layout view is how you tell the engine to load it in to VRAM on startup. If you don't need it on startup, just destroy it on start of layout - it still gets its textures loaded and can be created without stutter. So I think you already have the control you need?

Yes, it's what I've learnt to do for some assets which can be loaded and set invisible or destroyed on startup. But others cannot as its tied to game logic and AI. I notice those micro-stutter, the first time weapons fire or explosions go off awhile ago and hack it on start of layout to avoid it. Ultimately I'm sure its possible to add all the sprites one needs on the layout (off the margins so they aren't view-able) and destroy those instances on start-up (or add destroy on outside layout behavior)...

But more explicit control would be very useful. Just an event to "Load Sprite X into memory" would be much more easier to use avoiding all the workarounds.

eli0s Yes, example like this are good and are showing not only that such basic features are time consuming and difficult to implement, but also that we all implement it in the same way! That's one of the points of my post! We all just copy step by step what someone else figured out! That leads to thinking that this just could be there from the start as it is pretty much always done same way. It is a creative process for those who figure things out, but for all rest IT IS NOT. And I want to be creative with gameplay, not recreating features that are standards these days and allow for solid and interesting gameplay to happen.

"It is a creative process for those who figure things out, but for all rest IT IS NOT."

You've just pointed out a pretty big issue with plugs. If you take too much of the process out, the process of learning, no one will be able to figure out better ways to do things.

If all you are doing is copy and paste, then we are failing at teaching as well.

"It is a creative process for those who figure things out, but for all rest IT IS NOT."

You've just pointed out a pretty big issue with plugs. If you take too much of the process out, the process of learning, no one will be able to figure out better ways to do things.

If all you are doing is copy and paste, then we are failing at teaching as well.

People earn by copying. Also you need to diversify those who want to learn programming, from those who rather learn other game development elements. Pretty sure that niche for none-programming required software are the latter. Plugs should take care of all the standardized features, and events should be there to expand or create own plugs, but not to hack trough plugs.

Also after years of using construct, ho many ways there is to create a menu, or pushing out of objects? Really there is only one that works best it can, thought not perfect. Same for keybindings - when you think about it there is only one way to do it right, due to how c2 is structured. And could go on with lights etc. Instead of recreating existing and common technologies with events, I'd rather see them being there from the get go, and instead innovate in the design and gameplay environment, with additional elements done trough events.

"It is a creative process for those who figure things out, but for all rest IT IS NOT."

You've just pointed out a pretty big issue with plugs. If you take too much of the process out, the process of learning, no one will be able to figure out better ways to do things.

If all you are doing is copy and paste, then we are failing at teaching as well.

I recently saw

. It has some examples of how an IDE can inspire (or not) a developer by allowing him or her to interact with the code and also how the code can be clearly related with what it does at runtime. I feel like this is the right way to go for a game development engine, the platformer example in his talk clearly shows the power behind this kind of approach.

I know that for a programmer that can interpret code into images and gameplay mechanics in his/her mind, this might look obscuring and too restricting, it takes away from low level experimentation, but for a creator's point of view, it's just liberating. Eventually, everyone has to learn the basics in programming, but while I don't have to learn how to code from scratch a platform behavior in C2 (although I find the one existing with C2 very restricting), I do have to workaround a bunch of other, also basic imo, things.

As megatronx stated, if something is being used by a lot of people that copy someone else's solution, then it should be ironed out and be included as a standard feature by default. Debating about something that perhaps can be done by other means or with an 3rd party plug/software, when it is considered essential and/or very helpful to have within a creative environment, doesn't help either side of the argument. I think

X + cos(angle) * dist, Y + sin(angle) * dist

I dare say the most inspiring formula there is, and we don't even have an expression for it.

I would also say that if it doesn't inspire, you need to find out why it should.

X + cos(angle) * dist, Y + sin(angle) * dist

I dare say the most inspiring formula there is, and we don't even have an expression for it.

I would also say that if it doesn't inspire, you need to find out why it should.

I agree that learning is good. But math might not inspire if it's not someones priority. I am inspired by music from romantic period. It's different form of math. There is a need to remember that knowing a lot doesn't mean understanding a lot.

Anyway, I my goal is to encourage for plugins to be expanded in such way that all major and today's standards are there ready use, freeing so much of needed time, for more creativity, learning, and experimentation with innovative ideas.

newt , that's interesting. I am glad that the current C2 workflow doesn't limit your creative abilities, though, evidently, it lacks some favorite expressions, and I am also happy that you get your inspiration from math!

Clearly, you are more intellectual than me, I don't doubt about that! If this is your point, then you are spot on!

However, if I was capable of understanding this formula of yours, would I have been a better creator? I mean, does this formula help me create better environments in my scenes? Does it help to make better interactions, animations, gameplay elements, will this inspiration that I'll get from your formula help me get rid the frustration I get every time I want to lit a scene, create menus, paths, reflections, each and every-time I skip storytelling elements like multi-line dialogs or cut-scenes because they are too hard to manage with code and very complicated to call with actions..?

Perhaps it wouldn't have helped on the above, but I could have been a better person... I don't know. For now, with my current skill-set and limited brain power, I am dependent on other people, smarter people, to provide me with the tools that will allow me to make up for my ignorance, by being productive in areas that I was blessed to be more adept. I rely on those people to help, not question the need for help based on their abilities, but based on the gravity of the argument, taking in to account that is supposed to be a game creation tool that democratizes creativity by eliminating the need to code, this isn't a 64k scene contest!

Anyway, I don't meant for this to come up harsh, but I feel that sometimes you have a tendency to belittle others, especially when you find what they ask to be trivial to you.

Actually... yes, even the belittling, which I do too much, not to incite, but to challenge. If it's too harsh, I apologise.

Anyway, yes the formula could be used in many of those, like menus and paths especially.

Take megatronx's issue with pathfinder, its node based, a bunch of lines pointing at each other, and the algo describes perfectly a line between two points.

It could be used to move those tanks, and allow the control to keep them apart.