Battle Cry of Freedom (WIP)

[Olafson_1]

Hi there,

I would like to show you some pretty early, pre-alpha work we have been doing on our first stand alone game. I will update this thread frequently and I will try to answere any of your questions.

The following is from our Website.

The new game, which has the working title “Battle Cry of Freedom” is going to be a standalone title developed by our team alone. We are already in full process of developing the game.

Set during the exciting era of the American Civil War, players will immerse themselves in unique and rewarding tactical gameplay based on two teams fighting each other.
Utilising a wide range of weaponry, from long range rifled muskets and devastating artillery, to various deadly close combat tools such as bayonets, knives and muskets, players will take up the fight for the North or the South trying to win the day on the bloody battlefields of America.

The game will feature a large amount of players simultaneously fighting each other on the same battlefield in a completely destructible and realistic Civil War combat environment, rendered in beautiful up-to-date graphics. Our best efforts will be taken to ensure “Battle Cry of Freedom” provides highly enjoyable and balanced gameplay for the best American Civil War experience the market has to offer.

Please go to the Media section to take a look at some more early Pre-Alpha Screenshots. Also make sure to check out our FAQ here.

Battle Cry of Freedom is a crowd-funded project. As we are a small team who are working full time on this project, we need your help in acquiring the funds needed to create this game. To achieve this we have set up a donation system, similar to the one kickstarter is using. It features a tiered reward layout that is integrated into the forum. The rewards vary from possession of the game, access to the alpha and beta, and special boxed editions and banners. Anyone who donates gets exclusive access to the suggestions board, where he or she can actively take part in the games development.

If you want to know more about the games concept first, continue reading in the “About the game” section. We will frequently update it every few weeks and new content will be added soon.

There currently is not much to show, that is why it is in the WIP board. I will frequently update this thread, as soon as new stuff is available.

Here are the links again, to the various threads/sections:
Homepage
Media
Announcement
Donations
FAQ

[EctoNecro]

I’d love to play a game like this. Looking forward to your project! I hope you get some funds, I know how it feels to need resources, as I’m in the same situation myself :P.

[IndieScapeGames]

Man I swear some of these are photographs!

EXCELLENT!

[IndieScapeGames]

Oh wow, after browsing their site, I found out that these are the developers of the Mount Blade expansion Napoleanic Wars.

Very cool, and Unity is a great choice!

[BlankBlank5454]

My goodness. That looks amazing. Great job!

[roger0]

It looks exiting. But how are you going to have 500+ players on the field along with destructible buildings? That would leave battlefield 3 in the dust and that’s a recent AAA game.

[laakerules]

What ^he said, 500 players on the field, with destructable buildings? either 10 server systems used or you guys made a new super computer and reinvented the way that the internet works!

[Olafson_1]

Thanks to all of you. Ofc. there is not much to show right now, but we are working hard to get some more pictures up soon.
About the 500 player thing, this is Unity 3D! Not some wierd Frostbite 2 or Cryengine 3! In terms of Networking, Unity is just the best engine on the market. (And overall, it is pretty nice ) We will post more about that sunday, in our first Dev Blog. If you have additional questions after sunday, feel free to ask.

Ps. Got ninjad by laakerules
On one dual core system with 100mbit up/download.

[HeadClot88]

Loved Napoleonic Wars from you guys!

[Olafson_1]

From our Website:
www.fsegames.eu

Well, that has been one hell of an exciting announcement! The feedback and excitement we have received this week has been overwhelming, and we are proud to say that in just one week we have raised enough to hire our musician to start recording! So be ready for some awesome Drum/Fife/Trumpet and Fiddle tunes coming your way!

Starting today, there will be a weekly dev blog that will keep you up to date with the production of the game.

Next is the Developer’s shack. In some developer blogs one of our team members will write a little piece about some of the work they are doing, to give you some more detailed information on Battle Cry of Freedom. This week our main programmer Maxim “Vincenzo” stepped up to explain a little about how we are providing the huge amount of players we have promised!

Networking
I know it, we are insane!, 500 players… It seems impossible right? Well In our first dev blog we will explain some concepts on how we will get this to work.

When designing this network engine we had the following requirements:

Normal clans should be able to run servers, on average server hardware and connections.
At least double the player count that we could support in M&B: Warband - Napoleonic Wars.
It should support Melee/Ranged combat.
It must be cheat protected.
Environment such as buildings, fences and other scenery must be destructible.
Voice chat with other players should be possible.
Supporting physics with carts and other moving objects.

With these ideas in mind we went to the drawing board.
The big bottleneck for any multiplayer game with a lot of players, is the server. Figuring the average server would have an Intel Quadcore, and a 100 mbit uplink, we put the requirements for our server to half of these specifications, so a host could run two fully crowded servers on one server box.

First of all we should understand why high player counts are such a challenge, the reason behind it is the exponential amount of data.
In the average FPS game, one player generates about 0.5 Kilobytes of data per second while he is playing the game, this information has to be sent from the server to all other players.

Imagine a 100 player server, that would mean the server receives 0.5 Kilobytes of data from each player, but is sending out 50 Kilobytes per second (0.5 * 100) towards each player…, which would mean the total upstream of the server would be 5000 Kilobytes per second (50 KB/s * 100 players), which is already about 40 megabits total upstream!

Now, imagine a 200 player server, that would come down to (200 * 0.5) = 100 KB/s * 200 players = 20000 Kilobytes per second total upstream which is more than 156 megabit!, which is far more than the average server upstream link… 500 players would even come down to more than 976 megabit upstream which is virtually impossible.

So… how do we do it then?

Only send data when it is actually changed.
A player basically runs a simulation of the world. He gives input such as movement, attacks and other interactions. This input is sent directly towards the server, which processes the input and applies it to the game. These changes are then further sent to the other clients.

Most network engines simply send a constant stream of the latest state-data such as buttons being pressed, directions players are looking at and movement data to all players, for each player, as you might have guessed this creates a lot of redundant data.

In our design we only send changes, for instance if a player turns around, only his turning is sent, and once he stops looking around no further messages are sent for that player, at least until he interacts with the game world again. Same goes for movement, as soon as a player holds forward, only that is sent, as soon as he lets go of the button, that is sent.
This can save enormous amounts of data, because most players are usually not constantly moving/attacking/looking around or interacting with the game world.

Compress data, lossy, to acceptable values.
As you saw before, the amount of data sent is important, saving a single byte per player per network message could come down to 500 bytes already which is half a kilobyte! As such we apply heavy compression on data send from the server towards the clients.
For instance, a player looking around with his mouse moves around 360 degrees. Normally storing the rotation takes a floating point value of 4 bytes…

A single byte can store up to 256 unique values, as such if we map 360 degrees towards 256 values, we might lose precision of the exact rotation, for instance a player might be 1 or two degrees off than what he is looking at in reality, but this is neglectable and virtually impossible to detect for a player looking at another player. Thus we have just saved 75% of the data!

These kinds of compressions are done over the whole engine, voice is also heavily compressed down with the latest voice compression tech.
Most of these kinds of compression techniques have rarely if ever been done to this level of efficiency in other network engines. This is one of the main factors making these insane player counts possible.

Headers are costly, don’t send data too often.
Sending a single network message from the server towards the client takes headers, headers are simply information that routers use to know where a packet comes from and where it should go to.

A average UDP header comes down to about 58 bytes of data, on top of that we add our own 10 bytes header which tells us exactly when a packet was sent and where in the game it should go. As such, sending a message without any data at all already takes 68 bytes of data… thus its very important to send as few messages as possible.
In our design, we basically save up all the data that needs to be sent out to clients, and send it out at a steady 10 times per-second rate, this way we use the headers as efficiently as possible without creating too much delay.

Results.
So, that is well and dandy, but… how does that end up then?
Well, basically a player data packet is between 0 and 7 bytes, depending on the player giving none till all kinds of input. the average during my testing, with an extreme amount of movement changes/strafing and turning around a lot, is around 3 bytes which can be seen as the worst case scenario, as I don’t expect all players to move like that all the time…

