The Worst Enemy of a Programmer: Future Proofing

What of the following you think is harder?

  • solving a coding problem
  • solving a larger coding problem

Yep, me too.

Programming is about solving problems. When you try to future-proof your code, you’re effectively solving an unnecessarily harder and larger problem.

Why unnecessarily harder? Because odds are that your assumptions about the future are wrong!

Remember that “the user” can be you or your team too!

Story time!

I like making game dev tools. I love making stuff that makes stuff. Because of that, sometimes I just make tools without the real need for them!

So far so good. But in the middle of DeMagnete development, we decided to use some graph editor tool to help the game designer configure puzzle logic.

At the time I thought: “That’s great because I already created a graph editor before! Let’s justs use it!”.

Aaaannd it turned out subpar just like a fast-food sandwich.

I actually like Subway, tho.

The thing is, when I started creating it without real use, I took some design decisions that would bite us when using it in a real project.

Bad decisions

  • Tried to make everything extensible
  • Used an obscure graph drawing Unity API

Bad consequences

  • The highly-extensible part was getting on the way when trying to do simple stuff (and even then, it was not that extensible because at the time I didn’t know what would really benefit from being configurable)
  • There’s no in/out zooming
  • It’s hard to link nodes because slots are that small (there’s no API to change that)
  • Serialization was hard because we had to synchronize our model with the Unity API’s one
The first version of the graph editor

Rewriting the solution

Let them who never rewrote a solution implementation cast the first stone!

Wielding the knowledge of the pain points of the first API and also the exact needs that our tool would solve, we could finally go for a more robust solution.

TMW you deal with old/legacy code

In a weekend I was able to sketch a new graph editor tool from the ground up just because this time I knew what I was aiming for. And because of that, the API turned out simpler to both implement and use.

Good decisions

  • Keep API simple and opinionated
  • Use standard editor GUI tools and roll our own graph drawing API (it’s simpler than it seems!)

Good consequences

  • New node scripts are super compact and expressive
  • Possible to implement in/out zooming!!!
  • Easier to connect nodes since we coded our slot-mouse collision function
  • Serialization was more robust (once we figured out some initial issues haha) since we did not need to maintain two states synchronized (view and model of the graph)

Nice extras

  • Select GameObjects in the hierarchy when clicking their associated nodes
  • Ping nodes when the selection in hierarchy changes
  • Nodes can have any RGB color (before it had to be an enum - crazy right?)
  • It’s easier to change and animate edge color
  • We did a “cut edge” thing to mass remove edges like ShaderForge does (pretty cool and useful)
Current version of the graph editor

What changed

We solved the same problem twice. But the second implementation was much nicer and overall better.

The only thing that changed was that when I was first coding the tool, I’ve had no real necessity for it nor I’ve had any in the past.

This is one pattern I’ve noticed in other tools/code I made that had no real use case. And there was not a single one of these tools that I actually reused without any rewrite of sorts!

So that’s it! Keep your code in the present!

** Oh! Expect this new graph editor thing to be available on BitStrap soon!