Non GameObject oriented game design in unity

I'm coming to unity from monogame. with my game.

Unlike unity, monogame have everything dynamic. No GameObjects, No behaviour scripts or anything.

Therefore, I found that my game design is not much unity friendly. My game design concepts as follows,

• Fully code generated world. The ground is dynamically generated (Like Minecraft). The player can build and destroy. The world will generate and extend runtime. There are no scenes to design. +(GPU instancing needed)
• Server-client architecture game. (In both single and multiplayer modes)
• Mechanical Simulations. The player can create working machines with wheels, levers ... Which will require a numerous amount of collision detections. I think I should go with manual collision detection.
• There are circuits in the game. The player can reprogramme (in game) Microcontrollers with C#/VB.net . Which will be executed runtime using Code DOM. This needs direct access to runtime compiled dlls

There are more. I'm new to unity, but from the example projects around here, I see there is no chance for a free hand game design that is not oriented with GameObjects. In monogame, this Minecraft like ground was mostly created in GPU using HLSL. RAM only hold a Byte array of their block types. Over here I don't see that freedom. If unity has, please let me know!

My question is, How to create a fully code driven game that is not GameObject oriented?
I basically need an Update() loop, Draw() loop and Graphics and Physics APIs. I like to build the rest from scratch!

 

I think you are missing the point of using a full-formed engine. The idea is that these systems are integrated and ready to use out of box. You seem to be more interested in just writing your own game-specific engine from scratch by gluing different libraries of code together and then building your own game on top of that.

In the end, you can still do that in Unity but it's going to be a lot more work on your end. For rendering your could use the direct rendering methods to draw geometry and handle the data pipeline yourself with scripts. For physics you'd almost certainly have to import and external library, likely the same with audio. There is also the in-development ECS system. It doesn't rely on GameObjects directly, however, it's not yet fully integrated into the engine and again you'd likely have to write large portions of the engine yourself.

Perhaps a better approach would be a hybrid method, where you perform as much of the game logic as you can in your own code-base and then marshal that data back and forth between some 'dummy' Unity objects to make it integrate with the engine's built-in systems.

Overall I think you are coming at this the wrong way, though. IMO, you either want to write an engine yourself using libraries of code, or you want to adapt your development and workflow to suit the engine you will be using.

 

Thanks very much for these tips.
can you please point me into some tutorials on this part

"where you perform as much of the game logic as you can in your own code-base and then marshal that data back and forth between some 'dummy' Unity objects to make it integrate with the engine's built-in systems."

or some more info and "topic key words" to explore
​

 

I had thought of this for a while and the way to do it is to call the objects in the code.
However, I had found it much easier to go the object oriented way.

Each game engine has their own pros and cons. For unity, I find the object design to work well with my line of thinking. If you find it unsuitable, perhaps another engine or your own engine would be better.

 

You need at least one GameObject with at least one MonoBehaviour to provide you the Update() loop. Unity doesn't have a Draw() loop in the sense you're most likely thinking of. If you want to draw things at runtime purely through code you need to use Graphics.DrawMeshInstanced() in your Update() loop.

Likewise Unity doesn't provide a full fledged Physics API. If you need it you will have to integrate your own physics system.

https://docs.unity3d.com/ScriptReference/Graphics.DrawMeshInstanced.html

 

You'll be hard pressed to find any tutorials for what you want as it mostly defeats the purpose of using Unity, but what Ryiah said is the way to start. The biggest issue is that it's a very general problem with a very specific answer that is based on how you write your own code. You'd be much better equipped to answer the question yourself if you first familiarize yourself with Unity in general.

I'm still going to suggest that this is totally the wrong approach. It sounds like your game is already well underway. What problems have you encountered that warrant switching to Unity, vs just integrating well know libraries and writing the rest yourself? I'd suggest that you continue on this path and finish your current game. Afterward ( or even in the meantime) you can also do some research on how to make games with Unity the 'Unity way' and that will help you decide if and how you will approach your next project in Unity.

 

Thanks to everyone for these valuable ideas.

It looks like our game (Mechatronics) is a bit incompatible with 'the unity way'.
Therefore, We decided to carry on with Monogame.

However, with this warm welcome to the community, we are planning another game with Unity. We are pretty sure that it's well compatible with 'the unity way'. Which will be something similar to "Word Story", but in 3D and more freedom to the player.

I'm looking forward to discussing it with you guys.
Thanx again...

 

You should look into DOTS / ECS.
https://unity.com/dots
https://blogs.unity3d.com/2019/03/08/on-dots-entity-component-system/

Though if you want to build virtually everything from scratch you're basically reinventing the wheel. I'd suggest stepping back from how you want to build something and instead focus on what you want to build, then investigate what Unity provides that can make that easier. If you've already decided on how you want to build your game, you're better off just sticking with whatever tools you are already using.

 

Well, we feel like monogame is now going down. For example, Monogame did not get an update for 3 months now. Therefore, I can tell you that a huge amount of developers, who were once with Microsoft XNA, then Monogame will now come to Unity.
If you can make a way to enable users to inherit Unity Engines core functions (Like Main Update call and Draw calls), It will be the desired destination to those skilled game devs. They will find ways to do the rest for themselves.

 

That looks amazing!
Are there any tutorials on ECS? Is it stable enough? Do you think that it would fit into our game design?

 

There are some that have managed to complete commercial projects using it, either in part or in whole. However, the integration with the rest of Unity is very limited at this time. As far as stability, it seems to work very reliably but the API is getting frequent changes and Unity's official stance is that you should not start any serious projects with it at this time. It's more of a way for developers to get up to speed with how it will work as well as for Unity to get feedback from the community on how to improve it.

As far as Monogame going down, that sounds unfortunate. I when XNA went same way. That being said, if it is currently stable enough and there are no serious issues with it, even without further official support an already underway project should be fine. I certainly understand your concern though. It might be prudent to go through the Unity tutorials and try to build a few of the demonstrations they showcase. Best of luck!