My 3¢ about c2 and c3

Hi,

I've never really had a vibe to learn programming (even thought I did in the end learn some js/jquery and php because of work ), so the premise of none-programming game making software was always appealing to me. First there was an obscure gamemaker on atari st, then click and play on pc, followed by rpg maker and then games factory. I started when I was 7 years old. Then my friend showed me construct - back then alpha 0.18 with that pseudo top-down gta demo - and I've been learning and using it, and observing its development ever since. It always had and still has marvelous potential.

However I was never fully satisfied with it and never felt like it is delivering on its premise. I always waited for improvements hoping that certain things that I couldn't pull off now, will be made available at some point, and that technical issues will be resolver. The latter I'll leave for some other time.

At this moment, I'm certainly finding construct limiting, both creatively and productively. There always has been some obstacle getting in the way of realizing the vision. And then there is always a talk of walk around's to compensate of lack of many standards. Stuff like units pushing out of object, to be used in games like rts or hack and slash etc. Or input delays to simulate different action rates. Or even such simple thing like scrolling text and default menu plugins, resolution change etc. Many ui and level building improvements. Those need to be within the vanilla software from the start. Thought many things can be done trough events, they need incredible attention, most often feeling more like hacks and rarely ending up working precisely, tightly in action, making often game feel and look awkward. In the event style environment, behaviors, plugins be doing most of work, streamlined but with many options, ready to take on many different ideas, and taking care of mundane, but giving a lot of possibilities. Same goes for UI and level tools. This will free up time needed for development in other, more important areas of gameplay; areas that will make or break the success of the game. I'm talking about original ideas and fine-tuning, testing and experimenting.

So now c3 is on its way and I hope that this time around it will be made truly with the developer in mind.

Thanks for reading

From my point of view I think it's because C2 was designed and made long time ago (well, not really but a lot time have passed since) And for that time all was great! But times have changed, standards have changed and C2 popularity sky rocket quite high with a lot of new users. And I truly believe that C3 will catch up with all of that.

Can't find any other reason to justify things like

• not being able to manipulate group of objects at runtime without making long and sometimes complex events.
• doubling up every single object in the layout just to add some nice bump mapping effects - which again makes everything harder to work on
• not being able to use more than one lightsource on above effect !
• not being able to use more than one shadow caster on the layout without getting stupid results.

and so on...

Also i think C3 should go full on WebGL. Sorry to say this, but forget about canvas2d, there is really no point to have it. It makes everything more complicated than it should be.

I don't mind work arounds or hacks to get things to work, but I do mind some major technical limitations.

I'd be happy with some memory controls, load sprites into vram, unload from vram, giving the developer more control (optional) over this is required for very large games to run well on weaker hardware.

The biggest limitation I see currently is single-thread logic. JS/HTML5 has higher CPU overhead and we're limited to 1 thread when modern CPUs have 4-8 is quite backwards. Yes, multi-thread programming is very difficult. But other game engines have MT functional, even Unity these days are moving to DX12 and multi-thread native.

Think these concerns have been made a few times before and agree with what you are saying. C2 can do a lot of things which are great, but as mentioned you always have the feeling that only the basics have been implemented and all the details needed to really complete it are skipped. The examples that you give are good examples of that. But think one of the most obvious examples of this are something as simple as text object and the fact that its not possible to change alignment during runtime even though you can do it in the editor. I mean its a very common functionality in any form of application, where you work with text. Still after using C2 for such a long time, its still a huge mystery why such details are not seen as important to add. And there are loads of such issues which again underline what you are also mentioning.

So my hope with C3 is that Scirra release a much more polished application from the beginning, where all these details are added. So rather than spending so much time having to adding new functionality that should be there from the release, they spend a lot more energy listening to the community of dedicated users, that in my opinion comes up with a lot of very good ideas that could really improve the program and that they spend time adding those things instead. Most of the people that come up with these ideas are not newcomers to the program, but suggest stuff because they actually have used the program a lot and see gaps in it, that should be fixed. So really hope they keep a list of suggestion made through the years of what people are really missing in C2 so they can make sure its not the same issues C3.

