first of all i'd like to say that i started using Playmaker 1,5 years ago with some small previous programming knowledge in Java and i made a huge progress in that time. With progress comes further knowledge and the need to do stuff faster and simpler, which is the goal for all of us. Sure, i've got a lot more to learn as you have seen on the forums, but some things really started to hinder the progress.

I'm satisfied with global variables editor, though it can be tedious to work in it. How can i be satisfied if it's tedious to work with? Well, the principle is good, it is fast, but there are simply too many variables in use in any decent project to handle them in the editor. I've got about 800 global variables (for now), editing them in a meaningful manner is not viable without exporting and importing from a spreadsheet.

Easy Save (and Game Data Editor too) does a great job in exporting globals to a comma delimited file which can be easily manipulated in any spreadsheet software. Unfortunately, there's no way of reimporting it, so the export is only good for analysis purposes and you have to do any variable modification inside the engine. Easy Save 3 will probably have csv importer as far as i have seen, but i don't see why wouldn't Playmaker have such a feature natively? All the globals are saved in playmakerglobals anyway, just not delimited.

There's also been a discussion on "local global" variables (which can be seen between different FSM's on same object) but i see that discussion is from 2012., and though that would make things harder for rookies i think that would definitely cut the amount of work and number of variables needed later on in the development.

Another thing that i find a bit problematic are local variables. I don't think it would be easy or fast to make it possible, but viewing and editing those OUTSIDE the FSM with a pointer to the object they're attached to would be an enormous time saver. As of now, going from FSM to FSM is really time consuming.

With all that and some workflow stuff like grouping states it could became the ultimate all-in-one powerhouse.

I probably can, but as you probably remembered from the topics, i grasped arrays and hashtables in Playmaker not so long ago. This is my first bigger project so it's probably kind of messy and can be done a lot better. The thing is, it's easier for me to keep stuff in global variables which are exportable, quickly editable through editor and easily replaced in FSM by dragging and dropping then adding an another element to array/hashtable and then calling it from there every time i want to test something out.

ouch... I strongly advice you to cut down on the global variable usage, a typical sane project, may have 2 3 global variables top, above 10 you should use a dedicated MetaData Fsm hosting just local variables and have other fsm getting that value using getFsmXXX()

above 20 and when you realize there is a pattern, use ArrayMaker or similar. and have a global variable to the gameobject hosting these values, that's fine.

I don't think there is a technical drawback, it's just a very bad design pattern, that's all and the PlayMaker interface is not suitable for handling so many of them, as it's not supposed to work this way ( doesn't mean it should not be improved for clarity, etc etc).

i just wanted to say i listened to you, i deleted all but most important globals and made about 20 hash tables for storing data and cross referencing. To avoid fiddling with globals, i use Easy Saves 128-bit encryption. So there's really no need for any kind of globals exporter.

I know it can be made more efficiently, with a few xml/json files, but step by step

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.

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.

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)

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.