Since I don't know....
Moderator: Community Managers
Since I don't know....
I will ask.
How exactly are you doing this? I mean, without the code isn't this nearly impossible? I am not well versed in the technical aspects of emulators, but I thought the only reason an EQ emulator was possible was because someone leaked the code. How much is possible without code?
Now I've seen the videos and I'm impressed. Prior to coming here my wife casually mentioned a VG emulator and I (wrongly) told her, "Impossible". But what you have so far looks great! How does this whole thing work exactly?
How exactly are you doing this? I mean, without the code isn't this nearly impossible? I am not well versed in the technical aspects of emulators, but I thought the only reason an EQ emulator was possible was because someone leaked the code. How much is possible without code?
Now I've seen the videos and I'm impressed. Prior to coming here my wife casually mentioned a VG emulator and I (wrongly) told her, "Impossible". But what you have so far looks great! How does this whole thing work exactly?
- John Adams
- Retired
- Posts: 4581
- Joined: Wed Aug 28, 2013 9:40 am
- Location: Phoenix, AZ.
- Contact:
Re: Since I don't know....
Hello Jave,
Without getting into the nitty gritty, I will offer this. Client->Server apps communicate over the network via packets of data (generally speaking). "Opcodes" or Operation Codes get sent back and forth so each component knows what the other is doing. A simple look at a basic opcode is here on the wiki.
We have a client, we just do not have a server to talk back to the client. So, we are building the server. How we do that is with an incredible amount of patience, time and smarts on the part of packet analyzers and C++ coders to "guess" what the server should say back to the client. We can tell what the client->server say to each other, because we "sniffed" the packets going back and forth. Now, we analyze those packets and guess (based on years of experience doing this) what the contents are. Ie., is it a spell, is it a hail, is it a /wave.
Then, we build our own versions of these packets in the C++ code so when the client asks for a /wave, the server sends back the command needed to /wave. This is why it will take a long time to be a fully functioning game, unless we get hordes of C++ developers interested in helping.
Hope that answers your question. And just so you know, nothing is ever "impossible" with determination and dedication
Without getting into the nitty gritty, I will offer this. Client->Server apps communicate over the network via packets of data (generally speaking). "Opcodes" or Operation Codes get sent back and forth so each component knows what the other is doing. A simple look at a basic opcode is here on the wiki.
We have a client, we just do not have a server to talk back to the client. So, we are building the server. How we do that is with an incredible amount of patience, time and smarts on the part of packet analyzers and C++ coders to "guess" what the server should say back to the client. We can tell what the client->server say to each other, because we "sniffed" the packets going back and forth. Now, we analyze those packets and guess (based on years of experience doing this) what the contents are. Ie., is it a spell, is it a hail, is it a /wave.
Then, we build our own versions of these packets in the C++ code so when the client asks for a /wave, the server sends back the command needed to /wave. This is why it will take a long time to be a fully functioning game, unless we get hordes of C++ developers interested in helping.
Hope that answers your question. And just so you know, nothing is ever "impossible" with determination and dedication
-
- Posts: 5
- Joined: Thu Jul 31, 2014 5:02 am
Re: Since I don't know....
You guys are brilliant!!!
Another question though from a fan who is also not well versed in emulator technical aspects- Will the emulator also be based on the UR2 engine, or can a more "modern" engine be used by the emulator? I've heard that the UR2 engine was one of the things that led to the downfall of VG.
And forgive my inquisitiveness (and ignorance), but do you think you gathered enough data before sunset to recreate the Vanguard world reasonably close to the official version, including material from all 3 spheres?
Again, I am in awe of what you guys are able to do.
Another question though from a fan who is also not well versed in emulator technical aspects- Will the emulator also be based on the UR2 engine, or can a more "modern" engine be used by the emulator? I've heard that the UR2 engine was one of the things that led to the downfall of VG.
And forgive my inquisitiveness (and ignorance), but do you think you gathered enough data before sunset to recreate the Vanguard world reasonably close to the official version, including material from all 3 spheres?
Again, I am in awe of what you guys are able to do.
Re: Since I don't know....
Not a dev, but the server software isn't rendering anything itself and requires no graphics engine so to speak of. It is merely a program that coordinates and sends out information to the clients. If you have ever played around with any dedicated server program for a multiplayer game, you'll usually notice a pretty simple interface and that the server software tends to require a lot less resources (but usually substantially more bandwidth).
To migrate Vanguard over to a new engine, it would require porting and conversion of almost all the assets to the new engine. Scripting, skeletons, meshes and all that are not always a direct conversion, ESPECIALLY with the scripting. You would essentially be rebuilding the entire game, albeit with a nearly complete set of reference material, sounds, textures and so on. If you could get a diehard team of 20+ people who were real Unreal junkies, it might be doable in a relatively sane timeline. Dare to dream!
Any devs feel free to correct me if I am an idiot. =P
To migrate Vanguard over to a new engine, it would require porting and conversion of almost all the assets to the new engine. Scripting, skeletons, meshes and all that are not always a direct conversion, ESPECIALLY with the scripting. You would essentially be rebuilding the entire game, albeit with a nearly complete set of reference material, sounds, textures and so on. If you could get a diehard team of 20+ people who were real Unreal junkies, it might be doable in a relatively sane timeline. Dare to dream!
Any devs feel free to correct me if I am an idiot. =P
Re: Since I don't know....
You are correct Sacred. Basically the client and server use the Unreal engine although they have some different pieces. They also share some code to calculate things like physics. In case you aren't aware, the client simulates some physics on it's own, with some corrections sent from the server.
To port the game over to a new engine (like Unity) would take some time to convert the assets, unless there is some tool that converts Unreal assets to Unity assets. Tools like this probably do exist since both engines are popular. Even then you'd have to write the client in addition to the server. At least with the emu we can use the client as-is and just focus on the server.
I think there are still some cool things we will be able to do server-side. Perhaps much of the Vanguard problems were due to the server code, and if that was the case, we might be able to resolve that.
To port the game over to a new engine (like Unity) would take some time to convert the assets, unless there is some tool that converts Unreal assets to Unity assets. Tools like this probably do exist since both engines are popular. Even then you'd have to write the client in addition to the server. At least with the emu we can use the client as-is and just focus on the server.
I think there are still some cool things we will be able to do server-side. Perhaps much of the Vanguard problems were due to the server code, and if that was the case, we might be able to resolve that.
Re: Since I don't know....
Server code, network traffic (I am betting this has never was streamlined), map occlusion (early unreal engines never handled sorting all that well) and bunch of other things.
Re: Since I don't know....
Even if converting to a new version of Unreal, there would be a substantial bit of work to do as well as licensing and other legal headaches that might pop up. Converting to another engine like Unity, even with conversion utilities would probably require lots of garbage collection and testing as well. But I do agree with lots of issues being server-side. The client is pretty stable and has a good deal of polish to it thankfully.
Re: Since I don't know....
This is interesting. Thanks for the replies. Sounds like a ton of work. Doesn't sound like much the uneducated can help with but my wife and I will volunteer for any low level stuff that can be passed on, now or in the future.
-
- Posts: 5
- Joined: Thu Jul 31, 2014 5:02 am
Re: Since I don't know....
Yes, thanks for all the information!
Unfortunately, all of that coding sounds like it is well beyond my abilities too. Is there a paypal account for the emulator project? I would like to help in some way, as I'm feeling pretty down about the loss of the game.
Unfortunately, all of that coding sounds like it is well beyond my abilities too. Is there a paypal account for the emulator project? I would like to help in some way, as I'm feeling pretty down about the loss of the game.
- John Adams
- Retired
- Posts: 4581
- Joined: Wed Aug 28, 2013 9:40 am
- Location: Phoenix, AZ.
- Contact:
Re: Since I don't know....
There are many ways people can help us (greatly) without being C++/C# Developers. When we start building the world, we will need people to use our custom tools place things in the world (content designers) and verify things are working (beta testers) and mostly, experienced VG players who will be our only resources for getting this right.
Plenty non-technical, and super fun stuff to do - coming soon.
Plenty non-technical, and super fun stuff to do - coming soon.