Things I'd like to see in Construct.

Being a game developer both professionally and during my time off there are some things that I would like to see implemented in Construct. This is by no means a whine thread as I find Construct superior to all the other game making tools out there (MMF and Unity).

MMF had some pretty sweet features that I'd like to see in Construct. The ability to use LUA for your projects as well as the debug feature. I won't go much in depth about the LUA feature as I think it is pretty self explanatory what it does but sometimes I find myself a bit limited using the "click-scripting". It might be a case of me just not knowing how to use construct that well yet but I would like see a support for LUA as it is a widely used scripting language that is very easy to get into.

The debug feature in MMF was something that I really enjoyed. Instead of having to use text boxes to print the values of variables you could just use the debug box to see the values of all the variables and loops running in real time. This would be very useful, especially for arrays as they are very hard to keep track of in your head. :)

3D support. As much as I love sprites sometimes I find myself wishing I could use 3D models. Mostly for background stuff. I realize that when it comes to models Construct could never compete with unity but the ability to use models from time to time would be pretty sweet.

There's a debug plugin (3rd party), I haven't checked it but you can give it a try here http://www.scirra.com/forum/plugin-debug-panel_topic48052_post301500.html.

I also remember the MMF2 debug pannel and found it very useful.

I'd greatly like to see Lua scripting too. But that would, i believe, need a major code rewrite. I don't know . How MMF2 even supported scripting at all via plugins ? In the case of C2 i think the engine would have to be coded from the ground up with scripting in mind. The visual scripting would be just a 'frontend' for the script code...

I don't care for scripting, but I dunno if Lua support it's possible at this point in time. C2 was not developed with scripting in mind, in fact it was meant to do the opposite, to suppress that part of game making.

Why would you need to use scripting? I think there are quite enough options with the comprehensive event system and the Javascript plugins.

I'm fairly sure a debugger is on Scirra's todo list.

3D support is such a huge leap for any software. I think it's best if C2 just keeps to 2D games.

A user on these forums already posted that they were trying to create a dialog box (message box). Having the ability to script (javascript) was able to create a plugin for that use.

There are things that construct just cannot do. Either we try to encompass every possibility through event clicking for the user or we have to hope that plugins are written to accomplish the things that they cannot.

My advice to the OP would be to see if javascript can accomplish what you are hoping for with LUA?

This anti coding/scripting mentality on the forums is disheartening. Providing users with as many options as possible should be the goal, not limiting it to a click only interface. Certain individuals do not like coding or simply are unable to do it, and thats why the event system is so great for them. Others love it and enjoy it and are desperately trying to work with the event system in a way that flows like the way they code and script.

I spent good money on the software and so have many others that like coding/scripting. Our opinions are just as relevant as those that do not like coding.

^ Only that this software never promised any scripting at all, it just simply was not C2's goal. It is not a "mentality", there are many reasons beyond "not liking" or not "being able" to do it. Also, many of us make art of several forms, making music and spriting being two things that are very time consuming, why would I want to consume even more time on scripting when I just simply do not have it? I have scripted before, and as a personal opinion I don't see the point of it in a software like C2 and I will never go back to scripting if I don't have to.

^ Only that this software never promised any scripting at all, it just simply was not C2's goal. It is not a "mentality", there are many reasons beyond "not liking" or not "being able" to do it. Also, many of us make art of several forms, making music and spriting being two things that are very time consuming, why would I want to consume even more time on scripting when I just simply do not have it? I have scripted before, and as a personal opinion I don't see the point of it in a software like C2 and I will never go back to scripting if I don't have to.

No one is stating that you need to go back to scripting. Again, for those that are unable to script/code efficiently the event system is wonderful and very well may save you time. For others we feel it slows the process down.

This software provides the means to expand on it with javascript to make plugins and addons thankfully. These provide users that want custom or more in depth features in their games the ability to code for it, so while construct does not offer a direct ui to script, it does work with the javascript.

I understand your position on not seeing the point of it in software like C2. What is interesting is that others DO see the point of having it in software like C2. Again, providing more options for game developers is a good thing, limiting features one way or the other because other users are not comfortable or do not have a preference for them is silly.

We all need to be a little more open minded and understanding of others views and opinions. Whether or not construct ever allows for any scripting doesnt mean the ideas that the users have for it do not hold value.

Could you show a way that scripting can do something that the events system can't?

Keep in mind the complications of the export system, as well as minification have a huge bearing on that.

From what I have gathered, the problem with the event system resides with people that only ever coded or scripted, which is understandable, I have been using software similar to C2 for years and it took me no time to grasp how C2 flows. Hearing that someone feels limited with C2 is a rare thing to hear. Most the time people just want scripting to feel more at home.

I don't care whether scripting it's added or not, I'm indifferent towards it. C2 didn't do this cos users do not like script or are not comfy with it, there's plenty of great coders using it, C2 wanted to revolutionize and I think it is doing a great job. It is very disheartening for people or artists with no coding background to hear about a product that promises to let you make yer game with no "programming" required, only to later find out that if you want to make a good game, you have to actually learn a coding language, the program's own scripting language or use someone else's scripts. A loop that I have seen far too often and one that C2 broke out of and that is the main reason I love it, it delivers on what it promises and it has lots of power.

