However I gotta say you need to pull up your sleeves and do some work. many of your requests require code writing programmers to do all the time, often with no benefit. All they have are lines of code and then they have to compile and execute. There are no visual tools and inspectors. In fact C2 has probably the most robust API of any game language ever. And yet there is complaint that it doesn't do AI, Isometric so on so forth. Fimbul most API's don't do what C2 does at all. they are first and foremost renderers and 3d/2d mathematical apis.

Whiteclaws and jayderyu:

I'm not saying Ashley should create a build-your-own-ai interface. I'm saying the plugin SDK should be good enough for me to create that myself.

Check out Three.js, jaws.js, Pixl.js, Craft.js, Unity API, not a single one of these game engines can hold a match to C2 inferno in comparison of API. If you want to look at extensions done by other people then that's another matter, but that same principle applies here. Some one has done AI works, Isometric tiles and more. These other groups have produced massive games from rudimentary api's that have zero to no game logic and still pull of games like World of Warcraft.

These other frameworks are flexible enough to allow you to use your own formats, and allow you to build your own tools - what is called a "pipeline". Do you think WOW programmers did everything in code? No! They obviously built their own map editors, dialogue editors, and everything else they needed to make a game.

My point is that C2 is very impenetrable if you want to build your own tools to help you make your game - right now the only option is to crack open the XML files it generates and hope you didn't have a syntax error somewhere. I want ashley to make an IDE SDK so that I can make my own integrated editors to use inside C2.

Most of C2's limitations aren't limitations to the majority of gaming industry. Because once they get to work they aren't waiting on Ashley to do the grunt work for them.

Yes! Yes a thousand times this!

The problem with C2 is that, often, when you run into a problem, you have to wait for Ashley to fix it. There are no official ways to fix things yourself. It's too focused on beginners, and advanced users (those who know javascript, even if just a little) are left wanting.

Now you may ask, "hey, fimbul, why don't you use pixi.js instead?". I could do that - I know programming enough that I'm confident I could code an engine in pixi. However, I like the eventing system, I like the webgl effects, I like being able to easily change properties of my project, and have minification and png-compression. I like having Ashley focusing on performance while I cruise by.

Look at how powerful unity's extensions are: you could implement construct 2 as a unity plugin if you wanted! Now look at how pitiful c2's plugin SDK is.

Here are my main requests

Functions and Array as primitives like the Number/String

Modularity through Groups

Asset store

C2 IDE inherently group development tool.

We are in agreement. Also agree with your proposal for how function syntax should work. I also want to add that, since arrays are primitives, you'd be able to pass arrays as parameters to functions - that would rock!

As long as everything's running in javascript, the performance is never going to be as good as it could be, javascript is simply much slower than any native C++ code and theres nothing that can change that.

This is not the case at all. Yes, interpreted javascript is slower than C++, but that means nothing.

There are JIT compilers, for instance, and nothing prevents a native compilation from javascript to raw x86 code, generating equivalent performance to C++. The only limit is how "clever" the compiler is.

If you really want performance, the argument never ends: why not create the entire engine in C, which is much faster than C++? Why not create the engine in assembly? Why not create the engine in x86 instructions? There's no limit to how deep the rabbit hole goes - it's always a tradeoff.

Thing is, if you want to create a tool that is easy to program and can make use of the best (and bleeding edge) technology available, javascript is your best bet. Server side, there is very little that can go faster than javascript (node.js is way faster than .net, for instance). Desktop wise, we're playing catch-up, but we're almost there. Mobile, we still have a ways to go, but it will get there. The latest devices are already good enough, it's just a waiting game now, before they're widespread.

A lot of people, i'd even say the majority, use tools like construct/gamemaker/multimedia-fusion etc. because they want to make their "dream" game, not because they want to make their game as marketable and cross platform as possible. It's a hobby, and i think enabling people to make their game as big and complicated as they want within the scope of current hardware, rather than force them into cutting back so many features modern hardware would allow, makes C2 a lot less appealing to a lot of users.

