Modal windows? That is, if you have window A and it spawns modal window B, you cannot interact with window A until B is dealt with. Similarly, modal window B might spawn modal window C, and you cannot interact with B or A until you deal with C

I'm not convinced. I really dislike the idea of having two products ? what if I want to use both 2-D and 3-D together? It also depends just how much 3-D capability would be incorporated ? if it's just simple displaying of a model and maybe some basic lighting, There's no reason to redo anything from scratch when it can be made as a plugin instead. Making two products would be far, far more work for Ashley for no reason.

I'm also not sure how it would be better. The only thing I can think of that there might be a potential issue with is panning around a 3-D world in the layout editor. I can imagine that could be worked around elegantly by having a 3-D camera that's separate from the normal 2-D one that the user can switch between.

I don't want a separate product either, but I'm convinced that adding 3D support onto construct2 would be a nightmare that would delay other (much more important) features.

Like you said, even something simple such as panning around in the editor would require coding a separate camera and rendering engine - if you have a product that has two modes, it's basically the same as having another product.

I get that you want to be able to use 3D stuff in normal projects, and I agree - I've wanted to do that many many times - here's an example:

On a space game I'm working on, which is practically all 2D, one of the features is being able to choose a site on a planet to land on. Creating a 3D sphere with animated textures spinning around (simulating a planet) was a huge pain. Also, mapping mouse coordinates onto planet surface coordinates had to be done by hand using math. This would have been relatively simple to implement if C2 supported even basic 3D capabilities.

Still, I think it would be better to have a mainly 3D product that is 2D capable than the other way around.

Even if Ashley didn't intend to incorporate 3-D from the start, that doesn't necessarily mean that it will be difficult to implement. It might be, but you seem to have decided that it will be difficult and wouldn't succeed without knowing the underlying architecture like Ashley does.

Yes, it does not necessarily follow that it will be hard to implement - but trust me, it will. Though only Ashley can confirm this.

That doesn't mean a 3-D engine would generate too much garbage as well. They're not the same thing.

I said that to illustrate how, even with a well planned feature, problems happen. A 3D engine isn't likely to generate a lot of garbage, due to such engines usually being extremely optimized, so yes I'll agree there.

Here is a better example: most (if not all) 3D engines are meant to be used as a foundation for the rest of your engine, unlike box2d which is designed as an add-on. This means that, even if Ashley wanted to add 3D, it would need to be made in-house.

Anyway, it's irrelevant because Ashley has said that there are no short-term plans to add 3-D, so even if it does get added eventually, it'll be quite a while until then. Unless some third-party plug-in developer makes it first.

I don't think the chances of something good coming out of third-party plugin developers are in our favor. Look at MMF2: all those years third-party devs have been attempting to add 3D via extensions, with limited success (and poor quality overall - their best results are stuff like mode7).

Maybe the shader guys have more luck.

Definitely willing to pay for it, but I cannot discuss price.

Would I be willing to pay more than, say, UDK? Yes, if the quality is there.

If it's able to produce something like this (that is, a little bit more basic than unity):

<img src="http://1.bp.blogspot.com/-VPgn3SUa9rY/Tz36PnV-i3I/AAAAAAAAERw/qNK0xm97cdY/s1600/Download+PC+Games+Alien+Breed+-+Impact+2010+For+Free+4.jpg" border="0" />

then I'd definitely consider paying over $200 for an indie version, and over $2K for a commercial version.

If we're talking about this

<img src="http://img.brothersoft.com/screenshots/softimage/0/3d_games_tvmax-30029-1.jpeg" border="0" />

or this

<img src="http://blog.mozilla.org/labs/files/2012/04/no-comply.png" border="0" />

then I wouldn't be willing to pay anything for it, and I would think less of construct.

I'm not expecting the same level of detail as cryengine or UDK, of course.

Still, I don't want a tacked-on 3D solution, an in-house thing would be better (and perhaps the only viable alternative).

Keep in mind construct 2 was developed with a clear intention of integrating one (or maybe more?) physics engines later, so that's why it succeeded, and yet if you read Ashley's comments, it's clear he believes Box2D generates way too much garbage. I don't know if he cleaned up the code manually or left it as is, but it probably took a ton of work - and, again, this is something he was planning when C2 development started.

I don't think adding a 3D engine as an afterthought would be viable. I could be mistaken.

What I'd actually like, however, is some better eventing capabilities so we could fake 3D more easily.