shinkan many of the things in the event system go back to CC and even earlier to gf.

I'm also talking about stuff that we all would benefit from like plugins for in game ui/menu that can be extended if needed trough events, more collision options including those that would work together with pathfinding between units and option for units to avoid each other. Simpler paring of same types of objects. More input actions, like possibility to cancel input at any point. Adding pathfinding to platform games. Basically expanding wherever it can be expanded by taking under consideration different game scenarios. As nimos100 says, adding details, streamlining where it is possible by having chained actions and conditions on top of new functionalities. etc

megatronx

Your desire for better pathfinding or smarter pathfinding is in fact seeking the holygrail of RTS AI. Many many big-time RTS still struggle with smart pathfinding. What they achieve, it's all logic from "hacks and work-arounds", thinking outside the box.

I doubt we will ever get a smart pathfind AI out of the box. It's gonna require a lot of logic.

I'm not talking about events. I'm saying that core features of the editor should get a massive update.

What really needs to be discussed is how to better implement the plug system.

As is, third party developers shy away from sticking around for a few different reasons, backwards compatibility, no support, etc.

Then those that do attempt to try to make plugs wind up using existing libs rather than implement their own mechanics. That is something else that could be talked about more often.

Regular users need more plugs, and plug developers need more support, enough said.

Your desire for better pathfinding or smarter pathfinding is in fact seeking the holygrail of RTS AI. Many many big-time RTS still struggle with smart pathfinding. What they achieve, it's all logic from "hacks and work-arounds", thinking outside the box.

I doubt we will ever get a smart pathfind AI out of the box. It's gonna require a lot of logic.

Think you have a point there, but also in defence of Scirra, its not easy to meet every ones demand on which path finding method should be used, they use A* which is fine I think but of course if they can improve it somehow it would be good.

But now that they have added a path finding behaviour and you start working with it, you quickly realize that its very basic and lots of details are missing in it. Like the single collision mesh, which of course is a design issue, but also there could be an option to make the path finding good for grid based games. And an option to make it move as close to an object as possible if you try to path find to a closed off area and that it would be able to path find correctly when in comes to diagonal movement etc. Besides the collision mesh, these things are details that should have been added to the behaviour to increase its functionality. So having to make work around is fine, but it shouldn't be that you have to spend 80-90% of the time doing this, because its obvious that its stuff that should have been in C2 by default, but aint.

What really needs to be discussed is how to better implement the plug system.

As is, third party developers shy away from sticking around for a few different reasons, backwards compatibility, no support, etc.

Then those that do attempt to try to make plugs wind up using existing libs rather than implement their own mechanics. That is something else that could be talked about more often.

Regular users need more plugs, and plug developers need more support, enough said.

I was also thinking about something like build n plugin editor, where you can build your own plugins with events.

— I would like more functionality n those plugins, more versatile options. And speaking of pathfning, having units avoid each other is such a small but significant addition. And it's been done already in early dos days, i don't see a reason why it would be so difficult have now. But pathfinding is just a tip of the iceberg. There is way too much fiddling round with the mundane, and there is no need for simple things to be made so complex, that they need a lot of events to be made, as I've explained in op. x

One thing that I don´t like to see in Scirra's home page is "No Programming Required!". That is true for little demo games, but if you want to do a more "serious" games you need to program it with event sheets. From my experience, I do not use behaviors except for shadow casting. When you mix behaviors and custom movements, setting custom coordinates..., you get unexpected results. Things like pausing a game with event sheet are really easy breaking loops, but with behaviors is different. I usually always use families for everything too.

Anyways I think that Construct is the easiest and most powerful game creation tool out there, even I do not share Construct html future. And when I say Construct, I include Classic. I think they are 2 different products; one for making native games and the other for making web games.

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

