Without going into technical details this is not true. Even back then making your own front-end engine was a foolish waste of resources. For all of its problems, using Unreal easily shaved 2 years off the development cycle.
I didn't say make your own engine; I said you should have found a better one because it's obvious that Unreal never worked for Vangurad and still doesn't work for Vanguard today with the constant chunk crashes.
They're all working for pretty much free as far as I know. I'm pretty sure if you were anything but an engineer you'd be on board for doing a project like Pantheon just because it's another opportunity that doesn't seem completely hopeless.
Back then, there were no other Engines that would have even remotely fit the bill. Keep in mind the project was started in 2002 or 2003. It is shocking how much game development (especially online development) has changed in only a decade or so.
You're probably right; I don't follow industry rules and probably am way off. I simply am a software engineer. I innovate, I create, I make things happen that people don't even know that are possible. I don't count the dollars for the company, or hype everyone for the latest cock of duty - I just simply don't care about the financial part of it. I think of what's reasonable based on my experience. And my experience is pretty damn vast, if not considered 'professional'. Companies go head first into a lot of things they don't know about and set themselves up for failure financially because they overpay the wrong people and the people who made the game what it is always end up getting nailed or fired.
Well, I didn't say the engine was garbage. I said (if I remember correctly) that the game design was iron-clad, tech be damned. So many of the problems Vanguard had were trying to fit a square peg into a round hole. A big part of making a good game is modifying your design with creative solutions for difficult technical obstacles. This wasn't done with the open world design.
As a programmer I am calling bullshit on this. You can fix bad code, you can't fix bad design decisions. Performance issues are directly related to code, not design decisions.
Was one of those decisions, choosing for a seamless world and the chunk-thing? I just fired up VG on my i7, Radeon hd 7970, 16gb Ram comp with the game on an SSD and it still hitched. That was a big disappointment.
Still would be a technical decision. If the game designers are making technical decisions something else is amiss here.
I mean no project, no matter how big, has infinite time and resources. Making a game is often about juggling resources to find a maximal point where you get the best game with what you have. This means coming up with creative solutions, for all parties involved, that solve difficult problems.
But their job is to 'make it work'; that's what they get paid for. Start looking into performance monitoring tools. Start finding bottlenecks. They don't have infinite time, but there should be reasonable amounts of time to solve bottlenecks. Take APB: Reloaded for example, it took them 3 years (!!!) to solve a latency spike issue in their server code. That's the kind of unacceptable bugs that programmers like myself fix, and are never given the opportunity to fix due to not being in industry.
Yes, that was the big one. The game hitches when chunking primarily (if I understood correctly) because the server has to pack up all of your character information and send it to the server handling the next chunk. This causes all sorts of wonkyness on the chunk lines with everything, especially players and NPCs.
I'm sorry, but your ideas exist outside of reality.
At that point, why not allow the client to continue regardless of the server's response, and THEN allow for the chunking to occur in the background? Has no one in that team heard of threads and proper usage of mutexes? You can send the client the information again when it's proper to.
I must exist outside of reality, because I make the impossible happen when asked through programming *every day*