Hello there, which one is better for building a game for iOS? What are the differences between this tools? Does they do the same? Or can I combine both? Thx!
The difference is that uScript is a visual scripter for "general purpose code", so you can do basically everything but you are also responsible for managing it meaningfully. PlayMaker on the other end is no visual scripter in the same sense, its a Finite State Machine Editor. That has its benefits and cons, but especially if you are no savy programmer this is a major benefit as it ensures that you think about stuff in a clean way. uScript / Universe both don't lend a hend to prevent beginners from creating spaghetti code in graphs - which out of my view and experience means that you create even worse code than in text as a graph takes several times longer to be understood especially if it missbehaves. So combining the two and making best use of them where they really shine is likely the best thing you can do
uScript is a visual scripter -> replaces writing text by placing the more or less same stuff in nodes PlayMaker is an FSM editor -> you define states, define what happens when a state is entered, what happens upon exit of a state and upon transition and basing on whta such transitions happens Thats the difference anything beyond requires that you read up on the two things and what a Finite State Machine is
@dreamora - Your descriptions have piqued my curiosity. I code in UnityScript 99% of the time and although I'm comfortable with it, it's sometimes hard to track down errors in logic, especially in larger scripts. Would either of these help me to visualize my code better? How easy / hard would it be to "convert" my scripts into either of these formats?
Conversion to uScript would be relatively easy depending on what it does (anything thats very set enumeration / loop heavy can be hairy to deadly), but conversion to PlayMaker is basically impossible unless you had clean, state based code right from the start. Its out of my view impossible that you can track down errors in logic faster with any form of visual scripting than you can with debugging gives gives you clear insight. As uScript at the time lacks a visual debugger, I would have to point you to Antares Universe if you want to stand a chance to even identify errors in logic, uScript requires that you are able to pull of educated guesses to godlike guesses to find such errors or that you annoy yourself to hell by using the comment functions which let nodes that are activated fire off a text (thats as bad debugging wise as debugging was in unity 2.x prior the mono debugger support) There is one exception to this 'impossible': If you have a heavily state based environment, then PlayMaker will definitely allow you to find state transition problems and state mixup problems significantly faster than code level debugging as you aren't flooded with a lot of info you didn't want and didn't need
I'm totally for PlayMaker! they also have iOS related stuff, I'm not doing crazy programming but from time to time I found it difficult solving a problem with just unity scripting so now that I use Playmaker my life is a way easier, I know it sounds like a commercial but it's true eheheh .
@daxx2k: Ok, But wouldn't it be much more flexible with uScript? @all: Could a game like Mario or Zelda (completely) completed with PlayMaker or uScript? (this is truly not my goal, just want to know it) @all2: So uScript is like RAD for Apps? It saves me a lot of work, but let it flexible enough to do what I want to do and PlayMaker works 'only' the YES/NO-Way (YES entered room, light on - NO, didn't entered, light off)?
They generate functionality, they have nothing to do with "gaming tools" nor would I define them as RAD tools as they aren't limited in any such way, they can do what you feed them with through adding custom functionality. Also PlayMaker is no "YES/No" way thing but a state machine. State machines have nothing to do with yes / no or even branching as such. If you search for an analogy think of a DVD player thats in fast forward, rewind, stop, pause or play state, that for example would be a state machine. Games to a very large degree are state machines so its very well suited for this usage. There are only a handfull of areas where it can't be used and where you would need to use independent code or uScript, but half those areas also required that you are an advanced programmer with experience or interest to learn about the field indepth.
I originally bought Unity because I'm not a real programmer so I wanted something that was dealing with all the crazy xcode programming and focusing more con the art and gameplay of the game, unity scripting is fairly easy if you wanna do simple things, but know I don't even need to do that anymore with PlayMaker. I did this game : http://itunes.apple.com/us/app/toothache/id368884249?mt=8 it's nice and is not overly complicated to script, but it was my first app so I took time to learn unity scripting to do everything, I'm sure I can redo the entire game with playmaker in a way less time it took me the first time. Actually I've done an update to that game (not released yet) and I made it with Playmaker because it was easier and faster in that way
Sorry, missed this thread somehow... PlayMaker has a comprehensive set of SpriteManager2 Actions. There are also custom actions on the forums for EZGUI and other 2d libraries. RageTools + PlayMaker also looks like a winning combo for 2d games. Check out the end of the demo video for a timelapse showing RageTools + PlayMaker Also, bear in mind, with the 1.2 update, PlayMaker now has generic Get/Set Property Actions that let you interface with Unity components without writing custom actions. And I'll also be spending some time with uScript to see how to maximize PlayMaker + uScript (e.g., making PlayMaker actions with uScript). That could also be a killer combo!
Playmaker all the way. Why? Because in a couple hours or in a couple days in the worst scenario , you will be productive 100%.
This thread is a bit outdated but you guys might be interested by an alternative. Behaviour Tree is technique coming from AI and it can be a powerful tool handle your logics. I recently released Panda Behaviour on he Asset Store, which is a script-based Behaviour Tree Engine. It's a compromise between coding and visual scripting; you still write C# codes and additional BT scripts but the behaviour can be visualized and debugged as it is executing. More info here: http://www.pandabehaviour.com/
Eu sinceramente nunca usei o uscript, mas eu estou aprendendo. Parece muito fácil, mas eu sei que a ferramenta maker play é mais completo e tem sido usado por um longo tempo. Mas se é para criar um jogo usar tanto porque ambos trabalhando juntos podem oferecer um grande resultado. E uma coisa que eu já estou fazendo é usar uscript como scripts Eu não posso criar em C # Mas uma coisa que eu te digo se é para criar um jogo PRA MOBILE usar o criador do jogo porque do que eu vi, é mais estável e Seguro além de renderizar melhor o fps =)