Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Dismiss Notice

Going from Flash to Unity

Discussion in 'General Discussion' started by Barzona, Oct 4, 2014.

  1. Barzona

    Barzona

    Joined:
    Apr 8, 2014
    Posts:
    14
    It's as it says. I've been studying AS3 for a couple years now and am trying to make the leap to Unity. I've also been working on my first serious game for about 3.5 months, but since I noticed how cool Unity is, I want to port my progress over and continue on from there, as well as expand on it.

    There are a few things I don't understand, yet. In Flash, you'd have your .fla file that would link to your document class and then all of your custom child classes would just branch out from there. What's the equivalent to the document class and the .fla in Unity? Forgive me if I'm assuming that the two are even that similar at all and it turns out they aren't. I just need to know what to associate with what.

    Also, when I look that the Unity tutorials for scripting, I notice you have three different coding languages. From a glance, I think I would rather try my hand at C# rather than Java or Boo(which I've never even heard of. Which is the true best out of the three for making a simple browser game?

    Any advice is welcome.
     
  2. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,613
    Unity's equivalent to a .FLA file is 'your entire project folder.' Instead of packing all your assets into a big FLA file with supporting code files, you have them loose on disk in your Assets folder.

    There's no one single 'document' class equivalent; there's no object in code that represents 'the whole game' (unless you count UnityEngine.Application, which I don't, because it's static). You only have the child classes - individual component behaviours that you attach to game objects.

    Unity officially supports only two languages, C# and a variant on Javascript that we call UnityScript; Boo used to be supported, and it still works, but it's officially being phased out. The question of which is best is largely a religious one, but depends more on you than your project; as an AS3 coder you'll find UnityScript pretty familiar, but there are more resources for C# available.
     
    Cogent and Barzona like this.
  3. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,797
    Boo is SCARY, don't go near it.

    Any serious studio uses C#.

    And if you develop on windows of course you want the power that be Visual Studio, which offers far better intellisense for coding in C# than you would get from using UnityScript or MonoDevelop.

    And you can go even a step further and invest in Resharper, which makes coding in C# even more powerful and efficient.
     
    Barzona likes this.
  4. Barzona

    Barzona

    Joined:
    Apr 8, 2014
    Posts:
    14
    Sounds easy enough.

    About the child classes, and I guess this would be more of a coding question, but in AS3, I'd add certain objects to certain arrays and loop through said arrays to give each object the functionality of their class. For instance, I would have a Fruit.as class. In the Fruit class, I'd have a function to moveFruits(); and from the doc class I'd pass that function to all of the fruits in the fruit class by looping through the fruitArray.

    Are we still doing things like adding to arrays and checking for collisions with loops in Unity?

    Also in Flash, dragging objects from the library to the stage to set up a game was always considered very bad practice since adding things dynamically was the best way to go. In all of the tutorials I've seen, I only ever see people dragging their assets into the "stage". Either this is the right way to do it, or they are just trying to be quick.

    Sounds like I should stick to C#. Strangely, it looked more familiar to me compared to AS3 than the other two did based on the first few examples I was given.
     
  5. Barzona

    Barzona

    Joined:
    Apr 8, 2014
    Posts:
    14
    Sadly, I am on a Mac. ran into the same problem when I wanted to use FlashDevelop. I will be sticking with C#, though.
     
  6. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,613
    Effectively, yes, but it happens internally to Unity.

    You have your 'Update' function in Fruit, and Unity will automatically call it for you on every Fruit component once per frame. There's a big diagram of all the points at which Unity can be made to run your code in the manual (or you can use my older but color-coded version).

    If you still want to have your own arrays of objects and call moveFruits() yourself, you can do that - you have one object somewhere with an Update() function which just does it - but you can't edit Unity's loop itself.

    It depends on the situation, but usually there's absolutely nothing wrong with building up your objects at edit time. For some games - anything with a substantial 'game world' - it's pretty much required, as you don't want to be hard-coding the position of every individual piece of artwork that makes up your game level and then having to launch the entire game just to see if things are in the right places.

    One way to look at it is: putting objects into a scene is like building an 'instantiation script' for Unity, because that's what it does with the data at runtime, it goes through the list of everything you put into the scene file and instantiates it into memory. You can have as many scenes as you want, so you can put off 'running the script' (i.e. loading the scene) until the appropriate time - e.g. when the user's selected the level they want to load.
     
  7. Barzona

    Barzona

    Joined:
    Apr 8, 2014
    Posts:
    14
    Okay okay, so it seems like Unity automatically handles a large amount of functionality by itself. I read about the game "No time to explain" and how they were porting it over, but Unity handles its own physics and how it was was a problem for a Flash game that uses no physics. They had to work around it since, I guess, they couldn't disable Unity's built-in physics engine. I was only glancing at it, so I may have interpreted it wrong, but if it's true, that might be something of an issue. Correct me if I'm wrong about all that.

    Alright, if it's okay/expected to build directly in the stage area, I won't sweat it. Kinda makes me feel weird, though. Makes me think keeping things neat and tidy would be difficult.

    So, are scenes basically how you would handle levels? The main menu would be a scene, the map would be another, and each level would be their own?

    Alright, I won't bug you with any other questions if/after you respond. I could go on forever if I don't stop now.
     
  8. superpig

    superpig

    Drink more water! Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,613
    If you don't use the physics components, you're not feeding any data to the physics engine, so it doesn't really do anything. It's still there, just idling, burning up a fraction of a millisecond every frame. Not that big a deal.


    Keeping things organised definitely takes a bit of experience.

    Yes, that's a common way.

    Well, this is the forum, it's a good place for questions. But yeah it sounds like you could use a little experimentation time at this point.
     
  9. crag

    crag

    Joined:
    Dec 13, 2013
    Posts:
    145
    Opinion Police Alert! :)

    No offense @Meltdown but I don't see where OP mentions "studio". I see an indie dev who is making the transition from AS3 to Unity.

    Further, I am from the same boat. I was originally intending to jump into C# but the crew that contracted me requested UnityScript. These guys build shizzit way brainier than your typical 2D/3D games. Rather "gamified" physics/engineering apps being used in science classrooms across the US. I don't think you could blame them for being "not serious." ;)

    @Barzona I think it is important to note, like @superpig mentioned earlier, UnityScript vs C# is a religious debate BUT in MY experience many of the plugins you will find on the Asset Store are built in C#. Only a handful offer both. Why is this important? Eventually, it becomes a supreme pain in the ass to integrate both UnityScript and C# plugins. So, while I don't agree with "serious studio" angle, I DO agree with the "start with C#" mentality.

    In your favor, you are comfortable writing your own classes and generating content dynamically (I was often guilty for building flash projects with one empty keyframe). This is totally cool in Unity, you don't need to use individual scenes for menus or game levels, it can all be handled in one. You will generate your own workflow while you progress. You will learn some "best practices" from others. This community is unmatched in quality... leverage it.

    External Tools Tip: MonoDevelop sucks butt on Mac. Avoid at all costs. Sublime Text has been my choice. JetBrains ReSharper looks killer but does have a price tag on it.

    Development Tip: stay out of "Update" when possible. Depending on your game or app, there are many instances that you can do most things event-based.
     
  10. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,797
    Why does he need to mention the word 'studio' first in his post in order for me to mention that only serious game studio's that use Unity use C#? And no, it's not an opinion, it's a fact.
     
    Ryiah likes this.
  11. crag

    crag

    Joined:
    Dec 13, 2013
    Posts:
    145
    Soooo this crew that hired me is not serious? Hmm. And I thought they were, all those checks and business cards and websites and stuff. Guess now I know they are all smoke and mirrors. *shakes head* Thanks for clearing that up.