In a surprising turn of events, a flash of flame incinerated Tyler, leaving little other than the memory of his hugs. Has anyone seen him? Near his desk, there’s a suspicious pile of ash, but no one has yet dared to go through it and see if there are any charred bone shards remaining. No doubt it was more than mere coincidence that a large, winged creature was spotted flapping away from the scene. Alarmed citizens claim to have heard a terrific, thunderous roar flooding the air soon afterward. Further reports after lunchtime ends.

We released a checklist of tasks (which can be found at our website, www.camelotunchained.com), which need to be completed before Pre-Alpha Tests can begin, and we’ve been having lots of fun checking off boxes. It may be just a little silly, but we think it’s pretty exciting as the PAT checklist fills up!

Welcome to the section where we talk directly to you, the Community! Here is where I take your thoughts on the forum and attempt to give you more information on all those unanswered questions!

Q. When will we see a new approach to board discussions at large? To clarify, more dev-driven discussions with hard, important Q&A, and less non-stop speculation run amok? Just one or two topics a week would be awesome.

At this point in development, you can see from our PAT checklist that we’re pretty full up on things to work on, so there isn’t a whole lot of new “something to think about” forum feedback we’re trying to gather for now. Once we get our checklist finished and start running more frequent tests, you can expect more surveys and a higher frequency of directed forum discussions. We need the ability to modify/test things on our end without committing to something now that ends up needing to change. That said, I am already planning some other forms of sharing that might satisfy your hunger for dev info! Also, keep in mind that as we get closer to Alpha, there will be more discussions started by our developers in the Something to Think About threads.

Q. For people that play odd hours, (outside the daytime EST) yet have lots of time, when do you think, or do you think, we could be an asset to do IT? Or, when do you think semi- or round-the-clock IT testing could be done? (question applies to when client is up, of course)  

We are really appreciative of those who are in IT right now, or have been from the beginning! For now, ideal candidates are those who can come into the client during business hours EDT to do impromptu tests on-demand when we need a quick response. However, the servers are open to IT just about 24 hours a day, so there’s testing going on all the time, and they are always jumping on to help out as their schedule allows.

Q. Do you keep a running list of the forum ideas that you think have potential to be implemented in the game? Would we ever be able to see/discuss such a list?

I would say that the forum ideas inspire internal conversation when the topic is timely to what we are working on at the moment. We have a search feature, and a very deliberately designed forum, so our developers can go right to the current or old areas they want to see when those systems start being actively designed. As to the second part about such a list or conversation, no way! 😛

Q. Will we be able to get out of NPC boats early, or will we have to ride all the way to the drop-off?

This is a mostly seamless open world, which means that there is no zoning in the traditional sense; only internal zones for us to split things up (The Depths™, starting cities, etc.) for the engine so there are minimal loading screens. There might be ways to decrease the ride time if you have a port on your property, are a water mage, or similar things. Who says you won’t be able to jump off and swim? None of these have been fully explored yet, so take them only as my thoughts!

Q. Will caravans be sharable by more than one person to move goods, like can I share one with someone and make it more powerful and safe?

If you are asking if one caravan can hold goods for multiple people, then yes. You can definitely expect there to be ways for you to conscript someone else to haul your stuff from point A to point B for you if you don’t want to do it yourself, and there may be a way to group up with a bunch of friends who all want to transport stuff together, and assemble a caravan of the appropriate size.

Many thanks to Quentin for sending us awesome fan art! We really enjoyed looking through your work for hidden jokes and stuff. You cracked us up with your “Mark as a TDD art!” Now, for our next contest, we’re gonna send you wonderful folks to the forums. Take a photo of yourself or your pet making a face that looks like our current Banshee art, and put it into the contest thread on the forums!

Thanks so much to Raygar and the DAOCU group for this hilarious gift! Mark will just never live down the time he bought a Bobby Sherman record for his sister and got caught with it. You gave us all a huge laugh with the record and secret messages!

Map size is one of the defining characteristics of any open-world game. If the world is too large and sparse, players spend the majority of their time running from place to place. On the other hand, if it is too small and dense with points of interest, it is trivial to get anywhere at any time and the game feels less like a world and more like a theme park. We need to find the correct size, somewhere between the absolute minimum amount of space for everything we want in the world to physically fit, and the absolute maximum amount of space the game engine can support. Fortunately, there are some guidelines that help decide the scale of a game world, and determine how big is too big and how small is too small.



