Site Banner

Back to the Blog page.

Proxy Soldier postmortem

Proxy Soldier Image

Proxy Soldier was the result of throwing 7 students with next to no game development experience into the fire and watch them as they try to survive the endless onslaught of deadlines and technical hurdles development comes with. To be fair, it's not as bad as I describe it to be, but saying it was difficult would be an understatement.

Like stated earlier, our game was named Proxy Soldier. It's an online first person shooter set in a future world where the only type of entertainment is watching robots kill each other, apparently. The game was made in the Unity engine by a team of 7 students in about 6 months of constant work.

On my part, my name is Anthony Duquette. I was one of the two programmers on the project, mostly taking care of the gameplay while the other programmer handled networking and shaders. We also had 2 artists, 2 designers who dabbled in other subjects and our project manager.

Now, this whole postmortem will be from a super biased point of view of someone who never actually brought a project to completion. Some of the mistakes might be obvious to some, but we seriously wished we knew about them sooner.

What went right

1. Graphical quality

If I have to give props to people here, I would give them to our primary art team. Moe and Jess, our two main artists, managed to breathe life into what seemed like an artificial world and delivered when it came to anything art related.

By the end of the project, we had 7 unique weapons, a humongous detailed level and a heavily animated character. The result was quite impressive considering that, like the programmers, our art team was composed of only 2 artists, with some small props modeling help from everyone else.

The other impressive part is that we managed to keep our game true to the original art bible we drafted in the early weeks of the project. We could have easily strayed away from it and try something different, but we decided against it. That simple fact allowed us to save a lot of time in graphical design decisions.

2. Productivity

We knew that, if we wanted to make this project a success, we had to take drastic measures to make sure that we get to a presentable product in the small amount of time we had. The main decision was to take our teacher’s word to the letter and force a minimum work hour ethic where we had to do 20h every week minimum unless you had a valid reason. Even then, some of us managed to score 30h every other week.

This decision, which was often debated but never removed, allowed us to keep a steady stream of content flowing into our weekly builds. This was sometimes hard to keep since this minimum had to be kept during exam season and while we had homework piling up in the background.

3. Early programming progress

Something was clear from the very start : only two members of the team had enough programming passion and knowledge to carry on in that role the whole project. This meant that, in a programming-heavy project, we would need to practically do the work of 3 or 4 members as only two programmers.

On his side, he managed to get us a fully working networking system by the third week. I will go over in more details about that later in the post-mortem, but considering that we had a month to deliver our first prototype, we were glad that he managed to pull through like that.

On my side, I quickly came up with a weapon system that could satisfy our needs and more. Before this project, I touched Unity for about 1 month, which made this early part of our project a living nightmare. However, I didn’t want to let down my team and, for the prototype, all of the guns the team wanted to have was implemented in the project.

Same thing happened for our first release, which we had about 1 month and a half to create. We managed to get a playable build running over the network by the end of the second week. The new and improved weapon system was up by the middle of third week and we were able to “play” by the first month.

In hindsight, this might have been the golden age of the project. Everything changed when the networking attacked...

What went wrong

1. Technological scope

When we decided to work on this project in particular, our original design involved making a physics-based online first person shooter where you can throw objects like boxes over the network and have it reliably hit someone on the back of the head. This original idea made it so, in our oblivious beginnings, a lot of the game’s groundwork had to be designed with physics in mind.

From the start, we had to use a custom networking solution build over the Photon Networking SDK. In layman’s terms, we had to work using a handmade networking system, bringing tons of unforeseen bugs and issues that wouldn’t have happened if we decided to stick with the much simpler, but more limited, classic Photon system.

Considering that we only had 2 programmers and that the other programmer’s networking experience was based on books he read and a small game he made the year before using said classic Photon service, we realized that our endeavor might have been a bit too farfetched considering our resources. However, it was already too late. The game was too far in its development to make such a drastic change.

This also affected a lot of the development since the one thing that was often preventing us from playtesting more or from adding new things in the game was that the networking was simply not working. Even our official releases were filled with bugs, a large percentage coming from the networking. The technical scope was simply too large.

2. External influence

Fun fact, Proxy Soldier wasn’t our first idea for the project. It wasn’t even part of the first 3 idea we brought up to the teachers. Considering that over half of our team was really into environmental storytelling, that about the same amount really liked puzzle games and that one of our designer and I had experience in script writing, our original ideas were all story-focused with an emphasis on displaying stories in gameplay.

We were promptly rejected by the equivalent of our ‘producer’, being told that ‘the time we have is not enough to give such a game justice’ and ‘you can’t sell such a game at the trade shows we’re going to’. As a joke, we’ve decided to put an online first person shooter in our second round of ideas, the other programmer telling us that he wouldn’t mind diving further into networking. And behold, it was the idea chosen by our teacher.

You know you better than anyone else. Our first meeting was all about putting on the table what everyone liked, what we were good at and what we could do to help the project move forward. When we were shot down for our ideas, we knew we could go against our 'producer's' will and push our ideas forward, but we decided to take his more experienced advice and go with the game only one of us wanted to do. We knew we could make our original idea work, but we still went with it.

Now, at the end of everything, we kept telling to each other how we could have made the original idea work. How this game was made more as a teacher-pleaser than a game we actually enjoy working on. All I took from this part of the experience is that, sometimes, having experience doesn’t translate 1 for 1 to being completely right.

3. Mismanagement and dynamics

During our first two years in the program, we’ve been told how the job of project manager was the most important in the team. About how the one who gets the role must dedicate most, if not all, of his hours on managing the team and dealing with problems that has or will arise as time goes on. Now, we heard the plea and decided to place someone who wanted to be manager in the role, stating that, if you want to do it, you should be able to do a good job.

Sadly, we were mistaken. Our manager’s lax attitude, uncertainty about the smallest things and general passive-aggressive behaviour ended up causing more problems than solving them. Even simple ideas like writing a general description of what has been talked in the meeting was done poorly, turning an important conversation about some design decisions into ‘Talked about design stuff, again.’ I remember missing one meeting due to an appointment and having to go over what happened with my teammates due to the write-up being filled with less-than-helpful quips.

This issue with management lead to a lot of problems regarding team dynamics. Without a middleman to help us reach a decision, simple discussions would quickly turn into debates. This would cause situations where cliques would form in the team, with one side believing that they have the superior ideas over the other. This, mixed with the general aggressive attitude of certain group members, would make decision-making the most stressful activity to even happen.

In the end, I will state this : I am not perfect in this story. Even if I tried my best to stay out of the internal drama, it is hard to stay neutral when you’re surrounded by it every day. In hindsight, most of our issues stems from our inexperience. Whether it be our lack of judgement over our own skills, our ease of sway over anything we’re being told or our lack of knowledge over certain tasks we must do as the role we’ve been given, anything comes down to the fact that it was our first project.

I won’t say I liked the experience as a representation of my future. In fact, I do believe this project was an example of a worst case scenario in the realm of game development. However, saying I didn’t learn anything from it would be completely wrong. Every mistake I made or I saw being made is a lesson I got to learn and, after all this, I can say I learned a lot. All I have to do now is to take these lessons and use them to push a project I will like to work on to its completion.

Copyright © Anthony Duquette 2018. All Rights Reserved.