Introduction

Yay!

Last afternoon/night I ran my first Delta Green campaign. I was the Handler (DG equivalent of a Dungeon Master) and three of my buddies were new DG recruits.

I spent a couple of days prepping mostly from the Need to Know starter booklet and the Agent’s Handbook. I think the former was more condensed and useful for the first game, but I have no doubt that if we get to slide into some of the more advanced mechanics we’ll get good mileage out of the latter.

Disclaimer

This is all very much a rough idea. There is no spec here, this is the fuzziest of straw-men. As you read this, please keep that in mind.

I want to next publish a spec and reference implementation for both a client and server, just to give people a taste of what’s possible.

This document is not quite enough to do that, but should be enough to make reading that implementation more sensible.

So, it looks like I’ll be heading out to D.C. tomorrow for a bit on company business. Sort of a quarterly/semi-yearly team get together and retreat. I’m usually a fan of retreats, though travel itself I don’t really enjoy much anymore. After RC and some miscellaneous adventures last year I suppose I should change my outlook on that, but I can’t quite bring myself to.

On the plus side, I know folks there and it’s only like 3 hours on the plane. On the minus side, there are a bunch of little things to get done and knowing myself I’m going to have trouble getting to bed tonight.

Introduction

I’ve been doing a bit of work lately setting up a new machine for my job, and in the process making some scripts that can ease the process for later developers. The whole thing is written in Bash. Why might you find yourself wanting such a thing?

• Bash (or some other shell, probably Bash-compatible) is available nearly everywhere, so your tooling won’t need other tooling to bootstrap it
• Bash is relatively easy to use for stringing together common operations
• Having a common helper toolbelt with sub-commands (like you’d see with Heroku toolbelt) can save you a tremendous amount of time
• Encouraging teammates to build out commands for commons tasks insulates you if the precise details for those tasks change (say, switching from one way of tagging builds to another, etc.)

Downsides to this:

Introduction

One of my hobbies and fun things in life is to play tabletop role-playing games. I thought it might be fun to play with that a bit.

The system I’ve probably spent the most time in is Pathfinder 1st ed., though in college we used to play a whole bunch of Dungeons and Dragons 3 and 3.5 editions. These systems are all basically related, and there are some handy online references.

Introduction

Going back to Active Worlds, I’ve always been really fascinated by online virtual worlds. When WoW was just being released and Everquest and Asheron’s Call were the big Western MMORPGs, some friends and I had kicked around the idea of a post-apocalyptic FPSMMORPG. We burned a lot of cycles on it, learning a good deal of programming and art and game design and so forth, but ultimately never really got a product out.

Introduction

I keep a list of little neat projects that I think some programmers might find fun to write for themselves, if not actually use all the time. I figure I’ll list out what they are and give maybe quick blurbs about why I think they’re neat projects and some ideas for how to tackle them. I’ll do a few more write-ups with more stuff from that list from time to time.

I’ve spent the last several months in the Summer 1 2019 batch at the Recurse Center. The whole trip has been a really interesting and occasionally intense experience, but I don’t regret a moment of it.

What I worked on

My main project, spanning about ten of the twelve weeks of the time at RC, was a 3D rigid physics engine written in Elixir. I got as far as collision detection, and then got stuck for the last couple of weeks on the project on convex polyhedra intersection. I’ve written previously about that, and am planning to keep banging on it in the run-up to Elixirconf this year.

Introduction

One of the weird rabbitholes I fell into while working on the GJK implementation was figuring out how to find the nearest point on a tetrahedron to a query point. This also relates tightly to the idea of finding which Voronoi region a given point corresponds to–in fact, I elected to update my projection routine to also report which region a given point fell into.

The implementation of the thing itself is a bit annoying, since we have to calculate a bunch of barycoords and then figure out which domain (in increasing dimensionality) we may be falling into, but testing them is even more frought.

Current State of the Elixir Rigid Physics Library

• Create stub physics engine server in Elixir as a GenServer(done)
• Create visualizer for engine state using Three.js and Phoenix Channels (done)
• Add first body type to physics engine: boxes! (done)
• Add framework for doing dynamics sans collisions in engine (done)
• Add collision detection framework for finding contact manifolds (abandoned)
• Add collision restitution code
• Add friction
• Add joints and motors
• Add more types of bodies beyond boxes (we’re going full convex hull, God help me)
• Figure out how to spread the simulation across multiple processes
• Figure out how to spread the simulation across multiple nodes

Changing course

So, I kinda need a break on this. It’s been about ten weeks of banging on it, and the last few haven’t been nearly productive enough–my experience is telling me I need to either switch sub-tasks, or pull the ripcord entirely and switch to something else while I wrap up here at RC.