Porting from Gamemaker

This forum is currently in read-only mode.
  • As far as intuitiveness is concerned, most of my problems are with the image editor and animations right now. The animation tab really shouldn't exist, and there's plenty of room in the image editor for all its functions that right now doesn't seem to do anything. Right now you have to close an image then switch from a more useful tab to "animations," make a new animation that AFAIK you can't rename, then open it (Which also opens the first animation for some reason).

    There are too many things in general which make you close out of windows to change, such as object properties while in the event sheet, even though there's still a big list of objects to the side which stop functioning like they would in the layout editor.

    As far as the tabs go, right now I use "resources" as a dummy tab (Because right now none of its features seem to work) to keep the main window from resizing, then drag out each of the other windows so they can stack vertically. Otherwise it's too much of a break in pace to switch from "project" to "layers" all the time. I wish you could use some of that massive blank space to the right of the ribbon, as well.

    As far as the image editor is concerned, it's probably just a work in progress but there's a few things worth mentioning. The eraser tool is just the brush tool set to transparent. It would save huge amount of time letting the user just select transparency with the brush, especially with Ctrl+Left click. Image points cannot be ordered or deleted. They are always alphabetical. If I want to use them in a formula I have to preface them with 1,2,3 etc. If I get the order wrong I have to replace every single one; and with both image points and hotspots, you cannot enter text coordinates so this also makes it more difficult.

    It's also very difficult to get a tooltip on an object to show up. It seems to show up once per click, then disappears forever when you move the mouse at all. The tooltips, being the only way to tell which layer an object is on, also start being a problem when they tell you every object is apparently on layer *?*. Probably just a minor bug though.

    I don't mean this as a negative rant. I love construct and it's awesome. These are just some observations. Much respect to the work you guys have done.

  • new animation that AFAIK you can't rename

    You can rename animations... select the animation and change the name in the properties box.

    right now I use "resources" as a dummy tab (Because right now none of its features seem to work)

    The Resources tab works, it's just not feature complete. You can store sounds and other types of files in Binary, which get compiled into the .exe. You can also change the application icon. Fonts aren't implemented yet, and I'm not sure about menu items because I've never had need to change the app menu.

  • > new animation that AFAIK you can't rename

    >

    You can rename animations... select the animation and change the name in the properties box.

    > right now I use "resources" as a dummy tab (Because right now none of its features seem to work)

    >

    The Resources tab works, it's just not feature complete. You can store sounds and other types of files in Binary, which get compiled into the .exe. You can also change the application icon. Fonts aren't implemented yet, and I'm not sure about menu items because I've never had need to change the app menu.

    Oh, that's cool then. Another thing I've discovered is animation angles right now have nothing but the most obscure of uses. They change automatically when you rotate a sprite, and unless I'm mistaken they can't be changed otherwise. I can't think of a single situation where this would be useful, as apposed to animation directions being completely separate from angles and able to be changed through events, which is really useful.

  • I agree, angles should not have to do with animation angles. That should be seperate actions and conditions.

    It's pretty much only a hindrance this way. The only way around it that I can see is to make seperate animations for each direction you want if you intend to have rotation. Say, if I have a picture of a fist turned right, I might want it to rotate full 360s to punch a face. But I would also like it to be able to do this in the other direction, and I add a mirrored frame to the 180 angle, but then I am screwed for the rotation to look good as the fist will constantly flip every 180 degrees no matter the inital direction.

  • Oh, that's cool then. Another thing I've discovered is animation angles right now have nothing but the most obscure of uses. They change automatically when you rotate a sprite, and unless I'm mistaken they can't be changed otherwise.

    Well... yes they can. You can set a sprite to "No rotation" in the properties, or a few of the built-in behaviors have additional rotation settings. You can then set the angle to whatever you like with actions. If you set an angle of a sprite with no pre-defined animation angles, then it will simply turn the sprite. If there are any pre-defined angles then the sprite will adopt the animation angle closest to it's current angle.

    I agree, angles should not have to do with animation angles. That should be seperate actions and conditions.

    It's pretty much only a hindrance this way. The only way around it that I can see is to make seperate animations for each direction you want if you intend to have rotation. Say, if I have a picture of a fist turned right, I might want it to rotate full 360s to punch a face. But I would also like it to be able to do this in the other direction, and I add a mirrored frame to the 180 angle, but then I am screwed for the rotation to look good as the fist will constantly flip every 180 degrees no matter the inital direction.

    In that case, don't use animation angles... have a separate animations for "Fist left" and "Fist right," with only one angle each.

    Though I agree the whole animation angles thing might be a little confusing.

  • Well, yes, I said that was a possible way AROUND it, but why need a way around it? Could I get an example of a use for how the setup is now?

    If you have a picture for ever 360 degrees you don't need the rotation to begin with. If you almost have one for every picture you might as well use rotation because you're not gonna get a much cleaner image. And even if you do have one for nearly every direction a seperate animation angle command isn't exactly harder to handle, plus it lets you have both rotation and animation angle at once with comfort.

    Also, how do you retrieve the transparent color in the image editor? It would be nice and comfortable.

  • I knew about turning off angular rotation, but then, you couldn't rotate the sprite! It'd be a strange feature if the only way you could use it was to disable one of the most common and useful abilities.

  • I don't understand what all this angle stuff is about? They're an integral part of animations; the only way you wouldn't use them is if you're using a behavior like car, maybe platform and a few others. Ones like Grid, 8 direction etc need angles to behave as you'd expect. If I make an RPG and use Grid Behavior, do I want my right direction rotated 90 degrees to my south direction? Or do I want to draw it to look different using angles..

    Then you factor in custom engines or other uses etc, and not using angles only applies to a very specific set of genres or concepts.

  • If you only need one animation angle, just draw your object at 0 degrees and as you say, it'll smoothly rotate through 360 degrees. However, there are lots of cases of animations where objects can't be rotated automatically through 360 degrees. As Rich said, pokemon-style grid games use a different image for each of the four directions you can move in. Isometric games use a different animation usually for eight different angles - you absolutely can't let one image rotate through 360 degrees for that!

    dustingunn, some of your points are legitimate bugs. If you report them to the bug tracker they can be fixed. While the forums are a good place to discuss things like the purpose of animation angles, they're not very good for bug reports (the tracker is one central collection of all reports so we don't need to search through forums; bugs have open/closed statuses; people can attach files; each bug has its own comment thread; bugs can be assigned to developers; developers can request further information, etc etc).

  • Something to note is that the resource tab will soon be gone, implemented into the project bar. It was a little redundant and space filling.

    Also, you can collapse the ribbon by double clicking it, to gain some room.

  • I think there's a misunderstanding here as to our point. Of course games NEED sprites to be able to change DIRECTIONS.

    The thing is Dustin and I are confused as to why changing animation direction has to be linked to rotating the sprite itself.

    Look at MMF2, you have animations and animation directions. These are SEPERATE from the "set angle" action in the program. This is very useful and I really think setting the angle and the physical animation direction images shouldn't be linked as it is limiting and makes you create many more animations than you should need just to STOP Construct to change to my image of my character looking down instead of right because I wanted a rotating effect without changing the actual image of the character.

    <img src="http://www.konjak.org/angle.png">

    In this example image I show what I'd like to be possible. Animation direction is a seperate thing, and then setting the angle is another, shown here where the images of the animation directions have both been rotated 45 degrees clockwise (in an ugly way), but the angling is leaving the images alone, not try to flip them once they reach 180 degrees.

  • I'll think about it...but there are properties in sprite which allow some basic control so 45 degrees means it choses the right facing animation frame and wont rotate...but yeah having more power over that is a good thing.

    So to prevent 'breaking' old applications we need to impliment this by adding an action...

    either : 'Overwrite render angle' or 'Overwrite animation direction' so that if the action isn't called the two are linked...

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • That would be awesome! Thanks for the consideration!

  • Well, I think what you want is actually relatively easy to implement. All you want to do is separate the animation angle from the object angle. We could do that with an option "Lock animation angles to object angle", which if you turn off, allows independent animation angle and object angle control. Sound good?

    Would you mind phrasing it as a feature request instead of a gripe in future? This might take me twenty minutes to implement. We're all volunteers on this project, and it's a bit nicer to read through positive feature requests and how that'd allow us to do more, rather than how awful the current system is. I'm all for change, especially when it's this easy. No hard feelings

  • Sorry, I just sound like an ass when I talk, I love how you actually get things done compared to Clickteam (who like to delete posts or close threads that have suggestions in them).

    I just found it a bit strange a choice to merge animation direction and angle after having used MMF for so long...

    Thanks again!

    Ps. If it really takes 20 minutes, man you're quick! Don't you have to add conditions and actions relating to animation direction and object angle seperately?

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