Some features I would like to see

This forum is currently in read-only mode.
  • As is stated on the top. This will be a list of feature I would like to see.

    Features

    1) Pass through solid for sprites in the Event sheet editor.

    This This would come in handy for for a beat'em up game.

    when you need the characters in the game to stop at a wall but still be able to jump through it.

    2) Add frames in the picture editor.

    This will cut down on time for making an animation.

    Instend of having to to add one frame to the picture editor get out of it then add more frame to

    the animation bar to just go back the the picture editor and set it up.

    3) turn Based Strategy (TBS) behavior.

    Well that is it for now.

  • 1) This can be done rather easily already. I'd imagine it'd actually be quite difficult to get a correctly working action up and running, and useable in events.

    2) This would indeed be handy, it's something I've asked David for 1000 times .

    3) What would this plugin do?

  • 3) What would this plugin do?

    TBS or turn based strategy behviour rich. lol

    i think he means a behavior to emulate advance wars or fire emblem or something. which seems like a impossible behavior, since it would have to account for so many things.

    your going to be stuck using events for that tora.

  • >

    >

    > 3) What would this plugin do?

    >

    TBS or turn based strategy behviour rich. lol

    What do you mean? I know what TBS means, but it seems like a really impractical behavior.. perhaps he has some ideas which we aren't taking into account? Separate elements of TBS games like range calculation and visibility/fog of war could be done individually, of course.

  • yea thats what i was saying, its not really worth being a behaviour

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • i think he means a behavior to emulate advance wars or fire emblem or something. which seems like a impossible behavior, since it would have to account for so many things.

    Not in entirely emulating games like advance wars or fire emblem.

    but helping out with the NPc movement.

    perhaps he has some ideas which we aren't taking into account? Separate elements of TBS games like range calculation and visibility/fog of war could be done individually, of course.

    1) To put it in simple terms it will do what a RTS dose.

    It just would do it for in a grid movement.

    The TBS will provides path finding and calculate routes around obsacles on the grid.

    ("In games like shining force, advance wars, or fire emblem the NPC could move around objects

    like trees, water, mountains, walls, etc.")

    2)To give a fixed set of movement to an object

    The object will have to follow this movement until it reaches its objective.

    ("Like in Chess when the Knight only moves in a L shape, but still advances to its objective.")

  • 1) To put it in simple terms it will do what a RTS dose.

    It just would do it for in a grid movement.

    yea this would be pretty useful, but there are ways of doing it yourself. Also why TBS behavior and not grid path finding behavior?

  • Usually if you are suggesting a plugin or behavior, it helps to give a comprehensive description and possibly an example list of the actions, conditions and expressions it might feature. It's impossible to tell what you really mean and precisely what you want it to do if you just give a one line or few lines saying that you want something. When a developer (if they have time) comes to develop it, they'll have to put a lot of thought in to how to design the plugin/behavior, precisely which actions, conditions and expressions to add, and so on. If you don't specify what you're after, someone may make one and it could be completely different to what you really wanted because you didn't say!

  • Besides I think the grid movment behavior has an NPC selection wich moves objects randomly in a zone.

  • Besides I think the grid movment behavior has an NPC selection wich moves objects randomly in a zone.

    I'm pretty sure he wants something which solves like the rts behavior, but for a large grid board like in advance wars or final fantasy tactics or any grid based game. For example, certain units can be told to move a set number of spaces and it will solve the route for them while avoiding obstacles. Also, the obstacles only have to be declared as complete squares on the grid, so this avoids path finding glitches. I admit it would be useful, but it's also pretty easily possible with a bit of research.

  • yea this would be pretty useful, but there are ways of doing it yourself. Also why TBS behavior and not grid path finding behavior?

    becuase "grid path finding behavior" is to long.

    Besides I think the grid movment behavior has an NPC selection wich moves objects randomly in a zone.

    I'm pretty sure he wants something which solves like the rts behavior, but for a large grid board like in advance wars or final fantasy tactics or any grid based game. For example, certain units can be told to move a set number of spaces and it will solve the route for them while avoiding obstacles. Also, the obstacles only have to be declared as complete squares on the grid, so this avoids path finding glitches. I admit it would be useful, but it's also pretty easily possible with a bit of research.

    what Davioware said.

    Usually if you are suggesting a plugin or behavior, it helps to give a comprehensive description and possibly an example list of the actions, conditions and expressions it might feature. It's impossible to tell what you really mean and precisely what you want it to do if you just give a one line or few lines saying that you want something. When a developer (if they have time) comes to develop it, they'll have to put a lot of thought in to how to design the plugin/behavior, precisely which actions, conditions and expressions to add, and so on. If you don't specify what you're after, someone may make one and it could be completely different to what you really wanted because you didn't say!

    TBS Behavior

    TBSConditions

    Movement

    1 Is moving

    2 on arrived at target

    3 on arrived at waypiont

    4 on failed to find path

    TBS Actions

    Command

    1 add waypiont at object

    2 add waypiont at position

    3 move to object

    4 move to position

    5 stop

    Movement

    1 set acceleration

    2 set angle of motion

    3 set deceleration

    4 set max speed

    5 set object type to avoid

    6 set speed

    Settings

    1 add pathfinding obstacle

    2 regenerate obstacles map

    3 set activated

    TBS Expressions

    Movement

    1 get X component of motion

    2 get Y component of motion

    3 get acceleration rate

    4 get angle of motion

    5 get deceleration rate

    6 get destination X

    7 get destination Y

    8 get max speed

    9 get speed

    Ashley I hope this help.

  • This would be REALLY handy. TBS games can be tough to set up piecemeal, and anyway the behavior could be applied to board games as well. This would complement the awesome Card Game plugin that already exists nicely!

  • TBS Behavior

    TBSConditions

    TBS Actions

    TBS Expressions

    Ashley I hope this help.

    That's... exactly the same as the RTS Movement ACEs. If you want a grid version, you should probably get rid of the "Component of motion" stuff (mixing components causes angular motion) and add some grid-specific movement settings and other griddy type things.

    Actions:

    Move Space (Up, Down, Left, Right)

    Move to Destination Cell (Closest, Exact)*

    Set Destination Cell at (XY) **

    Stop at Next Cell

    * "Exact" can return two values: Failed and Arrived. If there is no path, the object will not move and return Failed. "Closest" can return two values: Blocked and Arrived. If there is no path, the object will move as close as possible and then return Blocked. With either option, if the object arrives at its destination it will return Arrived. Can be used for trigger conditions.

    ** Any XY values when used in conjunction with TBS will be converted to the closest grid cell.

    Conditions:

    Compare Direction (Up, Down, Left, Right)

    Cell at XY is Open

    Is Moving

    Has (Object) in Adjacent Cell (Up, Down, Left, Right)

    On Failed to find Exact path

    On Arrived at Destination

    On Blocked from Destination

    Expressions:

    Get current direction (Returns Up, Down, Left, Right)

    Get Cell at Coordinates (XY)

    Get Current Cell

    Get Destination Cell (Returns XY, or current cell XY if not moving)

    Of course, depending on how you want it to work, you'll probably want different ones. I'm just throwing out ideas here off the top of my head, some of these might not even work.

    Also, you may want to consider some sort of Turn Based stuff as well. ACEs for handling, you know... turns

  • >

    TBS Behavior

    > TBSConditions

    >

    > TBS Actions

    >

    > TBS Expressions

    >

    > Ashley I hope this help.

    >

    That's... exactly the same as the RTS Movement ACEs. If you want a grid version, you should probably get rid of the "Component of motion" stuff (mixing components causes angular motion) and add some grid-specific movement settings and other griddy type things.

    Actions:

    Move Space (Up, Down, Left, Right)

    Move to Destination Cell (Closest, Exact)*

    Set Destination Cell at (XY) **

    Stop at Next Cell

    * "Exact" can return two values: Failed and Arrived. If there is no path, the object will not move and return Failed. "Closest" can return two values: Blocked and Arrived. If there is no path, the object will move as close as possible and then return Blocked. With either option, if the object arrives at its destination it will return Arrived. Can be used for trigger conditions.

    ** Any XY values when used in conjunction with TBS will be converted to the closest grid cell.

    Conditions:

    Compare Direction (Up, Down, Left, Right)

    Cell at XY is Open

    Is Moving

    Has (Object) in Adjacent Cell (Up, Down, Left, Right)

    On Failed to find Exact path

    On Arrived at Destination

    On Blocked from Destination

    Expressions:

    Get current direction (Returns Up, Down, Left, Right)

    Get Cell at Coordinates (XY)

    Get Current Cell

    Get Destination Cell (Returns XY, or current cell XY if not moving)

    Of course, depending on how you want it to work, you'll probably want different ones. I'm just throwing out ideas here off the top of my head, some of these might not even work.

    Also, you may want to consider some sort of Turn Based stuff as well. ACEs for handling, you know... turns

    I left out some thing when it come to the turn base stuff, and the properties bar part.

    I did that so I could learn some more TBS, Pathfinding and so on.

    The RTS behavior as a template for TBS works best I think,

    I try using the RTS behavior to make a TBS.

    The only reason I don't use the RTS is it is not pixel perfect.

    After making a TBS system by hand I came up with some new features/ ideas I would like to add the my list.

  • When I said "Usually if you are suggesting a plugin or behavior, it helps to give a comprehensive description and possibly an example list of the actions, conditions and expressions it might feature", I didn't mean paste in the actions, conditions and expressions of an existing behavior. That's not thinking through how it's going to work at all! Rather than focus on the similarities to another behavior, focus on the differences, what's new about it, what it will do, how it will do it, why it's easier, why it's better than existing ways, how it integrates with existing features, the ways in which it will control objects, etc. etc. etc. There's a lot to think about.

    Behaviors aren't made by waving a hand and saying "it'll probably do something like that". Behaviors like the RTS movement are extremely carefully thought out and the algorithms and functionality are very carefully designed. That's necessary because programming is necessarily specific (you're instructing the computer precisely what to do). Feature requests which aren't well thought out are vague (so programmers don't see the benefit of going to all the effort) and also may result in something you didn't want, because you never said exactly what it was you wanted!

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