Implementing isometric, for instance, is very hard, due to being unable to add methods/functions to objects (even though we can add variables), not having access to z-ordering (must do an ordered loop), etc.

Ashley, I think you're overestimating the complexity of 3D and underestimating the capabilities of events!

3D maths, generally speaking (and I'm oly talking about programming logic), are simply extensions of 2D algorythms into 3D (ex. Bresenham's line, A*). Most of the truly complex stuff has to do with rendering (with a few exceptions such as gimbal locking), and that would be handled by [a theoretical 3d version of] construct.

Besides, what's keeping the event system from being as powerful (and faster) than coding by hand? I can't think of anything that can be implemented in code and can't be implemented via events - what's stopping events anyways? Most OO stuff can be directly adopted, such as custom variable types, object variables, pointers/direct referencing, inheritance (even if prototypical inheritance like js)!

As for modeling, it's not REALLY that hard to get into. I personally find sculpting with zBrush much easier than working pixel art with the tools available, and 2D art is only marginally better (thanks to spriter). And the results often look better, too.

I'm not saying Scirra should jump into a new product or try to cram 3D into construct 2 - First of all, scirra is too small to run two huge projects at once. Second of all, such a product would have to be designed from scratch.

There is demand for it, though, and I definitely think it's something worth considering for a future project.

Bartosh, I'm definitely interested in your project, could you post more about it?

Here are two of the most interesting resources I've collected when working on my massive ambitious project:

red3d.com/cwr/steer <-- steering, seeking and flocking behavior

gamasutra.com/view/feature/3549/interview_the_making_of_dwarf_.php <-- massive interview with Tarn Adams (my favorite developer), of special interest are worldgen and fluid dynamics in tile based maps.

Yeah, native json parsing in construct 2 is very poor. You'll need to use Rex's plugin like lemo mentioned.

I'd love to see a jquery jyntax on an official plugin, so we could feed it a string like "player[1].vehicle.movement.speed" and it would return a value.

It's a planned feature.

Ashley, I don't get the second problem.

If a new version of an official plugin comes out with a bug fix, then it's automatically updated. The only plugins that are bundled with the capx are the ones not present in the global list of plugins!

When saving a project, it looks at the global construct plugins folder. If the plugin is there, it skips it (regardless of whether it's an official plugin or a third party one). If it cannot find the plugin there, or if the plugin in the project folder is different than the version in the global folder, it gets bundled.

It's not like it's supposed to pack *ALL* plugins in the capx... In fact, it shouldn't bundle third party plugins if they're on the global folder.

The only way to have a capx with a forced out of date plugin would be to manually copy the outdated version into the project folder.

Meanwhile, there's nothing keeping you from modifying the existing sound plugin and adding those features, except perhaps your knowledge of JavaScript or the C2 Api.

Granted, it will break compatibility with existing projects unless you create a new plugin, and it won't work in the arcade, but I think it's a pretty viable option if you really need the features and know your user base.

Thumbs up! This is a minor thing for me, but if it improves project organization, I'm all for it! I even have some code specific to test projects and it would be great not having to delete them

It could even bundle the plugins along when you save the capx.

How would it handle a plugin/behavior that already exists in general? I'm guessing it would use the project-specific version, right?

No, there is no way to edit the "raw" code produced by construct 2. You're welcome to try - you can skip minifying and the output is open - but I don't think it's understandable, or even if it is, it's not worth the effort. The way to work around those limitations, since you know javascript, is to learn the API and write custom plugins - they work great for the majority of the cases, even if it takes some thinking.

Yes, there are loops - while loops, for loops, foreach loops, ordered loops, it's all there.

There are also functions now, albeit a bit primitive since they aren't first class citizens, and they don't really know what scope is.

It is possible to organize your code, and I personally am always trying to steer scirra towards improving the event system to make things more manageable (I think this is way more important than cocoonjs/awesomium/windows 8/etc, but they have to make money), and it's not like they're slacking - the newest additions are containers and functions, and they work well enough (though they could be improved a lot).

Overall, however, writing raw javascript code will always give you more power, but remember you'd be writing a whole new engine, complete with collision detection, object picking, memory management, drawing, loading...

Writing plugins may be more work than cramming a solution inside your own engine, but it's not that much work, the cost of writing an engine is gigantic, and the end result if you do write a construct plugin is an extremely modular piece of code that can be shared with the community and reused in other projects.

I used to think it was a bother writing custom plugins for every little thing, but now I honestly think it's worth it.