So, uh. I could write something here, but I kiiiiinda already made a blog post on the subject. http://eyesineverything.com/blog/blog/2017/05/25/reassessing-my-future-as-a-game-developer/ ^ Click it. Read it. Pretend I'm funny. It's all a difficult realization to come to, but ultimately, one that leaves me feeling optimistic for the future. I would like to hear your insight.

[ispoiler]Whew... I thought you were quitting Psycutlery, and maybe game development![/ispoiler] Yeah this is good news. I'm glad to see you're modernizing! Hopefully MFGG as a whole will follow in suit.

Neat! The switch to Unity is definitely a good choice. Unity is primarily aimed at 3D development, but they're catching up on 2D functionality. Plus, Unity runs on C# which is a big plus. And the Switch becomes a very viable possibility with Unity :D

I agree with Coco, while I don't think Unity is the best 2D game engine out there it's still miles better than Clickteam Fusion and it's undoubtedly the best choice for a Switch game. I'm kinda sad that the game's delayed, though.

As a Unity programmer, it's fine for 2D, despite there being many annoying things about Unity. I'm open for questions, if you need help.

^ Hey, thanks for the support! Would like to know what said "annoying things" are before I dive in, just to be prepared! The decision to research Unity comes from a good friend of mine, who, incidentally, happens to be the creator of Angry Video Game Nerd Adventures -- a Fusion game that you may have seen on 3DS and Wii U. I won't go into details, but going by our conversations, getting Fusion projects on Nintendo consoles [i]might be more trouble than it's worth,[/i] to put things mildly. This was his reason for switching to Unity for the sequel and everything else that would follow, and he's been highly recommending it to me ever since.

I never noticed anything too annoying in Unity so far, but I exclusively used it for 3D so far. The only thing I want to point out is to always make sure your game isn't running in the Unity IDE while you're compiling scripts. Most of the time you just get an error message but it can have some funky results.

Well, I wish you the best of luck with the move. Experience using Unity is always a good thing to have, and if it makes releasing the game on Nintendo systems easier, that's all the better. Just... don't scrap all the assets for the game. It's really the engine you need to change, not the art style. I could do with seeing a new soundtrack yes, but I think you'd be throwing away good stuff if you tossed the graphics out here.

Here are some notes I saved about Unity, originally from a file called "How Unity Works". These are just unexpected serialization problems. The serialization thing DJ Coco refers to is due to him not setting up his game to be serialized and deserialized correctly, which becomes less practical as your project gets bigger. It's a minor problem. Since you're new to Unity, I doubt you'll run into the problems below. I have not recently verified all of these with the newest version of Unity. I also apologize for the formatting and grammar. They were only meant to be seen by my eyes. [spoiler]-Unity does not correctly support animating multiple instances of the same component within a single GameObject. -Unity's GUI control focus (SetNextControlName, SetFocusedControl, etc): if multiple controls are given the same name, SetFocusControl will focus on the control named last. -GUIUtility.hotcontrol, GUIUtility.GetControlID(type): --set hotcontrol to zero so that other controls can take focus --the ID sequence given is the same per UI step. Thus, dynamic controls that are given IDs need to consider this problem Undo: Unity doesn't replace the reference unless it has been deleted. It's easy to test. You just create a non serialized field, set a value, and then try to Undo. After the Undo and redo, the non serialized value is unchanged, meaning that the component instance is the same. However, if you delete the component and undo to recreate it, the non serialized value is lost. This makes sense since there is no class to overwrite If you have a reference variable tracking an item in a list. If an Undo overwrites, then the tracker is overwritten instead of its reference changing. If the tracker was set to a deleted item, then an Undo overwrites the tracker, it does not replace it w/ a non-deleted item reference. -Note. This only applies to custom classes, not classes that inherit from monobehaviour or are transforms. These references are replaced instead of overwritten, as desired. none of Enable/Disable/Destroyed are called in edit mode (tested w/o ExecuteInEditMode attribute) Serialization: -a private serializable-type will be serialized between code recompiles, despite it being private and not marked as serialized or nonserialized. -if you mark it as nonserialized, then it won't persist between recompiles. -note. private fields not marked as nonserialized or serialized will not persist from edit mode to playmode //note: Unity serialization does not support nested type constraints (class notSerializable: SerDictionary<iVector,List<int>>) unless the nest is explicitly defined as (class serializableClass : SerDictionary<iVector,SerList_Int32>). Within the inspector, if you click Reset() on a component, the function will execute on a new instance of the component, not the existing component. Undo caveat: When a list has elements removed throughout multiple steps during an event (RepeatButton, MouseDrag, KeyDown, etc) Undo.RegisterCompleteObjectUndo() should be used instead of Undo.RecordObject(). The latter saves a diff. The former saves the complete state. For list element removal, you should use the former. There is no editor support for selection order. You can get the current selection.. just not the order they were selected. This is problematic if you ever want to create tools based on selection order, similar to how Blender works.[/spoiler]

Thank you, Coco and TheShyGuy -- I have yet to get much farther in the program than just downloading it, so I'd be lying if I said I completely understood what has just been posted. Hah. Nevertheless, I am now saving it all to a text file for when I [i]do[/i] gain some semblance of understanding! Could be a bit before I dive in -- need to assess if and how soon I'd need a new computer, solidify certain plans, and take things one step at a time... kinda need to focus on work this coming week as I have a bit of a project, but we'll see where things go from there. @CM30 -- No intention of scrapping my art assets, although some may require improvements (might redo the dialogue portraits, dunno). And I'm sorry to say I have no intention of switching out my musician either, although I'm sure he'll be open to critique!

[quote="TheShyGuy"]The serialization thing DJ Coco refers to is due to him not setting up his game to be serialized and deserialized correctly, which becomes less practical as your project gets bigger. It's a minor problem.[/quote]Hm? I'm pretty sure the thing I pointed out has nothing to do with serialization. Even if so, it doesn't make much sense to ensure everything is serialized correctly for scripts with stuff that's never meant to be serialized. It's not a big deal though, as you just need to quit playmode before recompile. Alternatively, there's even a failsafe script: https://forum.unity3d.com/threads/stop-play-mode-in-editor-when-script-changes.403922/#post-2632396 Also @TSG: A lot of these things sound like Unity bugs. Might want to report them back to the developers via "Help -> Report a Bug" so they're fixed in an upcoming update. https://unity3d.com/unity/qa/bug-reporting

DJ, check out the docs https://docs.unity3d.com/Manual/script-Serialization.html "Hot reloading in the Unity Editor" and I'll reconsider reporting the bugs. Thunder Dragon, yeah the notes are for the future you when/if you run into these problems.

[quote="TheShyGuy"]DJ, check out the docs https://docs.unity3d.com/Manual/script-Serialization.html "Hot reloading in the Unity Editor"[/quote]Ah, interesting. That explains why Unity doesn't automatically stop play mode on recompile. I can see that being useful, but mostly you just want the game to stop running when you recompile the scripts :P Especially when writing to external data you wouldn't wanna interfere with that in play mode lol.