playMaker

Author Topic: Playmaker 2.0 concerns  (Read 14240 times)

fatihkran

  • Playmaker Newbie
  • *
  • Posts: 4
Re: Playmaker 2.0 concerns
« Reply #45 on: November 23, 2020, 08:23:38 AM »
Subscription = no
Pay to upgrade = yes
Upgrade free = yes

+1

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: Playmaker 2.0 concerns
« Reply #46 on: November 23, 2020, 06:13:41 PM »
On the other hand, wanting property for a plugin that cannot exist outside of a tool that's on a subscription model might seem slightly absurd.

Broken Stylus

  • Beta Group
  • Hero Member
  • *
  • Posts: 772
Re: Playmaker 2.0 concerns
« Reply #47 on: January 01, 2021, 07:12:16 AM »
I've read this blogpost and I saw some requests in it that might be worth considering.

Quote
Fortunately, I was using Rider, and it has an incredible decompiler. It took some poking around and trial and error, but I managed to build a little wizard that would spit out FSMs based on a template, which sped up their process a lot. Obviously using private external APIs is not super safe, so my second wish for Hutong would be that they provided a public API for assembling FSMs and states via code for automation tasks – with that, we could have something that would parse a marked up text and generate the first pass on an FSM, having the best of both worlds.

Quote
Selecting a tool that will be an integral part of development is a always a bit of a leap of faith. Even though it doesn’t come without it’s problems, Playmaker has allowed me multiple times to enable designers and focus on shipping games instead of maintenance of non-game-specific code. It’s also important to notice that it is a tool that serves a specific purpose: it’s a state-machine based visual scripting editor made to be self contained, and that’s what you’ll get, so you should only use it if that’s what you need; it’s not a behaviour tree system, it’s not engineered towards working with external dependencies, there’s no API for building state machines via code.

Fat Pug Studio

  • Beta Group
  • Hero Member
  • *
  • Posts: 1294
    • Fat Pug Studio
Re: Playmaker 2.0 concerns
« Reply #48 on: August 10, 2021, 03:53:05 PM »
I've read this blogpost and I saw some requests in it that might be worth considering.

Quote
Fortunately, I was using Rider, and it has an incredible decompiler. It took some poking around and trial and error, but I managed to build a little wizard that would spit out FSMs based on a template, which sped up their process a lot. Obviously using private external APIs is not super safe, so my second wish for Hutong would be that they provided a public API for assembling FSMs and states via code for automation tasks – with that, we could have something that would parse a marked up text and generate the first pass on an FSM, having the best of both worlds.

Quote
Selecting a tool that will be an integral part of development is a always a bit of a leap of faith. Even though it doesn’t come without it’s problems, Playmaker has allowed me multiple times to enable designers and focus on shipping games instead of maintenance of non-game-specific code. It’s also important to notice that it is a tool that serves a specific purpose: it’s a state-machine based visual scripting editor made to be self contained, and that’s what you’ll get, so you should only use it if that’s what you need; it’s not a behaviour tree system, it’s not engineered towards working with external dependencies, there’s no API for building state machines via code.

Very nice, i'd rather like it without crippling bugs and functioning global variables first :)
Available for Playmaker work