It is good time to make the Construct great again

As someone who uses Rpgmaker (and finishes commercial games in it) and dreams of more flexibility in some areas (like the menus, oh dear the menus), I'd be all for Construct going for that market and offering some more options.

There is definitely something to say for having an engine that truly doesn't require you to learn programming, but still also doesn't have you start entirely from scratch. The community surrounding plugins you can just stuff in there and go with is great.

If I had as easy an entrance into starting a turnbased rpg here as I have with Rpgmaker, I would leap at the chance to try it out.

(Rpgmaker also has the advantage of being a one-time purchase instead of a subscription, but I suppose that is a different topic...)

Remember we're a small team with just a handful of staff working out a single office. If you're expecting Construct to dominate the entire game development industry and cover a feature set that would require hundreds of staff to achieve, it's unlikely to happen. I don't think it's realistic to expect so much of us, just like it's unrealistic to expect a small, self-funded team of indie game developers to build a MMORPG on the scale of World of Warcraft.

We really do care and I think we have achieved great things given the resources we have available. It is painful to read people accusing us of not caring and listing things we don't remotely have the resources to cover as their reasoning why.

I know people get tired of hearing me keep saying "we're a small team and we have limited resources". It's because it's true and 99% of the time it's the answer to "why hasn't XYZ been done yet". Claiming everything is broken, limited, or that the team don't care, is unreasonable and also a disservice to the many people over the years who have loved using Construct. I'd also point out the Forum & Community guidelines which cover this as I think these sorts of arguments are bad faith and I don't think that kind of thing should be discussed further on the forums.

I know people get tired of hearing me keep saying "we're a small team and we have limited resources". It's because it's true and 99% of the time it's the answer to "why hasn't XYZ been done yet".

Ashley - a suggestion/request to help with this: expose more of the SDK to allow third party devs to create more powerful addons/effects - we can help XYZ get done.

If you see this as valuable, we can post tight and directed requests for addon SDK features for specific XYZ-like addons (e.g. 3D view change in editor with access to more of the editor SDK / renderer.)

I mentioned RPG maker because it comes with immediately usable graphics--The Battle For Wesnoth-- does the same thing. You kind of program it in WML which is just wesnoth markup language but mostly you get lots and lots of 2.5 fully fleshed out little animation guys complete with default sword swipes and spells. You can get somebody really interested really fast with something that looks that good right away. Better than our default pig asset (not to knock the Scirra pig -- well, not too much).

Do I really want a demo with 3d dice and a pig for my first shot at an rpg in construct?

If you look at the library of 2.5D over at wesnoth you quickly see that it matters as much as the fact you don't have to be able to program.

yours

winkr7

I have been using C2 and C3 for a total of 10 years now. Yes, I haven't developed great games, but I still don't get the point where some users says that C3 is not scalable. Since "scalable" is a term that can be used in many situations, could you provide me some examples so it's easier to understand what's wrong?

Scaleability, in software at large, refers to difficulty/cost/time in adding additional features, allowing more users, and so on.

In games, scalability is the ability of developers to continue adding features/complexity to a game without breaking old code and taking forever to do it. In traditional coding environments, Poor architecture and poorly written code can mean that each additional feature added to the game requires exponentially more time, and risks breaking other features.

In construct, starting a new project is fast. Creating new objects is fast. Prototyping features is a breeze, But refactoring is SLOW and gets even more tedious the larger the game gets. Construct, by its very nature, encourages poor architecture (with nearly EVERYTHING in global scope, simply adding more objects to the project increases the time it takes to add new events). The event system itself, while easy to grasp and use initially, is nearly impossible to follow and implement industry standards for clean code. This is never a problem in small projects, but it is a massively huge problem in large projects. The awful part is that creating clean, SOLID style events, creates a rather large performance burden and overhead and require a ton of boiler plate events just to run. Not only that, you still canʻt create safe ways to interact with previously authored event sheets. Dang if you do, dang if you donʻt.

If you were to make a custom platformer handler, the fastest and most naive way to do so would be simply to make an if/else tree. For simple platformers with only running and jumping, this may be fine. No need to complicate things. But then what if you want add duck, duck rolling, ground pounds, jump forgivness, double jumps, wall runs, wall slides, phaseshifting, object lifting, rewind and timeshift, shooting and reloading, but only in some cases. No that original choice to use if/else trees looks pretty bad. You probably should be using some sort of state machine. But then what if you want the character abilities to be added and subtracted at runtime. There are flaws with using a state machine for complex character behaviors, so now we need a different system where components talk to each other, but remain implementation agnostic.