IMO this is the future for game making, traditional coding to me, it's better suited for applications/plugins and not games, of course this is my personal view. Even the big gaming companies build/buy their own software or pre-made frameworks to make games.

I don't understand why creating behaviors and plugins with the JavaScript SDK is not considered on par with (or superior to, in my opinion), scripting systems in other drag and drop game making apps. Once you get the hang of it, creating behaviors and plugins which add, modify, or even create new functionality, is rather easy. You're just moving the scripting down one level, from scripting directly in an object to an external bit of code.

I've had experience with various DnD systems with built-in scripting, and by far I think the JavaScript SDK gives me more power and control than a built-in system ever did.

This anti coding/scripting mentality on the forums is disheartening. Providing users with as many options as possible should be the goal, not limiting it to a click only interface. Certain individuals do not like coding or simply are unable to do it, and thats why the event system is so great for them. Others love it and enjoy it and are desperately trying to work with the event system in a way that flows like the way they code and script.

I spent good money on the software and so have many others that like coding/scripting. Our opinions are just as relevant as those that do not like coding.

You spent your good money on a codeless developer tool. Whoops.

Nearly limitless options already exist through programming. C2 seeks to port as much of that functionality over to a codeless environment as they can. That's my understanding of it, anyways. If you want a coding environment with WYSIWYG, you have plenty of options elsewhere. And with C2, you have the SDK which is developed hand-in-hand with the primary software. And nobody I've seen is against its use. So if you want to code, use it.

And why do you feel that providing as many options as possible is not a goal here? It's just trying to make those options available without coding. That's the whole point, as it has been since day one so far as I can tell.

If you bought this software to code in a way that isn't accessible in C2, then you made a mistake.

Heck, there are people here who've made things with events and expressions in Construct Classic that I'd argue would rival or surpass the difficulty of doing a similar thing with a coding language. One might ask what's the point of even doing that when you could just use a coding language? I say, why not push the limits?

At the end of the day, if you're going to make an event-based development platform, you need to focus on event-based development as your core tool, to the point that anything else should be an afterthought. In my opinion, if coding is a persons desire, they would be better off developing using a coding language and there are plenty of available options. I realize that there is a barrier to using event-based dev kits for people who are used to coding because what you do in a coding language doesn't directly translate to this. I know because I've had this barrier myself. But that's just the way it has to be. I don't think these types of developments should go out of their way to accommodate language programmers any more than coding developments should go out of their way to accommodate event-based programmers.

I don't understand why creating behaviors and plugins with the JavaScript SDK is not considered on par with (or superior to, in my opinion), scripting systems in other drag and drop game making apps. Once you get the hang of it, creating behaviors and plugins which add, modify, or even create new functionality, is rather easy. You're just moving the scripting down one level, from scripting directly in an object to an external bit of code.

I've had experience with various DnD systems with built-in scripting, and by far I think the JavaScript SDK gives me more power and control than a built-in system ever did.

I agree with this point very much.

> This anti coding/scripting mentality on the forums is disheartening. Providing users with as many options as possible should be the goal, not limiting it to a click only interface. Certain individuals do not like coding or simply are unable to do it, and thats why the event system is so great for them. Others love it and enjoy it and are desperately trying to work with the event system in a way that flows like the way they code and script.

>

> I spent good money on the software and so have many others that like coding/scripting. Our opinions are just as relevant as those that do not like coding.

You spent your good money on a codeless developer tool. Whoops.

Nearly limitless options already exist through programming. C2 seeks to port as much of that functionality over to a codeless environment as they can. That's my understanding of it, anyways. If you want a coding environment with WYSIWYG, you have plenty of options elsewhere. And with C2, you have the SDK which is developed hand-in-hand with the primary software. And nobody I've seen is against its use. So if you want to code, use it.

And why do you feel that providing as many options as possible is not a goal here? It's just trying to make those options available without coding. That's the whole point, as it has been since day one so far as I can tell.

If you bought this software to code in a way that isn't accessible in C2, then you made a mistake.

Why whoops? I made a whoops because I see validity in the opinions others have for scripting and coding with game development? Whoops because you assume I made a purchase without knowing exactly what I was buying? I knew exactly what I was spending my money on when I bought construct. I have followed it for quite some time. I was agreeing with others who make points about scripting and understand their point of view.

Instead of having a constructive conversation you simply point to the door to seek alternative solutions.

Also I remember "day one" including python scripting.

Hi there,

For myself i like the Idea behind Construct 2. It is an amazing Tool.

The only Problem (in my Eyes) is the little 2-Man Team. They can't do all the Million of Things in the same (short) Time.

My wish for the Future is, that all the Programmers that can Help this little "2-Man-Team" should bring in all the Knowledge they have an the "Will" to Help to Push this Great Tool.

Real Programming for Myself it is to Hard and also to Time-Intensive.

Construct 2 is a very good and intuitive Way to make Games.

KMag