How hard is to convert a usual c# code to Unity?

[Edreyn]

Hello everyone,
I have been developing a video game for some time. I guess I can’t post its name, since it’ll be advertisement, so I’ll try to explain it with words.

First of all, why I am thinking about converting to Unity. C# is language that is very easy to learn and use, but with big potential. However it has one big problem - game written on it, won’t work on Mac or mobile platforms, which means losing a big part of potential buyers.

First, I considered using Xamarin, but it only works on Visual Studio 2017 (and I have 2013). Not only the new version is very expensive, I also can’t be sure that older code won’t have problems on new platform.

So, I am considering Unity as an alternative.

The question is - how hard is to transfer all the content (and there is much of, since I am past alpha) to Unity. I need to transfer all images, and of course all the coding. About how hard and long that can be?

The game is an adventure, with static screens (moving between areas is done with one click, one scene is then replaced by another), so no character movement. Of course there are objects that can be interacted with, but for each such object, there are a number of possible images.

More easily - each room has a background image, each room object has a few possible images to put on top of background.

Code wise - there are only a few classes, but a large number of variables, arrays, lists and dictionaries.

Each game object has void methods for: Click, Mouse Enter and Mouse Leave.
Each area has: On Visibility Change

And there are many timers for pseudo-animation, like if you click on cupboard, it doesn’t open right away, but only a 0.5 second pause. That’s just an example, there are more complex timers.

Well, I explained the best I can. I repeat my question - how hard is to convert the game of described complexity from generic c# to Unity?

Thank you in advance,
Evgenie

[Schneider21]

@Edreyn

how hard is to convert the game of described complexity from generic c# to Unity?

How skilled of a programmer are you?

It’s difficult for me to surmise that from your post. If you have a “post-alpha” game with only a few classes using just generic C#, I’m suspicious you don’t have a ton of experience. That, or your game is insanely simple.

If I was creating a game outside any engine, I would need a dozen classes to get even a generic UI system running. Maybe that’s more a stylistic thing, but if your game is anything more than clicking to swap out images, I feel like the classes you do have are real monsters.

In any case, all of your existing assets will need imported and converted/configured to comply with Unity’s API. I’m assuming most of your images would be converted to Sprites if you’re planning on using Unity’s built-in UI system.

If you’re using Unity’s UI, you’ll have to strip out any code you wrote relating to UI and instead use the API and editor to set functionality.

Unity uses C#'s coroutines for doing tasks over time, which would handle your animations. Alternatively, you could use the Unity API Update loop and lerp movement of objects, or Unity’s animation state machines.

It’s absolutely doable, of course. But how much work it is and how long it would take is totally dependent on the specifics, both with your project and more importantly, with you.

[JoeStrout]

Hello, and welcome to the forums!

@Edreyn

I have been developing a video game for some time. I guess I can’t post its name, since it’ll be advertisement, so I’ll try to explain it with words.

It’s perfectly fine to name your game here, particularly if that would help us to understand what you’re doing. We’re not too picky about people promoting their own games in the context of some question or answer.

First of all, why I am thinking about converting to Unity. C# is language that is very easy to learn and use, but with big potential. However it has one big problem - game written on it, won’t work on Mac or mobile platforms, which means losing a big part of potential buyers.

That’s not quite true, of course. C# works on all platforms… I myself have written simple games in raw C# on the Mac, using Mono and my favorite text editor. However beyond a certain complexity, it becomes much easier to do it all in Unity, even if you’re only targeting one platform. So I’ve never finished a game in raw Mono; it’s just not worth the extra effort.

First, I considered using Xamarin, but it only works on Visual Studio 2017 (and I have 2013). Not only the new version is very expensive, I also can’t be sure that older code won’t have problems on new platform.

Yep, and their support for Mac is very poor. I too had high hopes for Xamarin, but I’ve given up on them.

So, I am considering Unity as an alternative.

You are smart. If you like C# and want to develop games, Unity is the only sensible choice, by far.

The question is - how hard is to transfer all the content (and there is much of, since I am past alpha) to Unity. I need to transfer all images, and of course all the coding. About how hard and long that can be?

