Learning

I'm optimistically labeling this "Part 1", as I hope to keep an ongoing log of things I learn while working on our various projects. Note that any information I put here has a pretty good chance of being... only partially correct, since I'll be writing about things I just learned.

We Made a Website!

I've got some background in web development in a previous life, but I've never self-hosted even a simple website before. So I learned a whole bunch, at a very shallow level, in a very short time.

I learned that Windows has come a long way, and you can... almost develop in it, but I hit a lot of snags and looked into setting up a Linux environment. Then I learned about WSL! WSL runs a Linux distribution right from Windows, without a virtual machine and without dual booting. It was incredibly simple to setup (with one caveat), and for my purposes has been just perfect.

Well ok, now the caveat, it does some weird networking stuff I don't understand which was causing curl (essentially, making a url call, from the command line) to timeout for me. Maybe there was something special about my setup that caused this, as it's hard to imagine curl just doesn't work for most WSL users, but this blog post saved me.

I learned a bit about DNS, like that you don't get "www" for free. Does anyone still type that part of the URL? Well I do, and it doesn't work without an extra DNS entry.

I learned about light and dark mode, tailwind, and Node.js. In particular, I learned you should probably stick to a single package manager. Trying to use 3 at once, based on mood or whatever tutorial I happened to be following, caused me some serious pain.

I learned that since markdown can contain HTML, the renderer that the template I use for this site uses is essentially evaluating arbitrary JavaScript code. (Since HTML can contains a <script> tag which executes JavaScript.) This is a problem in Node.js, given that it... runs in JavaScript, which could allow someone to inject some pretty nasty scripts with markdown. In practice, I think it's pretty safe since I'm in control of the markdown, but the host I'm using (smartly) doesn't allow eval'ing random JavaScript, so I had to swap the renderer to one that strips <script> tags and a few other things. It was amazingly simple to do, I just had to find an open source renderer, pull it in with the package manager, swap a few lines out, and remove the old one. I'm not a big JavaScript guy, but the simplicity of Node.js is really nice, and TypeScript (what I'm actually using) is a pretty nice language despite its roots.

Oh and hey, I also just learned you need to use backticks (``) to escape tags you don't want markdown to try to render. This blog post failed to compile because of my non-escaped <script>s.

Random Unity Stuff

I recently learned about Build Profiles, which allow you set up various platform-specific settings for your Unity build. I use it in Volcango to manage the various test and production builds on Android, iPhone, etc.

Some examples of why it's useful: Android doesn't allow you to set an APK as a "development" build when you're pushing it to external testing, while all the other platforms do, so my "Android Test" build is set to production mode, while the others can be in development mode. Before Build Profiles I was tediously swapping all these variables by hand, and often making mistakes that I only realized after the 10 minute build finished and was uploaded. Ugh.

I also learned about Scripting Defines, which you can also set in Build Profiles. Confusingly, but helpfully, you don't have to override the player settings to do this, even though Scripting Defines are normally defined there. You can override them right in the build profile, under "Build Data". I'm using these to swap between "dev" and "prod" servers for Volcango so that I'm not matchmaking my testers with my prod users, for example.

On that note, I also learned about Unity Remote Config, which is neat. It's a simple way to have build/platform specific variables that you can change without pushing a new build. For example, in Volcango I use it to push alert messages to players if something is broken (a hopefully rare, but at the moment fairly common, situation). I also use it to show forced update dialogs if we make a change that requires an update.

Closing Thoughts

Phew, that's a lot, and it's only what I learned in the last few weeks. I'll try to keep this up, but if not I'll just remove the "Part 1" and pretend I never intended to. :)