This type of problem is incredibly difficult, period. No matter which framework, technology or approach you use, getting a large number of moving objects to move co-operatively is very tough (I've tried!). This is not really something someone can just whip up a quick plugin to solve.

As for other suggestions, I'm always curious to see concrete suggestions for features and the use cases you could use them for. We're always trying to hit a balance between making it easy to get results, but avoiding cookie-cutter engine features. Sometimes people are looking for a built-in feature to implement a large portion of their game logic, but that's not our intent. For any logic specific to your own game, there is no substitute for events. I don't think it should be viewed as a failure of the product if you have to use events, that's actually part of the design.

Also i think C3 should go full on WebGL. Sorry to say this, but forget about canvas2d, there is really no point to have it. It makes everything more complicated than it should be.

I agree completely! However around 10% of desktop devices, and maybe more like 25% of Android devices, still don't support WebGL. I'd love to ditch the canvas2d renderer but I think it's just too soon, I think we need closer to 95% support on all devices.

I'd be happy with some memory controls, load sprites into vram, unload from vram, giving the developer more control (optional) over this is required for very large games to run well on weaker hardware.

The engine already does this automatically on a layout-by-layout basis. The problem with adding more control over this is you create the opportunity for mistakes in memory handling to actually make things worse and use even more memory, or you rely too much on mid-gameplay texture loading which can cause serious jank, which is something everyone wants to avoid.

[quote:2grxwa81]The biggest limitation I see currently is single-thread logic.

See Why do events only run on one core? The blog post goes on to detail many features which modern browsers (and our own engine) run multithreaded.

Ashley , some of the things mentioned here and on other posts are not cookie-cutter engine features. To name a few:

1) A basic platform path finding,

2) A more accurate path finding that can be used in a grid basis,

3) A proper lighting system that is integrated with the ability to have normal maps on the same spites,

4) A masking system that allow any sprite and/or layer to act as a mask upon any other sprite/layer,

5) A text object that supports basic formatting options (bold, italic, underline, color change, size, font, alignment) to be changed within the same text, as well as some scrolling-typewriting functionality,

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

7) Support for curves and curved path movement

8) A way to have any 3rd party plugins auto-update

9) To have behaviors intertwined in a manner that they can coexist and be self aware at the same time (have physics, platform/solids and sine based movements interact for example)

These are of the top of my head and I don't believe they are either niche features nor too genre specific...

Another example of what I've been talking about. Just doing shmup with my mate.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 (set to unbound scrolling), and adding solids to compensate is impossible, due to the enemies needing to fly trough the screen. Those little things matter. And no one is saying to not use events. But mixing plugns and events creates a lot of mixed resoults, as sometimes they just not compatible. Plugins need to be more feature proof and also work better.

eli0s additional option in pathfinding to avoid selected units / integration with physics!

> I'd be happy with some memory controls, load sprites into vram, unload from vram, giving the developer more control (optional) over this is required for very large games to run well on weaker hardware.

>

The engine already does this automatically on a layout-by-layout basis. The problem with adding more control over this is you create the opportunity for mistakes in memory handling to actually make things worse and use even more memory, or you rely too much on mid-gameplay texture loading which can cause serious jank, which is something everyone wants to avoid.

[quote:3rdo5u6u]The biggest limitation I see currently is single-thread logic.

See Why do events only run on one core? The blog post goes on to detail many features which modern browsers (and our own engine) run multithreaded.

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.

I'll give you a basic example of the jank that people notice in C2 games. When a layout is changed, everything prior is flushed to gc, a new layout is started, sprites are spawned etc, but they are spawned fresh when called in the first time in that layout, so creating a big sprite or one with many frames cause a visible stutter. Why? Because it has to be loaded from HDD and as its not present in vram.

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.

Multi-thread is difficult to get it to work well, big engines have it and little engines don't.

It's up to you guys for C3 if you want to be part of the big boys or not, its bluntly put but that's reality, I see it all the time when devs talk about game engines and compare them on forums and reddit. I regularly defend C2 on r/gamedev! Single-threaded on JS which incurs extra overhead is a limiting factor. Most C2 users wont ever hit that ceiling but it's lower than other engines and much lower than big engines that support multi-core CPUs well. So it's a question of how grand do you want your engine to be capable of?