In order to build such a component system, you really need to the full power of OOP and (very importantly) encapsulation. I can tell you right now, that that construct wonʻt make this easy to make. It also will be difficult to use and not accidentally break. You will spend alot of time repeatedly picking objects, so you can get their array or dictionary, so you can get another array or dictionary so you can pick another object so you can run a custom action on, that should return a value, but canʻt, because reasons. And every function you create has to exist in the global space, even though 90% of them should absolutely be private to only a few objects.

Given the way behaviors and plugins work with each other (not well, unless you can customize the runtime like SOLID does), they arenʻt good solutions either, especially since you canʻt use OOP with them.

For these reasons, construct is "unscalable". Making mario isnʻt too bad, and Iʻve seen alot of people make some pretty cool stuff with construct, but alot of times, the ease of using "construct" becomes more of a burden in those cases.

Remember we're a small team with just a handful of staff working out a single office. If you're expecting Construct to dominate the entire game development industry and cover a feature set that would require hundreds of staff to achieve, it's unlikely to happen. I don't think it's realistic to expect so much of us, just like it's unrealistic to expect a small, self-funded team of indie game developers to build a MMORPG on the scale of World of Warcraft.

We really do care and I think we have achieved great things given the resources we have available. It is painful to read people accusing us of not caring and listing things we don't remotely have the resources to cover as their reasoning why.

I know people get tired of hearing me keep saying "we're a small team and we have limited resources". It's because it's true and 99% of the time it's the answer to "why hasn't XYZ been done yet". Claiming everything is broken, limited, or that the team don't care, is unreasonable and also a disservice to the many people over the years who have loved using Construct. I'd also point out the Forum & Community guidelines which cover this as I think these sorts of arguments are bad faith and I don't think that kind of thing should be discussed further on the forums.

Yes, actually, that's it. Construct is made by a small and passionate team that intends to stay that way and cater to its niche, evolving in an organic manner.

A few years ago, Construct was perfect for me because, not knowing how to program, it still allowed me to do everything I wanted. However, when thinking about larger projects with bigger teams, we started to feel the barriers that are being discussed in this thread.

What constantly comes to my mind is the question, "Is it a good idea to continue in the long run?" After all, Construct is a tool that provides the foundation for my professional life. It's where I derive my income, and there is no option but to take it very seriously and think about the future.

I believe that Scirra, as a company, has every right to maintain the business model and philosophy it prefers, after all, it has been very successful. And for developers, it doesn't seem to make much sense to expect major additions and changes, as we understand that Scirra has its own pace.

Construct is an incredible, niche engine that fits its purpose very well and gives off a strong "Indie" vibe. Understanding how Scirra operates, we have to judge whether it's the right engine for each of our projects without creating false expectations.

I understand where you're coming from Ruskul but I don't necessarily agree. I don't think it's fair to try to strictly apply code architecture principles to Construct's Event sheet system as they have been written with typical coding languages in mind, and not event sheets.

Instead I think it's far more sensible to apply a set of new coding principles that are designed around the event sheet and Construct's addon architecture instead.

The idea that because you might outgrow an addon then you should absolutely avoid it doesn't make sense to me. If you truly have a good reason not to use built in features, I think writing a new behavior is a far better idea than trying to handle everything using events.

I have seen projects scale just fine within Construct's features, but it implies that you need to design your architecture around what's there, not around arbitrary coding style made for other software development environments.

However, if you would rather stick to paradigms you are already familiar with, then I would agree that maybe construct events aren't the best choice.

About scripting, while I agree that it's lacking in some aspects, there are many ways to extend it and break free from many of its limitations. In this aspect, since it's all JS, the sky is the limit with what you can do. Especially if you would rather ditch behaviors and write your own systems, I think writing your own behaviors in the form of scripts can fix whatever issue you have with the program.

Also, with the recent addition of TS, and with the VS Code extension, I think Unity C# with Visual Studio isn't that much of a better coding environment compared to C3. The only thing maybe is that it doesn't integrate into the editor, and C3 scripts aren't treated the same way as Unity scripts.

Ruskul Thanks for the details about scalability. I understand now what you mean, though, I agree with skymen that you can't expect Construct to be as another language, because that's the way it's build.

You need to use the right tool for the job you want to do. So, yeah, if you want to do a 3D MMORPG, Construct isn't the best tool to use, but for "middle" difficulty projects, I think an expert user can still mitigate the drawbacks of Construct with the experience.

Your example for a complex platformer is clear, I have experienced something like that working for some clients. Yes, it's a bit complex, but still doable. To me, as far as I know, it's still faster than code the game from scratch, even if sometime I spend 1 or 2 hours on one issue, overall the time spent for the whole project is still worth compared to do everything from scratch.

