playMaker

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - jeanfabre

Pages: [1] 2 3 ... 816
1
Action Requests / Re: Material GetPropertyBlock[SOLVED]
« on: November 10, 2017, 01:34:38 AM »
Hi,

 done, available on the Ecosystem.

 bye,

 Jean

2
Action Requests / Re: Timeline - Set Generic Binding
« on: November 10, 2017, 01:34:19 AM »
Hi,

 please update the action for setting generic binding, you';ll have the option to set binding for a track index or track name( Stream Name)
 
Let me know :)

if that's ok, I'll wrap this up and create a package with the timeline proxy as well.

 Bye,

 Jean

3
Action Requests / Re: Timeline - Set Generic Binding
« on: November 10, 2017, 12:50:19 AM »
Hi,

 I think you forgot the animator file:



Bye,

 Jean

4
Action Requests / Re: Quaternion get Angle/Axis
« on: November 09, 2017, 11:53:21 PM »
Hi,

 there is an action for this already: QuaternionAngleAxis

 is it not working for you?

 Bye,

 Jean

5
I'm quite a noob for using xml in game design, but i reckon it would be cool if it could use some sort of nested structure like class inheritance. Something like this:

<EnemyType>
   <EnemyType1>
      <Weapon>Blaster</Weapon>
      <Armor>Adamantium</Armor>
      <Sprite>image.png</Sprite>
      <EngineAnimation>Animation.anim</EngineAnimation>
      <LocalWeaponPosition>(x,y,z)</LocalWeaponPosition>
   </EnemyType1>
</EnemyType>

I suppose you could get data on either runtime or populate some sort of data structure like array or hashtable and then draw data on runtime.

Hi,

 yes totally. I have done that many times. you'll have a manager for your ennemy sitting at the root object of your ennemy instance, then several fsm are going to use this data on command. read the post above for more infos, but basically, each ennemy will be able to build itself based on that xml. you can save data in hashtable for later usage, or use the memory reference, I prefer not having every fsm using xml and indeed have a manager injecting data on other meta fsm ( the fsm that only host data, not doing anything), or hashtables indeed. then you fire a global event to that ennemy including children "SET YOURSELF UP" or something and every fsm will get the data they want, either from their meta data fsm companion, or hashtable or xml directly.

Bye,

 Jean

6
Hi Jean,

I would like to know, how you use XML in your own projects. You create a XML file and fill it with the needed data. After that do you implement this XML file in the unity app and parse it every time it is running? Or do you load the XML one time a change was made and convert it in another format for further use at runtime? I have the feeling parsing a big XML all runtime isn't the best way. But I have no clue.

Or do you use a XML for an at runtime populated database?


Hi,

 Very good questions :)

There is two cases for xml usage, you'll extrapolate on use case, but lets take level management and User Progress


Level Management: you have an Xml file that is part of your assets, it helps define the level content, where objects are, their setup.


-- Level Management

- This xm is generated during editing.
- you load it as is only at the very beginning of the game and keep it in a xml proxy
- everytime you need to build a level, you query that xml proxy with xpath, ask for the level data, save that in a memory reference ( in xml actions you can always save in memory)
- Use this memory reference in all related fsm to build up that level

- NEVER save xpath searched as string for using in game, string conversion is very performent sensitive, always use memory reference when in game.

-- User Progress

- That xml doesn't exist during editing, you create it from scratch the first time the user plays your game
- you save it and load it from the PlayerPrefs. Here you will need to parse it from and to string. So only save in player prefs when not in the game loop, like during the finished menu, pause menu.
- add new nodes related to a particular level and its user progress, when your user comes back, read that particular level node, and update player position, and level data ( some stars may be already picked up, don't show them, some items may be picked up, set them up accordingly)

To give you some numbers so that you understand the power behind this. I have helped game developers with this methods, and their xml level data was over 36Mb of xml in one single file, spanning across 100.000 lines of xml, all in plain english, defining each level ( 6 chapters if I recall properly, 16 levels per chapter). It loads on iPhone at the very beginning of the game, you just simply don't notice it, it takes less than half a second to load up in memory and become available for INSTANT queries using xpath throughout the game.

that same game is using xml for user progress, keeping track of all features, score, per level, total score, all the stars, bonuses, etc etc, and that data leaves in the playerPref under ONE key only! and totally spittable in the console or sent over the network to a server or mailed for debugging on actual existing players, agian because xml is plain english, you have a huge advantage for analysis over messed up multi key setup for playerprefs or database with obscur tables and difficult to retrieve overview of everything.

Bottom line: Xml rocks :) cons, .Net framework messed up big time so xml is not available on windows mobile... so be careful if you plan on porting to windows, which is unlikely but still a possibility. If that's the case, make sure to raise your voice for this total non sense to microsoft, they need to put it back.


as for sample, I am currently working on a mii character setup system, which will be using Xml for saving the user data, you will be able to load up other faces from other people as well, so the whole thing will be running as I explained above, follow me on Twitter for news: https://twitter.com/JeanAtPlayMaker/status/928546642420289537

I'll make that sample available on the ecosystem soon ( it will be iterative, this is fairly advanced project that will take some time to complete)

 Bye,

 Jean


7
Playmaker Help / Re: Cinemachine Actions for controlling Camera Blends?
« on: November 09, 2017, 11:21:28 PM »
cool :)

8
Playmaker Help / Re: mouse look incompatible with ui
« on: November 09, 2017, 11:20:37 PM »
Hi,

 yes, you need to use the uGui full addon package from the ecosystem.

 you have an action called "IsPointerOverUiObject"

