Current Development

Working on Technical Release 2 / Subspace Zone.

See full development status

Download Client & Development Tools

The game is currently in alpha preview. Expect lots of bugs.

Click here to download (Build f9cf197 at 10/4/2022 2:15 AM UTC)

This announcement has been a long time coming so pardon the delay.

Technical Release 1 (TR1) is finally out the door. This release has been mostly about wiring in the various systems - rendering, input, networking, a bit of physics, and the editors - to work together. What you see below are some screenshots that incorporate the visual aspects of TR1, backed by all the systems working together.

TR1 has been a difficult release to get to, in part because it brings all the independent pieces to work together. From the login screen, to the list of zones, to joining the zone, selecting a class, spawning a vehicle, moving around and whatnot. As always, note that the chat system is wired into the central server, so it is available to you as soon as you log in - you do not have to join a zone to chat to people (but arenas also have their own specific channels that cannot be accessed from outside).

A lot of work has been done on making the editors feature-complete and ready as well, and in particular the Mesh Editor which I had previously talked about is finally being worked on. I will make a separate post another time to describe it's features, but in short, the mesh editor allows you to assign collision shapes to your meshes (props, vehicles, computers) as well as to specify where you want projectiles and particles to be emitted. If a projectile outlet is attached to a hand, it will follow the animations (position and rotation) of the hand.

I decided to incorporate blurring as a small feature into TR1. Any region of the screen can be blurred, and un-blurred elements can be rendered on top of blurred elements. Later on I will be incorporating this into the game world itself to have frosted glass windows and floors.

Starting from Technical Release 2 onward, you will be able to download a game client binary, sign in and play. Later on you will also be able to download Infantry Studio along with other zone development tools.

It has been a busy year juggling work and other responsibilities, Infantry 1 needs and of course Infantry 2 needs as well. I've worked on the project on/off but as time goes I have ramped up the work on the project.

Last few months have been fairly productive for Infantry 2, here's whats up:

A cornerstone of this project is seeing the community come together, and I would like to start off by thanking all of you for being very supportive of the goals behind this project and supportive of me. This post brings the project close to the one year mark - give or take a month since I launched into the coding spree, having written the introductory posts on network programming and the like.

As time went on I have handed out more registration codes so people can have a look at what I've been up to. I haven't yet decided when I will be making the website fully public, but we're still aways off.

Here is a short and sweet update of what I have been working on over the last couple of months, along with a screenshot and a sigh of relief that it's all coming together:

Wrapping this up - this post has been a mixture of content within Technical Release 1 as well as bits of Technical Release 2. I have in mind to set up a Build/CI Server so that I can start releasing up-to-date game client executables to get some feedback from people.

Reminder: if you haven't filled out your Display Name in the Profile page, please do so.

As always, feel free to reach out to me on the discussion board if you have any questions or comments.

I have updated the Development page so that from here on out it's grabbing the work lists from our Trello board. Before, I had to manually update the two and they were never in sync. So that's one less thing to worry about on the website and managerial front.

The website is mostly at a point where I would have imagined it would be for the first release, and Arbiter is somewhat stable (odd bugs notwithstanding) and the core functionality of it is in place. I will be shifting the bulk of my focus onto Technical Release 1. Technical Releases bridge the quiet gaps of time prior to milestone releases, and I would like to get a client out as quickly as possible and build on it from there.

As always, feel free to reach out to me on the discussion board if you have any questions or comments.

My CDN and website encryption provider Cloudflare has finally brought in WebSocket protocol support. When I first started implementing the chat functionality within Arbiter, I had to put a hold on integrating it with the website because of this restriction – although I figured that eventually CF would support the protocol.

Website Development

With that in place, I went ahead and implemented the chat functionality that you hopefully see at the bottom of your screen. You can join channels and chat with other people using the same network that in-game players will be using, so the chat inside and outside of the game is one and the same.

The usual channel that I join is global. But you are welcome to make your own channel.

One of the things early on that I wanted to get into the chat system was the concept of having different kinds of hyperlinks, and to make them clickable. So when someone sends you a website address, you can click on it to open your browser. When someone mentions a channel, you can click on it to join, and lastly, when someone mentions another person, you can click on them to see their profile and add them to your friends list.

As for the rest of the website, Amazon Web Services (AWS) granted me some huge email quota and allowed me to send email to anyone, so I have put in the Forgot Password functionality that allows you to reset your password.