So we have to balance 3 things:

1) Understand the limit of the engine

2) Understand the experience of the developer with the engine

3) Understand the complexity of the game

Can you put a nail in a wood board with a screwdriver? Yes, but it's not so easy.

Should you try to put the nail in the board with the screwdriver? It depends.

Do you have an hammer just next to you? If no, and you have to drive two hours to the closed depo and come back, to buy a hammer, would you try with the screwdriver?

It depends on your experience, if you have already hammered a nail with a screwdriver many times, it might be worth to invest 1 minute in doing it, if not, and you plan to hammer a lot in your life in the future, better go to buy the hammer.

So, a lot come down to personal experience. For example, for multiplayer games, I started to develop a reusable event sheet. The main program call a function and the function call the events in the multiplayer event sheets. Yes, it's a double call, but it let me use generic multiplayer code for more than one project.

For audio management, I have a standalone event sheet, and I reuse it for all projects that require to play audio with music/sfx on/off and setting their volume according to the options.

While you might have obvious issues with the increase number of object in the projects that let you waste time in picking among those, you can still have benefit of using groups, events or even variables to enable/disable part of code or recycle it.

By the way, if you organise objects in folders, when adding a new condition or action, you can simply type its name to filter out all the other objects and that is pretty much the same time as writing code, if not faster. This is present in both C2 and C3, so having too many objects to filter, isn't really a big deal, unless I have misunderstood what you meant.

It would be nice if Scirra talked to users about things they are planning to add/are working on/thinking about adding early on.

Right now it's always, SURPRISE we added this new feature to address the thing everyone asked for, and sometimes it's really great, sometimes it's only okay, and then sometimes it missed the point completely, or is half baked. You never know.

But you always know that this is what you get now, no matter if you like it or not. You might get some changes through or a small addition during Beta, if you are around and have time to test, but the basic way the problem is solved or not solved will not change, and any hope for a different solution is now forever completely out the window.

So much unnecessary work could be avoided IMO if users would be consulted earlier in the design process, I'm fairly certain that many things could be scrapped before even a single line of code is written because it's simply something no one actually needs. That extra time could be spend on making features more complete by talking to the people who actually use the engine.

This doesn't have to be something completely open in the public if there is a fear of discussing features that might never actually arrive, but maybe specific people like R0J0hound, Overboy, skymen, Mikal, etc. could be involved in giving their thoughts and early feedback before production even starts (If they would be willing to spend some of their time on this).

Setup some NDA that they are not allowed to talk about it, or what ever it takes to get the people who, in the end, have to actually use these features, involved in the conceptualization and development process.

Right now it can sometimes feels a bit like damage control when a feature is released that has missed the mark.

Scaling to large projects is difficult even when you fully code things. There's an art to learning how to manage it and design things so that you can take them as far as you want to go.

The JavaScript (and now TypeScript) support in Construct is partly there so that if you are willing to code, you can use it to help scale your project further, or do advanced things beyond the capabilities of the built-in plugins and behaviors. For example you could write a custom pathfinding algorithm, running in a web worker for multithreading, and tweak it to match the specific needs of your game. You don't need to use the addon SDK either, so you can bypass all the configuration stuff you need to set up event sheet features, and just custom code something for your project. Then you can still write things nicely with modules and re-use that code across different projects, too.

So if you want scalability, or to do more advanced stuff than the plugins/behaviors provide, that's part of the reason it's there! You can usually also use event sheets for custom logic too of course - it just takes more work. Construct has always been designed with the philosophy that the built-in stuff covers common cases, but is flexible enough to adapt to specialist needs, or if you need to do something really customized and advanced, then there's capable coding features too.

I think we're posting at the same time, but I'd add: one of the reasons we have weekly beta releases is to get feedback as quickly as possible and iterate on it. We do try to release features as soon as is reasonable, because we don't want to spend ages working on something that isn't quite what people want. But when it comes to feature suggestions, often everyone wants something slightly different, or different people have strong but contradictory opinions on it. Nothing is perfect and will satisfy absolutely everyone, and I don't think that means we are doing it wrong.

> I know people get tired of hearing me keep saying "we're a small team and we have limited resources". It's because it's true and 99% of the time it's the answer to "why hasn't XYZ been done yet".

Ashley - a suggestion/request to help with this: expose more of the SDK to allow third party devs to create more powerful addons/effects - we can help XYZ get done.

If you see this as valuable, we can post tight and directed requests for addon SDK features for specific XYZ-like addons (e.g. 3D view change in editor with access to more of the editor SDK / renderer.)

This please.