Construct Translations

New releases and general discussions.

Post » Wed Dec 30, 2009 12:44 am

[quote="Ashley":1kp7vrxg][quote="Lost my Keys":1kp7vrxg]"export" the source code back out[/quote:1kp7vrxg]
What do you mean by importing source code to XNA then exporting it out again? That doesn't make any sense. Source code is source code.

As for exporting to source code, I really don't see the point. You would never be able to modify the source code to make changes. The insides of the event engine are very complex, and because there are no languages that support event style picking as language features, the generated sourcecode would not be human readable, it'd just be a massive mess, like a really complicated function copied and pasted a thousand times. And what kind of changes would you make? What would the advantages be? There are no advantages to exporting source code. Only disadvantages.[/quote:1kp7vrxg]

I disagree. There is no disadvantages of being able to export source code only advantages. I understand it may not be human readable, but even so saying the code as an export would not be useful or have any advantage is a bit extreme and over the top. Code at its very core is better then events, yes I understand events work really really REALLY well in construct, but if the program has a bug or they wish to expand on it with extreme custom code and actions that they could not do within the editor then it would be best to be able to see that code.

I know it will never happen because of how advanced and great the event system is but saying exporting code would not have any advantage is not true in any part of the context. Not trying to call you on anything but facts are facts.

I know the event system can do 99% of what anyone would possibly want with python possibly picking up the slack, but exporting code would be the ultimate in debugging and advanced mechanics.
B
4
G
3
Posts: 13
Reputation: 1,028

Post » Wed Dec 30, 2009 12:47 am

[quote="Ashley":2wgolwcx][quote="Lost my Keys":2wgolwcx]"export" the source code back out[/quote:2wgolwcx]
What do you mean by importing source code to XNA then exporting it out again? That doesn't make any sense. Source code is source code.

I know, hence the quotations and the chuckles :P

[quote:2wgolwcx]As for exporting to source code, I really don't see the point. You would never be able to modify the source code to make changes. The insides of the event engine are very complex, and because there are no languages that support event style picking as language features, the generated sourcecode would not be human readable, it'd just be a massive mess, like a really complicated function copied and pasted a thousand times. And what kind of changes would you make? What would the advantages be? There are no advantages to exporting source code. Only disadvantages.[/quote:2wgolwcx][/quote:2wgolwcx]

I think that's what he's wanting to do with it, yes. There's no other reason I can think of to have the source code (really what would be the point anyway, you can edit your own game in construct, and compile it and have the exe too, I wouldn't see the point in the source code for it as well). So yeah, that's what I think he wants to do. Create something inside construct, then rather than create an executable, he wants to create the source code itself (that when compiled would become the executable) so he can take it over to another program, like you would a jpeg or a text file. You know that can't be done (not in this case anyway), and I know that can't be done.
B
3
S
2
G
3
Posts: 628
Reputation: 2,531

Post » Wed Dec 30, 2009 2:01 am

[quote="vem0m":1akd0lh8]I disagree. There is no disadvantages of being able to export source code only advantages. I understand it may not be human readable, but even so saying the code as an export would not be useful or have any advantage is a bit extreme and over the top. Code at its very core is better then events, yes I understand events work really really REALLY well in construct, but if the program has a bug or they wish to expand on it with extreme custom code and actions that they could not do within the editor then it would be best to be able to see that code.

I know it will never happen because of how advanced and great the event system is but saying exporting code would not have any advantage is not true in any part of the context. Not trying to call you on anything but facts are facts.

I know the event system can do 99% of what anyone would possibly want with python possibly picking up the slack, but exporting code would be the ultimate in debugging and advanced mechanics.[/quote:1akd0lh8]
So what are these advantages? From what I can gather from your post, you state code is better than events even when not human readable. Why is that? Isn't it better to write custom code in plugins which Construct already supports? I'm not saying events are always superior to code - they're not - but the options are put your code in a plugin, or ponder what to do with tens of thousands of lines of unreadable code. This isn't about code vs. events, it's about Construct generating tonnes of useless source vs. giving you the finished thing. That's not a feature, it's a waste of time to develop, from my point of view!

Don't think this is a personal attack or anything, it's just that this idea about Construct generating source code comes up from time to time. I can't really see any point to it at all, so I'm trying to establish what people think it will enable. Such as:

[quote="Lost my keys":1akd0lh8]he wants to create the source code itself ... so he can take it over to another program, like you would a jpeg or a text file.[/quote:1akd0lh8]
Remember this is a big ball of mud code which doesn't make sense. What are you actually going to then do in another program with this unintuitive source code? I'm yet to hear any convincing real-world scenarios yet.
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,630

Post » Wed Dec 30, 2009 2:44 am

[quote="Ashley":1mgqzlah][quote="vem0m":1mgqzlah]I disagree. There is no disadvantages of being able to export source code only advantages. I understand it may not be human readable, but even so saying the code as an export would not be useful or have any advantage is a bit extreme and over the top. Code at its very core is better then events, yes I understand events work really really REALLY well in construct, but if the program has a bug or they wish to expand on it with extreme custom code and actions that they could not do within the editor then it would be best to be able to see that code.

I know it will never happen because of how advanced and great the event system is but saying exporting code would not have any advantage is not true in any part of the context. Not trying to call you on anything but facts are facts.

I know the event system can do 99% of what anyone would possibly want with python possibly picking up the slack, but exporting code would be the ultimate in debugging and advanced mechanics.[/quote:1mgqzlah]
So what are these advantages? From what I can gather from your post, you state code is better than events even when not human readable. Why is that? Isn't it better to write custom code in plugins which Construct already supports? I'm not saying events are always superior to code - they're not - but the options are put your code in a plugin, or ponder what to do with tens of thousands of lines of unreadable code. This isn't about code vs. events, it's about Construct generating tonnes of useless source vs. giving you the finished thing. That's not a feature, it's a waste of time to develop, from my point of view!

Don't think this is a personal attack or anything, it's just that this idea about Construct generating source code comes up from time to time. I can't really see any point to it at all, so I'm trying to establish what people think it will enable. Such as:

[quote="Lost my keys":1mgqzlah]he wants to create the source code itself ... so he can take it over to another program, like you would a jpeg or a text file.[/quote:1mgqzlah]
Remember this is a big ball of mud code which doesn't make sense. What are you actually going to then do in another program with this unintuitive source code? I'm yet to hear any convincing real-world scenarios yet.[/quote:1mgqzlah]

I never said unreadable code would be better, or even needed. I simply said the advantage is having access to that in case something comes up that cannot be fixed or added with events because of the scope needed, which in itself probably will not ever happen but the possibility is always there. I would never use it if it was added for several reasons I am just saying because it is unreadable and a mess does not make exporting source code as you put it "only disadvantages" as that is one single disadvantage among its so many, possibly useless uses. Those uses can still have advantages in extremely rare cases to some people. Not sure why but that cannot be dismissed.
B
4
G
3
Posts: 13
Reputation: 1,028

Post » Wed Dec 30, 2009 2:59 am

At college I've been around this group that works on "Model Driven" programming. I did cite Construct as an example to them.

"Model Driven" is when you use design software to.... well, design your software. I've always been the coding type, and never liked this approach, but I took a serious look at it in this workgroup.

What I found out is that Model Driven development only works when the model IS the software. That is, there's no in-between model (such as exported code, in this case).

WHY?
Well, if you export the code and then change something there, the modified code no longer conforms to the original model. Things are lost in translation. Semantics are lost when generating the code, code doesn't contain semantics so you can't have them when creating a model from code.

This happens always, everywhere! just try translating text from english to russian and back to english. Things are jumbled, meanings are lost. (Just in case: think of english and russian as two models for expressing human thought).

So I said, and this is my current official stance, Model Driven is only a good idea if there is no way to do these in-between changes. The model becomes the code.

This is my opinion, based on my own experience with tools like Bison, Flex, Antlrv3, Doxygen, PHPDoc, MySql Workbench, Power Designer, etc.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Wed Dec 30, 2009 3:30 am

[quote="Ashley":3du1b23c][quote="vem0m":3du1b23c]I disagree. There is no disadvantages of being able to export source code only advantages. I understand it may not be human readable, but even so saying the code as an export would not be useful or have any advantage is a bit extreme and over the top. Code at its very core is better then events, yes I understand events work really really REALLY well in construct, but if the program has a bug or they wish to expand on it with extreme custom code and actions that they could not do within the editor then it would be best to be able to see that code.

I know it will never happen because of how advanced and great the event system is but saying exporting code would not have any advantage is not true in any part of the context. Not trying to call you on anything but facts are facts.