Your Profile page now shows your country flag! In addition to displaying the country flag next to player names, my long-term goal is to geographically list zones so that people can do region filtering and find zones (and arenas) with lowest latency.

I looked into the possibility of also getting VOIP working over the website with people in the game. I will park it for now as Chrome's support for the codec that I am hoping to use for VOIP is buggy and incomplete. Firefox seems to have it working but I have not tried it out yet.

Last but not least, because of the changes made to accomodate the chat system, the website should be a tad faster.

Live Streaming Coding Sessions

One of the things I have wanted to explore was the possibility of streaming coding sessions, and see the feedback that people have on these. What would they like to see more of or less of, et cetera. Although the work load doesn't change, I can choose to stream doing website coding, server coding, game coding, photoshop work, 3d work, et cetera.

Here are the three coding sessions that I have recorded this month, mostly working on in-game UI elements and of course the chat system you now see on the website.

• In-Game Chat UI - Session 1 - July 3rd
• In-Game Chat UI - Session 2 - July 3rd
• Website Chat UI - Session 3 - July 10th

I will be integrating this more closely into the website so if you stumble upon me coding you can drop in and say hi.

Other Happenings

In the world of Infantry 1, I went ahead and implemented a new, hopefully more catchy home page for freeinfantry.com. District will be finalizing some of the content around FAQ.

Mizzouse has been busy working on an updated Infantry Map Editor and an updated Launcher as well.

It's been two months since the last update and things have been quiet. Here's what's been up:

1. My main Infantry-oriented focus has been on getting better with 3D modeling tools to get a good workflow going for asset creation, looking at what's out there and making it work for the game with minimal friction.

   Just as a reminder: the goal is not to be next-gen, but decent-gen with all the bells and whistles. The current trend is to go with Physically-Based Rendering; I am holding off on that in favour of getting something out quickly that I am more familiar with and people can work with quickly.

2. The foundation for the mesh editor is being worked on. I had spoken to Mizzouse to see if he is interested in working on it but he has more pressing things to do ☺. This editor bridges the gap between a 3D modeling suite and the game, as it allows you to add game-specific data to the model.

3. I helped with a medical hardware-based startup, this took up a significant portion of my time but the majority of my work, for the time being, is done.

Infantry the Game vs. Infantry the World Builder

A subject came up recently on the uslzone.com forums, in particular on attracting a new audience of people to Infantry.

The project I am working on is not the first Infantry remake, and it's not the only one currently under way and possibly not the last. If there is one recurring scenario that I can draw a lesson from about the projects that I have seen so far, it's that it has to do with a hard decision of whether Infantry Online is just a game or a framework for world building. It's fair to say that one of the pivotal reasons why these projects have failed is they have not clearly defined where they lie on this spectrum, and in certain cases the team members are polarized to different ends of the spectrum. Difficult technical decisions have to be made from this as well that have impact on the audience (ie. simplifications have concenquences on the audience you attract/deter.)

Infantry The Game concerns itself with the gameplay aspect of the Collective Military vs. Titan Militia war. There are load-outs and store-purchasable items, and the two sides are identical in gameplay and tactical approach. Barring map asymmetry, the players themselves are mirrored.

Infantry The World Builder provides a framework under which Infantry The Game can exist: the player sees the game through a camera, and experiences the game through a set of a rigidly defined rules of how objects behave and interact with eachother. The relation between their input and the change in the game world. Items have properties by which they can affect objects in certain ways, and so on.

For a lot of developers, myself included, this is a difficult line to walk. In reading old patch notes that Jeff Petersen had written for the very early stages of the game, he also had to make these choices. Over time, the game evolved into the framework that we know today, but it did not start out that way. A number of early maps that the game had no longer work. They were discontinued because of framework changes that subsequently could not be rolled back into the zones.

I bring this topic up because the discussions we've been having are rooted in determining what should be included in Infantry 2, and what shouldn't be — and I think this is very much related to the Game vs. Framework nature of Infantry. As always, I am listening to people's suggestions - Axidus and STAS have contributed far too many good points in this regard and I do want to implement some of the (less batshit-crazy) suggestions that work to Infantry's advantages.