Firstly, the type of game matters, because it frames the considerations for what makes the size of the world important. In our case, we are making what is essentially a medieval fantasy war game conquest map, which means things like territory and resource control, logistics, and force projection are extremely important considerations, but things like good quest flow are less so. This requires the size of our game world to move away from the small side of the scale, because we want the time it takes to get from place to place to be significant enough that it is not too trivial to move assets between points on the map that are far apart. That way, we create windows of opportunity during battles that rely on that mechanic.



Another consideration is travel speed. Changing the speed at which entities move through the world makes the world feel smaller or larger. The faster players move in our game, the larger our map needs to be, if we want the time required for players to get from place to place to remain the same. Travel speed, on the whole, means more than just player run speed. It includes boats, caravans, and any other means of getting player characters and assets from place to place.



Pacing is another vital element of a fun game that is greatly affected by world size. Even though we don’t have direct control over points of interest in a world full of player-built structures, we can strongly influence pacing by the way we populate the world with strategic locations and resources, and how we handle respawning. Even in a very large game world, we can ensure that combat isn’t a rare and brief occurrence. Mainly, we have to make sure to place key locations such that fortifications can be built along front lines, located relatively close to one another, and to allow respawning nearby. These choices allow the ratio of time in combat to travel downtime to become balanced.



So exactly how big is our game world going to be? How large is each island?  How fast can players run? How fast are boats and caravans? How much can boats and caravans carry?  We’re a long way from finalizing these decisions. At present, we’re modeling combat movement speed at an approximate base of 4-6 meters per second, and our temporary pre-alpha testing map size is 400×400 meters. During Alpha testing, we hope to get combat travel movement speed implemented starting at around 10 meters per second with a temporary 10,000×10,000 meter map, which will give us a better feel for movement in a more reasonable space. The next step in map building is to go much bigger. Exactly how much bigger I can’t say yet, and it’s definitely going to take some iteration to get right.



Some of our most important goals are making logistics matter and mitigating force projection. Between land and sea travel, you can expect getting from one far corner of the map to the other to take hours rather than minutes.



Of course, since we want RvR combat to be the main focus of the moment-to-moment game (for non-crafters), we’ll try to make sure you won’t have to travel for anywhere near that long when you die on the front lines and want to get back to a protracted battle, no matter how big the world is. On the other hand, if there is an important battle going on far from where you are when you log on, don’t expect to be able to get there and help out immediately.



We need localized battles to happen at a variety of objectives spread out across the entire map, rather than only ever having one or two huge fights at a time that draw in everyone from across the entire game world. Players who build their homes, outposts, keeps, and cities in one part of the map should expect to have a regional area of operations relatively close by, rather than traversing the entire world every day to find the one place where everyone has come together to fight.

I hope this has given you some insight into where we are going with our game world, and why it is important for us to provide a large amount of space that will take players some time to traverse. There is still a lot left to do before we get to show you a glimpse of everything Mark laid out in the BSC map presentation. Still, as you can see from our Pre-Alpha Test checklist, we’re making big steps with larger maps and more well-defined movement rules, and you can expect to see more improvement through pre-alpha and beyond.

Greetings from the Art Team. I’m Scott Trolan, Art Lead/Animator here at CSE. As always, we’re busy making “ALL THE THINGS” for the ever-watching eyeballs of 20,000+ backers – thats like, what? — 40,000+ eyeballs if you do the math, but I’m an artist so I could be off by a +.



Lately, the Art Team has been responsible for delivering a new Tuatha Dé Danann race for gameplay, Arthurian Storm Rider concept development, art and character rig pipeline improvements, Web and UI assets, and supporting the programming team as they roll out a little thing called PRE-ALPHA Testing. 



For the BSC days, we created a new giant race for two of the three realms. Sadly, the Tuatha Dé Danann Realm lacked their giant. As soon as we were able to pick back up on character development, we went right to work on the Fir Bog giant. The Fir Bog was concepted by Michelle and Sandra back in April, so we were really excited to get her into the Camelot Unchained lineup of playable characters. Mike M. has done a beautiful job sculpting and rigging the Fir Bog, making it a true privilege for myself to animate and import into the editor.  



