Alpha Post-Mortem - CoSigners

Time slips through my fingers so fast that the semester ends before I even realize it. If there is one thing that I wish I could get more from this semester, it’s time. However, no matter how busy I am, Co-Signers has always been my prime focus, and that’s probably why I’m hunted by other projects at the end of the semester. But on the other hand, I did learn a lot through this craziness.

Anyway, let’s cut to the case.

What did I contribute?

Since there is a lot, I’ll divide them into three parts: prototype, alpha and overall.

Prototype

·        Networking: Start interface, Player Connection Building, Chat Window & Server Register

      This was done on the first week of starting of the project development. I chose to finish this first because all of us were worried about whether we could pull this off or not since it’s a pretty ambitious project. Some even suggested that we finish the two ends first then worry about the communication. I knew that if we did that, the networking would haunt us for the whole prototyping process. So I did my research on Unity networking, figured out how to register on remote server and pass data through different network instances, made a game starting interface for networking that are still using in the alpha build.

Even it’s just one week, but the completion of networking showed the whole team that we could do this, which cheers up everyone without me saying one word. And this brings every member into the “development mode”, which in my opinion means far more than the task itself. I consider this one of my favorite moments of this semester.

·         Hacker: Node (& Graph) System

The first “real task” I have in this project, which is the core of the entire game, since most of the systems are built upon this system (or at least related).

This one is a result of teamwork, we had a “little challenge” when building this system: Since two nodes are connected on both ends, we are dealing with an un-directional graph; but we do need to know whether each node is connected to the source node when releasing a node, so there is “direction” in that graph. How to build a direction in an un-directional graph? Chris, Nikhil and I discussed this for a few days and came up with a solution, which is basically adding a marking mechanic on to the graph. Although I’m the one did all the “dirty work”, but I’m pretty happy with how this task is completed. And we had a habit of discussing tricky coding problems because of this, which benefits a lot to the team.   

·        Hacker: Node UI Logic & Timer

The Node UI was another thing that I spent many time on, although Chris was the one that actually made most of the UI, all those pretty little icons that you can click. The actual logic that controls what icon to show on what state, what kind of buttons to show when you click on a node and what happens to the node when you click the button is quite painful to implement, especially when there are nine states on each node and each node could have different types which means different icons and buttons to show based on those state.

The timer was the little bonus task that I gave to myself, it’s funny to see how people just get used to the look of it, considering the fact that we haven’t even discussed seriously about how the timer should look. I guess that’s my secret way of affecting game design.

·        Networking: Data Communication Between Two Players

Passing data from one player to another is not hard at all; there are a lot of ways to achieve that in Unity. What takes time is to find out the best way to get the things we want, by best I mean using least amount of data to synchronize the game. I always believe that in some future we’ll have to implement voice communication into our game, which would make the bandwidth of the network very precious. That’s why I took the time to do this, and I’m pretty happy with the result.

·        Point-men: Tracker bug & Camera bug on hacker’s side

I worked with Kiran on this because it concerns not only point-men but also hacker and network synchronization.

For the tracker bug, he made sure that the point-men is able to throw a tracker (&camera) bug onto the guard, and I made sure that there is an icon of the guard show-up on the hacker’s screen.  

For the camera bug, he made sure that there is a camera on the bug; I made sure that a camera icon is shown on hacker’s side when it’s thrown and it’s clickable and viewable.

·        Point-men: Door on hacker’s side

Who knows a door open/close/lock function could be so annoying to implement?

I worked with Vaibhav on this because it concerns not only point-men but also hacker and network synchronization. I made sure that the hacker can’t perform actions on an opened door, door states’ synchronization through the network and the door’s UI on the hacker’s side. Vaibhav did the rest, including door’s animation and the actual state change.

·        The Game: Control-Panel & Objective System

The control-panel is an easy task; basically it’s just a collider in the point-men’s world which turns a normal node of the hacker to a source node. I added the objective system myself because there is pretty much no goal for the hacker and point-men by the time we want to play test our prototype.

Alpha

·        The Game: Re-architect the networking interface, node system, UI system & Timer

One of the main differences between a prototype and a real game is how organized and flexible your code is. That’s why we spent about two weeks re-architect the game. We had our discussion through the whole team, between individuals. A few major changes were made on networking, UI and Guard AI. I've spent most time re-factory the networking interface and the UI system. The communications between two players has now been integrated into one interface class, which has made it much easier to debug and handle. And the UI has now been separated from the node system, which makes it easier to manage the UI changes on nodes.

I consider this the greatest success of the alpha because this is the result of collaboration of the whole team and this is what brings the new teammates “into the team”.

·        The Game: Jammed State to The Doors & Door Indicators &gray out buttons when it is opened

Apparently the door has become a main thing in our game, which is sad, but necessary, since this is the most apparent way to make two players communicate. We had a team discussion on how the door should behave on hacker, point-men and guards’ actions and came up with this design change. The actual task is simple, which only took me about two hours to finish.

                                    

·        Hacker: New State To the Node – “Inactive”

