|Paizo Pathfinder® Paizo Games|
|About Paizo Messageboards News Paizo Blog Help/FAQ|
After a reasonable effort to contact the person currently identified as the leader with no success, we will attempt to establish communication with other known members of the Settlement and ask them how they would like to proceed.
We have ways of identifying those people: the Land Rush leaderboard, and the relationship between characters and email accounts. We will certainly consider other relevent factors and affilitations as well.
If we cannot establish communication with anyone, we will recycle the Settlement and allocate it to a new group in a future promotion. If the other members of the Settlement cannot come to some reasonably supported nomination for a new leader, we will do the same.
In all cases we will use our discretionary powers to act in the best interest of the game and its community to make a fair and transparent disposition of the Settlement.
I think those kinds of dispositions will take weeks, not days or months.
It will be really easy to impose the restriction. Building a system where Settlements can make Alliances to share training requires all sorts of work. Putting in the restriction is probably something that could be done as a part of a 2-week sprint as an additional task on top of someone's more lengthy work. So "soon" is a function of "when do we impose the restriction" vs. "when can we build and deploy all the necessary code to make the Alliance feature work". And THAT will be a function of "what is our current prioritized list of features and fixes and where should this particular feature be slotted in that priority list?" Since the team is not considering any new features beyond "make the server work a lot better" and "fix all the known bugs with already implemented features" and "get the minimum necessary support tools built for customer service", we have no idea what that priority list really looks like.
Once we get through the Early Enrollment start then we'll actually have the space we need to start Crowdforging in earnest and that is when those kinds of prioritizations will start to be made.
OK, so here's the deal.
There was a plan to implement a "murderer" flag and some of the code supporting that flag was built. Apparently it became turned on at some point, but it was not really fully or correctly implemented. So we are going to turn it off. It may, however, take a few deployments to get it fully turned off (we're in the process of making a build right now and since we just figured this all out the changes will likely not make it into that build but rather the next one).
Now: You can use trainers in any Settlement. So whomever has the most towers that matches your training needs is where you would want to go.
Soon: You won't be able to train at a Settlement other than your own, or an NPC Settlement.
Later: Settlements will be able to make deals to open their training facilities to allies.
In all cases you'll have to meet the minimum reputation threshold to enter the Settlement and access the Trainers.
Now: If you have trained a rank of a feat Feat you can use it as long as your Settlement provides support for that rank.
Soon: No Change
Later: Settlements will be able to construct buildings that enable characters to access ranks of Feats higher than what the Settlement itself can provide.
Changes to Feat Ranks As Underlying Settlement Variables Change
Now: At server downtime your Settlement affiliation determines the max rank of the Feats you have access to.
Soon: There will be some kind of cool-down period during which you can continue to use all of your training if the Settlement you are a member of cannot support it.
Later: Same as soon but probably with all sorts of variables and conditions.
Answer to original question:
Local: The range of your minimap
What you use them for:
Local: Talking with everyone fighting for a Tower
Why not have "General chat":
Because it becomes useless very very quickly. Even a relatively small number of concurrent users will swamp it.
Note that as of Alpha 13 we don't post notifications that people are entering and leaving the game, which reduces the clutter substantially.
My definition of "sandbox MMO" is:
A game where the emergent behavior of people engaged in meaningful human interaction produces persistent and signifigant effects on the game world, and where the primary driver of value are those people's interactions and those persistent effects, not developer choices or storylines.
So let's be clear about what the MVP feature is and what the planned iterations for the feature is.
The MVP feature is:
You can only be a member of one company. Companies can only be members of one Settlement.
You have a max ranks of training in a Feat based on the number of Towers controlled by your Settlement. As that number changes, the max rank number changes. If you change the Settlement you are affiliated with the Ranks of the Feats you can access change ASAP.
This is how the game works today and will work when Early Enrollment begins.
In no particular order; these are just written as I remember them from the design document.
The Worst Case Scenario:
The design anticipates that some characters will suffer the worst case scenario.
They will lose access to a Settlement that has support for Ranks of Feats they have trained, the cooldown will expire, and they will not be able to find a new Settlement to accept them that will have support for those Ranks. They will cease having access to those Ranks (and possibly the Feat entirely) until such time as they're able to find a Settlement who can support those Ranks and Feats again.
On purpose we are designing the game in such a way that some characters, based on their actions, will find that the only Settlements they can be members of have only low Ranks of limited Feats available for training and support. Those characters will be substantially less powerful than they would be if they had proper support for their training. This is an intentional penalty.
There is no noticeable parallel to EvE to be found in PFO. This is a farce and one that is not claimed by anyone with any real experience playing EvE.
Pathfinder Online's parallels to EVE are many.
Your definition and my definition are not congruent.
In fact, I think the pursuit of your definition is why most sandbox MMOs have failed.
Players - some fun news for your Thanksgiving weekend!
We are going to be patching the game this afternoon to update to Alpha 13. We are doing some final checkouts of the server code as I write this, and then we expect to take the game off line while we run the update process. I'll update this thread when Alpha 13 is ready for you to begin patching!
Realistically, a tiny, tiny number of people are going to know anything about Pathfinder Online when we begin Early Enrollment. We're not going to spend the millions of dollars in marketing that would be required to move that needle to anything approaching the kind of awareness that a AAA Theme Park game enjoys when it launches.
So there's no point in worrying about this problem. Players who obsess over the fact that someone else has a number bigger than their number somewhere in a character's manifest that they cannot ever match or exceed are not our long-term target market.
There is an idea for a design for weapon specific consumables that you would craft with the same skills, facilities and components as the weapons themselves. Imagine something like whetstones or arrow staighteners, etc. They would have a limited time effect and you would want them active whenever you faced a significant combat so you would want to carry a lot of them and use them liberally, and they could not be threaded.
That would give us an economic engine that would power the crafting characters who want to make weapons even if the demand for weapons is artificially supressed by Threads.
The downside is that it is really finnicky and requires almost every character to spend time micro-managing stuff in the field, under stress, which seems likely to become "not fun" very quickly.
The designers have been noodling over ideas for repair kits for weapons and armor which might be a better solution with the same basic idea of parallelling the crafting of those items with something that will be consumable but won't feel like a life or death choice in the heat of battle.
This may all be moot though. Practically speaking, characters may die often enough that they are consuming weapons and armor fast enough to create meaningful economic activity without these other systems.
There needs to be a mechanic that encourages a Settlement to boot a character that isn't conforming to the Settlement's standards of behavior (or to acknowledge those standards have changed). There is a fine line between making such a system a series of interesting choices (which is good) and a mechanic which is really a mandate (which is bad).
In the short term we just need to get the functionality built to make being in a Settlement meaningful, and making denial of access to that Settlement meaningful. Then we can start Crowdforging more elaborate systems on top.
We are focused on fulfilling the plan we outlined in Closing the Gap to Early Enrollment.
These are the things that have to work before we start Early Enrollment.
Here's a current update:
Improved. System no longer puts you into a new hex when you desynch. Numbers of desynchs reduced. We found and fixed several bugs that were contributing to performance hits on the server. Still not at the goal for performance and stability but progress being steadily made.
This is a perfect example of the integrate, test, diagnose, plan to fix loop. All the low hanging fruit has been harvested. Now we're looking more deeply into the code to find places where we can optimize. Of everything we're doing, this is by far the hardest. It's taking the time of multiple programmers.
Customer Service Refund Tool
No update - status unknown to me at this time. We have a "worst case" system that involves Customer Service making a request of a programmer who has to do some manual work to instigate a refund. Clearly that's not optimal.
Code complete, scheduled for test this week.
Exception: We do not yet have a command that lets us boot a player off the server. That has to be done before we can start Early Enrollment.
Logging is now possible but a UI for us to see the logs has not yet been built. Scheduled for this week, maybe testable this week.
Remove Leave Button from Company UI
Deployed Alpha 12.2
PvP Windows And Tower Capture Mechanics Need to Work As Designed
Deployed Alpha 12.2
Changes to the Chat Channels
Code complete, scheduled for test this week.
Fixes to Company and Settlement Management UI
Deployed Alpha 12.2
Speeding Up Turn Rates for Mouse Users
Deployed Alpha 12.2
Feats Don't Appear on Paper Doll
Deployed Alpha 12.2
Changes to Reputation Calculations
Deployed Alpha 12.2
Code complete, scheduled for test this week.
New Player Packs
Code complete, scheduled for test this week.
The Mac Client
This is the biggest unknown. We are continuing to work on problems related to the Mac client including performance and including the patching issues discussed in this week's blog. We are likely going to have some in-depth Mac conversations this week to try and narrow down our range of options.
Everything else waits until the above list is finished (and very occasionally a programmer can pick up a lower-priority task when they have a few minutes between larger tasks.)
There are a handful of "bugs" that are really errors in the back-end system we use to package data for the game. Those don't require programming to fix, they just have to be corrected in the back-end system. So things like missing or incorrect prerequisites, drop rates for loot, harvesting node changes, etc. get picked up and fixed continuously as we identify them, but they don't appear in game until a whole new build is created and deployed. We should be very "clean" on the list of such bugs when we get to Early Enrollment and we're building a plan to validate a lot of these systems before we go to Early Enrollment to raise our confidence level that the system is working as intended.
Why do you wear heavy armor?
It is to maximize your defense. That implies you intend to spend substantial time in combat.
If you are fighting monsters, most of the loot you should get is close to weightless. Starter gear is the notable exception. And it is an exception.
So the character who sees themselves in the role of treating monsters as resource nodes should be fine wearing heavy armor and recovering valuable loot like recipes and spells. You can solo that system if you want. You probably will have to be discarding heavy, low value loot regularly though so you won't be approaching max efficiency.
If you are fighting PCs you expect to get a lot of heavy loot.
That character is stuck in the middle of a meaningful decision. If they use heavy armor the amount of spoils they can recover is substantially reduced. If they wear lighter armor the damage they can absorb will be substantially reduced. If they try to armor up or down depending on where they are in the cycle, they risk becoming someone else's content.
The solution to that problem is "work with another player". In other words, "banditry" is not a good fit for solo play.
We are going to record a lot of in-game footage for our first trailer. To do that I need to recruit a team of players to help us stage the scenes we need to record.
We'll do this work in the afternoons and evenings to get as many people as we can - we'll probably work on this from around 5pm to 8pm on weeknights and possibly during the day on weekends.
You'll need to be able to follow directions very carefully. When the director tells you to walk to a certain point, and face a certain direction, and take a certain action, you have to do it - when we're trying to get several dozen characters to all perform on queue, anyone who isn't able to follow directions will waste the time of a lot of people.
There will be a lot of standing around doing nothing. It takes time to get everyone into the right positions and we'll be experimenting as we go to get the right shots from the right angles. For 30 seconds of recorded footage it might take 30 minutes of staging. You'll need to be able to be bored for long stretches.
Our concept for our trailer has good guys and bad guys in roughly equal numbers. Depending on how many volunteers we have you may have to play a character that doesn't match up with your "in game" persona. Be willing to accept that the needs of casting may outweigh your preferences as to "side".
We want to shoot footage of groups harvesting, fighting monsters, and ambushing and fighting each other. And we want to recored an epic battle around a Tower.
If this sounds interesting to you, leave a message in this thread indicating that you'd like to help. When we get ready to schedule our first in-game recording session, I will contact you via paizo.com private message to give you the details.
To help me keep track of the volunteers, please don't post in this thread if you're not able to participate. Thanks!
Old vets should be leaders of large groups. Think fleet commanders in EVE, or capital ship pilots (our equivalent to capital ships will likely be seige-related entities which we have not yet even really begun to design). They will likely be necessary to operate the kinds of transport beyond simple mounts that large caravans will want. They will provide benefits to Settlments, POIs and Outposts when they assume various critical positions innthe settlement heirarchies, etc.
We will certainly continie to add contnent and systems for those characters over time. It will be a rich domain of Crowdforging and iteration.
I am absolutely not surprised that server population is low. I think we have been in Alpha a month too long. The initial rush of "how does this work" is over. Now most people are just waiting for the "real game" to begin. The stuff that is hard to do will be wasted when we start Early Enrollment. And the benefits of having a lot of people logged in and playing won't materialize until the results of all that work is persistent.
@AvenaOats - you are exactly right in your apprehensions and they mirror my own.
Unity just doesn't have a client/server architecture we could use off the shelf. There were attempts to make MMO systems for Unity but none of them passed even the first tests we subjected them to.
However, of all the things that we could have had to "roll our own" in this project, the client/server component is the one thing I was comfortable doing because that's the work that Mark did at Cryptic. Having already gone down this path once, he has a very good idea on how to scope the various problems and what the system needs to be able to do in terms of performance and capacity.
It is suboptimal that we had to do this work. If we could have used a system that already had it we'd have been further advanced in other aspects of the project. But life is life, and we had to roll with that punch.
Long term it's probably a benefit because we'll have more control over how this critical part of our system works. If we were using someone else's code we would have to deal with those interactions, but having done it ourselves we can make whatever changes we think necessary whenever we think they're necessary.
EVE is not a "sharded world".
This is another of those discontinuous function steps.
It turned out that the architecture of the first MMOs had a serious problem. The database they used were limited in the number of transactions they could process per second, and the way those games were architected generated a tremendous number of transactions. What the engineers discovered was that they could run worlds with about 3,500 accounts logged in simultaneously to the logical server (the cluster of all physical servers that comprised a world). If they tried to push above that number they found the whole cluster would suffer.
In addition they discovered that they could have about 20x as many accounts on a server cluster as they could have logged in accounts. Since each account has a certain overhead load in terms of number of characters, and each character has a certain overhead load in terms of the amount of space it and is associated data structures occupy in the database, and the larger the database the slower it performs, pushing much above that number of accounts also caused serious performance problems.
(If you remember the first year of WoW, this is why they had to keep stopping the sales of the game or not letting people create new accounts and why they were introducing new servers continuously. They were trying to build and provision servers fast enough to keep ahead of these limits and sometimes couldn't.)
In this era everyone used SQL servers and that meant for the most part Oracle (once you got above a certain size it was really hard to use PostGres or MySQL, and there were for various reasons high end considerations that tended to drive people away from Microsoft SQL and towards Oracle). A lot of project started on an open source SQL server and had to spend a huge amount of money redesigning for Oracle. Those companies that tried to stay on MySQL or PostGres quickly found that they were forced to spend as much time working on the database as they were working on the game and they rapidly ended up with custom database code that was hard to maintain.
When EVE was developed CCP wanted to avoid these problems because they wanted to have a single logical server. To do that they needed a database that could withstand having 10-20x more user accounts and logged in characters than the traditional MMO architecture. They finally settled on a combination of hardware and software solutions to the problem.
On the software side they went with Microsoft SQL and became a part of a project inside Microsoft to help companies who wanted to do high volume transaction processing on MSSQL. That got them access to engineers who could help troubleshoot bottlenecks, recommend how to configure the systems, and investigate bugs and performance problems.
The other thing they decided to do was to move to a solid-state harddrive system. This was long before SSDs were commercially available. The only vendor that could produce a drive unit with the storage capacity CCP needed was a Defense Department contractor who built hardware for mysterious 3-letter government agencies. CCP was able to buy one of their drives, although it required negotiating a special export license and it had to be located in the UK, not in Iceland.
That combination worked and CCP was able to push their system past what everyone else was able to achieve. Due to the benefits of Moore's law on SQL databases, they've been able to keep expanding and extending their architecture to accommodate growth.
One other element that they used to good effect was the natural segmentation of the game world into separate star systems. They don't have a "seamless world" like Pathfinder Online or World of Warcraft. By containerizing activity in discrete nodes they were able to parallelize the processing work for those nodes, putting each one on its own hardware. There were 5,000, then 7,500 systems, and theoretically they could have had a 1:1 mapping between a physical server and a star system. In practice they did not because most of those systems have very low populations most of the time so several can be hosted on a single physical server.
There is a problem with CCP's architecture. They wrote the core game code in Stackless Python. This is a pretty good language for a lot of reasons and it has a lot of fans in game development. It does, however, have one significant flaw. Stackless Python appears to the programmers as if it is a multithreaded system allowing them to parallelize their code for maximum efficiency. However, in fact, it relies on an internal data structure called the GIL (Global Interlock) to synchronize all the threads. And the GIL is processor bound. That means that CCP can run many star systems on one processor, but it cannot run one star system on many processors.
Moore's law used to increase the speeds of processors so CCP kept getting more capacity as processors sped up. But for a while now instead of making the processors faster, CPUs have been getting more processing cores. The total number of instructions the chips can process continues to increase but the number of instructions a single core can process has flatlined. CCP is not getting the benefits of Moore's law anymore.
In order to fix this problem, CCP will have to rewrite it from the ground up in a different language. So far, that has proven to be a task beyond their considerable collective ability.
Since EVE was developed and long after the first MMOs, a whole new approach to high volume transaction processing has been developed to serve the needs of massively large global internet services like Google and Facebook. In general that's known as "noSQL". These solutions provide pathways to deliver a higher level of performance than traditional SQL-style databases.
Microsoft also created and made available the .NET system and the C# programming language. Those tools enable developers to create highly parallellized code that can use multiple processors efficiently while working in a very high level language with modern features like reflection and garbage collection. Due to the way Microsoft elected to release these tools there are versions which work on Mac, Windows and Linux. That enables developers to write cross-platform applications, and THAT enables us to do things like run the game servers on very high performance Linux optimized specifically for our needs, and have clients for Windows and Macintosh that can all interoperate, with everything taking maximum advantage of whatever hardware we're running on.
So we're now in the territory of doing a "WoW-style" seamless world on an EVE-style single server. Nobody knows how well this will scale and how we'll deal with the inevitable problems of congestion and load balancing, but we are reasonably sure that we've passed through several gates of hardware and software capability that enable us to attempt it.
The team is working on ideas for our first trailer for the game. We'd love to hear your ideas.
The whole trailer will be less than 2 minutes long, and that will feature about 90 seconds of "real stuff" surrounded by 30 seconds of marketing payload and legalese. So whatever your idea is, it has to be extremely succinct.
The trailer is going to focus on 4 key messages: Crowdforging, Settlement & Characters, richness of content, and "the world is new and awaits your impact".
Today, I'd love to hear your ideas about how we can visually express the following ideas:
As a part of the creative process it can be helpful to just spitball a lot of ideas. Sometimes the final concept emerges just from getting the creative flow going.
It can be very hard to contribute if you're worried that your idea won't be popular or might draw criticism.
So please do not critique anyone's ideas. If you don't like one, or don't agree with one, just ignore it. I'd rather hear more people make one idea than one person make many ideas.
@Bluddwolf - ok, that's a legit place to start. It certainly isn't obvious to the average player why "making a multiplayer game into an MMO isn't just adding more server capacity". I'll try to explain a bit.
The topology of most multiplayer games is a hub & spoke model. One machine is "the server", and all the players in the game connect 1:1 to the server. Often one of the players is also playing the game on the server and it may be invisible to the players that this topology is being used - it "just works".
In this model, all the game state information is held on one physical computer. In a slightly more advanced model, there may be one computer that manages the game mechanics, and one computer that works as a database. The "logical server" is two physical computers. However, even in this topology, one of the physical computers is really running the show, the other is just acting as a parallel processing solution for data - a Master/Slave relationship where the slave just does whatever it is told.
This is how Neverwinter Nights worked, or how Battlefield and Call of Duty work. It's how Life is Feudal "Your Own", and Rust works.
The key difference between this topology, and a true MMO, is that this topology doesn't scale. There's a certain amount of overhead for every client connection. At about 128 connections, even the fastest computers, with the very best network connections become overloaded. In real-world applications that number is usually 64 people not 128 people, and for games with a very low latency, the number is lower - around 16-24 connections (thus the relative sizes of the forces in Battlefield and Call of Duty multiplayer).
As soon as you hit that limit, if you want to continue to grow, you have to move to a multi-server architecture and that's where things go through a discontinuous function (for the first but not last time).
If you have multiple servers, they need a way to coordinate with each other, as well as with the clients. They need to allocate resources in some coherent fashion. They need to be able to transfer data between them as clients change connections between servers. They need to have some fault tolerance and some redundancy. At this level, you are almost guaranteed to have a database system running in parallel as well, but now instead of a master/slave relationship, you have to figure out how multiple servers can read and write to that database without overwriting each other's data.
On the front end, you need a system to pool inbound client connections, because you don't want the clients to be making individual connections to physical servers. The clients connect to a fixed address, and then their traffic is routed to the proper physical boxes. That has scalar problems too, and eventually you have to have an array of those front end routers and those routers have to be synchronized and coordinated.
Suddenly you have a huge new load on the system, which is all the overhead traffic required to keep all these physical machines in synch. So each physical server becomes less and less efficient compared to the original single server topology.
Eventually, you reach another discontinuous function. Adding another physical sever means that the total overhead required to keep everything in synch exceeds 100%. You have to come up with some other solution. The first generation of MMOs did this by sharding - they split their game worlds into independent slices. The current generation is trying to avoid this using single servers (EVE, Pathfinder Online, etc.) and "mega servers" (Elder Scrolls, Wildstar, etc.) Making this work requires some very deep level planning about how the game is designed and built from the ground up.
Let's talk about some use cases.
The simple case is that I want to have a character walk from a hex served by one physical machine to a hex served by a second.
Standing in Hex 1, I want to be able to see what is in Hex 2. So there has to be some mechanism on the border for the game state in the two hexes to be shared in near realtime.
Standing in Hex 1, I want to be able to shoot something in Hex 2. So there has to be some mechanism on the edge for the game state to understand that I've targeted across a server boundary, and that effects are going to cross the server boundary.
Now I want to walk across the boundary. All the data associated with my character, it's inventory, it's chat, it's current game state, it's flags, it's party, Company and Settlement entanglements, etc. all need to be transferred from Hex 1 to Hex 2. Permissions to write and read in the database have to be changed. Pending transactions have to be committed. Etc. etc. etc.
There are complications. How far into Hex 2 should i be able to see? What about seeing even further - should I be able to see mountains on the horizon that are even further away?
What if a bunch of players all line up on the hex boundary and coordinate stepping across all at once? How will the servers handle becoming overloaded?
What if the handoff is inconsistent? What if Hex 2 thinks that the data Hex 1 is sending it is corrupt, desynched, or otherwise dangerous?
What if there's a network or hardware failure in the middle of this process? How do things get unwound? How can the system be put into a "safe state"?
Are we extracting analytics data? Do we have telemetry coming out of the server or from the clients? Where does that get stored and how is access controlled to it?
Oh, and by the way, everything has to be encrypted, so we have to be running a bunch of computationally intensive math continuously on every packet.
This is where hundreds of millions of dollars have been lost in trying to make multiplayer games into massively multiplayer games. The implications of doing all these things reverberate to every corner of the project. For example, yesterday I updated the Combat Guide to describe the timing of how attack actions work. There's a 300 millisecond "validation" component to that system that exists purely to enable the server to detect and reject attempts to compromise the client, and to detect desynchronization. If we didn't build that 300 millisecond period into the animations, and we learned later that we needed to do it, every combat animation in the game would need to be revised. That's one example of literally hundreds.
It took 15 years to learn just the rough outlines of "best practices" for making MMOs. It's one of the big differences between teams that have made them before and teams that are making one for the first time (and one of the reasons I get whatever sleep I get at night is because Mark has done this 3 times, Lee has done it twice, and Mike has done it twice). The learning curve on stuff like this is atrocious. And there's no one-size-fits-all solution, even for games that are seemingly similar on their surface. We have unique problems that World of Warcraft doesn't have, and vice versa. So each team not only has to have a working fundamental knowledge of all the things that could go wrong, but also has to be creatively thinking about all new ways to catastrophically fail and try to avoid them.
The difference between a multiplayer game and an MMO really is the difference between walking and flying in a jet plane.
I have modified the Combat Guide to reflect my increased understanding of the timing of attacks and interrupts.
Here is the new section:
Attack Timing & Animations
When a character initiates an Attack Action, a number of processes are triggered. These take place during the total time of the attack. Currently, the in-game tool tips are displaying just the Cooldown time. The total attack time is the Cooldown time + Validation time. Total attack time is not currently displayed to the player. In this section we will use the full total attack time when we discuss the length of an attack.
We do not currently have a system that can alter the animation in mid-playback based on conditions during the period of the attack. So currently each attack animation plays identically for every iteration of that Attack Action regardless of what might happen during any discrete instance of that attack. Our plan is that if an attack fails Validation or is interrupted the animation should blend to some kind of “I have been interrupted” animation, but that technology has not been fully implemented yet.
If Validation fails there is no effect on the character’s Stamina. The Stamina bar does not change to reflect the cost of the action until after the Validation period has passed so there is a lag between initiating an attack and seeing the Stamina bar change of 300 milliseconds. If Validation fails the player is immediately free to attempt another attack (or other action).
Interrupt & Followthrough Phases
Attacks that have speeds less than 1.3 seconds cannot be interrupted. These fast attacks only have a Followthrough phase.
To determine the lengths of each phase, begin by calculating the Followthrough length.
Followthrough Phase Length
Interrupt Phase Length
For example, an attack that displays a Cooldown time of 1.4 seconds is actually an attack with a 1.7 second total length. That attack will have 300 milliseconds of Validation, 1 second of Interrupt phase and 400 milliseconds of Followthrough phase.
The Sequence of Events
Note: If you are using an attack with a total time of 1.3 seconds or longer that includes an Interrupt effect, you may find it very hard to time that action so that it actually interrupts your target. You have to deliver the attack such that the resolution moment happens within the target’s Interrupt Phase, and you’ll have to factor in your own Interrupt Phase length. Hitting targets with Interrupt effects using attacks with lengths less than 1.3 seconds is much easier.
Right now there are 3 comparables. Cryptic, Portaltarium and Chris Roberts Space Industries. If Camelot Unchained makes more public progress, I'd add them to that list.
Cryptic uses about 30 people to make an MMO, but they are using toosls paid for by previous development, including a huge amount of development paid for by Microsoft for an aborted Marvel MMO. So they can dedicate all the staff on a project to art, programming and game design and not worry about tools or infrastructure. Plus they have a separate pool of people for marketing and customer support, and for server operations.
I would estimate loosely that the investment Cryptic makes in an MMO before they start monetizing it, exclusive of marketing and infrastructure, is 3x what we have spent so far, and a year or more of time longer than we've spent, and not factoring the time/value of the Cryptic tools. They don't do MVPs (although I think a really strong argument could be made that Star Trek Online was an MVP.)
Portaltarium is about our size and they're spending about what we are spending. They elected to invest a lot of time and effort into interior spaces and dungeons, which they are monetizing by selling housing. From what I have seen Shroud is ahead of us in terms of UI and the aformentioned interior spaces, but we have a more robust single-server MMO platform, zoneless world, and a lot more character content (Feats, armor, weapons, etc.)
They raised 3x as much money was we did through crowdsourcing, and Portaltarium has some external funding that came to the company before it started work on Shroud. Plus they are a cohesive team who have been working together in this space for 20 years, with a history of process that I can only envy.
Our MVP is an MMO. My opinion of Shroud based on their public statements about their roadmap is that their MVP is a Neverwinter Nights-class "MO", designed for small groups of players and solo players with MMO style markets and maybe chat.
Chris Roberts has raised 10x the money we have spent. He has a hundred people working in several studios. They have invested a lot of that money into their art and their stuff looks gorgeous. So far he has released two modules: a hanger and a dogfighting system. As far as I know they have not started delivering client/server work - the dogfighting module is peer to peer from what I understand. I don't have any sense of what their path to an "MMO" experience is, but I suspect it will be 2-3 more years of work minimum. His MVP appears to be a series of modules with the theory they can be linked together into a cohesive whole at the end of that release process.
I've been pretty public for 2 years+ that I think one of our big risks is adequately setting expectations for the start of Early Enrollment. The whole process is so outside people's prior experiences that they are likely to have trouble framing it in a context that makes sense to them. Witness the multiple threads here and elsewhere about whether Early Enrollment is a "beta", if Early Enrollment is a "release", etc. These are attempts to frame the start of play in familiar terms even though the actual process is new.
We just have to keep reiterating the idea that people are seeing this game in Year 2 of a 5 year development cycle. Most people have never seen a game in this state before. It's so far out of context that they don't know how to evaluate it on its merits. (And based on the comments some people have made that they think we should be "further along", a lot of people have no realistic idea of how amazing the progress on this project has been so far).
That will apply to the press as well. They have no mechanism to evaluate "Early Enrollment", despite having to grapple with Steam Early Access. The whole idea of starting to sell a product at this stage of development runs at cross purposes to a review culture designed to pass judgement on a completed process.
We use Unity, and Unity's strengths and weaknesses are our strengths and weaknesses.
In the middle of the Unity graphic system is a step where a lot of math is performed to transform all the various layers in the meshes that make up a character into a single mesh so that we can render a frame of a scene in a reasonable amount of time.
The system which does this on Windows is better than the system which does this on Mac. We have to spend substantial engineering time for incremental progress on that step. That is a constrained resource, so we want to spend as little the on it as we reasonably so those resources can be deployed on fixing other problems and iterating on features which affect very user not just the Mac users.
The Mac client is running very well and I think there won't be many complaints about the quality of the graphics from any Mac user. I'm optimistic that we will have it in testers hands soon, but I don't make that call, I wait until the team tells me they are ready. As soon as they are ready, we will get a test set up and running.
it really won't be challenging or involve meaningful human interaction.
Right now, nobody is going to be forming large groups of guards and organized harvesting trips, when naked solo gathering is so much more effective.
You see how feeling at risk whenever you are in the wilderness is exactly what drives groups and organized harvesting, right?
All the data I have ever seen is that when a sandbox MMO is working, it's peak concurrency is about 20% of active players. So that goal will remain pretty central to our plans.
We know that we need to create formation combat in the mid-term timeframe because it lets us substantially increase the density of characters in a hex. When a formation is used we can reduce a lot of network and graphic overhead. The trick is going to be managing things like marshaling (how do we handle having a lot of characters enter a hex in order to join a unit) and lack of cohesion - either intentional or unintentional. We don't want breaking up a formation to be a rewarding tactic in terms of injecting lag or latency in the middle of a battle. So its a huge design and engineering challenge.
I love the engagement. I love the raw and unfiltered criticism. I gaurantee you much worse is being said in much more toxic ways outside our forums. The best way to know where the "pain points" are is to hear it directly.
If I thought we'd made any major errors in strategy I'd be more concerned. Right now I am still sure we're doing the right things, in the right order. We are just doing them more slowly then we'd all like. That's the nature of software development though and it shocks nobody who has done a large project.
Virtually everything the community is asking for are things we are actively working on. There's no mis-match between desires and resource allocation. We just need more time.