As @Schneider21 says, it depends on your skill and the complexity of your code base. But probably not long.

It sounds like your game is entirely 2D, with simply overlaying images at various places and responding to clicks. The standard Unity way to do these things is with Sprites, but in your case I suspect it might be easier (and would work just fine) to do it entirely with UI elements (mainly Image and Button).

So, I suggest you set aside a few days or a week and work your way carefully through the UI tutorials. Then start a new project, move your images over, and start building it up. If your code is neatly factored with UI stuff separate from game logic, you’ll be able to use your game logic scripts pretty much as they are (and throw out the UI scripts; you won’t need them).

Good luck, and have fun!

[Kiwasi]

It will cost you a day or two to learn the interface and port across a screen or two. That experience will give you more data on how the process is going to go then anything we can offer.

You will need to restructure your code around MonoBehaviour to receive Unity’s various messages. There is no main in Unity, instead the engine handles the core loop, and calls into your code at various stages.

Any utility or data classes will be able to be used pretty much verbatim in Unity.

@JoeStrout

It sounds like your game is entirely 2D, with simply overlaying images at various places and responding to clicks. The standard Unity way to do these things is with Sprites, but in your case I suspect it might be easier (and would work just fine) to do it entirely with UI elements (mainly Image and Button).

I would recommend Sprites. You can still tie them to UI input with a Physics2DRaycaster on the main camera. Sprites are easier to position programmatically then UI elements. And I believe they are more performant (although performance is likely not a consideration for this game).

[Ryiah]

@Edreyn

First, I considered using Xamarin, but it only works on Visual Studio 2017 (and I have 2013). Not only the new version is very expensive, I also can’t be sure that older code won’t have problems on new platform.

Xamarin works with Visual Studio 2017 Community edition which is completely free.

https://forums.xamarin.com/discussion/91729/getting-visual-studio-2017-community-xamarin-working

Unless you don’t qualify for the free VS Community license there are very few reasons to actually buy VS.

https://www.visualstudio.com/license-terms/mlt553321/

[JoeStrout]

@Kiwasi

I would recommend Sprites. You can still tie them to UI input with a Physics2DRaycaster on the main camera. Sprites are easier to position programmatically then UI elements. And I believe they are more performant (although performance is likely not a consideration for this game).

Either would work, and Sprites are certainly the more standard approach. But positioning UI elements programmatically isn’t that hard; you get the RectTransform and assign to anchoredPosition (and keep a consistent anchor reference point, such as the lower-left corner). Of course this requires typecasting .transform, so you’d probably want to wrap it in a helper method.

But then you can get MouseEnter/MouseExit/Click events pretty much for free.

The main problem with using a ray caster on the main camera is that, sooner or later you’re going to add some UI (even if it’s just a pause screen or options dialog or whatever), and then you’re going to want to not pass the mouse behavior to your game objects while it’s over the UI. And that gets really thorny. You end up ripping out your camera-based raycaster and instead putting a big invisible Image with an EventTrigger component at the top of your UI hierarchy, so it only gets events when there isn’t something else on top of it. (And then that can of course invoke something that does ray-casting to deal with sprites.)

@Edreyn , don’t let all this scare you. When I say things like “hard” or “thorny” in the context of Unity, you should think “minor annoyance” by the standards of most other environments. Sprites or UI, either will work, and either one is going to be pretty easy. If you run into any speedbumps along the way, we’ll help.

[Ryiah]

@JoeStrout

The main problem with using a ray caster on the main camera is that, sooner or later you’re going to add some UI (even if it’s just a pause screen or options dialog or whatever), and then you’re going to want to not pass the mouse behavior to your game objects while it’s over the UI. And that gets really thorny.

Raycasts can be specified with a layer mask. What’s preventing you from simply telling it to ignore the UI layer?

[Kiwasi]

@JoeStrout

The main problem with using a ray caster on the main camera is that, sooner or later you’re going to add some UI (even if it’s just a pause screen or options dialog or whatever), and then you’re going to want to not pass the mouse behavior to your game objects while it’s over the UI. And that gets really thorny. You end up ripping out your camera-based raycaster and instead putting a big invisible Image with an EventTrigger component at the top of your UI hierarchy, so it only gets events when there isn’t something else on top of it. (And then that can of course invoke something that does ray-casting to deal with sprites.)