I know the event system can do 99% of what anyone would possibly want with python possibly picking up the slack, but exporting code would be the ultimate in debugging and advanced mechanics.[/quote:3du1b23c]
So what are these advantages? From what I can gather from your post, you state code is better than events even when not human readable. Why is that? Isn't it better to write custom code in plugins which Construct already supports? I'm not saying events are always superior to code - they're not - but the options are put your code in a plugin, or ponder what to do with tens of thousands of lines of unreadable code. This isn't about code vs. events, it's about Construct generating tonnes of useless source vs. giving you the finished thing. That's not a feature, it's a waste of time to develop, from my point of view!

Don't think this is a personal attack or anything, it's just that this idea about Construct generating source code comes up from time to time. I can't really see any point to it at all, so I'm trying to establish what people think it will enable. Such as:

[quote="Lost my keys":3du1b23c]he wants to create the source code itself ... so he can take it over to another program, like you would a jpeg or a text file.[/quote:3du1b23c]
Remember this is a big ball of mud code which doesn't make sense. What are you actually going to then do in another program with this unintuitive source code? I'm yet to hear any convincing real-world scenarios yet.[/quote:3du1b23c]

How the heck should I know? LOL I'm just telling you what it LOOKS like he wants to do with it, taking this and his other posts into account, ask him not me. I think the whole bloody thing is stupid, why even go near code if you don't have to. Please don't lump me in with these two users, thanks. I am in no way affiliated with either of them.
B
3
S
2
G
3
Posts: 628
Reputation: 2,531

Post » Wed Dec 30, 2009 1:55 pm

Lotta open-minded folks here :roll:

LOL... Yikes. Sorry, I shouldn't have posted an idea. I did that before I realized it would make everyone go bananas :)

I'll just say this and dash... When I used to have group chats with David Winter (Maximum Football) it was talked about how some companies wanted to have the option for some programming input. Some variation of C is a norm of course, so it would stand to reason that if you're trying to get hooked up with a studio and you can produce that from the game you're making in a program like this, you'd have a more favorable product because you'd be speaking their language, and it would cut down or eliminate any costs involved with remaking your game.

I know a guy at EA Canada who is making a CFL game as we speak (by himself). Now say he were to create it in a program like this, that would be great. But he's already seen development cost hurdles thrown at him by the company, if he brought an MFA or a CAP EA brass would surely reject it because while they love the idea of a CFL game, they have no desire to pay much money to develop it since the ROI will be low. But if he comes with something already done in C, he's eliminated a lot of hurdles.

There is always the debate of "well, if your game is good enough they'll remake it and eat the costs!" And this is true, it's happened. I know some games that were done in MMF that a larger studio bought and remade. As a Concept Designer/Inventor, some of the concepts I created in the past required prototypes. Sometimes, the make of it required a company to do more work if they wanted to use it, so this made negotiation more difficult. If I was able to create something in the format they're familiar with, it was smoother and they were more open.
B
2
G
3
Posts: 42
Reputation: 934

Post » Wed Dec 30, 2009 3:02 pm

Yeah I see what you mean, but I don't think that going at it from the back end would ever do you any good. You would need an interpreter, for something that already is an interpenetration.

Beyond that, having the ability to "hack" the exe would be... lets just say scary for independent game developers.

Would it not be better to go at it from the front end, and wait for a cross platform compatible version of Construct?
Image Image
B
161
S
48
G
91
Posts: 7,359
Reputation: 67,273

Post » Wed Dec 30, 2009 3:53 pm

You can use C/C++ in the plugin SDK for Construct - that's what all plugins and behaviors (like Sprite) are already written in. Does that help?
Scirra Founder
B
359
S
214
G
72
Posts: 22,952
Reputation: 178,630

Post » Wed Dec 30, 2009 9:20 pm

hey! another post with snide namecalling and half-truths! I'll just let it slide.

SLIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIDE.

Okay done. So!
Say a company thought the game was really good but they need the source. Say your IDE exports source. Say the techs take a look at the exported source.

Say the tech say "screw it, we'll redo". Why? semantics are ALWAYS lost in model translation. There's no way automately generated code can be as nice to read and modify as properly documented and commented code is.
So yeah, remaking is probably the best way to go about that, even if you could export source. Have you ever looked at generated code? I have. It takes much less effort to rewrite than to understand and modify it.
I won't recite my basis for this, as I already did.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

PreviousNext

Return to Construct Classic Discussion

Who is online

Users browsing this forum: No registered users and 0 guests