How do I encapsulate game logic into components? Is there ANY clean way in C3?

Hi,

I'm a programmer familiar with various other game engines and gamedev libraries. I am looking into Construct3 now to see whether it's viable for quick prototyping of 2d games.

I want to code and experiment with more complex logic.

I've noticed one big issue so far. Construct is apparently targeted towards non-programmers. The whole design is around "event sheet" which means practically all logic (except maybe behaviours) is centralized. This might be ok for some small simple games, but in general it's a bad engineering practice.

I want to break up the logic and encapsulate/bundle it somehow with objects to make reusable components. Of course SOME logic may stay at top level.

Is there any clean way to organize game logic in C3?

PS. I was looking at the scripting possibilities. Unless I missed something, if I use scripted actions or events or even self-standing JS scripts, I need to anchor the logic to the top level explicitly (and it would not be directly associated with game objects). In other words, seems like I have to work around basic design of the framework. The documentation also does not mention such use of scripting.

Its sounds like drag and drop easy buttons.

There's a fair amount you can do with the plug SDK, but I would say that with this being a subscription service, and the runtimes being custom, that's not really doable.

Its sounds like drag and drop easy buttons.

There's a fair amount you can do with the plug SDK, but I would say that with this being a subscription service, and the runtimes being custom, that's not really doable.

are you sure this is the post on this topic? :P

Could your posts be less nebulas?

This architectural question on game logic, what does it have to do with "drag and drop easy buttons"? Perhaps I am missing something so please explain ;)

If you don't understand what I am talking about - let's say I want to tell an NPC object to "run" and then that object should decide what actions to take, e.g. what animations to play, what movement to make. In engines like Unity, Godot (and many others) I would either call a method or send a signal to that object and have a handler.script on that object implementing the relevant logic. I currently don't see a way to achieve something like this in C3 in a relatively clean way.

construct.net/en/make-games/manuals/addon-sdk

Plugs, and behaviors can't know your naming method, in case that's what you are asking for.

The JavaScript scripting feature would allow for some better modularity.

I don't see any non-dirty way to do this with core features of the engine. No, it's not about naming at all.

So you're basically saying that I'd have to modify/extend the engine itself (by creating an add-on) in order to get this kind of functionality and be able to structure the logic better. Well, that's a bummer.

No, it's not about naming at all.

Well its about picking with conditions and events. Scripting not so much.

The only way to make an object that does all that is to roll your own with the sdk like Sprite, or the 3d Object, but that has nothing to do with extending the engine.

Then again events are robust enough to handle all that already and the logic may just be different than what you expect. It works in a linear fashion rather than a object oriented one.

Construct wasn’t really designed with components like you describe in mind.

As advertised it caters to non programmers with its layout editor and behaviors, with minimal use of events.

Beyond that more advanced logic can be done with straight events. It’s a bit quirky in areas but any algorithm can be made with it. And in relation to your original question you can organize things with events but it’s not really modular enough to be be reused between projects. So you end up doing a lot of things from scratch every time.

To make reusable stuff people end up using the sdk to make plugins and behaviors. JavaScript is mainly to tie in to third party libraries, or for performance reasons, or because people prefer it over using events.

Overall construct wasn’t designed to do super structured code like Godot or unity. You can come up with ways to organize things with event groups and event sheets but it’s largely up to individual users.

Beyond that more advanced logic can be done with straight events. It’s a bit quirky in areas but any algorithm can be made with it. And in relation to your original question you can organize things with events but it’s not really modular enough to be be reused between projects. So you end up doing a lot of things from scratch every time.

Thanks, yeah that was my impression as well. I did not look into all details but I am thinking of delegating actions to JS files that would be specific to object types. Still I would need to trigger handlers from event sheet which smells, but at least I don't have to have everything on top level - and I would like to be still able to reuse and and interact with existing behaviours (e.g. physics).

I will looks more into ways of writing own behaviours/plugins/addons, but TBH if I need to implement this myself then I might probably just as well write a game on other engine..

I disagree that Construct caters to non-programmers, that's more a marketing line. It does however cater to solo-devs and smaller projects/teams. I say that as someone who TAUGHT construct to non-programmers for 5 years. I ALWAYS had to teach them programming in order for them to understand construct.

I know what you mean ;) this is a bit of marketing overstatement - clicking out a loop or variable assignment is not that different from typing it in. From my perspective it means it's targeted towards non-SDEs as it does not support object-oriented approach apparently..

Thanks, yes I will give it a try, see how frustrated I can be with having all the logic stuff rigged in a single place (and how much time I could save compared to other engines). I suppose it should be ok at least for simple projects.

another thing I have been doing the last couple years is I make separate event sheets for things like 'PlayerHandling' and I #include that sheet in my main sheet. So in a way I could reuse that sheet in another project as long as I have the same objects and names. I have done that for pause functions and pause menu controls.