am very, very confused with your post. You said "enabling people to make their game as big and complicated as they want [...] makes C2 a lot less appealing to a lot of users", which makes no sense.

Then you said

A lot of people didn't leave because we got tired and stopped using the software

ait, what? You're saying people got tired and stopped using the software, and for that reason, they didn't leave?

I think I agree with what you said, or maybe I agree with the opposite of what you said? I can't be certain.

I gotta agree with almost everything here. Except the arrays and dictionaries, I have extensive systems that use arrays that would be far more complicated otherwise.

I'm not saying arrays should be abolished, I'm saying they should be more integrated

Right now, we have two types of variables, string and number. I want more:

• String
• Number
• Boolean
• Array
• Dictionary
• Object (yes I know you can do this with IID pointers, but it's clumsy - besides, why not implement it natively?)

This way you can have an array of numbers and text, just like you do now, but it will also be possible to have an array of objects (a preselected objects list, or pSOL, for advanced users).

Example:

With a dictionary of arrays of text as an instance variable of an object, the syntax would be object.dictionary["key"].array[position]. This looks way more complicated than it is. Look how easy making an inventory would be:

• player.inventory["name"].slot[0] ? get the name of the item in the first slot of the inventory
• player.inventory["quantity"].slot[3] ? get the quantity of items in the fourth slot (not third, since it starts at zero) item in the inventory
• player.inventory["id"].slot.Width() ? get the number of slots in the inventory

Sure, why not? Construct's price has been steadily rising as you surely know (since you're an early adopter). Also, there's no reason why the business edition can't be more powerful than the standard edition (collaboration features look like a nice fit there).

Solutions:

Keep in mind most of the following solutions have been requested or mentioned many times already:

[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16]

So, in the last post I detailed the problems we face with trying to create big games in C2, now let's talk about solutions that can be implemented without taking the next 10 years:

Widgets:

We need some way to simplify object management, and I think a good place to start is to allow better object grouping. I know we have families, and those allow things like placing a head onto a body, or a healthbar onto a target, but we need to go deeper. We need widgets!

• More layers of object-nesting: We can have multi-part objects, but why not have those multi-part objects also be parts of other objects? Say you have a complex gun made of several sprites, particle emitters, webGL effects, and you want to use that gun on a spriter character with independent limbs?
• Functions as part of objects: Instead of coding things as a series of instructions in line, you can "group" related functions together, and fire them using a function! An enemy needs to reload? Regardless of his race, weapon or current animation, just use the action "reload" on that enemy!
• Variable grouping and variable nesting: See this post
• Deprecate the array and dictionary objects: We have strings. We have numbers. And then we have the array, which is just a numbered container for strings and numbers, and the dictionary, which is a string-coded container for strings and numbers. Those shouldn't be objects, they should be variable types (for global/local variables and for instance variables). If you want to know the name of the third item in your player's inventory, just do player.inventory[3].name (this example is 1-based, but the final result should probably be zero based) - no need for a separate array object! Want to know the score of a player named Fimbul? Just read Scores["Fimbul"] - no need for a separate dictionary object!

More powerful SDK:

This one is for plugin/behavior developers: How about more controls? Dynamic properties based on user input? Sliders? Checkboxes? Radio buttons?

Many of the more advanced recent plugins have special interfaces inside the editor - tilemap and spriter are two examples. Well I want to have my own interface too!

What if I want to create a dialogue editor, or a state machine, or a map editor? Right now, I would have to create my own editor to manipulate XML files and save them again. With an IDE SDK, we could create interfaces that do complex things automatically!

Better project management:

We need ways to simplify project management. We currently don't have ways of collaborating - only one programmer can work at a time. That single programmer is also responsible for updating graphics and tweaking effects, music and sounds, story, balance the game (change health/damage values, etc). While this is fine for a small product, if construct wants to see serious use, it's going to have to learn to play in a team, with multiple people working on the same project at once.

Middlewares:

We already have some middleware integrated with construct, but we could always use more! Right now, the problem is that integrating middleware with construct 2 is a task that can only be accomplished by Ashley - if we had an API to communicate with construct, we could hook the tools ourselves!

Here is a list of some tools, I included spriter and tiled (both already integrated) to show that C2 is no stranger to using external tools.

• Spriter (art and animation)
  
• Tiled (map editing)
  
• Storybricks (emergent AI, NPC behaviors)
  
• articy:draft (RPG workflow, dialogues, map editing, a ton of stuff)
  
• Chat Mapper (dialogue tree editor)
  

I've been sitting on this post for a long time, and was waiting for the multiplayer feature to be released before posting it. I'm releasing it now before the next big project is attempted.

Many people are always complaining about the lack of big, serious projects in Construct 2, and I agree! All that we see right now, at least in terms of released content, are small webgames/freegames/mobile titles. Now, when I talk about big games, I'm not talking in terms of hours - the engine is already capable of delivering experiences such as spelunky, super meat boy or even mark of the ninja (which only recently became possible due to spriter). If you understand construct eventing enough, you can even succeed pulling off titles like Braid.

So, this leaves construct in a very nice position regarding some genres (keep in mind we're talking about the desktop):

• Platformers ✓ Levels can share a common event sheet ✓ Cutscenes can be done in different layouts ✓ Spriter enables powerful animation features ✓ Most stuff can be tracked using global variables (stats, combos, achievements)
• Point-and-click adventures ✓ Levels can be done in different layouts/sheets ✓ WebGL allows for stunning scenes ✗ Branching narrative gets confusing very quickly
• Racing games ✓ Plenty of third-party plugins and behaviors allow for cool movement ✓ Particles and physics allow for dynamic tracks ✓ Automatic layout memory management allows for BIG tracks and lots of AI players ✗ Upgrades that cause complex interactions get unwieldy quickly
• Vertical/Horizontal Shooters
• Physics-based puzzles

Some genres, however, still remain remarkably difficult to attempt with construct. You may notice that the genres C2 has difficulty with are the most ambitious genres - this is the type of stuff people attempt with unity or write custom engines, but I don't see why that has to be the case. I would like to, for once, see a big, complex, ambitious project succeed:

• RPG (à la RPG maker) ✓ Dialogues can be easily tied to NPCs via the use of families, and downloaded individually ✗ Tilemap object is very deficient: can't add properties to individual tiles, no multi-tile entities, can't apply shading to single tiles, collision mapping must be done with separate object, tile placement is cumbersome, "open-world" layouts eat lots of memory (there's no option to only load visible tiles) ✗ Can't do isometric (yes I know you technically "can", but there's a lot of pain with back-to-front rendering and z-ordering for pseudo-3d complicates matters further) ✗ NPC movements (i.e. wandering, chasing, fleeing) must be coded by hand (a behavior that attempts to do this would have to tie into c2's tile structure, generating a dependency that the SDK doesn't tell us how to address) ✗ Inventory is hard to manage, requiring separate projects and, in some cases, even plugins ✗ Windowed interfaces are hard, little can be shared and there's no concept of "sub-layouts" to ease this. 9-patch object sometimes shows seams, hardcoded interfaces are tough to reskin, sub-components (sliders, checkboxes, accordions) are hard to reuse since "widgets" don't exist
• Management games (sim-*, *-dash,*-tycoon) ✗ Complex interactions are hard when all you have are global/local variables (you can't even group variables) ✗ Some things that require interconnection are utterly alien: how do you implement a road network (including avenues and traffic lights)? A power grid (including blackouts)? ✗ Interfaces are hard: see above ✗ Saving and loading must be coded manually, since in these types of games the position of objects don't really matter all that much
• RTS ✓ Advanced picking features, as well as families, allow for multi-team combat ✓ Composite units (tanks with turrets) are allowed ✓ Saving and loading can be handled mostly automatically ✓ Terrains/scenarios can use different layouts while sharing event sheets ✗ Coding AI procedurally gets messy very quickly, to work properly you need to develop a finite-state-machine interpreter by hand ✗ Drawing primitives like "selection boxes" or targeting lines don't exist, must be done manually by stretching sprites ✗ Objects require many variables, which cannot be grouped or organized in any way ✗ Functions are procedural and cannot be tied to objects - having a unit aim at another and chase it requires creating logic that doesn't make sense outside of a given state (such as "chasing"), as well as keeping instance-id references and repicking almost every tick
• MMOs ✓ Real-time games are finally possible ✓ Can use peer2peer architecture to reduce bandwidth costs - you don't even have to host your own signalling server ✗ Server side coding must be done outside construct, with platforms like node.js, unless you want a flimsy server running on a browser tab (the sysadmin inside me cringes at the idea) - also you can't access databases or do any heavy lifting.

Now, I understand that in the past, performance just wasn't there - but now the desktop side of things is already fast enough that such projects can be attempted in seriousness. It may look like we need a TON of features to get to that point, but in my next post I will propose some features that will alleviate this burden without placing a ton of work onto Scirra.

Doesn't construct already do variable nesting? Like, if I drag a global into a group, it only functions in the scope of the group. Or am I misinterpreting your meaning here?

No, you got that wrong. I don't mean variable scoping (this is already implemented, like you said, and works fine), just variable nesting (which is just cosmetic) - similar to how javascript objects are accessed:

player.equipment.armor.blunt.pctResistance

As for instances vars...I've never had a need for that many, but...yikes. Yeah, if I was in that situation, I would want folders too...

Yes, you got that correctly. What I wanted is a solution like this inside the instance variables pane (the image is just an example I took from an e-commerce widget thing, ignore the text and focus on the functionality only):

Variable nesting in general would be super useful

Also, instance variables could benefit from this grouping as well.

I don't get why this isn't already implemented, it seems so easy, especially considering it's only a visual thing with no impact whatsoever on the game engine.

Here's an use case for variable grouping: a medieval RPG, where attacks can deal different types of damage:

• Piercing
• Slashing
• Blunt
• Magical
• Siege
• Elemental: Earth
• Elemental: Air
• Elemental: Water
• Elemental: Fire

Then I have different ways to mitigate damage:

• Damage treshold (flat damage reduction)
• Damage resistance (% reduction)
• Evasion (% chance to completely negate damage)

And for attack I would need:

• Base damage (used as a base for calculating)
• % increases and decreases
• Flat increases and decreases
• Effective damage (all bonuses and penalties applied)

So I have 9*4=36 variables for attack

9*3=27 variables for defense

for a total of 63 damage-type related variables. For each "player" or "enemy" type. You can see how this can quickly become unwieldy with the current system of a flat list of variables.

Under the current system, you end up with variables named attack_damagetype_blunt_basedamage littered all over your objects, and you cannot simply "hide" them or collapse their group.

I've already completed both a game AND its sequel ... I need to first be able to reliably export my games to my target platforms.

Scirra ... are aware of the state of mobile games with C2 ...So it is clearly willfully misleading.

Yes, the current state of mobile games with C2 is bad, I'm not denying it. But exporters don't help you either! Making feature-compatible native exporters for android AND iOS would take a long time, so you would have to seat on your games for at least another few years! Also, by the time those years pass, the devices in the market will already be powerful enough to run your games, so the exporter would probably be redundant.

Now, I'm assuming you already tried to optimize your game and even sent a capx to Ashley for guidance, and those things didn't work. If so, right now your best bet is to hope intel exporter works better, or that C2 integrates with Ejecta, and that ejecta somehow solves your problems.

There are no quick solutions to your problem. You are right to be angry that mobile sucks (but to be honest, threads complaining about performance are nothing new, why did you insist on making mobile games when the whole board consistently complains that mobile is broken?)

https://www.scirra.com/blog/83/optimisa ... -your-time

If it turns out this is an issue with WebRTC or the browsers themselves, instead of being something Ashley did wrong, there's still a workaround you can do:

In your games, make different "rooms" for people, based on what browser they're using. This way you guarantee same-browser players play together and avoid issues.