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!
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.
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.
- Tried to make everything extensible
- Used an obscure graph drawing Unity API
- 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
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.
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.
- Keep API simple and opinionated
- Use standard editor GUI tools and roll our own graph drawing API (it’s simpler than it seems!)
- 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)
- 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)
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!