2 Replies - 1250 Views - Last Post: 29 May 2019 - 05:44 AM Rate Topic: -----

#1 sonar87   User is offline

  • D.I.C Head

Reputation: 3
  • View blog
  • Posts: 82
  • Joined: 04-February 08

Monogame vs Unity for 2D game

Posted 28 May 2019 - 08:43 PM

Is there any benefit to using Unity over Monogame for a 2d if you are already familiar with monogame? Or is Unity only really helpful for 3d games?
Is This A Good Question/Topic? 0
  • +

Replies To: Monogame vs Unity for 2D game

#2 modi123_1   User is online

  • Suitor #2
  • member icon

Reputation: 15493
  • View blog
  • Posts: 62,050
  • Joined: 12-June 08

Re: Monogame vs Unity for 2D game

Posted 28 May 2019 - 08:46 PM

I use it frequently for 2d game development. I find their support, forums, tutorials, and updates all helpful as well as the robust platform targeting I can get.
Was This Post Helpful? 1
  • +
  • -

#3 NicVene   User is offline

  • New D.I.C Head

Reputation: 10
  • View blog
  • Posts: 9
  • Joined: 28-May 19

Re: Monogame vs Unity for 2D game

Posted 29 May 2019 - 05:44 AM

I'm a strong believer in the notion that the tools you know are likely best for you at the moment, but only for that moment.

Really, you'll only answer the question by running through a walkthru tutorial on Unity (which means installing Unity) to see how familiar or unfamiliar it is to you, and if you think you gain something. I don't know MonoGame, so I can't compare beyond what I can see about MonoGame from the website.

The central usage of Unity is the editor. The editor is actually written as a Unity game, which means you are able to add code to modify and extend the editor (not exactly a beginner's task, though). C# is viewed as attached scripts to game objects added to the editor. Many new users tend to think of code from this viewpoint to such an extent they seem to think the script is a central programming concept, which it isn't.

If you prefer to view your work as purely software, you may find Unity objectionable at first. Some of us just prefer to think of our development from a main function outward, in full control. Unity development doesn't present that viewpoint.

The underlying engine is written in C++, and you can implement C++ code if you want, but there's always a C# interface involved. The "main" function is hidden from you. All initialization is done by the Unity Engine, and your first contact with code will be in the form of a script firing initialization functions (Awake, Start, etc).

The primary use case is to attach a C# class (the script) to an object in the game, and write code in the Update function (called at every frame flip), or the FixedUpdate function (at every Physics step). This can actually make for a quick start from idea to a working first draft.

There are multiple rendering pipelines to choose from. Some are aimed at high efficiency on mobile devices, and the other extreme is for very high quality 3D on PC's and consoles.

For years the primary physics solution is a built in PhysX implementation that generally works fairly well. They don't expose the raw PhysX engine, and physics can be rather simple to implement.

In my own use of Unity I opted to build the PhysX from source just so I could have raw access to PhysX in C++, particularly some (3D) joints they call articulations (particularly suited for robotic simulations). To that end I can say it is possible to use any physics engine you'd prefer.

Unity is at a development crossroad. As of 2019 they're beginning to release ECS into their C# support using the Burst compiler, which generates native code. They've had support of IL2CPP, giving native output, but this approach moves toward a more native approach to data, for high performance and efficiency. It isn't complete, but it means there are two ways to make the code work.

They're also adding two other physics options. They are implementing their own physics engine in C# based on Havok's design. They're also offering the full Havok engine (for a price, but not yet published as I can see).

Most experienced Unity developers remain focused on the standard physics approach and the 'standard' C# means of coding.

If you prefer to view game development first and foremost as software development, you may find any of the large game engines a bit foreign.

If you'd like to view game development as primarily a visual development act, starting with what you see (as would a digital artist) and THEN considering the code attached to it, Unity is likely what you'll want.

That said, it should be stressed that when you make changes to code, it is nearly immediate that you can test the code (without having to build the game into an executable). Debugging through Visual Studio works well. There is a strong, obvious association between code and the visual objects it acts upon.

As to the various game engines (which I'll leave to you to find), Unity has one particular strength the others completely lack...mobile support. If you need to target mobile devices, with concern for battery life and compatibility (especially for Android devices), Unity is by far the best choice. If you want to code in C++, prefer very high quality graphics and can accept the limit of mobile support only for higher end, recent devices, with less concern for battery efficiency, there are other game engines one might call better. Most have the "visual" orientation model - you start with artwork, and see your game take visual form from the beginning. Code is added, not central.

All engines of this type tend to make larger executable builds, but they focus on leverage to move from concept to finished game quickly.

I recently used Unity to help with teach programming and building robots for a robotics club at the local high school (my son attended). I wanted the kids to be able to experiment with their robot designs in the contest they were competing in, before the built the robot. The design was created in CAD tools, from which I took artwork for the robot (along with the contest's playing field and target objects), building a simulation of the contest with their design. This allowed them to notice flaws from a strategic viewpoint, which modified design, leading to an updated simulation. They could also practice strategy, timing and compete against each other before the robot could actually operate. Unity made the process fairly straight forward, though as with all such digital modeling tools, there's some experiment with file formats to load a 3D model into Unity.

While I've always looked at other engines, and come from a development background (40 years), I've not yet been convinced to use another engine for compelling reasons.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1