@Ryiah

Raycasts can be specified with a layer mask. What’s preventing you from simply telling it to ignore the UI layer?

Can I take a moment to express my disappointment that neither of you appear to be subscribed to my channel. Or if you are, you haven’t religiously memorized all of my videos?

Skip to the third method

Unity UI - Blocking clicks

Anyway, the text version for all you text purists out there is as follows:

• Create an EventSystem
• Attach a Physics2DRaycster to the appropriate camera
• Attach a Collider2D to any sprites that need to be interacted with
• Attach appropriate interfaces, EventTrigger or Button to the sprites

Doing it this way means that you can drive all mouse and touch input through the EventSystem. Then you never get conflicts between the UI and world objects.

And to top it off, you can also build custom Raycasters that behave in anyway you like.

[JoeStrout]

Well, yeah, the only problem with your YouTube channel is that it appears to consist mainly of videos.

But you’re absolutely right, I forgot (or never knew) that EventSystem works directly with on a Physics2DRaycaster (actually, all such raycasters in the scene, according to this). Good call!

I still think a generic event catcher (an Image in the back of the UI hierarchy… or, using your method, it could be some big screen-sized BoxCollider2D in the sprite hierarchy) is useful in some cases, where you want to handle the mouse in code and not rely on everything you want to interact with having a collider. But for most purposes, individual colliders are the way to go, and this is a great trick. (And as you point out, you could also implement a custom raycaster that doesn’t use physics colliders.)

I learned something new today. That’s awesome. Thank you, @Kiwasi ! (But man, it’s going to take a while to get used to the new moniker…)

[Kiwasi]

@JoeStrout

Well, yeah, the only problem with your YouTube channel is that it appears to consist mainly of videos.

Ironically I prefer text tutorials myself. But they just don’t seem to have the reach of videos. My best text tutorial has reached 4000 views. My best video tutorial has reached 110,000 views. I’m considering building a text transcript for each video, which might get the best of both worlds, but I haven’t found the time yet.

@JoeStrout

I still think a generic event catcher (an Image in the back of the UI hierarchy… or, using your method, it could be some big screen-sized BoxCollider2D in the sprite hierarchy) is useful in some cases, where you want to handle the mouse in code and not rely on everything you want to interact with having a collider. But for most purposes, individual colliders are the way to go, and this is a great trick. (And as you point out, you could also implement a custom raycaster that doesn’t use physics colliders.)

One of the big problems with the current EventSystem setup is there is no smooth way to detect a click on nothing. While the EventSystem class is technically open source, modifying it can be a pain. So I normally deal with this by just throwing a big collider or UI element behind everything.

Although now that I’m thinking about it, I could write a custom raycaster that always returns one result at a distance beyond the far clipping plane of the camera. That way every event will get captured, without ever having to worry about invisible elements. Let me go mess around with this…

@Edreyn sorry for wandering so far off your original topic.

[Edreyn]

Everyone, thank you for your answers. I considered again, and for now decided to stay with what I have now - generic c#. For more complex games in the future, I guess I’ll use Unity, but not now.

Evgenie

[JoeStrout]

@Kiwasi

Ironically I prefer text tutorials myself. But they just don’t seem to have the reach of videos. My best text tutorial has reached 4000 views. My best video tutorial has reached 110,000 views. I’m considering building a text transcript for each video, which might get the best of both worlds, but I haven’t found the time yet.

Yes, yoots these days seem unable to consume content that’s not in video form. I’ve had frustrating “how to” searches turn up videos of nothing but text, appearing one agonizingly slow sentence after another, describing how to do something. They could have put the exact same content on a web page and enabled me to consume it in 5 seconds instead of 30, but no!

(I hope I’m not offending someone, but not too worried about it… as this is not in video form, the yoots will never see it. )

