I agree Our site saves small pieces of text information (cookies) on your device in order to authenticate logins, deliver better content and provide statistical analysis. You can adjust your browser settings to prevent our site from using cookies, but doing so will prevent some aspects of the site from functioning properly.
Our forums have been abuzz for the past month or so with speculation on the path that Goblinworks is taking to get from the Alpha Test to Early Enrollment. This blog is going to describe that roadmap in some detail. We believe that a fundamental tenant of Crowdforging is enabling the community to see "behind the curtain" and understand what we're doing on a short-term basis so that they can provide informed feedback for longer-term work.
We'd love to get your feedback on this blog, and your thoughts on the prioritization of the work we're doing. Please comment in this thread on the forums!
Concerned about a feature that is key to your enjoyment of the game that doesn't appear in this progress report? Feeling nervous that so much work needs to be done before Early Enrollment can begin? These are understandable worries. A lot of development teams keep this kind of information out of public view. We don't. We cannot. We committed to our community to provide as much information about what we're doing, why, when, and how as we can. We accept that the downside for that level of transparency is that we become vulnerable to those who focus on the negative. But we think we gain much much more from the trust that we're building by telling people exactly what the project status is and then following through on our commitments.
Software development can be scary as hell. Almost all big projects go over budget and miss deadlines. That is just the nature of working on technology outside the envelope. It's ok to be a little scared - that's part of the thrill of discovery.
We have always had a rough idea of what our "Minimum Viable Product" would need to have in terms of features and stability in order to transition out of Alpha and into Early Enrollment. That definition was by nature pretty fuzzy when Alpha began because we needed the Alpha process to help narrow down the areas we needed to focus on and to get feedback from the community to help direct the effort.
In October we moved our objectives to a fairly narrow band of features that emerged as a consensus from your input and our internal discussions. We've been working very hard to achieve a satisfactory level of completion on those features and functions. This blog is going to describe in some detail what is on that list.
We are not going to provide a comprehensive list of open issues. It would be too lengthy for a reasonably sized blog. Some of the things we're working on relate to system security and we don't want to talk about that stuff in public. Some items are just housekeeping related to our tools, our processes, or simple "fixes" to constant values in game mechanics that don't match the design plan. What we're sharing with you today are the features, fixes, and content that we consider the most interesting and useful to share with the community.
To reiterate: These are features, functions, and content delivered at a "first iteration" point. They are by no means "finished". Many will be continuously iterated on for the rest of the life of the game. Others are "good enough" for the start of Early Enrollment, but will need to be polished through a couple of additional iteration steps before they're truly complete.
Our goal for the start of Early Enrollment is to have the "Minimum Viable" features working. "Working" is a broadly defined term. It often includes a mechanism that requires a manual step, or a process that involves a staff member taking some action, or a placeholder activity that achieves the intended result but in a manner that will be replaced with a much better process in the near term.
We have completed a lot of the work we identified early in October. Some of that was deployed in Alpha 11. Some is behind-the-scenes technology for analytics and Customer Service. A few examples are:
We now have a tool that enables Customer Service to add or remove items from customer accounts like Add-Ons and MTX items. We will be able to use this tool in a manual process to "move" items from accounts that acquired them via the Kickstarter to the target accounts that should receive the items prior to the start of Early Enrollment. We'll write a lot more about this soon, including a process for those who need this service.
Our Customer Service team now has the ability to alter the amount of game time on an account.
We'll write a much more lengthy blog about this topic, but the short summary is that for the first month, we won't have an active game time management system, but will instead use server logs to determine if players have opted to use a month of game time. Players who do not wish to use any of their game time need to refrain from logging in to the game (not the website - website logins will not count) during the first month of Early Enrollment.
These are items that we have identified that we cannot launch Early Enrollment without closing as "complete and satisfactory". They have the highest level of urgency and are a major focus that may impact several interrelated systems.
Our self-defined goal is: The server needs to be able to operate without dropping normal client connections with 2,000 logged in clients, and 100 characters active in a hex. This reflects the conditions we expect to see at peak concurrent connections with 10,000 active player accounts.
Additionally we are committing to the rule: A broken client connection should not result in the character appearing in a new hex. This will end the apparent "teleport" issues that current Alpha players see when they experience a desynchronization event and their client makes a new server connection.
We are working on improving the ability of the server and client to determine when they've become fatally desynchronized so that the client can be forcibly disconnected before too much time has passed.
We want the servers to refuse connections when they're overloaded. In the long term there will likely be a login queue of some kind, along with an estimate of time remaining before the client can connect. In the short term, the player will be given an error message indicating that the server is at capacity and that login attempts will fail.
We have identified situations where the handoff between physical servers, and server / client disconnects, and issues with server database updates can exhibit the symptoms of a "rollback" resulting in the loss of items and the un-training of Feats. The known issues will be fixed and the team will continue to work to improve the consistency of the system to minimize these occurrences.
These are items that we expect to complete before Early Enrollment begins. If for some reason we cannot, we expect that completion will happen very shortly after Early Enrollment starts.
We need a way to refund a purchase made through the goblinworks.com/shop. Long term this will be a tool that our CS team can use without assistance. In the short term, this will likely be a process that requires a handoff to a programmer, and then a return handoff to confirm that the refund was properly processed.
The staff will have the ability to make GameMaster (GM) characters. These characters will have the "GM" prefix on their names, and will have access to various special in-game commands to help players. GM characters will be logged in and able to provide help as much of the day as we can manage, eventually expanding to true 24x7x365 coverage.
We will gain a much needed tool in the form of a combat log that will be accessible to the game designers, QA and programmers. Eventually we'll make some form of logging available to the players too. This log will help us validate that the combat system is working as specified and help us untangle some of the more esoteric bugs related to how various systems are interoperating.
We are going to take the "Leave" button off of the Company user interface window. To leave a Company you will need to use a "/" command. We also intend to make it impossible to leave a Company if you are the Leader and there are any other members of the Company.
Introduced in Alpha 10, these are critical parts of the War of Towers. We likely will not deploy this feature at the start of Early Enrollment (we've already announced a 2 week space between the start of play and the start of the War of Towers). However we want to finish filing all the rough edges off this code before we start Early Enrollment for internal testing purposes.
We are going to change our Chat system. We are going to add a Help channel, and that is where our GM team is going to monitor the game for requests for help. Chat will be global. We are going to remove the "General" channel, and there won't be a global "open chat" channel. There will be a channel for each Hex though, which will replace the "Local" channel currently in the Alpha.
A number of small fixes are being implemented into these windows including some highlighting of selected items, indications of the number of Towers held by each Company, and details on which Towers are held.
The choice of the PvP window will be made consistent with the user's local time. Changes to PvP windows have to work correctly.
Note: The system has a hard limit on the number of results it will return for searches in the Company/Settlement UI. Doing a "blank search" in the Company Search window will not return a list of all the Companies in the game. Currently there is no way for a player to get a complete list of Companies. The Search window does not clearly communicate that it returns only partial data sets, and some players therefore think there is a bug with the search window. We'll improve this feature but it is not on the critical path for Early Enrollment.
You may have noticed that if you turn your character using the keyboard, you spin much faster than if you turn the character using mouselook. We're going get those two speeds to more closely match which will improve PvP (your opponents won't be able to run past you faster than you can spin the camera to keep an eye on them).
This is a bug that was introduced in Alpha 11. When you drag a Feat to the Paper Doll, it should appear immediately.
A new formula will be applied to Reputation, as follows:
For killing a character: (((Target 's Reputation+7500)/1000) *5)^1.5
Killing a character with Reputation 7,500 (max) will inflict 649.5 points of Reputation damage.
Reputation Recovery: Base rate 200/hour. Bonus regen = 10/hour (after 1st) to a max total of 250/hour. (The total regeneration of Reputation would be capped at 250 points/hour.)
The implication to this is that players will be able to kill other characters frequently without blocking their access to most training. Killing a several characters a day will not be catastrophic. Aggressive Characters will still acquire flags that make them killable by other characters without reputation losses.
We will monitor conditions in game continuously and take action if we feel the Reputation penalties are too low.
The functionality for Destiny's Twin will be ready when Early Enrollment starts. The details of the feature are being simplified. You will not have to establish a "Main / Destiny's Twin" relationship between two characters. You will just designate a character (permanently, irrevocably) as a Destiny's Twin, and that character will gain XP as long as the account is actively using game time.
These will be available at the start of Early Enrollment. We are still finalizing the exact contents of the packs and will blog more about this soon.
Note: It is likely that the New Player Packs will be changed over time as we add more content and functionality to the game. The decision to consume one of these items will be irrevocable and we do not plan to update the items received from consumption of one of these packs regardless of future iteration on their contents.
We have a Macintosh Client on the way. We've been testing it internally for a couple of weeks. Currently the build exposes a lot of debugging information that we don't want to make available to the public. Shortly we expect to begin a round of closed testing outside the office for the client, and will have it ready for widespread use soon thereafter. The client will likely not have the same level of graphic performance at the highest graphic settings levels as the Windows client due to a lot of factors related to the differences in architecture between Windows and OSX but it will still be a very good experience.
We can start Early Enrollment with the Must Complete items checked off, and with most of the Urgent items addressed (and with all of them addressed on a very short time horizon.)
The following are things we are going to work on within the first 30 days of the start of Early Enrollment. These are also critical to the game and to the user experience but not having them at the start of Early Enrollment will not compromise the fundamental integrity of the basic game. The quicker we achieve these milestones, the better, and the team plans to check them off very quickly.
Autotargeting should only select targets that can be hit without a Reputation penalty. This will eliminate the current issue with attacks "accidentally" targeting friendly player characters and creating a snowball of Reputation losses. In general, another Player Character should not be targeted unless that character has been flagged as an attacker. So if someone in your party "accidentally" hits your character once, that character won't be autotargetted.
The Customer Service team will receive a GM command that will let us pull a character from anywhere on the map to the GM Character's location. We'll use this to resolve "stuck" and other terrrain-based problems.
The Customer Service team will receive GM commands that allow us to take the following actions:
At first on the login screen, and eventually in all UI fields, you will be able to tab between them.
This is a major feature with several aspects.
When a player character is killed it converts to a "husk". The husk acts like a resource node. Characters can interact with the husk to get access to a portion of the dead character's inventory. On death, a portion of the non-equipped inventory the character is carrying is destroyed. Equipped Gear takes a point of durability damage and remains with the character when ressurected. The rest of the character's inventory is seeded into the husk as potential loot. The dead character can get everything from its own husk in one interaction. Other characters can select one item per interaction.
The achievement tracker is going to be a target for a lengthy series of iterations in the short term, and in the long term we plan to add substantial functionality to it to help players determine how to achieve their character development objectives as well as tracking their progress.
Immediate improvements include:
A bug that we thought was fixed has proved more persistent than expected. Many Feats that are "reactive", applying an effect on a target when the source succeeds in meeting some condition like making a Sneak Attack or inflicting a Critical Hit are also applying those effects to the source. This will be fixed.
The team is not going to deploy an update to the Alpha this week. Our next candidate build for Early Enrollment will likely be deployed next Thursday. Internal and Alpha testing over the weekend will be used to determine if that build is suitable for the start of Early Enrollment. If it is, we will start the 48 hour countdown timer as soon as we have completed our certification tests. If not, we will continue to iterate on the code and work towards a new candidate build as soon as possible.