Experience Battlefield 3 Like never before
Closed Beta
In Progress
Experience a project built by the community, for the community.
Have full control, with self-hosted dedicated game servers.
Enjoy unprecedented access to new and unleashed game features.
Create unique experiences by leveraging modding capabilities.
Image courtesy of Berduu

Tune in tomorrow, May 13th at 18:15 UTC, to witness MeetYourMakers go head-to-head against iPLAY in a one of a kind show-match, and only on Venice Unleashed!
Both teams will compete with a roster of 5 professional players in a Best-of-Three, adrenaline filled Squad Rush match.

The event will be hosted and broadcasted by LevelBF, and casted by MiloshTheMedic!

You don't want to miss this!
Earlier today our first Open Bughunting Season came to a close.
It is only because of your tremendous support and feedback that this event was a success!

You tested, you provided feedback, and we listened, and during the course of the past 3 days over 60 new issues were reported by you, out of which more than half have already been fixed! There were some issues that made the game almost completely unplayable at times, but thanks to your patience we managed to isolate and resolve most of them. If you want a complete list of changes that were made during the past two days, make sure to check our changelog.

During this test we learned several new things, not only about the game engine and our client, but also about the community.

For starters, we figured out that there's no single consumer-grade machine powerful enough to run one of our 120Hz servers with more than 30 players, and even that is pushing it. This didn't come to much surprise to us, as we already knew that the CPU requirements would rise, we just weren't sure about how much. We will be analyzing the data we collected in order to be able to more specifically provide hardware and bandwidth requirements for servers.

Secondly, we learned that events like these require better instrumentation. People need to be guided in what to do when testing something, and even though our setup worked well for most things, some players were still left confused and lost without guidance, something we will be definitely taking into consideration for our next test.

Finally, we saw great support and excitement from the competitive community.

Venice Unleashed aims to be an environment for all players, both competitive and casual, so we've been working hard on features that will make everybody's experience much better, from small changes to our interface and mod tools, to advanced tools for professional players and casters.

We will now be entering a period of slight silence, while we sort out and resolve all of the game-breaking and usability bugs you reported, and working on optimizing and putting the final touches on our backend services, in order to get one step closer to the ultimate and Unleashed Battlefield 3 experience!

Once again, we'd like to thank all of you who tested with us and provided valuable feedback.
This wouldn't have been possible without you!

From everyone at Emulator Nexus, thank you, and we hope to see you again soon in our next open test!

Hello fellow players!
We're very excited to announce that starting this weekend, and for only 72 hours, Venice Unleashed will be open for everyone to use.

Starting at Saturday, May 9th, 12:00 UTC, any registered Emulator Nexus member will be able to access all of the features Venice Unleashed provides, for 72 hours, without the requirement for a registered key.

So clear your schedule, jump in, and help us discover possible bugs, test our new high frequency networking code, and stress-test our services.
Your feedback will help us improve Venice Unleashed and our services, and will bring us one step closer to a fully open release.

Have questions about the Open Bughunting Season?
Make sure to check out our 72h Open Bughunting Season FAQ!

See you on the Battlefield!
The so called Frostbite netcode has been a huge topic of debate over the past couple of years.

Since release, various 'unoptimized' portions of the networking system in Frostbite games have been plaguing the Battlefield community, with high in-game response times from client to client, hit detection issues, slow replication of movement updates, and so on...

Most people first 'discovered' this topic with the release of Battlefield 4, where some of the previously mentioned issues were significant, and directly affected the enjoyment and playability of the game, but the truth is that even earlier games are plagued by these issues, and in our case, Battlefield 3.

After numerous requests from our community, we decided it was finally time to take a closer look at the so called netcode, perform some research on it, and see what we could do about it.

The first thing we did is to gather some statistical data on how the game performed.

For all of our tests, we spawned two VU clients connected to a dedicated server, all running on the same machine, and therefore with virtually no network latency overhead.
Then, we fired 38 shots (from both game instances), and we measured the time it took for every shot to register its damage on either client.

All of our measurements were accurate down to the microsecond, but for the purposes of this presentation, all times were converted to milliseconds.


In the above graph, you can see the time distribution between different shots, along with the low, high, and average latency values in ms.
To our surprise, updates averaged to a staggering 90ms, which means that from the moment someone shot you on his screen, it would take approximately 90ms (+ network latency) for you to see that reflected on your screen.

The other thing that we could deduct from this data is that updates appeared to occur within a 30ms interval from each other.

From that data we came to the conclusion that the incoming frequency for clients was approximately 15Hz, and the outgoing frequency was approximately 30Hz (and vice-versa for the server).

Out of curiosity, we performed another test, but this time, with network smoothing set to 100% (in the first test it was set to 0%).
We think the results speak for themselves...


You might notice that after the 19th shot, updates are shifted upwards by approximately 30ms.
This appears to happen because of the simulation latency difference between the two clients, since the last 19 shots were shot from the second client.

Long story short, unless you're filming a cinematic (or something similar), you should avoid having network smoothing on.

After we were done with our initial tests, it was time for research and experimentation.

Our goal wasn't to optimize the internal workings of the netcode, as doing so would require countless hours of work and dedication, with probably little to no payoff.
What we set out to do was to figure out whether it was possible or not to up the replication frequency whilst maintaining a fully functional game, and if in doing so we could improve the update latency.

After approximately two weeks of constant research, tests, failures, and more tests, we came to the following conclusion:
It was definitely possible!

That's why we're extremely excited to announce the High Frequency update for Venice Unleashed!

Starting with build 8312, the Venice Unleashed client can optionally function in High Frequency mode, allowing you to connect to High Frequency servers and enjoy low latency updates.

We could go on and on babbling about how much more better the game works with our High Frequency code, but instead we'll let our test results speak for themselves:


From what you can see in the above graph, the average latency has been decreased by almost 3 times, to an impressive 35ms, a value which makes our client compete with some of the most optimized competitive games out there.

There is still a slight deviation of ~12ms, but that's to be expected and shouldn't be significant when it comes to gameplay.

For those of you that don't really like graphs, we've also recorded a comparison video, comparing the regular frequency netcode against our high frequency netcode:

The original footage was recorded at 60fps and then slowed down in post.

Now, all these changes might sound good and dreamy, but they do come at a cost.

A server (or client) running in High Frequency mode will consume approximately four times (x4) more bandwidth (both incoming and outgoing), and will see a slight increase in CPU usage.
Additionally, there are a couple of issues that are currently present, the two most significant of them being wobbly first person models, and weird dirt-bike physics.

We are of course currently in the process of fixing the aforementioned issues, and we hope to have a fully functional high frequency client as soon as possible.

Interestingly, another side-effect we observed was that loading times were slightly decreased when running in high frequency mode, but we don't think that's something that requires fixing.

Unfortunately, because some of our code changes are being performed at a very deep level in the engine, switching to (or from) high frequency mode requires a client restart.
When connecting to a high frequency server from a regular frequency client (or vice-versa), the client will automatically prompt you to restart your game.

Alternatively, you can always run your game in high frequency mode by providing the -highfreq parameter when launching vu.exe (also usable for running a server in high frequency mode).

Test Server #001 is already running in High Frequency mode, so you can already jump in and test it for yourself!

This post is the first of a two-part post.
Stay tuned for the next part, in which we will discuss the latest changes in the Spectator mode, and the future of the project.


Latest Tweets

Due to high demand we're currently unable to accommodate any additional key requests. Thank you everyone for your patience and support. 1 month ago
During the course of the next few days we will be performing maintenance and upgrading our backend services. Downtime is to be expected. 1 month ago