One of the big problems with the current EventSystem setup is there is no smooth way to detect a click on nothing. While the EventSystem class is technically open source, modifying it can be a pain. So I normally deal with this by just throwing a big collider or UI element behind everything.

Right, which is pretty much the same as what I do (which is why I missed the nifty trick before).

Although now that I’m thinking about it, I could write a custom raycaster that always returns one result at a distance beyond the far clipping plane of the camera. That way every event will get captured, without ever having to worry about invisible elements.

True, though it’s not much worry… and there’s something to be said for having a clear object in the hierarchy (I call mine “EventCatcher”) to poke at. Though of course you could just as well put your raycaster on an otherwise empty object, also called EventCatcher (apparently it doesn’t matter where in the scene your raycaster lives).

@Edreyn sorry for wandering so far off your original topic.

Yeah, me too. Short answer is the same: Unity is the right choice for this; please go for it!

[Edreyn]

Thank you for advice to use free Visual Studio Community. For now I’ll stay with usual c#.

[Kiwasi]

@JoeStrout

True, though it’s not much worry…

There is always a moment in a project when I forget about where I put the invisible collider and then spend half an hour debugging why my events are not working, only to realise I just need to move the invisible collider.

[Edreyn]

Rather then answering me, you started arguing with each other, using many terms I can’t understand and puzzling me even more. Sorry if someone treats this as insult, but you don’t look like a community that will support a newbie. You actually scare people away. Me at least.

[Schneider21]

@Edreyn

Rather then answering me, you started arguing with each other, using many terms I can’t understand and puzzling me even more. Sorry if someone treats this as insult, but you don’t look like a community that will support a newbie. You actually scare people away. Me at least.

You were given 4 replies that pretty thoroughly answered your original question. The people who responded then continued the discussion by addressing items the others brought up. Maybe it wasn’t focused on the specific question you asked, but that’s the point of a forum: to have a discussion.

You indicated you were at an advanced stage in your game development process, which doesn’t suggest being totally new to concepts like raycasting and event systems. These concepts within the context of Unity may be new to you, but how else would you prefer to be exposed to them if not through a related discussion by knowledgeable community members?

If you prefer only on-topic answers with no additional discussion, check out Unity Answers.

[Ryiah]

@Schneider21

If you prefer only on-topic answers with no additional discussion, check out Unity Answers.

Only catch with Unity Answers is that your first post or two has to go through moderation (you’ll receive karma for them passing through, for them getting answered, etc) but until then you’re dependent on volunteer moderators bothering to show up to flag them through the system and it can take up to a week in some cases.

@Edreyn

Rather then answering me, you started arguing with each other, using many terms I can’t understand and puzzling me even more. Sorry if someone treats this as insult, but you don’t look like a community that will support a newbie. You actually scare people away. Me at least.

Both event systems and raycasting are basic concepts. You will encounter them regardless of whether you choose to go with Unity or stick with Xamarin. In fact I’d be surprised if you haven’t been using event systems in Xamarin and just weren’t aware that’s what it was. Just in case you’re curious I’ll link the appropriate tutorials.

https://unity3d.com/learn/tutorials/topics/physics/raycasting
https://unity3d.com/learn/tutorials/topics/user-interface-ui/ui-events-and-event-triggers

If you wish to make a career out of game development, or even just programming itself, you’re going to have to get into the mindset of writing down the terms you don’t understand to research them when you have the time to do so. You’ll never reach the point where you don’t pick up new terms. Computer tech is simply moving forward too fast to be able to stop.

[Kiwasi]

@Edreyn

Rather then answering me, you started arguing with each other, using many terms I can’t understand and puzzling me even more. Sorry if someone treats this as insult, but you don’t look like a community that will support a newbie. You actually scare people away. Me at least.

Sorry you feel that way. Your question was pretty vauge, so we answered it as best we could. We do much better with specific questions which have specific answers. If there is any specific terms you want defined, go ahead and ask. But simply saying ‘you used too many big words’ doesn’t give us much to go on.

The further discussion after we answered your question is our motivation for participating in the community. We all learned something new in this thread, which makes it valuable for everyone.

TL;DR: If you want high quality specific answers, ask high quality specific questions.