My 2cents about construct2

Hello,

I follow you guys from construct classic. I think that you really know what you're doing, construct2 games are really fast and optimized, still I'm considering switching to a "real" js engine (like impact).

I'll still be using construct2 for fun and small projects, sadly at the state in my humble opinion construct2 is no more than a click and play style product, not suitable for a "real" game. And it's a shame because the code it produce is lightning fast.

So far I found 2 critical problems with construct2.

1) Lack of debug. It' s impossible to keep track of what is happening in a complex project. I don't need nothing fancy, even something basic with all the var dump would be helpful.

2) Lack of clear references to ojbects id. I can pick an instance with a UID, but only from an event. What if inside an event I want to apply actions to one instance then switch to another? I understand that I could do it by creating "hacks" (setting global and local variables or object varibales and then checking them) but this gets really confusing and with the lack of a debugger almost impossible to track on large scale projects.

I hope this ends up in a constructive (no pun intended) conversation. I would love to hear other opinions.

1. Not sure how a debugger would work since even the preview runs off of another program... your browser.

However the text object can be used with events fairly efficiently.

2. Please, please, please stop using uid. It was not designed for this purpose.

Instead use the object index, as in sprite(index). Each time you add an instance(even in the editor) it is assigned an index based on how many instances already exist. That's far more practical than trying to guess what the uid is.

Just remember that sprite(0), or tiledbg(0) is the first instance added, sprite(1) is the second etc.

1. C2 is in beta - there's a lot of functionality missing. I expect a debugger to be made at some point.

2. Some of that functionality that's missing is functions, which in CC you can use to, in the middle of an event, run another event with its own selected object list, with the option of remembering or forgetting the instances of the event the function was run from.

C2 = Klik n' Play? Wow, dude. C2 is completely capable of making "real games." It's just that people would rather experiment with it right now than make full-fledged games because it hasn't even been in development for an entire year yet. People seem to forget that.

I'll agree with you on the debug part, that was an inconvenience

when I first started with C2, but that's all it is, an inconvenience.

You can easily make your own debug with a text object and an

every tick event.

I also agree with you on making a full-fledged game at this stage in development.

Give it time until its features are filled out more.

When it gets to the point where Construct is feature-wise,

it's going to be an extremely capable engine, plenty capable

of full games. But that's a ways off, that's why I'm not doing anything

serious in C2.

I also don't think we're going to see anything amazing from it until

some more exporters come out for it.

2. Please, please, please stop using uid. It was not designed for this purpose.

Instead use the object index, as in sprite(index). Each time you add an instance(even in the editor) it is assigned an index based on how many instances already exist. That's far more practical than trying to guess what the uid is.

The problem is that you can't access dynamically the ID ofan object. For example, when I click witht the mouse object on a Sprite, I can store his UID in a var, but not is ID.

We hope to remedy points #1 and #2 in future with some extra features. We have a long todo list though!

As for the point about being able to make "real" games - they certainly have been made in Classic, and we're aiming to make Construct 2 even better for big games. I would argue this point further, but I think an even better thing to do is for us to spend the next year or so continuing down the long list of features we have planned to make "real" games easy to make in Construct 2, wait for some people to make "real" games, then link you to those games as a counter-argument. <img src="smileys/smiley1.gif" border="0" align="middle" />

Debugging is hard in these kind of programming languages. The best way to do it is to constantly test and run step by step. If you are used to classic game production with code you have to test as you go.

Personally there isn't a better 2D engine. The scale ability of the engine is pretty impressive once you get to know it.

Well, for debugging I use Firebug for Firefox, at least it tells me what went wrong whenever the game fails to run or crashes.

Fully agreed with Mipey.

Also a "true engine as jsimpact", on the debugger part will rely also on the browser's debugger.

So if you want to debug, use the console in the browser, it is here for it.

Not to mention the fact that ImpactJS doesn't implement all of the HTML5/JSCSS3 spec, since it needs to translate the calls to OpenGL...

IMHO, I think C2 is a great tool for those, like me, who knows the logic behind software production, but did not falls in love with programming languages. Instead, we invested more in graphic appeal and gameplay. So ,the C2 current limits do not hinder the evolution of my work and my personal satisfaction with their development.

2. Please, please, please stop using uid. It was not designed for this purpose.

Instead use the object index, as in sprite(index). Each time you add an instance(even in the editor) it is assigned an index based on how many instances already exist. That's far more practical than trying to guess what the uid is.

This seems counter logical to me. If a UID is a uniquely assigned ID that will never change during runtime, and the object index merely lists the current index of the instance, which (am I right in thinking) will change if more instances are added or removed around it, then it makes for much better practice to use the UID when referencing any specific instance. The only argument against it that I can think is some sort of speed hit due to the way the look up is implemented.

It doesn't change during runtime, but you cannot count on what it will be until after the object has been created at runtime. Each time you run the game the UID will likely be different.

Think of it like this - if on preview 1, you create an instance of a sprite, it will have a UID, like 1. If on playthrough 2 you create an instance of sprite2 first, then create a sprite instance, sprite will have a different UID, like 2, than it had on the first playthrough, because sprite2 was assigned the UID 1 first because it was created first.

Does that make sense?

Atleast it doesent bug in the event editor where groups are constantly selected and it jumps back and forth