It's unfortunate that the Subspace/Continuum and Infantry are two split communities with a hint of dislike for eachother, because both games are based on the same framework. This, along with just keeping things simple at first, is the reason behind my decision to start with a Subspace zone. I will roll it into the over all storyline of Collectives vs. Titans down the line.

Wrapping up — In the next few updates, I want to get a playable prototype out and some screenshots.

Basic physics simulation is in place – it's frame-rate independent running on it's own timer, and can take the accelerations I throw at it, updating the velocities and in turn updating the positions of objects. The way it's written ends up reporting a set of collisions each frame so that the event handlers can kick in and take care of what needs to be done on these events.

With simulator in place, the recent discussion on items prompted me to shift temporarily to focus on the item and vehicle editors. So I'll jump right in.

Infantry Studio: Item Editor

For awhile now I had in mind to explore a different, more direct way of expressing intent when creating the item logic. The original Infantry editors have many different types of items but they generally do one of these two things: apply effect and create thing. For the most part, that's it.

I decided to use an approach where there is one unified item structure, and it exposes hooks into various events around that item where effects and create can be applied. An example of an Item Event is when it's used (or activated, if it's toggled). Another example is when a Projectile collides with something. You can see how this ties into the physics simulation.

Here are a few screenshots of the item editor. It's a work in progress as always but should give you a good idea of what it's about:

This approach casts away the superficial differences between a Stimpack item and a Carapace Armor item – they are both effects that alter an attribute of the vehicle (Hit Points, Damage Resistance respectively) once the On Use/Activate event is fired. Similarly, when a projectile is within the proximity of a particular vehicle, it fires the On Impact event which applies an effect.

The reason why projectiles get their own definitions rather than be directly expressed inside of the item event is so that one projectile can reference another, which in turn can reference another, and so on. This is also true for items - as you can Create or Remove Items on events. So you get Multi-Item and Item Maker in one.

At a later time, I will discuss repulsion and how they are tied into force fields. Force fields can be used to repel, shield, slow down, heal and apply other effects within a sphere.

Infantry Studio: Vehicle Editor

The Vehicle editor has for the most part stayed the same. I have removed the Computer Vehicles and am just calling them Computers. Their abilities are also expressed via the item editor.

In Closing

I'm looking forward to the feedback on the new editors, in particular the item editor. I think the new approach is more flexible while providing the ability to quickly model the existing Infantry Online 1 item rules.

I haven't discussed the Graphics tab at all – I will reserve that one for a later time because it will be tied into the 3d modeling pipeline.

The focus for the last week and a half was on fleshing out the details around how the modeling, texturing and mapping processes would work. I did a bit of modeling, a bit of texturing, and a bit of coding. It's scatterbrained in a way but critical to making sure things end up working together before any serious time is invested into the content itself. As such, you wouldn't want to see more boxes, walls, barrels and towers that I made and textured for the sake of getting some content in there.

3D Asset Pipeline

In a 3d modeling/sculpting application, the usual approach is to center-align whatever it is you are working on, and your vertices extend in every direction. Games have their own set of rules, however. Because the map editor has a grid that you can adjust and snap objects to, I decided that the approach to integrating this with 3d packages is to place the origin pivot in the bottom corner of the mesh, and all the vertices of the mesh would extend in the <+x, +y, +z> direction.

For vehicles, the likely place will be at the bottom center since we generally treat a player's position to be at the center of them. Using the foot pivot means we can always place them on the ground without having to think about how high they are and calculating an offset from a different origin.

The intermediate file format used is FBX. A lot of 3d software out there supports it and from a programming stand-point it's not too bad. It has recently been adopted full-on by Epic for Unreal 4, and Unity has had support for awhile now. Looking back, it turned out to be a favourable decision to focus early on in the development on having a small utility program that can take FBX – a really complex file format – and output our own War Angels format, which by comparison is fairly light and contains the mesh, textures, animations as well as game-specific data (I'll talk about this data another time).

