This would be easier in JS, but then makes for some gotchas - for example if you put an array object's array in to an object's instance variable then change it from there, both get updated, and that might not be what you wanted.

Better to have the gotchas than to not have proper arrays at all! I'd rather have it always be reference and if you want by copy you can manually copy the array yourself. This is just an organization feature, really.

I'm not sure how exactly you think this would really work (...) you need the condition to pick the instance to run the actions on, so there needs to be a condition involved either way

I'm not sure what the problem is. The current system is to have an event where we pick a variable out of an object, corresponding to the UID that we want to work with. Then we have another event that picks that object by it's UID, and we perform actions on it.

An example: say we want to get the fire rate of a turret. The current workflow is like this:

• Read the UID stored in the array "players" at X position 0
• Pick the character object with the UID above
• Read the turret property of the character object, which will be a UID (but is in fact just a number)
• Pick the turret object with the UID above
• Read the fireRate property of the turret object we just picked

With my proposed system, you'd have two ways of doing it:

• Call the expression players[0].character.turret.fireRate directly. There is no ambiguity at any point about what you are referring to, and the SOL is never modified.
• Use the "pick an object by UID" condition to pick players[0].character.turret, then read the "fireRate" property. The expression editor doesn't understand nested expressions right now.

This example may sound weird, but let me give you a typical scenario of an RPG:

Each character has a healthbar and an inventory with N slots

In the inventory, on slot 0, there is a fire sword

That fire sword has a name, damage, attack speed, critical hit chance, etc.

That sword's damage and critical hit chance is also divided based on it's fire damage and slashing damage

Really the only problem is that the expression editor doesn't understand nesting (because as far as it is concerned, a UID stored in a variable is just a number), the rest is all secondary. Sure we could try to think some magic with regards to modifying the SOL, or calling methods directly by reference, but that's all secondary.

It's feasible to make a plugin that does exactly that with the current SDK, I believe, but we'd need the path expression to be surrounded by double quotes, like jQuery Selectors. It would be better if it was more integrated with the SDK.

[quote:28918sp9] 4 - First class functions. You should be able to return functions as well as store functions as properties of an object. This is something that javascript can already do, so why not?

Again, if you just throw out a programming language feature, how would that really look in the event system? And why would that be useful?

Maybe I don't need to pass around functions, sure, but we need at least a way to have methods without having to clutter the namespace with object-specific functions, as well as a proper way to do callbacks (again, without storing function names in arrays). If we were able to store functions in an object's property lists, that would solve the problem, and if we're doing that, why not go all the way and allow expressions to be passed around? Again, that is secondary, the primary goal is just to allow objects to have their own functions without polluting the global namespace with functions like addItemToPlayerInventory(item,quantity,playerUID)

I'd add most of the other suggestions in this thread have been suggested several times in the past - we have a very long todo list, and a finite amount of hours in the day. So if you really want a feature suggestion to be taken seriously, you should go in to detail about how it would work, give several examples of previously difficult things that become a lot easier with the feature, and some reasons why it's important enough to do before all the other feature requests we have!

Well right now I'd say the biggest thing is to extend the SDK, and for that we need an extensible editor, and for that we need C3, so I think you're already on the right track there. It's hard for me to gauge what's easy and what's hard to do since I don't know the internals of the engine.

Also some kind of vector type for 2D/3D

I think there was a vector type, but Ashley removed it due to it generating too much garbage (if I recall correctly, it was instantiating a new object every time you wanted a vector), and therefore overworking the GC.

This was a long time ago, though, and things have probably improved now that we have JIT compiling and smarter GCs.

These are all very basic features and the argument that construct users "dont need" this kind of functionality is kind of weak, games use data types to simplify code, whereas construct forces you to build things in boilerplate using floats and ints and basic types, and makes using proper complex data-types extremely annoying.

Amen to that.

Having to store references to other objects by storing their IDs as a number, then having a sub-event pick them out is garbage. Same goes for polluting your function namespace by creating pseudo "methods" that take an object ID as a parameter.

