Construct Translations

This forum is currently in read-only mode.
  • > 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.

    >

    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:

    > 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.

    >

    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.

    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.

  • Lotta open-minded folks here

    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.

  • 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?

  • 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?

  • 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.

  • Well in c# or XNA you can export to consoles <img src="smileys/smiley10.gif" border="0" align="middle" />

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • L01ZA you can do the same in Unity or UDK (hint: Most console games are made in one of these now, or a custom engine that uses scripting in its own kind of language), which have their own scripting languages. CC is just a visual version of a scripting language and for those that like "real code" there is some decent Python support. I don't see any reason to argue over it though, the amount of TIME saved by tools like Construct Classic and Construct 2 is why they exist.

    Construct tools are awesome for prototyping and finding something you want to make into a full game, even if you do switch to programming later on.

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)