Two weeks ago, several of my friends and I – who play a cooperative videogame together – were a little frustrated with some changes made with no warning by the developers. We didn’t understand why they made them (they never communicated a clear goal or process or … anything, really) and we certainly didn’t like many of them invalidating previously useful pieces of equipment and strategies and so on, without giving us new, similarly effective stuff. It was, more or less, a global nerf. To a free product, that’s one thing, but to a product people paid money for? And to a product with many, many DLC items people paid more money for? A no-warning, no-explanation global balance change was awful.
On the other hand, the developers helpfully left the entire code to change everything in unencrypted lua, and the clients trust the local lua … so if we modified the values and all ran with the same code, we’d all experience the same balance. Security? What’s that? But convenient for our purposes.
After reading a lot of community complaints about the changes, I thought “…I can do this. I can make this.” So I took it upon myself to redo the balance values, distribute a lua override file to my friends, and for us, at least, we’re playing the game we want to play. It wasn’t until I was having what amounted to an impromptu standup over VOIP that I realized …we’re basically doing agile videogame modding.
I mean – not exactly agile. But surprisingly close for a group of random people on the internet. I’d develop a small series of changes, distribute the file, and then discuss with the group what I changed. We’d test, I’d get feedback, and develop a different version almost while playing. Repeat for several days and what started as a fairly unambitious project – “fix some things we don’t like” pretty much completed itself painlessly. I started with a proof of concept on October 30, first release October 31, and effectively finished on November 7. It was a one week sprint!
That’s unusual for video game modifications – succeeding, and succeeding quickly? I don’t think any of the reasons we succeeded are out of the ordinary for software development, but it’s good to apply lessons learned whenever you can. To start with, before I wrote a single line of code I did two things:
I was starting from scratch on lua editing and a three-year-old spaghetti tangle of uncommented code to boot. What to do? I found a mentor with a deep understanding of this game’s particular lua structure and quirks. I can safely say I wouldn’t have even started this project without them – simple as that. No need to reinvent what’s already been done – and for this project, no interest!
And, because this was a small project done in spare time, I had to be careful to scope it carefully. I chose to only “fix what was broken” such that if something the developers had changed was usable and effective even if it we felt it was ‘unbalanced’ … fine. I wouldn’t fix that. Sticking to that goal wasn’t always easy – we all had moments of “wouldn’t it be nice if,” or “how about we do…” which were traps for all the good intentions behind them. Defining the scope in advance and in fairly concrete terms helped keep this to a minimum.
During development, things proceeded more or less as expected – it was, of course, important to have proper version control. Everyone quickly got in the habit of starting our playtests by pulling the latest version, and because I was the sole developer I’d make sure to clearly lay out what had changed, why, and what specifics – if any – I’d like to target that session.
It was also important to avoid sweeping changes. Broadly speaking ingame equipment is sorted into roles, and in those roles, tiers. Let’s say there were 20 things sorted into 4 tiers of 5 items each; I would test one item of each tier as a prototype for the concept – not just change all 20 and hope for the best. Focusing this tightly also let me get a much better feel for how to make the changes in the first place – so the next time, I could get it right or close to right the first try. It didn’t happen every time, but it felt really good to calculate an idea, implement and have it be right on target first thing.
We also had some advantages by virtue of being both the development group and stakeholders. Everyone involved had a deep understanding of the game’s mechanics and systems. We knew exactly what to look for and how to test – no need to develop testing routines. It also meant sign-off on an issue could be as simple as polling the group for “yeah, this works.”
Like I said earlier – no major surprises here. But good practice is good practice, even when you’re having fun with your friends. Well, if you think tweaking lua and testing is fun. That’s up to you.