Caspian - State of Elyria 2017
Hail Elyrians,
Back in December of 2016 I started a tradition by writing my first annual "look back." It was my first annual because I wasn't expecting to write another one until next December. However, starting as early as May I began feeling like another was necessary. I wasn't entirely sure why I felt that way, I just knew I did. Then, earlier this week, when in a meeting with our leadership team I realized what it was.
In our meeting the subject of our company's core values came up. One of our values is transparency, and that stood out to me. I reflected on the last few months and realized that we'd become less transparent with our community and, as a result, we weren't upholding one of our studio's core values. So I started thinking about why that was and what we could do about it. And this is what I came up with...
When we first started working on CoE we were extremely transparent. We regularly sat in IRC or Discord and chatted with players about everything - what we were working on, how progress was going, etc. We regularly shared screenshots and we even had "Caspian Story Time", where I'd leak bits of lore in the form of stories about the various Qin of the Qindred faith. It was as close to "seeing how the sausage is made" as we could possibly get.
But as time went on and our audience increased, so too did the number of people who didn't have the same stomach for seeing what's in the sausage. And I can't blame them. Game development can be a messy process. There's a ton of iterations, throw-away work, slipped milestones, resource shortages, illnesses, and everything else you can imagine. And seeing all that can leave a bad taste in someone's mouth. It's a lot like seeing those videos on YouTube about how gelatin or hotdogs are made (Don't do it, it's a trap!).
In this regard, transparency is a double-edged sword. People want to feel connected to the project they're supporting (and we want them to!), but getting too much visibility into the process can actually reduce confidence and make people question their support. In other words, sometimes it can make you lose your appetite. As we started realizing that exposing too much information could be counter-productive we began shifting the information we shared from raw and wriggling, to something more broadly appetizing.
Regardless of our intentions, it's clear we may have overcompensated in our desire to shield the community for the messier parts of game development. Where once we chatted with the community about how the build was failing, we instead only shared work that we were proud of or was farther along in development. Where once I sat in IRC discussing lore as it was being written down, I now had to spend my time working with the growing team to develop the ideas I came up with, and we were careful not to share things that were half-baked that would set unrealistic expectations among our fans. And, most noticeably, where once we shared even the dates of our internal milestones, we now no longer shared even what year the game was going to ship in. In short, we went from being fully transparent to sharing only about as much as the average game studio (not enough!). And that's not the studio we want to be.
So, this State of Elyria is an attempt at getting back to where we want to be; to revealing those things we've kept close to the vest, and to answering those questions we know you've been asking. So, like the ghosts of Elyria Past, Present, and Future, let's take a look at what we've done so far this year, where we are now, and where we're headed.
OR
Caspian - A year in foundation
As the trees lose their leaves, the air turns cold, and frost can be found gathering on the ground in the morning, I'm reminded that winter is once again upon us (Ok, so winter may look different in Seattle than other places). This necessarily leads to a period of reflection and retrospection as I think about what we've achieved as a studio over the past year and what we have planned for the year to come. So, in accordance with my annual "Look Back", let's take some time to revisit the many foundations laid in 2017, and the progress we'll be making in 2018.
2017, A Year of Foundations
I'm often overheard at home and around the office using analogies to communicate sometimes complex concepts to my kids, coworkers, and friends. In truth, I'm almost as famous for my analogies as I am for my puns. Sometimes I borrow from existing analogies and frequently I come up with my own. When preparing for this blog post I was thinking not only about what we had achieved in 2017 and what we will be achieving in 2018, but also how 2017 was different from 2016. As I was thinking, the frequently used construction analogy that is frequently utilized in software engineering came to mind.
The idea is that software engineering is akin to civil engineering, and that the process of building a house or a skyscraper can provide lessons toward the construction of software. The analogy usually draws parallels between the different phases of construction such as the requirements gathering, drawing up blueprints, laying a foundation, creating a frame, etc. There are also many reusable terms such as architecture, scaffolding, building, and more. Of course, there are some key differences as well which leads people to argue the validity of the construction analogy, but that's irrelevant for this conversation.
If I continue the construction analogy, then the primary focus of 2016 was on the concepting phase of development. We worked on prototypes, proofs of concepts, and small demos to validate the ideas we had. This would be a lot like an architect creating 2D or 3D models of their building to pitch the design and project to others. It’s not throw-away work, as the concepts and designs serve to guide the vision of the project, but clearly a sketch, render, or even blueprints won't keep you warm in the winter.
If the clear majority of 2016 was on concepting and drawing up blueprints, then November of 2016, just over 13 months ago, was when we finally broke ground on the construction of Chronicles of Elyria. It's when we took the vision and concepts we'd created and really started to build something out of it. It stands to reason then that 2017 was about building the foundation and infrastructure of the project. Much like a skyscraper must have a solid, deep foundation, and reinforcements to handle the weight, so too does an MMO like Chronicles of Elyria. A game like this requires a high-level architecture, a deep set of foundational work on the client and server, a strong support system, and infrastructure with which to see the project to completion. With that in mind, let’s take a closer look at some of the foundational work that happened in 2017.
Server Foundations
When talking about an MMORPG - or as we like to call games like Chronicles of Elyria, a Multiplayer Evolving Online World (Meow!) - there’s nothing more foundational than the back-end server. The back-end server is responsible for managing the entire state of the game, performing all the necessary computations for systems like AI, physics, pathfinding, and combat, and for receiving and processing all the input for, in the case of CoE, hundreds of thousands of connected clients. In January of 2017 we began the long process of taking what was mostly an offline, single-player game – designed primarily to validate user experience and gameplay feel – and turn it into a MEOW (what can I say, the Internet loves cats).
The process of building a scalable, reliable back-end server with all the gameplay mechanics for a game like Chronicles of Elyria can be divided up into two primary components. There’s the platform, necessary for providing infrastructure such as entity and state management, fault tolerance, load balancing, and a method of cross-process communication, and then there are the services or workers that are responsible for performing all the actual gameplay logic and processing the user input of all the clients.
Shortly after we announced development of Chronicles of Elyria we started looking around for ways to solve the typical problems associated with building a large, distributed simulation. In short, we were looking for ways to speed up development of the platform. As part of our research we got in contact with Improbable and as a first effort at bringing our game online, we began integrating SpatialOS in January of 2017. As a test, we built our own PhysX simulation in SpatialOS which, when integrated with our Unreal Engine 4 (UE4) client, allowed us to move around the world using our own custom physics engine in a way that provided all the benefits SpatialOS has to offer.
Of course, SpatialOS isn't a game engine, so while it provided a platform on which we could build our game, we were still responsible for writing all the systems of CoE.
During the development of Chronicles of Elyria, we found that we could make headway faster, enable unique gameplay features, and leverage a large ecosystem of existing code by moving from C# to JavaScript/TypeScript as the primary language of our backend. Fortunately for us, as of SpatialOS 10.3 Improbable had an experimental JavaScript SDK, which meant we could continue to use SpatialOS along with our new chosen language and architecture. So in early spring we made the move from C# to JavaScript and, as a result, saw rapid improvements in the rate at which we could develop new features. This was also around the time we saw accelerated progress in the development of the VoxElyria client (formerly referred to as ElyriaMUD).
OR
Caspian - State of Elyria State of the Studio
Hail Elyrians,
With the beginning of a new year, and with our experiences interacting with publishers and investors in 2017, we've been evaluating our funding and staffing needs going forward.
>Both we at the studio, and the community at large, have a strong desire to maintain creative control of Chronicles of Elyria, as can be seen from the posts here and here. There's also been discussion during Q&As and on Discord about ways we could attract publishers while still keeping true to our values such as the thread here.
Soulbound Studios is a community-centric development studio. We rely on player feedback to help shape the future of the game, and we've relied on crowdfunding to get us this far. In an effort to make rapid progress on the game we know will redefine the MMORPG genre, we began pitching our game to publishers and investors throughout last year. We knew with the additional funding a publisher could provide, we would be able to get to market quicker than we had previously announced. However, as we reached the end of 2017 it became clear publishers were disinclined to take the risk on an innovative game such as Chronicles of Elyria without changing our intended vision. Some publishers wanted micro-transactions, loot crates, or other features that prioritize revenue over player experience. None of these options are in the best interest of our vision or players.
From the end of 2016 to the end of 2017 we nearly doubled in staff, however that team size was never intended to be sustainable without the long-term aid of a publisher or investor. In their absence, and as a result of our change in focus back to crowdfunding, we adjusted our resources accordingly so as to be sustainable solely through sales from our online store. Unfortunately this meant parting ways with a few of our team members. This was painful for all of us as we had developed a close bond with everyone in the studio, but it was a necessary action to move forward at the velocity and cost we need to succeed.
In regards to studio finances, we are now able to sustain development at our current size without the need for a publisher or investor. We plan on continuing crowdfunding for the foreseeable future so that we can maintain creative control of the game, and ultimately deliver the promise of Chronicles of Elyria.
OR
Caspian - The State of Elyria, The Calm Before the Storm
Dear Elyrians,
Over the last five months here at the studio, the game and teams have been undergoing a near constant transformation. From the shape and features of Elyria across the different servers to the features and mechanics of the game - even the very offices we work in - everything has been changing at break-neck speeds.
Back in October of 2018, what seems like just a month ago to those of us here at the studio, we declared the beginning of Release 0.5.0. And then, just a month after that, many of us were neck-deep in Map Voting, then Server Selection, then the Lost Vault event, and then finally our winter vacation.
Meanwhile, the rest of the team began moving forward with integrating gameplay features into our new client, as well as re-writing the UI system, which were together the focus of Release 0.5.0. As a reminder, our goal for the completion of Release 0.5.0 is to have a complete, playable game, composed of all the many features we've worked on over the last 18 months or so. We knew it was going to take a lot of work, and so the studio entered a bit of a heads-down, focused mindset.
No longer content to just tell you about what we're working on, the team was committed to showing you.
All of these changes together have created an energy and electricity about the office that is thrilling. There's a sort of anticipation, if you will, as we work to complete Release 0.5.0 and deliver Domain & Settlement Selection. Two things which will no doubt be a major focus of 2019, both for us as well as for all of you. And while there's been a lull in our messaging and communication, this is no sign of slowdowns or delays. Quite the opposite. What must have felt like a deafening silence by us over the last few months was just the quiet before the storm. And the storm is about to break...
Studio Growth
Over the last 5 months of Release 0.5.0, the feeling in the studio has transitioned from one of solemnly marching forward, with what seems like an interminable list of features, to one of energy, inspiration, and the strong sense of achievement.
The team comes in on Mondays excited to be back in the office. We are focused, eager to collaborate, and more productive than ever. At any given point in time the office is either quiet as a mouse, with people silently working on their tasks, or abuzz with team members standing outside of the design office talking about a mechanic that is currently in development. Our "company" has become a "team" and nothing makes me happier than seeing the team excited about the project.
New Office Space
Speaking of offices, last October the team moved out of our old studio and into a new one that is almost twice the size! Rather than just being in a single, big, open-office environment, we're now spread out between two open-office floor plans as well as half a dozen private offices. We've got an extra conference room, a larger kitchen, a larger film studio, a larger motion capture studio with higher ceilings, and we've even got a server room now. No more storing our file servers in the kitchen!
The old office with our Soulbound Studios mural.
I'll admit it was bittersweet, however. The old studio was, while not the birthplace of the company, where we spent the majority of its early years. Moving on from one location to the next marked the transition from an infant or newborn company, into a company outgrowing its youth and becoming something more mature and capable. Remembering the NERF fights in the old studio is simultaneously happy and sad. On one hand, I can still remember when Aurora dislodged Strider's retina with a well-placed NERF bullet. On the other hand, every studio has to grow up just a little when they're ready for success.
The wall mural in its new home, seen through the office window.
New Hires
Part of the excitement and energy in the studio comes not just from the new digs, but from the new blood in the office. As we carve out huge chunks of gameplay features and world generation and prepare for players to get their hands on the game, it's become necessary for us to once again grow the team. So, over the last month, we've been running candidates through the office to meet the team, show off what we're working on, and grill the candidates in what seems like a never-ending parade of interviews. But seeing the excitement by the candidates has further ignited the passion of the team! And while the process can be a little disruptive at times, it's also resulted in some great new team members.
A few weeks ago we brought Willie, a new animator, into our office. Willie has been working with our Sr. Character Animator on combat animations. We've also just recently hired two new Technical Designers that begin on Monday. A very experienced Sr. Technical Designer named Steven, and an impressive, talented Jr. Technical Designer named Jasmine. We're really excited about having them as part of the team, as that'll make implementation of gameplay mechanics go that much faster.
But those three aren't the only new people we're looking at. I got a chance to look at my internal HR board and, over the last month, I've overseen up to 17 different people going through the interview and hiring process. That includes engineers, designers, animators, environment artists, graphics designers, UI/UX designers, and even a new Director of Marketing.
The sheer number of interviews and hires we're doing right now is a sign of the growth we're looking for in 2019. And that growth means faster development, quicker releases, and more polish on the work we do. In short, the new spark of talent in the office is what's adding to that electric feeling in the air here at the studio.
State of the Game
You've probably heard the saying "insanity is doing the same thing over and over again expecting a different result," and while I can tell you that is not, in fact, the definition of insanity, I can tell you there is still some merit to the idea. For us, it insinuates that if we attempt to build Chronicles of Elyria in the same way as every other MMO, using the same tools and methodologies, we'll likely end up with a game that is very similar to those other MMOs, will take about as long to develop as they did, and will cost just as much. None of that is attractive to us.
So we develop CoE using slightly different paradigms than people may typically be used to. Furthermore, we use every opportunity to innovate, to try something new and different, and to employ best practices which either increase productivity or reduce overhead. This all results in us trying some things that may seem impractical to some, but are ultimately designed to allow us to do more, with less.
If this is the first State of Elyria you've read, or if you're unfamiliar with our software development paradigm, let me quickly catch you up.
Our Method of Success
First, we approach Chronicles of Elyria with the idea of developing "breadth first." That means that once we've demonstrated to ourselves that we know how to do something or are capable of doing something, we often move on to the next thing without making much further progress on the previous thing. That may seem a little backward, but it's designed to get the hardest challenges out of the way as quickly as possible.
As an example, in the earliest days of CoE, we established that we could move around the world and interact with things using our male character model. There wasn't, at the time, a need to develop our female model as it didn't provide any additional validation for that use case. So for the longest time, we didn't have a female model.
This type of approach has continued in all areas of development. For example, we established that we could create our own architecture and build our own structures. We did this with the Neran style of architecture as it was the architectural style with the most available source material. We didn't need to focus on any other architecture at the time, as it didn't provide any additional validation. But just like with the female model, we're now going back and working on some of the additional architectures and buildings.
Another thing I wanted to comment on is our philosophy on iterating when it costs the least and provides the least amount of overhead. It's commonly understood in the game industry that it's cheaper to modify a concept piece than it is a 3D model, and it's cheaper to manipulate a model before it's been weighted and animated than after. We apply this same principle to all areas of development, not just content.
As a result, we architect our game such that the client and server can be iterated on independently of one another, and we even go so far as to develop multiple clients that allow us to iterate as quickly as possible during each stage of development. But just like a concept is ultimately used as reference for a model, and a model is needed before you can animate anything, our different clients either become part of the final game, or provide a frame of reference in which we can build our final client upon.
The development of an early test client is a core part of our different development stages and is pivotal to our strategy of iterating quickly. And in case you're unfamiliar with the typical development road-map, here is ours.
- Pre-Alpha
- Alpha 1
- Alpha 2
- Beta 1
- Beta 2
It's important to note that because of our different approach to game development as well as our procedural and systems driven approach to both gameplay and world building, it's not always easy to show visible forward progress. Sometimes we're focusing heavily on the server, which doesn't show well. Sometimes we're working on stuff that can be visually represented, but we've stopped just far enough into development to validate a mechanic, but not so far as to make it visually appealing to the players. As a result, there are often periods where there is more progress than we can reasonably share without expecting people to look at it and go, "You're not as far along as we thought." In truth, we're probably further; it just isn't obvious due to our development methodologies.
So where are we in development right now? Let's talk about it.
Current State
Chronicles of Elyria is currently in the Pre-Alpha phase of development, which both describes a deliverable as well as the type of work we're doing. As a deliverable, the Pre-Alpha phase for us means delivering a client and server that allows our Alpha 1 backers to get in and play a subset of the Alpha 1 features in a fully playable game. As a descriptor for the type of work we're doing, it means we're focused on getting a functional client and server, as well integrating a lot of the game mechanics we've worked on in various prototypes previously. In specific, the Pre-Alpha includes the following feature areas:
- Access Restriction
- Artificial Intelligence
- Character Creation
- Combat
- Contracts
- Crafting
- Dynamic Environments
- Equipment & Inventory
- Identities
- Knowledge & Gossip
- Lifecycle
- Locomotion & Physics
- NPC Interaction
- Procedural Story Engine
- Reputation & Fame
- Skills
- Survival Mechanics
- World Interaction
Now, most of the server work was done back in 2017 and 2018, so the vast majority of work being done right now is on integration and iteration of the above gameplay mechanics into our client, as well as work on our new user interface. Since October of last year, we've been iterating on all of the above mechanics in one way or another, and progress is coming along at a speed and quality that makes me indescribably happy, because I am finally seeing my vision of Elyria being forged into our shared reality.
OR
Caspian - Adventure Completeion: From Pre to Alpha
Hail Elyrians!
As the leaves transition from their summer greens to autumn hues of reds and yellows, so too are the intrepid adventurers here at Soulbound Studios transitioning from their previous adventure to their next. Which means it's time for our adventure completion blog post. Before jumping in, feel free to familiarize yourself with the goals we set for ourselves at the beginning of Adventure 0.4.0 by checking out the Intro Blog as well as the Update Blog. Once you're done, or if you're just too eager to see how things turned out, then settle down with some warm apple cider or some hot tea and read on!
Building New Systems
While there's certainly no shortage of screenshots or concepts below, as I sat down to write this completion blog I did note an unusual absence of any pictures or illustrations of the systems and gameplay we've been working on in 0.4.0. I mean, we've got plenty of pictures we can show of the environments we're building, items we've created for crafting, farming, and other systems (many of which we use for our Thursday Shinies), but there's still a notable lack of images and videos of new gameplay from this release.
In truth, the lack of images is a symptom of our approach to game development and not due to any lack of progress. But even still, I felt like an explanation was due that helped readers understand just how much progress was made in 0.4.0 and just how important that work was. The best way to explain where we are in development right now is through an analogy.
Building a game like Chronicles of Elyria is a lot like designing and building a new car. Back in 2015 when we first started talking about Chronicles of Elyria, it was a lot like sharing the spec sheet for CoE. We talked about the major systems, how powerful the engine would be, what kind of mileage people should expect from the game, etc.
But just like with cars, people quickly wanted to see what the game was going to look like. So we spent time working on the body of the game. In MMO terminology, that's the client. It's the part people can see and what many people use to compare one game to another. Back then we worked on a lot of prototypes involving the client. This included prototypes and demos of our aging & dynamics systems, our world interaction system, weather, combat, crafting, parkour, and a few others. All of which were designed to test out ideas and player reception, by showing the "exterior" of the game. But, in our car metaphor, those were all scale models. They showed what the car would look like, but they were built on temporary chassis that needed to be replaced before real forward progress could be made.
Of course, we knew we'd eventually need to road test the game so we started development of our powertrain. In MMO parlance, that would be our back-end server architecture. In fact, the vast majority of 2017 was spent building our drivetrain. This work continued over into the first part of 2018 as we began work on other major components of the powertrain. But even still, we didn't have a functioning game yet. There's just more to a car than the powertrain, the steering wheel, and the body.
And that's what Release 0.4.0 was all about. It was about manufacturing all those other parts that make up a car. Breaking from the analogy, release 0.4.0 was really about building base implementations of the various game systems necessary to have a functioning game. Now, due to our unique approach to software development, those systems were all built in isolation from the main game as part of a smaller manufacturing process. At first that may sound silly. But consider that automobile companies don't build their parts into the cars. They manufacture and test their parts separate from the vehicles, and then assemble them together afterwards. The same goes for us. That, incidentally, is the reason why, in spite of all of the design and engineering completed in 0.4.0, there's little we can actually show yet. We've got a lot of independent parts that still need to be assembled into a larger product.
>
While I don't want to steal the thunder of the 0.5.0 introductory blog post coming later this week, this is precisely what 0.5.0 is all about. Release 0.5.0 is about assembling the parts we've just created and seeing how it all looks when put together. In short, completion of 0.5.0 gets us to where we finally want to be; able to show off the game as a functioning product, and not just a set of independent, disconnected parts.
With all that said, 0.4.0 did allow us to implement several new systems, as well as iterate on some existing ones. Let's take a deeper look at what systems we touched in 0.4.0.
Manufacturing New Parts
>
While we had originally planned to launch pre-Alpha with nothing but walking and talking (and then gradually introducing new features), we decided after completion of 0.3.0 that the world felt too sparse, and the mechanics too thin to provide any real value from testing. After all, what kind of feedback can the alpha testers provide if there's nothing to give feedback on? So in 0.4.0 we aimed at getting implementations of as many Alpha 1 features as possible, as well as iterations on a few other established features. These base implementations aren't final, mind you, as there would be little value in the pre-Alpha if we weren't willing to iterate on, and make changes to, the initial releases. But they still provide a base implementation we can get feedback on.
Newly Implemented
A lot of new systems were worked on in 0.4.0. But here's an overview of the work done on some of the most important ones.
Artificial Intelligence
While we had more or less completed the design of our NPC and creature AI, we had only implemented one-off actors to fulfill specific roles. In release 0.4.0, we began implementation of a more general goal-based, need-based AI system, complete with a node-graph authoring system to allow us to customize NPC behaviors without having to go all the way into code. If we play our cards right, this node-graph AI system will be the same system and interface used by players to script their own OPCs, post-launch. While there's still a lot of iteration left on this system, and a lot of clean-up before it can be put in the hands of players, here's a quick glance at a fun node-graph we made to handle an NPC interaction scenario.
Crafting Stations
While we already had a blacksmithing demo and working system prior to 0.4.0, this release saw implementation of a new framework for quickly developing new crafting stations. The end-result is tighter integration with our world-interaction system and a deeper understanding of how stations will work; both from a design and engineering standpoint. The integration with world-interaction and survival also allowed us to create a few non-crafting stations, such as wells and water fountains, as well as fire pits, tents, and bedrolls for keeping warm.
>Family Narrative
Although we had worked on character creation in the first few releases of CoE, we had skipped the family system and focused on creating wards. In Release 0.4.0, we began work on character creation utilizing the family narrative system. This is a series of background prompts and historical narrative that players will go through during character creation that allows them to both filter the world for matching families, as well as set their starting values for skills and attributes. More work remains on this system, but it provides the groundwork for character creation with families.
Personal Destiny System
Not to be outdone, we also worked on the personal destiny system in 0.4.0. It was already thoroughly designed, but in this latest release we implemented our first iteration of the mechanics which allows us to take the year, month, and day of a character's birth and generate the set of conflicts and unique story arcs the character might experience in their lifetime. The Personal Destiny system ties in heavily with our dynamic story engine and will continue to get love in 0.5.0 as we work further on dynamic story-telling.
Souls
Similar to the Personal Destiny System, we already had a design for Souls but hadn't previously connected it to anything. Which is to say, while you could pick a soul during character creation, it didn't bring with it the skill ramps, etc. Now, it does.
Identities
Moving outside of character creation again, we also did work on Identities in 0.4.0. This ties in heavily with so many systems that while it's not particularly complex by itself, it's a cornerstone that needed to be implemented before many other systems could be started. With 0.4.0 out of the way, many other systems now think about your character in terms of their identity, not some absolute character ID. As a result, it's possible to swap between your main identity or an alternate identity, changing the way you interact with NPCs and contracts.
Contracts
Speaking of contracts, one of the first systems to use character Identities is the Contract System. Release 0.4.0 saw the first implementation of contracts as functional game elements that can be initiated, tracked, and completed. We also implemented a few of the starting clauses and conditions for completing a contract. Beyond implementation though, iteration work we did on the Skill System, combined with work on Knowledge and Gossip, did result in some pretty amazing changes to the Contract system. I'd like to go into more depth, but the recent changes in the Contract System really warrant a design journal all on its own.
Environment
Finally, while we had client-side weather effects before, we didn't have any server-side weather system. In release 0.4.0, we implemented a base version of dynamic temperature change, humidity, and weather patterns. This allows areas to change their weather dynamically over time, driven by a larger weather system. This of course ties into the survival system, which, while something we'd already begun, did see some additional functionality in Release 0.4.0.
Re-Visited Systems
In addition to the previous new implementations, some systems got additional functionality, while others got some re-design. Note that the ones that are undergoing a bit of a re-design don't necessarily have new implementations yet, but will during Release 0.5.0.
Survival Mechanics
Previously we had the basic survival mechanics in place. Characters had fatigue and energy, as well as hunger and thirst. But getting more hungry or thirsty, or getting more fatigued would only cause you to drop to 0 vitality. That was it. In Release 0.4.0 we added incapacitation and our first version of spirit walking. We also added several new survival mechanics such as a wounds and status effects, as well as homeostasis. As mentioned before, with the addition of dynamic temperature and things like fire pits, it's now possible to control your body temperature.
Skills
Skills continues to see some of the heaviest re-design in CoE. When we first proposed CoE we had the goal of making all actions a player could take require some combination of character skill and player skill. As you can imagine, this required the development of some artificial constraints and UI in order to make sure there were components of both player and character skill. But if you think about it, there are many different actions a player takes that could potentially require mostly character skill, mostly player skill, or no skill at all. And in some cases, even when no character or player skill is required, there's still some degree of character or player knowledge required. The recent changes are worthy of a new design journal, but 0.4.0 saw some significant streamlining and improvements to what we had previously described as our skill system. Stay tuned for a blog on skills, knowledge, and related mechanics.
Combat
Another system to see some significant re-design in 0.4.0 was our combat system. For those following along, we had an initial implementation of our combat system as early as the beginning of 2016. This combat system used a combination of techniques, combined with dodging, parrying, and deflecting, to create a combat system which was easy to learn but difficult to master. Success was based on timing and your ability to anticipate your opponent and counter effectively; much like more traditional fighting games. To show off the system, we took a version to our very first PAX East showing. But then in 2017, as we transitioned from technical demos and proofs of concept to an online game, we held off on re-integrating the combat system in our parkour demo so the high-adventure feeling of jumping from platform to platform and sliding down a zip-line could really shine. Instead, we implemented a slightly simpler combat system just to make sure the combat experience wasn't entirely missing.
But now we're working to re-integrate a variation of our original combat system into the game again. I say variation, because while we liked the overall feel and flow of combat, it lacked variety. Being based on combinations of solely left and right mouse clicks meant combat was always initiated one of two ways. This felt constrained, so in 0.4.0 we began implementation of a new system of combat utilizing dynamic stances that allow for a bit more variety. This work will continue in 0.5.0.
Knowledge
Finally, 0.4.0 saw the first draft functional design of the Knowledge and Gossip systems. This isn't high-level. This is down in the dirt details. Details about what type of information can be learned, how it's learned, and how information can be transferred to others. We even created a paper prototype game that allowed us to explore and demonstrate the ideas to other members of the studio. We began our first draft of the implementation system in Release 0.4.0, capturing and recording events your character witnesses for use in the knowledge store, but there's still so much more to implement here I put it in this section. But this feature area will get a ton more work done on it in 0.5.0.
Ready, Set, Vote
In addition to work on the game itself, myself and Orlando spent time in 0.4.0 working on Map Voting. Map Voting is one of the events that people - myself included - have been anxiously waiting for. Once Map Voting begins players will get to take part in an historic event - selecting the world maps for the different servers. Something that, as far as I know, no MMO player has ever been able to do before. And once Map Voting ends, players will finally be able to see the lay of the land and biomes for their servers. Furthermore, with map voting out of the way, we'll be just a stone's throw away from Domain & Settlement Selection, which is one of the most anticipated pre-launch events we'll have.
With Domain & Settlement Selection, all those kingdoms, duchies, counties, and settlements that exist on the starting continents can finally be claimed by their sovereign! Players can start communicating with confidence which biome, tribe, and environmental effects best describes the experience they're offering other players. Furthermore, they can adequately plan for launch and begin recruiting in earnest.
Getting Map Voting out the door involves not only having maps to vote on, but a portal in which to vote in. While work on world generation continues, in 0.4.0 we all-but-finished the map voting portal. You'd previously seen the wireframes, then the graphical design. Below are some screenshots of the map-voting portal as it exists today.
So, I know what you're asking: "When is Map Voting?!" While we've got a date in mind now, I'll leave the exact announcement of when Map Voting begins for the 0.5.0 Intro blog coming out later this week. Because, you know, it's going to be during Release 0.5.0.
The Evolution of Pre-Alpha
Thus far, I've mostly talked about what the engineering and design guilds have been up to, but the art guild has not been idle. Before I talk more about what the content team has been up to though, it's probably a good idea to provide a bit more information on our development approach.
Our approach to development is something I've referred to in the past as our Rope Bridge Philosophy. Which, while I won't go into great depth here, is about building thin vertical slices of our systems and solutions - in isolation - and then iterating on them quickly and frequently. Our implementations focus heavily on developing with SOLID design principles in addition to a couple of our own principles. In particular, we try to develop CoE in a way that allows for "Separation of Concern", "Iterate Where it's Cheapest," "Code by Necessity," and "Optimize Last." Of these principles, the first two are particularly relevant to what the art guild has been working on.
Separation of Concern
Separation of Concern from a SOLID design standpoint means making sure the code and systems we develop are only focused on a single responsibility. There are many benefits to this approach that can be found on the web, but we've taken it a step further. For us, Separation of Concern means being able to develop the game independently of one another, so that nobody on the team is ever blocked by the work someone else is doing. This means separating not only the client from the server, so they can be worked on independently, but also separating the engineering from the content. This is the primary reason we've been developing CoE with two separate clients; a high-fidelity, high polygon client you've come to know as the CoE client (so the content team can work separate from designers/engineers), and a low-fidelity, low-polygon client you've come to know as the Pre-Alpha Client or "VoxElyria" (so the design/engineering teams can work independently of the artists).
Iterate Where it's Cheapest
In addition to Separation of Concern, we also try to iterate where it's cheapest. This concept is again seen frequently in project management, as it makes logical sense to do R&D where it's least expensive; but we've taken it a step further with our development of dual clients. Whereas concept art allows you to iterate and discard ideas quickly before moving on to 3D models, and where 3D models can be iterated on and discarded before moving on to animations, our development of dual clients allow us to test and validate our functional requirements and designs while spending as little time on art and content as possible. Of course, what designs and features we can validate has changed over time as we've attempted to make the pre-Alpha more accessible to players, and as the need has arisen for us to be able to test more functionality.
ElyriaMUD
When we first talked about our design methodology and rapid prototyping back in 2015/2016 we were talking about ElyriaMUD. The intention was for it to be a text-only RPG that would allow us to implement core game mechanics without having to worry about assets at all. Such an implementation requires the least amount of coupling between engineering/design and content you can possibly imagine. It actually allows us to test and explore new mechanics pretty quickly, and the simple nature of the implementation means even our designers can, using our chosen language of TypeScript, write and test new gameplay mechanics. I say "allows us to," because while nobody knew it, we did actually implement ElyriaMUD. ElyriaMUD has been in use even as recent as Release 0.4.0 to explore new functionality without having to involve the content team. Work done in ElyriaMUD can be implemented and tested, and then migrated over to one of the other clients. While we've never actually shown ElyriaMUD before, I figured now is as good of a time as any to share pictures of it. Here's a few below.
I can't seem to find Caspians apology post when SBS could not deliver on pre-alpha and basically comes out and said that they lied about the progress being made and it got so out of hand that they could not lie about it anymore since they were not going to deliver on Alpha despite working overtime and being stressed out etc and had to come clean.
At which time he vowed to double down on quality vs quantity and take more time to develop the game properly.
As you can see in the posts above they make grandeos claims after claim after claim that they have so much stuff and there is so much progress and everything is happening so quickly. They claimed a lot and they have shown litterally nothing this whole time. They claim to have all the concept art and a bunch of assets back in 2015 and yet we are still getting concept art instead of assets or animated assets.
I honestly dont see anything really resembling what they claimed in terms of this fast progress or all the things they seem to be working on or have worked on.
This company has no idea of how to market or sell a crowd funding game and treat it like some kind of hidden secret that nobody should ever know whats going on under the hood.
When you run a crowd funded game showing progress and generating interest is key to the very survival of the game. It amazes me they got this far without really showing anything worth paying attention to. It wont last forever without showing that progress.
