Python support announced

This forum is currently in read-only mode.
0 favourites
From the Asset Store
Controller Support ,TouchScreen Support , Keyboard Support , Action Platformer, Lots of Animations
  • Hey everyone, we're planning on integrating Python scripting in to the IDE. This will allow you to either:

    • Write entire games using Python scripting.
    • Use normal event sheets as before, but include snippets of Python to perform complex loops, calculations or other areas difficult to express in events efficiently.

    You can find out about Python here:

    http://www.python.org/

    We won't be forgetting about events - they're just as important as scripting. So we won't be leaving events behind and making Construct a script only tool, but we won't be making Construct an events only tool with scripting bolted on. We're going to make them work together and make both useful.

    If you have any ideas on what you want to see in Python scripting, or what it should be able to do, get your ideas in here <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile"> We should have it ready in a couple of builds, around 0.9, so have your say now <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile">

  • Oh wow, this is so cool. I was thinking about learning Python a few weeks ago, and didn't start. Now I will! This is an incredible feature to add, and the best idea yet. I'll offer some suggestions as soon as I familiarize myself with the language.

  • Ashley, I cannot tell you how much I love you ;D

    But seriously, this is great. More freedom, more flexibility. Thanks.

    Btw, I began to study C++ thanks to Construct - 'cause some day I will contribute developing it too >:D. Bwah hah. Actually, I studied it long time ago, but didn't have much use for it, so I forgot pretty much everything :P. Now I have use, at last. I should just review the code and try to understand how it works. It'll be interesting christmas for me...

  • I don't post here often, but I think this is an excellent idea. Python is a pretty easy language, personally only took me a few days to learn.

    How about being able to write extensions in Python? It's a far simpler language than C++, which would make it easier for amateur developers to write extensions for Construct. Python has great interoperability with C++, so the Python SDK could be entirely based off the C++ SDK.

  • I have two reactions to this announcement...

    1) Yay! Scripting is great! <img src="{SMILIES_PATH}/icon_biggrin.gif" alt=":D" title="Very Happy" />

    2) Nooooo! Not Python! Can I somehow convince you to switch to Ruby instead? It's much more beautiful to work with.

    Great work anyway! <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

  • Lua is a great little language too. Very lightweight.

    Easy to add. Doesn't force the programmer to count the spaces and tabs. <img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" />

  • How about being able to write extensions in Python? It's a far simpler language than C++, which would make it easier for amateur developers to write extensions for Construct. Python has great interoperability with C++, so the Python SDK could be entirely based off the C++ SDK.

    I don't think writing extensions in Python is a good idea. That would effectively nullify the one of the major benefits of extensions in C++: C++ is fast. It's a compiled language. Python is interpreted language, so it doesn't perform any faster than Construct's events, which are, too, an interpreted language. Actually, I think that events might perform faster than Python, because they are very simple. But I don't know, it's about the optimisation of the interpreter, after all.

  • > How about being able to write extensions in Python? It's a far simpler language than C++, which would make it easier for amateur developers to write extensions for Construct. Python has great interoperability with C++, so the Python SDK could be entirely based off the C++ SDK.

    >

    I don't think writing extensions in Python is a good idea. That would effectively nullify the one of the major benefits of extensions in C++: C++ is fast. It's a compiled language. Python is interpreted language, so it doesn't perform any faster than Construct's events, which are, too, an interpreted language. Actually, I think that events might perform faster than Python, because they are very simple. But I don't know, it's about the optimisation of the interpreter, after all.

    Only for close loops; for many things you can bind to C++ for any function you'd want to impliment that's available in the C++ world to python but not available to Scirra by finding the python bindings and attaching it to the scirra plugin SDK wrapper for python. This is useful for people who don't like C++ but will tolerate easier-to-use languages like python and would only want limited extension creatibility... I guess it all depends on what sort of extensions you could create with inline python rather than importing it...

    As for Ruby and Lua, please god no. Beauty in language? Are you guys smoking your CS majors? The whole idea about easy tools like Construct is that form follows function -- it does what it does and it does it good, effective, and easy. I should disclose my personal bias by saying that I'm a BASIC programmer and I don't give a crap about "beauty" in the classic programmer's sense -- verbosity makes it much easier for ANYONE to get into programming vs. something that looks like a math problem.

    Edit: To not sound like a hypocrite I also request that Scirra's inline python editor provide auto-tabs

  • I think no matter what scripting language we pick, X people would say "OMG awesome!!" and Y people would say "no way not that one!!". We've investigated a few, and picked python for several reasons, one of which being it has got very good C/C++ integration which makes it very flexible for Construct.

    Also for highly algorithmic stuff (tight loops with lots of variables), Python is almost certainly faster. In Construct if you add to a counter or global variable or whatever, you still have the overhead of jumping in to an action, whereas Python just knows to increment a variable and probably does this in a very optimised fashion. That's part of the use of having Python. There will also be bindings to call actions (and possibly conditions and expressions) from Python itself, but when you do this you still get the overhead of jumping in to an action.

    As for SDKs, Python plugins etc. we have plans to significantly improve the modularity of coding with events, and python fits in to this rather neatly. We'll be announcing more stuff in future <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

  • As for SDKs, Python plugins etc. we have plans to significantly improve the modularity of coding with events, and python fits in to this rather neatly. We'll be announcing more stuff in future :)

    Yay. That's nice to hear :).

  • As for Ruby and Lua, please god no. Beauty in language? Are you guys smoking your CS majors?

    I don't have a CS major. But I do smoke.

    The whole idea about easy tools like Construct is that form follows function -- it does what it does and it does it good, effective, and easy.

    Yes!

    But doing it in style counts for a lot too! <img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" />

    And it might be a bit easier for people without a programmers background to understand "10.times do print 'Hello' end"

    better than "for i in range(10): <newline here> <some whitespace here> print 'Hello'<another newline>"

    Ok, so what if I'm a bit biased... <img src="{SMILIES_PATH}/icon_wink.gif" alt=";)" title="Wink" />

    I should disclose my personal bias by saying that I'm a BASIC programmer and I don't give a crap about "beauty" in the classic programmer's sense -- verbosity makes it much easier for ANYONE to get into programming vs. something that looks like a math problem.

    I have a long history with BASIC. It was what I began with almost 20 years ago, and it's what I use mostly today. BASIC is not a pretty language. <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

    It's just that I really dislike that whitespace plays such a big role. And I really believe that Ruby is so much easier to read and understand.

    But arguing about this is futile, since Ashley have already decided to go the Python route. <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

    Edit: To not sound like a hypocrite I also request that Scirra's inline python editor provide auto-tabs

    I agree! Syntax highlighting would be nice too.

  • ooh yes, syntax highlighting. Luckily, there's tons of great libs out there already to provide "drop-in" IDE performance features for coding such as syntax highlighting and auto-tabs. Just think about this, deps. MSVS puts tabs in for you now, so really there's no reason to hate tabs out of laziness (which was my main reason I didn't like forced whitespace). If the IDE used for Python in Scirra Construct did the same thing, I could care less about forced whitespace. The IDE would usually handle it, and eventually (this is what happened to me), I started tabbing out of habit anyway to avoid the auto-tabs making me lose my place.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Very good news!

    Using both events AND scripts is the most comfortable solution!

    The ability to script will surely stimulate the interest of Game Maker community as well!

  • I'm a little concerned that one or the other will be neglected, but we'll see what happens. I know that's not the plan, but often when you have two entirely different ways of coding something, one way takes precedence.

    But I really do welcome the whole modularity thing.

  • I'm a little concerned that one or the other will be neglected, but we'll see what happens. I know that's not the plan, but often when you have two entirely different ways of coding something, one way takes precedence.

    Same for me.

    I use a program like this to avoid scripting. As, long as the events stay the focus, then I support it ... otherwise I guess Construct is not what I need.

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