We have heard you. We apologize for the confusion and angst the runtime fee policy we announced on Tuesday caused. We are listening, talking to our team members, community, customers, and partners, and will be making changes to the policy. We will share an update in a couple of days. Thank you for your honest and critical feedback.
Agreed.
Yeah, I think the right thing to do would’ve been to make the wilderness a safe PvP faction vs faction area that’s basically a continuous version of one of those events.
Any code base can be fixed, it’s just a function of time and money. They can yell spaghetti code all they want, but ultimately Jagex is the one that allowed that to happen in the first place. It’s not an excuse to further gaslight your customers. It’s something you should take accountability on, and work to fix. Done right, having your own engine is an opportunity to do new and exciting things.
It’s certainly a very large financial undertaking to change the engine like that, and at that point they’re honestly better off just making a new game entirely.
I love your idea for the wilderness, safe PvP for factions would’ve been a lot of fun.
They might be doing exactly that FWIW. There’s some evidence Jagex is working on a “RuneScape universe” oriented game in Unreal Engine.
Still, that’s not the silver bullet that people often think it is. Rewrites are often far more expensive than originally anticipated and extremely risky as even if you intend to make the exact same game, there are often differences that come down to the underlying engine in how the game plays that can be controversial.
For context, I’ve been on a team that did a full rewrite of a large complicated C# web application in Ruby and I’ve also worked on several C/C++ “desktop” applications that have roots in the late 80s and early 90s. The former is more “fun” in a sense, you can make up for a lot of sins. However, I fundamentally believe that unless the language you’re moving from has serious fundamental issues (e.g. you’re insane and wrote a million line application in Bash), you’re probably better taking a hard look at your application and retrofitting new systems inside of the old application where you most badly need those changes.
Even in the “worst case” it’s in practice true that most of the code doesn’t need touched, it’s just some really intertwined portions that need revamped. You can often get away with making a new system that replaces the guts of the old, thus powering both the existing code, and allowing you to achieve whatever goal you had in rewriting in the first place (working faster, safer, more readably, etc).