Lightweight editor or standalone quick player

Unity Engine
1

During latest unity developments I think it has gotten pretty clear that the unity team is struggling to keep editor quality on par with expectations. All while still trying to get DOTS ready for production.

The editor has lots of weird UX quirks, performance issues, crashes easily, but most of all it exhibits workflow issues for coders.

If there is anything I have learned during my latest years of working with Unity it has been to minimize the time I spend in the editor. If there is anything I can do in code instead of the editor I do it in code. Chances are the editor will crash (for something such as silly as my game crashes) and I loose all my stuff. Every second spent in the editor is a potential second lost.

There has been widespread recognition on a major workflow issue, where switching from your code editor to the unity editor: you have to wait, press play, then wait again.

I believe most programmer related workflow issues stems from the fact that the editor runs the game in the editor process rather than in a separate process (like any other programming environment). Changing this would require a costly major overhaul of the of the editor architecture.

Now this will come as a pretty blatant opinion from the perspective of a silly ignorant coder. I have multiple roles and spend quite some time in shader graph etc. However… “As a coder” I love unity the “game engine” (especially the direction it is going with DOTS), but I couldn’t care less about the “editor”. I just want to compile my code changes and run them as quick as possible.

So from a coder perspective I think you should open up the possibilities to develop alternative editors/players for programmers. That way you could outsource some of the workflow issues concerning us silly coders and focus on what matters, DOTS.

I would like to se either:

  1. A standalone player that can be launched immediately from my development environment.
    My current development environment (Rider) has a build button. To be honest, I’m not sure of to what extent it compiles my game. Because Rider itself cant run it. But whatever it does it is pretty quick and I can only Imagine it wouldn’t be that much more time added to the process to also run the game.

  2. A lightweight editor rebuilt from the ground. You decide the features. I’d say the less the better. The editor runs the game in a isolated/sandboxed process and doesn’t need to reload the whole editor and freeze whenever game code changes. Just like any other programmer environment.

3 Likes
2

I try to get around it by using script-inspector 3 and playmaker
Script-inspector let me stay focussed on the game and I don’t need to switch between programs
Playmaker does not need compilation when I edit my state-machines so I can quickly iterate my game play.

By the way I came across this tweet

2 Likes
3

Yea I can only imagine how much creativity can flow when using tools like that. Unfortunately we are a bit reliant on dots for our game systems atm. But will definitely check out some of those tools when working with some lighter game mechanics. I personally love the creativity I can express when working on shaders in Unity because of how fast it is to experiment.

4

Voted no because I think Unity has many issues that I feel are much more pressing than being ‘lightweight’ or using a standalone player (e.g. the UX-quirks you mentioned).
A full rewrite of the editor would be a massive project.

5

I hear you. Unfortunately I believe the only way to get to the root cause with these UX issues is a rewrite.

I can only speak for myself, but my guess is it is actually a full rewrite of the editor we would all like to see in the end.

However, my intent with this post is to propose a feasible way to get there. Instead of the team hiding under the sand for 10 years and then coming up with an amazing new editor. They can start on the ground and deliver immediate value with a parallel lightweight editor for programmers. They could then let it live its own life, in its own development cycle. Which would follow the more decentralized approach unity has taken for most of the non-editor infrastructure (DOTS, UI, Renderer and Physics).

6

Hey, coming here from the other thread :slight_smile:
All very good and very valid points. Sadly, I just don’t see that happening in my lifetime.

They already have 500 different feet in 500 different feature reworks:

  • New input system
  • DOTS
  • New UI
  • Bolt or whatever that will end up being called
  • Various rendering things that are in various states of incompleteness

For the Editor to become like it should be, they would probably need to completely redo the entire thing. There are just too many things wrong with it, on an architectural level, like the play-mode running on the same thread.

Also, if I learned one thing in my 6 years as a Unity developer: The marketing people are driving the company, not the product people. It has never really been any other way, Unity started out with a bang and multiple millions of marketing, which definitely helped its success and was a smart choice at the beginning.

But it’s like what Steve Jobs said, if the marketing people are running the company and making the decisions based on advertisement $$$, the product will S U C K. And that’s where we are.
I am 100% sure there are soo many sad developers at Unity that are very very skilled and really want to make super cool changes on a fundamental level, but it has become very obvious that it doesn’t work like that.
Even @Joachim_Ante_1 who is the damn CTO of the company seems to have problems properly pushing his agenda, and no “DOTS is coming, don’t worry guys, we just need 3 more years” post will convince me otherwise.

Don’t get me wrong: I love what Joachim has done and he’s been one of the few extremely good influences on the company over the past few years (together with Mike Acton), but with a career CEO like this who doesn’t understand the product & developer’s needs, how could it be anything else?

