No Editor, all VS studio, is it possible?

I'm a code junkie, I live and breathe it. I like Unity so far, but I really just want to treat it as a large, powerful framework.

How close can I get to this? What do I -have- to use the editor for, if anything? Is there a way to launch a game from code?

 

You're setting yourself up for a lot of pain since quite a good deal of stuff is designed with the editor in mind (especially things like mecanim/animator).

But technically you could get away with this by having a single 'entry' script attached to a GameObject in a scene. And that scene is you boot scene.

And that 'entry' script acts as your entry point to your 99.9999% pure code structure.

Good luck though...

 

You can get really close to what you want. You might be able to go all the way but the Pareto principle applies.

I build all logic in VS with Resharper, NCrunch and all the other big kid tools. I even compile my MonoBehaviour implementations (which are super thin adapters into the real code) in VS. The compile output goes to a folder in my assets directory (I like Assets\bin\). Then I create the smallest hierarchy of game objects required to host my code.

With very little effort you could get it down to one game object that loads everything and builds all the other game objects dynamically. Most people don't because most people find it easier to use the Unity Editor for modeling the game objects, tying together the materials and other assets, et cetera. Not me and apparently not you, but most people.

With more effort, you might be able to write a plug-in for Unity that gets you out of even the bootstrap game object. If there's a command-line compile option (which it seems like there'd have to be fore CICD pipelines), you're golden. I answered a question on Unity Answers about that back when the Earth was still cooling.

I'm not sure the ROI on that last little bit of effort is there.

 

What @lordofduct said.

 

You'll need to open the editor at some point to import all of your various assets. And to do a final build. You can automate both of these processes if you really want to.

However you'll be effectively rebuilding some of Unity's more useful features with this approach. I would highly recommend getting familiar with the interface and getting set up to do at least some work in the editor.

 

Only for setting up the template necessary for the current and future projects. For gameplay that's a single scene with a single GameObject that has a single MonoBehaviour attached to it. For the development logic that would be importing the editor script that would handle tasks like importing assets, setting up prefabs, and so on.

Both MonoBehaviour and EditorWindow have Update methods that will be called a number of times per second.

https://docs.unity3d.com/ScriptReference/MonoBehaviour.html
https://docs.unity3d.com/ScriptReference/EditorWindow.html

This. While I can understand the approach taken for gameplay, I simply can't imagine myself taking a similar approach for editor-side tasks like importing assets. At least not for a serious project as the editor simply makes life much easier.

 

I wouldn't want to import 100+ sounds via code or shell and try to sort them out when I could drag, drop and listen to them right there in the editor. There's plenty of visual stuff where it's much simpler to just run, stop, tweak sliders and run again. Code, build, run, stop and tweak is a much lengthier process.

Don't work against the tools. Work with them.

 

So when I first got into game development... which was before Unity, but my early feelings were still there when I got to unity.

But when I first got into game dev and I saw these engines with editors and craziness all attached. I was just like "what's this stuff for! I'm a programmer! I love code... give me code... this is just stupid weird hand holding stuff!"

...

And you know what, if you're just a programmer this sort of makes sense. What is all this for? I can just write code that does this for me. Why would I use this?

But then I realized I can't draw worth a good god damn.

And I started working with other people. People who brought very different skill sets to the table. And we were using tools/libraries that were very code oriented. And well, I kept having to spend all my time writing visual tools for my artist/partner to use.

It kept me from getting to write code for games, and instead writing tools to make games.

...

That's what the Unity editor is. It's the toolset for the artists/designers/music/non-programmers of the team.

If you don't have anyone like that on your team. Well, maybe you don't need the editor. But are you really going to ALWAYS be on a one man programmer team only!?

IMO, get used to working with artists/designers, not against artists/designers. They'll love you for it in the long run.

 

Thanks for the great responses! I guess my biggest beef with the editor is the concept of attaching code to objects, rather than code owning objects. Asset management was something I hadn't thought of a whole lot.

 

Not just asset management, but UI development as well.

Unless you really enjoy building, running, find out if that one text label is off by 2 pixels, stop, hunt for the label in code, adjust it by whatever code support you have for it, rebuild, run, oops now it word wrapped, fix, etc.

I get being a code junkie and want to be pure code. I get it. I used to be like that. Until I found I was doing the same damn thing again over and over again. At some point you just say f*ck this, just grab an API and be done with it.

 

Well GameObject's are code themselves. And your code is written into classes that are components, which are instantiated as objects.

So really you're attaching objects to objects.

It's an extension of the composite design pattern. It relies on the idea compositing functionality together, rather than inheriting functionality.

I don't know how you make your "code owning objects". But I usually do by allowing one object to composite another object into itself. You know, like a class with a field that references another class.

 

Honestly you normally run with both paradigms. Unique objects tend to 'own the code'. Generic objects get spawned as prefabs and tend to 'be owned by code'.

This is of course a massive oversimplification.

 

I'm not sure why you even want to use Unity if that's how you want to do things. You're also going about things the really, really hard way IMHO. There's plenty of code to be written in Unity, you aren't "cheating" by using the editor to make scenes and define objects. Duplicating that in code will be very difficult and un-fun, so un-fun that you'll probably want to make a level editor to help you define scenes for your game and that point you've just come full circle.

I would ask yourself why you really want to not use the Unity editor and if you really don't want to use the Unity editor, why you want to use Unity at all.