So in worst case we end up with (500 players * 3 bytes) + 65 bytes header * 10 updates per second = 15680 Bytes per second, or, about 15.3 Kilobytes per second… Times 500 players, it comes down to 7650 Kilobytes per second, or about 59.7 Megabit per second. which is well under 100 megabit upstream of the average server!

We plotted our engine upstream with different player counts in comparison to the average network engine in the following graph:

In Conclusion.
In theory, we could reach much greater player counts, so long as one uses a very good server, with for instance, a 1000 mbit uplink! We announced a player count of 500, as this is what we are confident we can provide, given the current design and previously implemented network engine tests. Progress on the network engine has been great, most of it is working and implemented, We have the confidence to start the live tests soon. For now, using random generated player data yields great results.

If you didn’t realise we were raising money to complete this project head over here to check out our reward tiers here.

We will see you next week!

[LilWiebe]

I was hoping to save this idea until I owned Unity Pro and could profit from it personally, but I think it would be a shame if this project didn’t have it. You NEED realtime transparent shadows. I know that TECHNICALLY this isn’t supported in unity, but it is doable. On your main directional sun light, add an orthographic camera. Have this camera render transparent objects ONLY at a fairly low resolution, but use a depth stencil from solid surfaces. Render to a texture. Use a custom shader on this camera to invert the alpha channel Then pass this render texture into the light cookie on the directional sun light. That way, you’ll basically project the alpha of the particles onto solid surfaces in the game, and BAM! Your explosions, fires, muzzle flashes etc. will cast shadows! I don’t really care if you credit me, I just wanna see how your game looks with this little do-dad applied.

[roger0]

I’m getting that your going to use various network optimization techniques in order to get to so many players within a single game. Although im still in a bit disbelieve as to why we’re not seeing more FPS games with 500+ players at once coming from companies with multi million dollar budgets like battlefield 3. Which is stuck at 64 players max.

[laakerules]

What he said^, what the networkign says is that you are basically trying to do what a mmo does from a server, but in fps form instead of clicks you have multiple movements all at once. Take Runescape for example, they do excactly what you explained but only for players within the same region as you, then they only transfer the clicks needed or the few words typed, but with a fps there is way more things that need to be communicated through the server, especially to stop lag kills where you hit the person but there already around a corner and miles away from you in there game. I personally say goodluck as it is near impossible to achieve a 500 playercount on a server without lag in a fps, especially when there is so many values that need to be transfered. Sure it might not lag for 50 of those 500 but then you have the other 450 that will rage and quit.

[Olafson_1]

Well, thanks. We are pretty confident that we can achieve 500 players. Our last tests have showed that 350 players perform quite well, and our engine is still in the works. Basically, as we said in the Dev Blog, with 500 players we would only use about 59mbit per server, which is nothing compared to the usual network engine which would use about 1gbit per server…

[laakerules]

Okay well basically ill believe it when i see it, and i will comend the devs on achieving the thought impossible.

[roger0]

May I ask what kind of networking your using? ULink? Photon?

[laakerules]

There doing Udp Nat Whole punching custom functions that there writing, basic packet sending from clients to server then to other clients.

My thoughts of what they would do as it is easiest to work with and allows the most customization.

[Olafson_1]

We are using our own implementation/modifcation of Ulink.

[JamesArndt]

I don’t honestly care how many people will work in the multiplayer to be honest. If 65% of the field were AI I wouldn’t even mind. It’s the fact that this is a game set in something historically realistic…a truly pivotal time for our nation. This was unlike any other war, in the fact we were killing our own family, our own neighbors… we were fighting each other on American soil. Kudos to you guys for bringing a game to life that’s set in this time period!

[SevenBits]

Graphics look nice from what I see in the screenshots.

I don’t honestly care how many people will work in the multiplayer to be honest. If 65% of the field were AI I wouldn’t even mind. It’s the fact that this is a game set in something historically realistic…a truly pivotal time for our nation. This was unlike any other war, in the fact we were killing our own family, our own neighbors… we were fighting each other on American soil. Kudos to you guys for bringing a game to life that’s set in this time period!

I agree somewhat, but multiplayer can always make a game fun. Also, I don’t know if you’ve said this before, but having it be a game like Star Wars Battlefront where you can choose your “unit” and then spawn would be really cool.