The formats for War Angels are mostly binary but the specifications will be open. I am using a container format called protobuf that allows you to write the specification in a straight-forward way, and then output the files for a variety of languages (C++, Python, C#, etc). I made this decision early on so that people can eventually write their own tooling on top of ours, hence the game having a 3d file format that can be integrated seamlessly with their tools.

Continuing Work

With the pipeline looking reasonable, I am back to working on the game. My first focus is on getting a physics simulation working ASAP. While I have some existing physics code in there it's nowhere near up and running. I will have to recall some of the work I did for War Angels. The brunt of the work will be on the architectural portion of things, because while the bare-bones simulation – commonly referred to as the integrator – is easy to get up and running, the real effort is in structuring the code so that adding the features of Infantry, all the various hook points and places where a developer can insert pre-conditions, post-conditions and event logic, is as painless from my perspective as possible. And hopefully yours.

In closing notes, I have updated the Development page with the work that is to be done. Also, STAS and Axidus are tearing up the discussion forums with notes from Combined Arms.

Last week one of the things I focused on was building out the War Angels editor.

Infantry Studio combines the tools of Infantry Online – map, vehicle, .LIO, item and skill editors – under one program with seamless integration between them. I had to make the choice between having one editor that takes care of many things, or a handful of small editors that handle their own isolated parts. In the end, I went with having one large editor that handles the map components seamlessly.

As mentioned, the editor has the tooling of Infantry Online. The Vehicles, Items, Skills and Classes panels make up for a good portion of the editing capability. However, there is lots more. The only way to show is through screenshots, and some descriptions for what isn't there (but is coming!)

In other news

I have been busy working out some art direction decisions and the visual identity behind the Subspace zone and War Angels in general. To this end, I have uploaded a Star Map to the Media page. Terra ("New Earth" in Collective's power) is not yet on there, but will be soon.

Last but not least, STAS has joined the forums and weighs in on the work him, Ryanbe, dangerz and LooseCannon did for Infantry Online 1.

To wrap this post up, when you open up the map editor and the assets are being loaded, a splash screen is showed with a 2001: A Space Oddyssey inspired quote:

Finally got around to putting the Storyline up. Have a read, let me know what you think.

Armor asked what the roadmap for development looks like. I ended up going overboard with details in this post.

Site registrations are now in place. I have sent out registration codes to a few people to start inviting others.

Profile page is now up and running. Please set your Display Name to something, as it will be used in-game as well.

Long-term thinking for the profile page is to use it to manager your aliases, squads and display your stats.

Pages are starting to get filled in bit by bit. Media now contains the user interface concepts.

Hey everyone,

You're probably wondering what is this. So read on.

I have finally started work on this website proper. Previously I registered this website as an alternative to our main website at http://freeinfantry.org when it went down due to provider issues. It's here as a failover so that people could connect and play.

Going forward, this is the primary channel for development of War Angels.

The content for the individual sections is for the most part finished. I will be uploading it bit by bit over the week and will set up a Discussion Board for the group of players who are welcome to help test the game as we are developing it. If you can read this post, you are part of that group. Go on the discussion board and introduce yourself.

More long-form answers to some outstanding questions can be found over in the Q & A section. If you don't find a question there that is answered, feel free to post it in the discussion board and I will be answering.

Below you will find a few posts that have been written in late 2015 when I was first starting the project up. These posts should clear up some immediate things about the scope and overall plan for this project.

FreeInfantry.org continues to serve all your Infantry Online 1 needs.

Survival

It's hard to believe, but the Free Infantry project has survived beyond SOEs existence. Just yesterday, there were 90 players online and playing in USL. A handful more were lounging around in CTFPL. Looking back, it seemed unlikely that this project would come this far. There were times of complete drought in player population, where less than 10 people would log on and play for weeks at a time. This had been the state of things on SOE servers as well. Infantry had been proclaimed dead.

Turn of the Tide

The discussion of making a new Infantry client never seems to settle down. There is always a small group of people discussing it on the forum, IRC channel orin the game zones. There is always a flurry of ideas.

I cannot, and will not, make promises. It would be a huge lie to proclaim that we are going to spring a client up from nowhere and modernize the game in a short period of time. The journey is not the destination, and the outcome may not be what was originally intended and hoped for. Existing attempts to bring Infantry to 2015 standards have been futile because there is a huge amount of importance placed on a contradictive "vision"; a loose set of goals that is barred by a lack of clarity, unity, and the focus required to get things done. This is where, I believe, the words "writing a New Client" come from, along with other unnecessary baggage that it entails.

There are no hard-defined boundaries by which development can progress. Developers doom themselves this way all the time. I try to avoid this and do things bit by bit instead.

How can we do better?

Firstly, there is no great vision behind this. Mizzouse and myself are just scratching an itch, pecking between the gaps of what Infantry is.

There are no gameplay changes. Infantry plays fine the way it is right now. A transition from sprite-based to 3D assets will incur some changes in terms of the perceived "feel" of the game, but this is negligible.

Mizzouse is most interested in writing the networking layers. The work he has done on Free Infantry has enticed him to pursue this path deeper. I would like to create a visual identity for the game using the storyline as a kind of template to work off of. I believe that the various pieces of lore Infantry has embedded are a good place to start.

Both of us will be working on bits and pieces to make the game come to life.

There is no great plan to get zones of 100, 200, 400 people playing yet. Chances are, a number of fatal issues will be found with a handful of players that would sink the server with more players. So it's impractical to aim that big to begin with anyway.

Community

The community remains at the fore-front, as always. And I don't just mean this in the community of players; I also mean the people that are responsible for developing the content for the zones. One of the vital aspects of Infantry to me has been the community-based effort. We made the game we wanted to play. The zones that you play today were, in most part, made by the people in the community. People you play with.

Current FreeInfantry Network Model

We currently have a set up that is as follows:

1. You download the launcher.
2. You run the launcher, and it updates all of your files.
3. You create an account, or login with an existing account.
4. You run the game and see the list of zones.
5. You join a zone and play in an arena.

Steps 1-4 have nothing to do with step 5. Steps 1-4 are the things that we had to write ourselves. All the account management code, the game updating logic, and even the directory server, are done as little "servlets" that we hooked up to work together. This forms the backbone of FreeInfantry.

I have made concious decisions when I wrote the account server and the autoupdater. Respectively, they are:

1. Account server should work through HTTP, and should use standard HTTP verbs. This would allow a web server to communicate with the account server if anyone wished to register and log in on a website, and then using that same username and password, play the game. Essentially, I wanted to find a protocol that unified account management in an easy way. HTTP let me do that. You see this nowadays more often - Steam, Battle.net, Origin, and so on and so forth.

   One thing that has been paid attention to is to never store the passwords in plaintext on the server. They are always encrypted. The downside is that we can't retrieve your password - we reset it for you.

2. Autoupdater's protocol is also HTTP based. The reason why is HTTP based is because it is a 1:1 copy of the SOE autoupdater. Shortly before SOE closed their doors and discontinued the "Station Launcher", I opened up Wireshark and took a look at how it works. The reason for doing this, at the time, was because there was still a bit of distrust over Free Infantry. Many years ago, there were rumours about how FI was stealing people's credit cards.

To help lift things up a bit, I looked for a way to allow people to use their existing files, including Infantry.exe. To go a step further, I used SOE's own network endpoint to fetch the files. It was only when SOE shut down the Station Launcher that I enabled our own endpoint to get the files.

The protocol stayed the same.

Moving Forward

On a technical level, good and bad decisions were made. I have learned some things over the last few years that I would like to incorporate into a new design that I hope will work with Infantry 2. The "master server" will be evolved to encompass more, and here is the feature set that I have in mind.

1. Accounts: Both accounts and aliases are no longer associated with any zone in particular. Zones will have no deep, direct knowledge of accounts. They will merely work with an opaque account signature that they can get a small subset of data from. The reason for this will become evident shortly.

2. Squads: Squads are now a thing. When a squad is created, a squad-only channel is created. Squad memberships are a thing.

3. Chat system: All player-to-player communication is zone-independent. Zones and individual arenas are able to register a channel. Players are also able to register a channel. Zones have no knowledge, and no data is sent through a zone.

4. Launcher: There is no longer a launcher. Once you start the game, the game will autoupdate itself. A separate stand-alone program is used to update the main exe, but it is only executed when the executable needs to be updated.

5. Zones: Because zones have very little knowledge of player data, they can be hosted independently. Some zones have "privilege escalation" in that they are officially supported and officially hosted, which means that we authorize them to write details back to the central database for ranking purposes. Free-form zones do not get this. However, they can still hook into the Directory Server. Each zone has a "key" that it uses to authorize itself with the central server.

Example

Let's take a look at how this works from a case perspective: when a player joins a zone.

1. The player sees a list of zones. This list is obtained from the directory server. Zones are marked with either "Official" or "Player Hosted" next to them.

2. The player clicks on a zone to join. The server performs a series of checks to make sure that the player is allowed to join. The server then sends a token to the zone. This token represents the player on that zone. The server also sends this token to the player.

3. The player now starts to establish communication with the zone. Providing the token, the player is authorized to play and joins the zone.

Any stats that have to be written about the player are done so through this token. The zone server has very little knowledge about player data - they can request information about them for this particular zone, and the alias used (for display purposes). The zone writes information back about the player for this zone using the token.

Once a player leaves the zone, the token is discarded by the server.

Wrapping Up

We are moving into a hopefully better direction with this approach to networking. We call this centralized server the "Arbiter".

Because of the ability of a zone to be free-standing, the concept of chatrooms and channels is completely disconnected from them. Channels like private messages, squad and other chatrooms should be able to exist without needing zones. We will reveal bit by bit what other niceties this brings us as we implement them.

Both Mizz and myself have a thing for network programming. Infantry Online has lots of network-related code.

I have been meaning to write on this subject for awhile, firstly because networking is generally a topic that is discussed in a shallow way. The focus is predominantly on the ingame network protocol, which these days makes up for a fraction of the overall network code.

Indeed, the usual gameplay netcode is pithy. It is nonetheless often plagued by complexities that are required by the real-time nature of most games. Which brings me to the second reason why I wanted to write this: I wanted to discuss some of the upsides and downsides of the way that Infantry's ingame network code works with the game.

I'll start with this subject first, and then talk about other networking code later on.

Infantry's best network-related choices also happen to be some of it's worst. This has nothing to do with sloppy or inept programming. It is not a bug. You see this come up in other games all the time, but it is not really discussed in depth outside of select circles. You see a YouTube video of someone showing how terrible Battlefield's netcode is, showing how someone won't die, or someone being killed by a laggy player or some such. "EA Sucks!". You may also see this with Counter-Strike, PlanetSide 2, and a number of console games.

You have probably played Infantry and tossed a grenade, and while it goes "over" the opponent and keeps rolling, they still die. A moment of anxhiety where you thought you missed someone turns out that it was actually a hit.

But think about it - shouldn't that grenade have exploded on the opponent, instead of just continuing to live and explode elsewhere?

The reason why that opponent died is because of a concept of "fairness" in multiplayer games. These are unwritten rules that run contrary to what FPS "client-server" games usually do - and what most players are used to. FPS games in general have a central server that simulates and determines through the simulation who killed who, and broadcasts this information to all clients.

The downside of this usual FPS model is the players need to compensate for the delay of messaging between themselves and the server, and the other clients and the server. This compensation is why you have to "lead" a target in multiplayer games to properly kill them. The shot needs to "register on the server". Quake and the related games have a small sound that plays whenever you shoot that rings out whether the server acknowledged your shot as a proper hit.

The downside of this approach is that some players have a better connection, and some players have a worse connection. This is where a sense of unfairness comes from. The players with better network connections will win over the players with worse connections because they don't have to monkey around with the lag and leading their shots and a host of other oddities.

There is a way to level out the playing field - and that is to allow the client to say when they have hit someone, and when they have been hit. This allows a player with a worse connection to point at an opponent and get a hit, as if they were playing locally.

The downside of this is obvious: this allows clients to cheat. It also means that you may think you are safe, and a moment later you will get a message saying you died to an invisible opponent. From his point of view, he saw you and he shot you.

Games try to mitigate this by being selective about what the client is in charge of. Infantry's clients are in charge of their own health and energy, only. Even if you see that you hit someone, if they were not hit on their machine, their health and energy remain the same.

Which brings me back to the example up there with the grenade. We did not see the grenade hit the opponent, but the opponent saw themselves get hit on their machine, and so they died and sent a message saying they died.

Unfortunately, the flip side to what Infantry does is that when you have a player who is lagging, you will shoot them and you will not get a single hit. Because on their machine, they are not being hit.

Arbitration

A way to overcome this is to let all clients that are present to an event - such as a projectile hitting an opponent - inform the server of what they saw. The server can then work with this information to deduce that an opponent should be dead by now, and proceed to mark them as dead. This is typically called "arbitration".

Arbitration isn't exact; the information is speculative at best, but it helps to determine if something could have potentially happened by cross-referencing the times and distances that the event occured on each involved client.

Wrapping Up

This sums up about the majority of Infantry's game client to zone server networking architecture. In the next part, I'll discuss the master server that is responsible for accounts, chat, squads, updates and other things.