StAtrill's Forum Posts

  • >

    > Idk, the main thing I liked about GM was how tight it was with GML. It just worked. (And the syntax was close to C based languages, the learning curve is next to nothing)

    >

    aside from python, which is insanely c-like

    you can make plugins for construct fairly easily using c++ ,

    everything you do in construct is done with a plugin, from loading an image into a sprite, to applying a platform behavior, to playing a sound, to opening a file dialogue. they are as powerful and fast as the c++ that spawns them. the possibilities are endless.

    Lol the point of that was that the two are closely integrated, not that they were similar languages. GML was designed with gamemaker in mind, while python was simply designed to be an easy-to-use open-source alternative. You could code your entire game in GML if you wanted to without running into any issues (and with great ease, may i add), and it seems like the extent of python inside Construct is for nothing more than running intensive computations that wouldnt translate well into Constructs normal event system (at least it seems that way from my basic experience with it).

    And python and the C languages really arent that alike at all. Aside from words like "if", "then", and "else", the similarities stop. I could go deep into this, but you could also do your homework and find this out yourself.

    Finally, GM can be slow (mainly if you dont know what your doing), but it isnt weak. I wrote an entire skeletal animation program in it (for the curious: http://www.yoyogames.com/games/102929-animator) and it can maintain 127 fps running my entire animation engine AND the separate front end to it with a full skeleton across nine depth levels (on my old P4 3.2 Ghz). The source code itself is a few thousand lines long and it doesnt even choke. GM would be a great tool if... well im not going to get into all that here.

    —:

    "GM would be a great tool if..." <--Why I switched to construct

  • *High five*

    People like you deserve cookies. By any chance, do you look into bugs by request?

  • My two cents:

    One thing I do miss about Game Maker over construct, among other minor things, is that you can explicitly control how to handle drawing events for objects: where as you can draw another object, or clones of the object, or nothing at all...

    My two most missed applications of the above feature are one:

    -Pasting a grass sprite (for example) and it draws randomly sized and colored copies around itself. You can quickly make entire fields of grass this way, or apply the same technique to make an epic explosion look soo much cooler...

    Idk, the main thing I liked about GM was how tight it was with GML. It just worked. (And the syntax was close to C based languages, the learning curve is next to nothing)

    But.... The loading screens (no matter how short) are nothing short of downright tacky (Especially if you are like me and tried to develop a semi-professional feeling application with it). And then, there is no native support for windows forms, and GM is beginning to seem more bloated with every new version (considering the runtime alone is 2.53 megs).

    The real reason I made the switch: Rapid prototyping. Seriously, this gives a whole new meaning to the word. If youve never participated in an one-hour game-making compo, or have never even heard of such a thing, then youve never heard of this program (or its lame cousin MMF/TGF). And considering I dont have tons of free time anymore, Construct just makes sense.

  • Not to sound too young or anything, but I had kinda hoped to find the N64 on here somewhere...

    Its a classic. Well, to my generation anyway.

  • I would use a varaible to keep track of the last clicked unit (by unique id, of course). Then, upon releasing the mouse button, the unit whose unique ID matches the stored on in the global var has its angle of motion changed.

    Lol and if that was confusing, ask and I (or anyone, for that matter) can provide you with an example.

  • I would simply restart construct. As far as i know, Construct forgets all menu-related settings upon close. (Which, in your case, might work to your advantage)

  • > Next idea: Construct ships with free ice cream.

    >

    You just hate the lactose intolerant, don't you?

    Cmon man, it was either that or lasers....

    FunEffect:

    How would you even check to see if it was picking objects already destroyed? They dont show up in the debugger (for me anyway...).

  • Count me in. I might have just the thing for this too...

    Hopefully the deadline has a bit of time to it though, I just switched to construct and so dont have many projects to show so far :/

  • As I recall it's been recommended recently

    Lol whoops, missed that. Glad to see theres other's wishing for this though! It deff sucks being the lone supporter of any idea (no matter how good).

    Next idea: Construct ships with free ice cream.

  • Lol not to be too off topic or anything, but i just made the amazing revelation that if you close the objects bar, you cannot open it again.

    While every other main bar has this nifty little button on the home tab for reopening it, the objects bar does not. (And theres no 'Reset all toolbars' option anywhere either)

    It particularly sucks after you just set the objects bar to show the object tree and it crashes, so you figure you'll just close and re-open it. But noo... if you close it, it STAYS closed :/

    Anyone else for a button to re-open the objects bar?

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Whoops, that was from an earlier bug report I made

    The file (and the link to it) is correct now.

  • If i'm correct, the default behavior of the 'System::Create" action is to spawn a sprite with its original dimensions. I dont know how, but somehow i messed up my .cap file to where it spawns the sprite for my bullet with a default width and height of 0. I have toggled every event that pertains to the bullet sprite, I have replaced the event creating the bullet with one that spawns it (redundant action btw?), and unless I set the width and height, they are always zero.

    And, before someone suggests that I simply set the widths and heights myself, understand that it doesn't solve the issue: they are not supposed to spawn with a width/height of zero.

    Heres a semi-stripped down cap:

    http://www.mediafire.com/file/dlocfgm2ncf/Bug report.cap

    Press V to shoot - the debugger shows the bullets there, they just are invisible.

    The weirdest thing about this bug is that it was gradual - at first only a few bullets here and there wouldnt appear, and now none do.

  • You, sir, may have just made the most useful third party plugin I have seen yet. Construct should distribute with this.

    D/ling now, will give feedback.

    My two sense on the raw data: try to make this plugin nothing more than an interface to the Wiimote. if the Wiimote returns rough data, then pass back unadultered rough data. Let it be a limitation of the Wiimote, not an issue with your plugin. And if you must provide some method to smooth it, also provide some way to turn it off

    EDIT: My vote is for one object that manages all plugins, then I can dynamically modify things to multiple controllers more fluently. Also, you could do things like reassign controller numbers in-game.

  • No, in Click development suites, there is an in-editor menu option that will take all the events that pertain to one object and switch it with another.

    So, given objects A, B, and C, if there is events that involve objects A and B, and object B is replaced by C, then all those events we had earlier now involve objects A and C. (I think thats what hes talking about)

    This could be a useful feature.

  • I 2nd this request.

    I personally wouldnt particles to become *too complex*, I just wish more parameters supported negative numbers. For instance, you cant create a particle with a negative speed. While im sure this normally would not be necessary (if they all spawned at the same point it would appear exactly as it would as with positive speed, just transformed 180 degrees), if you spawn your particles at random spots then you would end up with an 'implosion' effect of sorts. But, particles cant have negative speeds, so you would need to simulate this kind of effect yourself.

    And if this functionality were added, then maybe a negative fade out time could become a fade in time?