There are two completely separate groups/realities here:

  1. The Unity people and the people who make/give them money. I am no part of group 1.
  2. Actual game developers who are relying on their product to be usable and die a slow death by a million cuts.
    It’s fundamentally disconnected, the company doesn’t even make their money with people like me - why should they listen to us?

As much as I would like things to be different, I just don’t see it happening. I don’t see Unity magically becoming a engine without a gazillion things that pain us, without fundamental problems.

Lastly, a list of things that would need to happen in order to salvage the situation, at least somewhat.
But this is magical fairy land stuff:

  1. Make the engine open-source. Better: Free and open source. Without this, none of the other things will ever matter because we can’t fix engine-level stuff.

  2. Rework the entire editor with the community’s help.

  3. Finish DOTS, polish & integrate it into the new editor.

  4. ???

  5. Profit

2 Likes
7

How about this for a lightweight runner: You run run_build.py and it creates a build and launches your game. Unfortunately, I don’t know how you could get your debugger to auto-attach.

#! /usr/bin/env python3
# run_build.py

# Build and launch a Unity project
# Get your editor to call this in a way where you can see its output.

import os
import pprint
import subprocess

unity_exe = 'c:/Program Files/Unity/Hub/Editor/2020.3.12f1/Editor/Unity.exe'
project_root = 'c:/code/bug-repro/'
logfile = os.path.join(project_root, 'build.log')
args = [
    unity_exe,
    "-projectPath", project_root,
    "-batchmode",
    "-logFile", logfile,
    "-executeMethod", "Builder.Build",
    "-quit"
]
# Could use command arg for building to avoid any C# code, but it requires you
# set the appropriate scenes and configuration (scripts only, etc) in
# File > Build Settings and it doesn't seem to be any faster.
# args = [
#     unity_exe,
#     "-projectPath", project_root,
#     "-batchmode",
#     "-buildWindows64Player", "c:/code/Builds/gamebuild/game.exe",
#     "-logFile", logfile,
#     "-quit"
# ]

pprint.pprint(args)

is_error = False
try:
    subprocess.check_call(
        args,
        cwd=project_root,
        universal_newlines=True,
    )
except subprocess.CalledProcessError:
    is_error = True

with open(logfile) as f:
    print()
    print(logfile)
    print()
    start_of_interesting_log = "-- Build Starting --"
    end_of_interesting_log = "-- Build Complete --"
    can_print = is_error
    for line in f:
        can_print = can_print or start_of_interesting_log in line
        if can_print:
            can_print = end_of_interesting_log not in line
            print(line, end='')

// Put this in Assets/Scripts/Editor/Builder.cs

using UnityEngine;
using UnityEditor;

public static class Builder
{
    // Possibly this could be done with -buildWindows64Player, but we can do
    // more build prep from inside Unity code here (building asset bundles,
    // etc).
    public static void Build()
    {
        Debug.Log("-- Build Starting --");
        var buildPlayerOptions = new BuildPlayerOptions();
        // Make this list as short as possible to make faster builds. You could
        // filter EditorBuildSettings.scenes instead of listing scenes here.
        buildPlayerOptions.scenes = new[] {
            "Assets/Scenes/SampleScene.unity",
        };
        // You could generate a .cs file that contains this path from run_build.py.
        buildPlayerOptions.locationPathName = "c:/code/Builds/gamebuild/game.exe";
        buildPlayerOptions.target = BuildTarget.StandaloneWindows;
        buildPlayerOptions.options = BuildOptions.Development | BuildOptions.AutoRunPlayer | BuildOptions.AllowDebugging;
        if (System.IO.File.Exists(buildPlayerOptions.locationPathName))
        {
            // disable this line if you make asset changes.
            buildPlayerOptions.options |= BuildOptions.BuildScriptsOnly | BuildOptions.PatchPackage;
        }

        var report = BuildPipeline.BuildPlayer(buildPlayerOptions);
        var summary = report.summary;

        // This duration doesn't include Unity startup time. For me, that's about 10 seconds.
        var duration = summary.buildEndedAt - summary.buildStartedAt;

        Debug.Log($"Build {summary.result} after {duration.Seconds} seconds\n"+"-- Build Complete --");
    }
}

You could easily make this a lot fancier so the python generates a .cs file for any constants that should be used by Build() and to take arguments instead of hard coding paths.

On a nearly empty project and a pretty good computer, the first build takes 25 seconds and subsequent builds take 15 seconds (because of PatchPackage). That’s pretty long, but may be preferable to using the editor. And if Unity improves startup time, then everyone benefits!