Also having to attach arrays to objects, having to dynamically spawn dictionaries, having arrays storing references to dictionary IDs, it's all horrible hacks everywhere if you want to implement a proper data structure, you usually end up reaching for the SDK all the time, which is not ideal since it breaks your flow and saps motivation.

4) Some way to have Object "methods" or perhaps some way to link an Object method to call a Function Event?

5) Function definition markup/tags to define what params a Function needs and is visible in Action Function call dialog

6) Return multiple values or an array from function

Love the suggestions!

A few additions:

1 - Start treating arrays as a proper type, instead of an object. We have string, number and bool, why not array?

2 - Same goes for dictionaries (AKA hashmaps, AKA associative arrays), so that you can do array["position"] as well as array[1]

3 - Pointers as a type. This means you can store references to an object inside another object, as a property. Right now you can do this by storing the object's ID, but you can't do stuff like player.weapon[1].destroy() in a single event

4 - First class functions. You should be able to return functions as well as store functions as properties of an object. This is something that javascript can already do, so why not?

5 - N-Dimensional arrays, as well as arbitrarily nested arrays. This, combined with the points above, would allow you to express things like player.inventory[0]["quantity"] = 1

This is all speculation, but from what Ashley has said in the past, I'm pretty confident that construct 3 will be an HTML5 editor, won't be browser based, won't be "in the cloud", won't be subscription based, and will remain a desktop app, with technology behind the editor probably being HTML5.

This has several advantages:

• Linux/Mac/Windows support out of the box
• Fewer discrepancies between editor and runtime (such as shader bugs)
• Code reuse (since everything will be javascript)
• Better and more extensive API for plugin developers
• More editor features (since we won't be limited by a third party GUI API like the one in construct 2)

What will likely happen, and what makes the most sense, is that c3 will be a javascript app compiled in NWK (or similar) to turn it into an executable, with a decoupled "compiler" that spits out your games.

really tired of repeating it all

I believe a stickied post or a blog post would help here?

I mean it's obvious for you, and for forum regulars like me and others here, but many new users have never read the other posts, or at least they pretend not to. A sticky could alleviate that, I think.

I'm just pointing out that the less layers involved above DirectX/OpenGL, the better the performance and control over his own program that Ashley will have.

Yes, but at the cost of development speed. Also I think "control over his own program" is a bit of a dubious statement. By giving up on code provided by browser vendors to work around limitations, bugs and incompatibilities between different configurations/hardware setups, you're absorbing responsibility for overcoming those problems yourself, polluting your codebase with patches. The way I see it, you lose even more control over your own codebase, since you keep having to put dirty hacks to make it work with another set of "third parties".

Of course going down anywhere below C++ and a graphics API is entering into layers that I would never expect a lone developer to code for, but pretending that HTML5 works how it was supposed to at the export side of things has to stop.

The future (for now) is javascript, that much is pretty clear - the discussion is whether things are moving at an acceptable pace (you say they're not, I say they are). Unless something changed and I didn't notice it, tech such as NaCl and PNaCl aren't moving forward. Even if you think HTML is a bad choice, what other option do we have? Haxe is a pile of garbage documentation-wise, just look at their tutorials and try to follow along - it looks like a graveyard of broken changes - nothing ever works like the docs say they should, and even the standard library is unstable, not to mention the libraries/packages (which are third parties, btw). So what about a native exporter for Android? Well there's no such thing: android apps run on top of a virtual machine, and even before that mobile games used to run on j2me which is now extinct. I pity the ones who developed an exporter for it. Oh wait...

Maybe if there was one console that could actually run REAL games (made in HTML5/WebGL from C2) well then we'd all be happy, but as long as everyone is using a million different devices and platforms, the ability to have my game work badly across all of them is no good compared to just one export platform running perfectly across the majority of my customer/userbase

That's the whole point. Everyone wants that. Your choices are:

• Haxe - broken spec, outdated/wrong docs, small community, not production-ready
• Java - they haven't delivered on their promise of "write once - run everywhere" yet, why should they start?
• Air/Silverlight/whatever - so, like, wrappers? Also, as you can see, they're all dead by now
• HTML5 - big performance leaps every year, growing capabilities, multi-billion dollar investments, humongous community, and we already have dedicated HTML5 devices

I can do enough in Construct 2 to make my games, the bug fixing and runtime performance is all I need to be happy. Editor-side C2 works way better than any engine as-is for 2D games. I see no reason to update the editor aside from making it easier for plugins like Quazi's Q3D to control more of the GUI.

The runtime already does nearly everything I want it to do, it's the editor that gets in the way. Developer time is much more valuable than machine time! When I making/use external tools to simplify development I feel like it's a huge waste of time, that I'm fighting the IDE more than being aided by it, especially considering there's no easy way to integrate tools to the IDE (without going through ashley, a la spriter) so you're forced to close the editor before using them (since they modify the XML directly). The interface is the biggest hindrance for gamemaking for the kinds of games I like to make.

Performance on the desktop, at least for me, is great. Mobile games have good performance as well, even on my comparatively ancient Galaxy Note 2, provided you keep in mind that mobile devices are basically toys

Pictured: a modern mobile device compared to a modern desktop computer

Most mobile games are a joke, the top selling games rarely have more than 50 sprites on-screen at a time, and yet you see people here wanting to create mobile games with 1000 sprites, all with physics enabled and two/three effects, and hand-painted full-hd rotating backgrounds. Native isn't going to get you there, and even if you were a programmer god and could create and engine entirely in handwritten ASM, I doubt it would do it either.

If only people would publish their games for others like me (or Ashley) to pick apart, we could point out the problem and optimize them. Heck, I might even sell that as a service.

[quote:17azthjc]We know from painful experience that letting a third party layer of software come between the platform and the developer ultimately results in sub-standard apps and hinders the enhancement and progress of the platform.

I disagree with that statement completely. Reliance on third parties is only bad if you suffer from vendor lock-in (which we don't, by the way, the closest we get is over-reliance on chromium, which isn't even that bad since chromium is FOSS). What you're calling "third parties" actually means "abstraction layers" in this context, and those are the holy grail of computing, and has been that way since its inception.

It is obvious that the more layers of abstraction you have between you and the metal, the slower things are, but the more layers you remove, the more you start finding that writing software borders on the impossible, culminating in "real programmers use a magnetized needle and a steady hand". For example, buggy and bloated as graphics drivers may be, no one would dream of ditching them and pushing raw instructions directly to the GPU, even if those ended up being a thousand times faster than going through the drivers.

Same goes for the myriad of third-party-reliant technologies used by Scirra to provide fast turnaround, easy gamemaking capabilities and seamless portability. To implement those by hand would require titanic efforts that a solo programmer just can't cope with, regardless of his "rockstar" status. Ashley has stated multiple times: bringing feature parity to a native exporter amounts to writing a browser engine from scratch; and lest anyone thinks this is easy, remember that Opera is basically a wrapper nowadays, even their multi-man team and 2~3% market penetration (which is huge when you consider the numbers we're talking about here) wasn't enough to convince them to stay (nevermind "switching to") in-house.

If we go by what the market is showing us with regards to other game-making tools, as soon as you start writing native exporters, your product is frozen. Feature development slows to a glacial pace and all efforts are shifted to attempts to bring feature parity and bug fixes.

- Set "myKey" to "myValue" (only writes to cache)

- Write "myKey" (writes for real and is asynchronous)

I agree with rex here - the only difference is I would drop the "write" action entirely. This proposed schema looks like many of the modern key-value storage schemas, which don't truly commit the data to disk until some time later, hence the term "eventually consistent". This shows that the proposed flow is a pattern (as opposed to an anti-pattern).

The system as it is implemented now is close to the way it works in javascript, and I'm used to the async nature of js, but I believe it is very hard for beginners to grasp: remember some people have difficulty with arrays and some think variables are too hard. I'm not saying constuct should be designed solely for those people (lest we become like some other game-making software out there *cough*), but it should at least cater to them if it doesn't get in the way.

The benefits of a "fake write" with posterior flush are reduced complexity for the dev (which is one of the strong suits of C2) and performance (since you don't have to wait to read values you just set). The only (slight) complication for you Ashley would be to ensure that writes issued in order get committed in order as well, and if there's a conflict, last write wins.

It would be worth it to investigate how writes commit if the application crashes before receiving acknowledgement (different engines may do this differently). If it commits even without acks and "last write wins", as I suspect it happens, then there is no problem at all.

Nesteris Yep, actually they said 200 releases when the site went live too, same goes for 2 M download, they were not yet at 2 M...

I guess marketing and rounding up can go together, even if I think it is kind of cheating..

to be fair, that site wasn't publicized anywhere and construct 3 doesn't exist either, so the way I see it they get a pass. Does anyone have any doubt that we'll see r200 before construct 3, considering we're on r199? I mean unless ashley gets run over by a bus or something, r200 is pretty much inevitable

mind mapping?

You don't know mind mapping? Oh boy it's your lucky day!

Mind mapping is a technique to help you sort out your ideas, and can be used for project planning, todo lists, project management, brainstorming and all sorts of things (I've even seen it used for bugtracking/bugfixing). You just make a big diagram to categorize your ideas/tasks/whatever in a hierarchical form, thus creating a "mind map" of your thoughts and their connections. It's sincerely fantastic for everything (including game design and programming), and vastly superior to todo lists.

Check out freemind for a FOSS alternative

There's also simplemind as a good commercial option. Also available for Android and Apple, and it's really worth the price.

I understand your opinion but as a designer I disagree with it. If you suggest make the editor support CSS instead of make the editor skinnable your not giving the real problem to Ashley solve, your are giving only one limiting solution. The end user needs a skinnable editor, if it's better to do it through CSS or other method is up to Ashley to decide based on all the other decisions he will need to do for the engine. If in the design path chosen by Ashley CSS ends up not being an option, then by your suggestion we will not have a skinnable editor, even though maybe there's other ways it could be implemented inside those restrictions.

So in my view there's no harm in asking requests that are not strictly architectural. Ashley can analyze what's needed to make that particular feature feasible and decide what is needed to change in the Construct architecture to make it happen. If Ashley is willing to make architectural changes...

Hm. Yeah you're absolutely right, requesting "CSS support" is no different than asking for "C# exporters", it's focusing too much on the means instead of the ends. Ashley should be the one dictating the technologies. 100% agreed.

I think megatronx gave a good idea in that sense, just start a topic where users can vent about their current frustrations with the current IDE and other users could propose solutions to them.

But you can see what I'm trying to say here, right? Just don't allow C3 to become a bag full of special cases, exceptions and niche features (C2 is becoming more and more like that recently)

So right now. The list would support all your posted ideas. Though it does come down to. how flexible the current system is, how much needs to be redone, and what Ashley's values of the suggestions.

Oh, I know, I just wanted to make it clear for everyone that this is not a place to request trivial things. As it stands, people will eventually jump in this thread asking for things that can already be implemented (i.e. "there should be a plugin for adbizz" or "make a physics plugin using PunyPhysixz"), or features that are too niche and would be better expanded as an architectural change (i.e. "make a plugin for damage types" - this could be made much easier if we had a better way to fold away or abstract object variables, or using your "generic object" idea).

Some (imho bad) ideas already requested:

• Make the editor skinnable (a.k.a. "make a dark theme") sounds like a nice idea, until you realize you can just say make the editor support CSS and get something much more versatile, while still getting everything you want
• Support for multilanguage also sounds nice, but you can instead ask for make the editor support third-party javascript libraries and get access to tons and tons of free, open-source translating libraries already available as well as other nifty stuff for drawing, maths and lots of other things
• we need a menu editor is desperately needed, but nowhere near as flexible as make the runtime support sub-layouts

Some grandiose ideas are better here (some great ones already in this thread and the document!), such as increased versatility for the layout editor , allowing you to customize it in such a way that in addition to supporting top-down and sidescrolling views (which is what we have currently) it will also be able to handle isometric, 2.5D and 3D. This should be done preferentially via plugins or config options, avoiding hardcoding as much as possible.

[quote:hxkchvw4]I also think each one of us should write down what is annoying bout current IDE workflow.

Want to start another topic? I'd post there.