Today I deployed a new iteration of Catastrophe X that enables player ratings, completing phase five of the accounts project. Ratings are shown next to display names throughout (most of) the game, and reflect your past performance in battle. More details about how ratings work are available in the nascent game help section.
My next priority is to create a live list of the game's top-rated players -- more on that soon!
Saturday, January 28, 2012
Tuesday, January 24, 2012
Battle Histories are Here
Today I deployed a new iteration of Catastrophe X that enables battle histories. When a battle is completed, each player receives a new entry summarizing their performance in both their headquarters and their profile. The system also reports players' all-time total victories, defeats, and surrenders on their profiles and in their headquarters. As with the rest of the game, all updates occurs in real-time so you never need to refresh anything.
My next priority is to put together a rating system that aggregates each player's battle history into a single number. More soon!
My next priority is to put together a rating system that aggregates each player's battle history into a single number. More soon!
Saturday, January 21, 2012
Player Profiles are Here
Today I deployed phase three of the accounts project, which enables player profiles. Throughout the game you can now click on a player's display name to open their profile. Profiles display basic player statistics, as well as real-time battle and upcoming battle activity.
With today's deployment I have also added a basic introduction page that shows the latest blog post and some information about how to get started. Down the road I will add player rankings as well as more in-depth help features.
I have also continued to roll out the new framework behind the scenes, and it is now fully in place on the hub. While I was there, I also made a variety of small improvements throughout the hub.
My next priority is to start recording each account's battle history to form the basis of player rankings. In anticipation of this feature, I have left space for battle histories on both your headquarters and on player profiles.
More soon!
With today's deployment I have also added a basic introduction page that shows the latest blog post and some information about how to get started. Down the road I will add player rankings as well as more in-depth help features.
I have also continued to roll out the new framework behind the scenes, and it is now fully in place on the hub. While I was there, I also made a variety of small improvements throughout the hub.
My next priority is to start recording each account's battle history to form the basis of player rankings. In anticipation of this feature, I have left space for battle histories on both your headquarters and on player profiles.
More soon!
Tuesday, January 10, 2012
New Framework and Chrome Connectivity Issues
It has been a while since my last post, but development of Catastrophe X has been moving ahead at a healthy pace. Today I deployed my most recent iteration, which fixes a connectivity issue that arose in new versions of Chrome, and implements some core changes that will allow me to develop features more quickly going forward. More on that...
In my last post I announced that developing basic user profiles would be my next priority. However, after delving into the project I realized that my underlying framework for client-server communication was flawed. The issue was that whenever a player performed an action, the server was responsible for determining which other players needed to know about the action. This meant that each new feature would make it more difficult to determine which players needed to know about each action, which would increasingly complicate development.
The game's color-coded display name printouts (red = offline, white = online) illustrate the problem well. Under the old framework, when a player went offline the server would scan through that player's ongoing and upcoming battles to determine who needed to be notified. Since I plan on showing display names in many different places thoughout the game in the future (profiles, rankings, private chats, friend/enemy lists, and so on), this calculation would become increasingly burdensome, both to code and to execute.
My solution was to flip things around let the clients tell the server which actions they care about. Now when a player goes offline, the server just notifies all the clients that indicated an interest in that information -- it doesn't need to look at which battles the player is in, for example. This approach will make it easier for me to develop more complex features, reduce server load, and enable user-customized interfaces because each client can receive updates about whatever it wants.
Of course, changing this now is like trying to change the foundation of a house after the walls have been built. Many thousands of lines of code rely on the old framework, and it would take a month or more of uninterrupted work to update everything. Since I am not willing to stop feature development for that long, I have configured the new framework to temporarily run in parallel with the old one. I will immediately start building new features using the new framework while I update existing components gradually.
From a player perspective, today's game looks essentially the same as yesterday's. However, behind the scenes today's deployment will enable me to create new features at a significantly faster pace. I am now off and running on player profiles.
More soon!
In my last post I announced that developing basic user profiles would be my next priority. However, after delving into the project I realized that my underlying framework for client-server communication was flawed. The issue was that whenever a player performed an action, the server was responsible for determining which other players needed to know about the action. This meant that each new feature would make it more difficult to determine which players needed to know about each action, which would increasingly complicate development.
The game's color-coded display name printouts (red = offline, white = online) illustrate the problem well. Under the old framework, when a player went offline the server would scan through that player's ongoing and upcoming battles to determine who needed to be notified. Since I plan on showing display names in many different places thoughout the game in the future (profiles, rankings, private chats, friend/enemy lists, and so on), this calculation would become increasingly burdensome, both to code and to execute.
My solution was to flip things around let the clients tell the server which actions they care about. Now when a player goes offline, the server just notifies all the clients that indicated an interest in that information -- it doesn't need to look at which battles the player is in, for example. This approach will make it easier for me to develop more complex features, reduce server load, and enable user-customized interfaces because each client can receive updates about whatever it wants.
Of course, changing this now is like trying to change the foundation of a house after the walls have been built. Many thousands of lines of code rely on the old framework, and it would take a month or more of uninterrupted work to update everything. Since I am not willing to stop feature development for that long, I have configured the new framework to temporarily run in parallel with the old one. I will immediately start building new features using the new framework while I update existing components gradually.
From a player perspective, today's game looks essentially the same as yesterday's. However, behind the scenes today's deployment will enable me to create new features at a significantly faster pace. I am now off and running on player profiles.
More soon!
Subscribe to:
Posts (Atom)