From the time the campaign to raise support for Camelot Unchained started until fairly recently, we designed our characters as what we call “one-offs,” meaning they were un-customizable for MMO character creation. They were sculpted with full garments and personality to showcase our artistic vision for the games inhabitants. We are now at a phase where we have the programming support to design our characters with the expectation for customization and optimization. We are establishing that new pipeline now, as we develop an Arthurian race, the Storm Riders. Once the pipeline has proven successful, we will have better abilities to reuse textures, re-target animations, and customize character appearances.  



Currently, we are working office-wide to deliver our Pre-Alpha Testing (PAT) release. This is has involved everything from testing, updating, uploading, adding, fixing, to kicking art assets into submission. Mike C. has been knocking out amazing VFX, considering the small amount of time given to him to do so! James K. has been assisting the Web/Programming team with gorgeous graphic and UI/UX design! I have been working closely with programmer James B. on skeleton masking and multi-part animations. Tyler, man of many hats, adjusted world terrain for objective gameplay and made a plethora of beautiful rocks. 



Soon, you will be able to see everything we’ve been working on so hard since the BSC days. Thanks for your interest and feedback on the forums! We’re always listening!

State of the Build

In the run-up to Alpha, we’re trying to provide more timely patch notes for our Internal Testers about the changes to the game. This not only shows off the hard work we’re doing, but it also gives our testers areas to focus on for testing. Here’s a peek at some of the work we’ve done this month, as we get Alpha in shape to present to a wider audience.

• Natural splines, for all your smooth curve needs.
• Physics engine now supports forcing players to teleport around.
• Fixes in testing for Relay/Listen server, which will improve general stability of all of our servers.
• Character persistence is in: position, kills, health, and facing will now save when you log out/in. Aw, no more free heals when logging out.
• Client now logs crashes to the server. Makes it so we can get better information when it crashes on player machines.
• The sky is now data-driven. This won’t change anything just yet, but it paves the way for more dynamic skies. 

Spotlight: A Week in The Life of a Game Programmer

People wonder what it’s like to be a game programmer. Here’s a little peek at what I’ve been working on.

Developing games, particularly MMOs, is a team effort. We might say that someone created some system in the game, but the reality is that much of the work is shared. One of the most important attributes of a game programmer is to be able to work with other people.

I was tasked with creating a “control game.” Control points in the world allow each faction to capture it and earn a score during a 15-minute round. The goal is to give the alpha players something to do besides just log on, sling around a few (very cool-looking) fireballs, then log off. We don’t have keeps for players to fight over (yet), so for now players will be able to fight over a City State Entertainment favorite: ducks!

Let’s start at the beginning. The control game was decided and scheduled by the team leads.  Mark, Andrew, and Tyler decided I would be the best person to work on this system. My first step was to talk to Mark and Ben about the general shape of the system. We wanted to keep it simple, and we discussed some basic rules. Ben then wrote down details about those rules for a game system for me to use.

After that, I started looking at the code I would need to create. Are there any existing systems that I could re-use? Well, the control points want to know when someone is nearby. The trigger volumes we use for the cloud effects in the game do that, so I could re-use the physics work that Rob worked on.

As I ran into problems, I talked to other programmers for suggestions. Tim helped with some game logic, JB gave me a few ideas for how to deal with objects on the client side, and Rob stepped in and helped me clean up some of my client code. The control game publishes the score information via the Web AI, so James Koo and Bryce created a UI element to show the score and game status. I also continued to work with Ben to adjust some of the gameplay based on our changing needs.

Of course, we need art! I couldn’t wait for the artists to create assets specific for this system, so I re-used other assets for my tests. Player models represented who controlled a point, and I re-used other particle effects to indicate capture. In this image, it might look like a hamadryad is being burned in a fire wall, but this actually indicates that an Arthurian is trying to capture a TDD control point in the prototype version of the game. Mike and Tyler will create the lovely assets the Alpha players will see.

Finally, the code goes into review. This means that other programmers take a look all the code and suggest improvements or spot bugs before they are released. Tim, Rob, and Bryce were the lucky ones this time. When they approve my changes, it will get added to the game, and the testers will be able to take over control points in the world. Then, on to the next task! But that’s a story for another time…