Skip to content

Instantly share code, notes, and snippets.

Engine vs content

Unity-based gameplay code should define only aspects unlikely to change or requiring high performance. Because of open and web based nature of the project, commonly changed and content-related scripts have to be editable from web browser. Prototyping, testing and publishing changed to them cannot require usage of local native build system. They include:

  • characters,
  • items,
  • quests,
  • dialogues,
  • object interactions,
  • gui elements. There is currently no way to interpret C# code on the browser, and its compilation to WebAssembly requires complex properiarty build system. Because of this, mentioned scripts have to use another language which can either run in browser or which can be effectively run on top of C# compiled to WebAssembly.

Keybase proof

I hereby claim:

To claim this, I am signing this object:

using System;
using System.CodeDom.Compiler;
using System.Collections.Generic;
using System.Linq;
using System.Reflection;
using System.Threading;
using Microsoft.CSharp;
using Techbox.Client.Utils;
using Object = UnityEngine.Object;
<link rel="import" href="../paper-input/paper-input.html">
<link rel="import" href="../paper-slider/paper-slider.html">
<link rel="import" href="../paper-toast/paper-toast.html">
<link rel="import" href="../paper-tabs/paper-tabs.html">
<link rel="import" href="../paper-tabs/paper-tab.html">
<link rel="import" href="../paper-toggle-button/paper-toggle-button.html">
<link rel="import" href="../core-tooltip/core-tooltip.html">
<link rel="import" href="../core-field/core-field.html">
<link rel="import" href="../core-icon/core-icon.html">
<link rel="import" href="../core-input/core-input.html">