I've long wondered if I should add a scripting language to my game engine. I know that most game engines could do without such a feature but I just recently came across Chibi-Scheme, a library that allows the use of Scheme lisp scripting for C programs.

I like Lisp. I use it a lot when customizing my Emacs environment (using ELisp). There's something about it's syntax and different way to structure programs that appeals to my programmer brain. I've toyed with other Lisp flavors but never had a strong enough reason to continue using them. With Chibi-scheme I may have found that reason.

I am aware that Lisp is not as widespread as Lua or Javascript. And that choosing it might limit the number of potential people to try out my game engine. But as I've been telling myself over and over, this is a self-learning project. So it's okay if no one would try it out as long as I get to learn from it.

This morning I started implementing a simple implementation of Chibi. Thankfully, it's easy to setup. However, the more I implement it the more that I realize that I may need to change how my engine is structured to better suit Lisp's functional nature. This means less object oriented design similar to how Raylib does things.

I still need some time to think this through. I am open to do the changes needed if I am to include a scripting language. I just want to make sure if my engine would really need it. We'll see.

Our latest game, HistoHunters, has grown into a really big project that compilation now takes a really long time. Longer than no sane programmer wants it to be. It has gotten so bad that changing a single file would take about a minute for recompilation!

Thankfully, I have managed to shorten this wait time through the use of assembly definitions. If you have a big Unity project and compile times are slow, this is the solution to that. Just for kicks I also purchased an SSD and that also helped reduce compile times (Not much as the assembly definitions though).

However, in spite of these changes compiling still takes a few seconds to reload scripts. This seems to be the lowest it could go. While this is definitely better, I can't help but feel that the seconds spent waiting is wasted.

I recently got the idea of having Unity inform me when a script has finished reloading. Instead of informing me visually, I decided that it would also be better for it to play an audible beep sound. With this, I could use the time to close my eyes, relax, or stretch. Once it beeps I'll just open my eyes and I'm back to working again. Once it beeps I'll just open my eyes and I'm back to working again. It's such a simple thing but I feel has a good impact on my health.

Here's the code that I use if you are interested. Note that this is an editor script so it should be placed inside any "Editor" folder for it to run.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;
using UnityEditor;
using System.Diagnostics;

public class BuildManager : MonoBehaviour
{
    [UnityEditor.Callbacks.DidReloadScripts]
    private static void OnScriptsReloaded() 
    {
        EditorApplication.Beep();
    }
}

The code above uses Unity's EditorApplication.Beep() API so it should work on Windows and Mac. But since I'm using Linux to develop games on it does not seem to work for me.

Here's a different version that spawns a OS process and runs the play command to generate a short sine wave beep. Be sure to have sox installed on your Linux machine for this to work.

ProcessStartInfo proc = new ProcessStartInfo();
proc.FileName = "play";
proc.Arguments = "-q -n synth 0.1 sin 880 vol 0.2";
proc.WindowStyle = ProcessWindowStyle.Minimized;
proc.CreateNoWindow = true;
Process.Start(proc);

Of course, this is not a solution to the compile time problem. I'd still have to wait for it to finish. But what I like about this is that it has turned a negative into a positive. And that is always great.

I've recently embarked on a mission to fully integrate Emacs with my Unity game development environment. One feature that I wanted to have is the ability to open Unity scripts and text-based files in Emacs instead of MonoDevelop. This is an easy task for supported external editors but for those who aren't (Like Emacs), doing something like this is a bit tricky.

Setting emacsclient as the external editor works in opening the files but the line number is not passed at all (Or is not received by emacs. Seems to be a bug). This means that opening files in the Project Window works but you would not be able to to jump to lines that have errors from the Console. This, of course, is unacceptable.

I've tried a number of different solutions. A lot of them are hacky but clever. There was this one option of setting a Sublime Text proxy as a external editor and then having that application call Emacs with the correct line number. I was not able to make it work but the idea fascinated me. There was also one that involved using Mac OS X's Automator where you wrap a shell script as an automator app and you set that as the external editor. Didn't work either but it did teach me about Automator and it's future possible uses for my environment.

Thankfully, there was one solution that worked and it involved creating a .cs file and setting up a function with OnOpenAssetAttribute callback attribute. This function is called when Unity receives a command to open an asset. From here we start a process that invokes emacsclient with the correct file and line numbers.

Here is a short example:

[OnOpenAssetAttribute()]
public static bool OnOpenedAsset(int instanceID, int line)
{
    UnityEngine.Object selected = EditorUtility.InstanceIDToObject(instanceID);
    string ProjectPath = System.IO.Path.GetDirectoryName(UnityEngine.Application.dataPath);
    string completeFilepath = ProjectPath + Path.DirectorySeparatorChar + AssetDatabase.GetAssetPath(selected);

    // We check if this is the type of file we can open
    if (selected.GetType().ToString() == "UnityEditor.MonoScript" ||
        selected.GetType().ToString() == "UnityEngine.Shader" ) {

        string args = "-n +" + line.ToString() + " " + completeFilepath;

        // We start a process by passing the command "emacsclient -n +linenumber filePath"
        System.Diagnostics.Process proc = new System.Diagnostics.Process();
        proc.StartInfo.FileName = "/Applications/Emacs.app/Contents/MacOS/bin/emacsclient";
        proc.StartInfo.Arguments = args;
        proc.StartInfo.UseShellExecute = false;
        proc.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
        proc.StartInfo.CreateNoWindow = true;
        proc.StartInfo.RedirectStandardOutput = true;
        proc.Start();

bo // Tell unity we have handled the opening of the file. return true; }

    // We were not able to open the file. Let unity handle the opening.
    return false;
}

Note: This file needs to be placed inside an "Editor" folder within Unity in order for it to work.

Go here if you want to see a more complete and fully featured implementaition of the code above. Also, a hat tip to this repository for the solution which was largely inspired by the VSCode project.