The hacker is known to be too hard and overwhelming, partly because of the security system, another part is that when a node gets released, the whole branch goes dark and you have to recapture all of them again. That’s why we added a new state to the node “inactive”  so that the branch could be re-captured automatically when the hacker get back the released node. I implemented this after a discussion with Nikhil.  And I’m still worried about whether this would make the hacker too easy or not.

·        Hacker: Power-off node

I did this one with Vaibhav, I did the hacker part, Vaibhav did the point-men part.

A new feature that makes the hacker collaborate with the point-men, it’s kind of like the control-panel. The difference is that the hacker can’t actually capture this node unless the point-men activate the power panel.

·        Hacker: IR node functionality & IR radius UI

I did this one with Kiran and Chris. Kiran finished the system that calculate whether a guard is in the IR radius or not; Chris made sure that each IR node could have its own radius and I did the node logic on the hacker’s part, implemented the creation of an actual “radius” image when the player captures the node and the play/display of the guard’s icon on hacker’s map.

Personally I like this node function, but there is a concern that the IR is so over power that it may make the camera useless, which is the thing that we really want to keep in the game.

·        Hacker: EMP node functionality & EMP Wave

I did this one with Vaibhav. He worked on the whole functionality and I made sure that the EMP reflected correctly on the node system. I also handled the creation of the “EMP wave” image on the hacker map and disabled the click ability of hacker on any of the “EMPed” node during the EMP duration.

·        Hacker: Tutorial Cues

This is just a GUI thing that I did in 20 minutes on the hacker map for the play-testing on the open house. Doesn’t seem to help that much.

Overall

As you can see, I contribute a lot on this project. For the whole semester, I’ve been doing everything I can either on the team or on the tasks to move the project forward as fast as possible. It’s safe to say that I know most of the code in the game, which makes me a great asset on debugging (and believe me when I say we spent a lot of time on this). And because of that, I become the “go-to guy” when someone had a problem with Unity or the code. Overall, I’m pretty happy with what I did this semester and my role in this team.

What would I do different?

There are so much stuff going on this semester, things got so crazy and intertwined together that I was so close to lose track of everything. So if there is anything that I want to change, the first thing would be to keep things more organized.

With that being said, I’m very satisfied with everything I’ve done and learned this semester. So there is nothing that I want to change on that regard.

However, team and game wise, there are things that could have been done differently. At the end of the alpha, there are a few left over bugs that occurred on the play-testing mainly because we treat part of our implementation with “let’s do this for now and change it later, as long as it works” attitude. We kind of keep our eyes closed on that since everybody is so busy and we don’t want to be too harsh on anybody. And that’s the wrong way of doing things since we are professionals, or at least we are learning to be.

On the game side, since the development cycle is so short (one month for prototype and one month for alpha, during which there are tons of other work to do), we hardly have any time to spare on play testing and iterating process. Which made us went a little astray from thinking on the player’s perspective. We added a few new features that we thought could solve the point-men have no influence on the hacker issue. But we neglected the fundamental issue that there is still nothing much to do for the point-men, I mean EMP and power-off panel are great features, but they are still the things that the point-men can do FOR the hacker, what’s the fun for the point-men? The candy is a potential fun element but we can’t know for sure since it’s a suicide weapon right now as it’ll attract the guards from half of the map when you throw it. The thing is, the point-men must be able to improvise and we have to create the “thrill” for both the point-men and the hacker. This should be the top thing on our to-do list and I really regret the fact that we couldn’t do this earlier.

What did I learn?

Ø  Communication is the key.

We had a lot of conversations inside our team (besides stand-up), it becomes a habit for us to talk about the game and the programming after lunch on Tuesday and Thursday, which is really helpful, not only to figure out solutions for certain problems, but also to know what everybody is doing and what’s new on game design. 

Ø  Keep an open mind, listen to other’s suggestion, they have values.

We all hate people that do not listen, I sometimes do it myself. But yes, hear what they have to say, there are many cases that someone’s suggestion really helped me.

Ø  How to multi-task

You really have to figure that out when you have more than four projects to do every week. Since it takes time for me to get “in the zone”, I always evaluate how much time each project needs and set different schedules for each project and focus only on that during that time period. I also left some schedule open in case I didn’t finish one of them in time, which does happen from time to time.

Ø  It’s nice to help out others.

By nice I mean helpful to myself, sometimes I got to relive what I learned, sometimes I got to know how others do their stuff and what’s more fun than solving problems?

Ø  Keep it professional

We shouldn’t let our personal feelings get in the way of pushing forward our project. There are cases that I really want some tasks since they are challenging and interesting, chances are your team members would also be interested on these tasks. Sometimes it’s nice to let go if you already have a handful of stuff to do.

Ø  Always look at the future

This is regarding programming; when you design your system, you should really take into consider what could happen to that system, what functions that system should support in the future. It’s could make life a lot easier.

Ø  You never know what problems you game have until you play-test.

Especially on networking, things could be very different between playing along and playing on network.