you can see it in action with the sample "uGuiCheckPointerIsOverUI" also available on the Ecosystem.

 Bye,

 Jean

9
Playmaker Help / Re: Move object clone to tapped location
« on: November 09, 2017, 11:14:43 PM »
Hi,

 the api update is not a bug, it's a feature :) it will happen in 2017.2 as well, PlayMaker covering so much ground from Unity 4 to 2017 means some api has to be updated and Unity is aware of this and runs this checker and automatically change code where it's obvious. So it's fine.

 bye,

 Jean

10
Hi,

 Excellent! yes xml/json is the next step, but don't rush it, just go along with hashtables, it;'s already a massive improvements right there.

 for json vs xml, make sure to choose wisely, xml will allow you to use xPath which is a extermly powerful way to access data within Xml, something Json can not do, but json takes less size for the same data.

Bye,

 Jean

11
Action Requests / Re: Material GetPropertyBlock[SOLVED]
« on: November 09, 2017, 09:16:09 AM »
Hi,

 I'll do the getters tomorrow.

 bye,

 Jean

12
Known Playmaker Issues / Re: Patch for Unity 2017.2 warnings
« on: November 09, 2017, 07:55:29 AM »
Hi,

 Please redownload this Patch if you did already, I included more disabling around iTween and GuiElements usage in actions.

 Bye,

 Jean

13
Hi,

 there is a difference, the student version will not let you use custom actions, only the actions provided with PlayMaker asset.

 Bye,

 Jean

14
General Discussion / Re: Why Playmaker and not Bolt
« on: November 08, 2017, 11:51:53 PM »
Hi,

also, on Multi Player, you are right, we are actively supported Photon, and we have a close relationship with them to make sure all goes well with PlayMaker integration, so ping me if you have questions on multi player, I am the one in charge with the multi player support :)

 bye,

 Jean

15
General Discussion / Re: Why Playmaker and not Bolt
« on: November 08, 2017, 11:50:07 PM »
Hi,

User Friendly is difficult to assess if you haven't actually used the assets. PlayMaker is going to get the job done far quicker than any other visual scripting for a very good reason, it is not a visual scripting tool ! ... :)

There is a huge misunderstanding with this, PlayMaker is first and foremost a Finite State Machine, and the thinking process is totally different than scripting ( visual or not), so with PlayMaker you never take a line of code and turn it visual as such, you need to understand what it does and think about how to do it from a finite State Machine point of view, it's a paradigm shift in design patterns.

The visual aspect comes from wiring together the states and Finite State Machines components on each GameObjects. That's all.

Also, PlayMaker actions are not just wrappers for each Unity Api function, or property, it provides a lot more and as such makes production a lot faster as a result, typically, to move an object, you are presented with a lot of options, all combined intuitively in one action.

It all comes down to testing them solution for real, Unfortunatly it means purchasing it, hopefully one day, PlayMaker will be offering a trial version.

Bolt will likely resonnate big in Unity Community, it is indeed very well executed, they currently are both the top grossing asset, which tells a lot about the need for Visual Scripting inside the Unity community. So here it will really be a question of feeling, I think both are totally viable solution, but as Kurt mentionned, PlayMaker is battle tested and has been around for 6 years now, HutongGames is also aggressivly investing back your money into support to make sure you are not left on your own for learning. Basically, PlayMaker is here to stay, new tools come and go, some make it, some simply fade off after a year or two. It doesn't look like bolt is going that way tho, proper effort seem to go for this tool and it's good.

The other thing to be aware of is that Unity is likely going to come up one way or the other with its own visual scripting, and I know why they haven't committed yet, because they are facing a very difficult choice:

either you use an all around solution like Bolt and Kismet ( visual scripting for unReal Engine), but you rely on either code reflection which is bad for perfs or generated code, which sucks and also has perfs impact and limitations, or you go the PlayMaker way, where each api is wrapped around a regular script, and you leave the visual aspect for handling the high level communication between these actions. The downside is that you need to constantly support new api and new features for non coders ( PlayMaker has reflection in some actions to let you access new stuff, but it;'s generally not recommended, ask us for a custom action instead).

Remember that PlayMaker visual scripting tools is not just for non coders. I can do everything by code, yet I use PlayMaker for 100% of my personal project and client's project, because I am faster with it then with pure scripting, I verify this everyday... It's quicker to write a custom action and reuse it over and over in various projects than writing the same lines of code many times and end up with duplicates of the same features in every projects of yours... PlayMaker helps with this tremendously.

Bottom Line, there is a chance Unity will come up with its own solution and its likely to look more like Bolt than Unity, because it's less risky for the market and a direct competitor for Kismet. PlayMaker is on a league of its own.

PlayMaker helps both world, you are non coder, fine, you are a code fine... with bolt, I don't see any coder getting into this because it's a one to one relation with regular scripting. PlayMaker brings on the table far more. I was at Unite last month, and the remarkable feedback that we got was that many developers would just stop by and thank PlayMaker for having helped us make it in the industry, they started without coding experience, then slowly started getting into scripting because it's not that hard and you start by writing simple custom actions, and after a while, you end up using PlayMaker and scripting combined and you litteraly reach the sweat spot, being totally empowered to do anything you want with Unity: fast and fun.

There is also the Ecosystem browser, which is a convenient In Editor browser for custom actions hosted online on various github repositories, giving you access to thousands of custom actions, samples and packages.

Bye,

Jean



Pages: [1] 2 3 ... 816