Category Archives: Design

Engineering the Service Mindset

Posted on by
Comments

Hi, my name is Charles Hollingsworth and I am the Engineering Director for Xaviant. I have had the opportunity to transition our team from building traditional data-driven client/server applications to console/PC games. We have accomplished this by leveraging the powerful CryEngine3 platform, training our developers and then augmenting our team with experienced game engineers. We have adopted a dual mission on our engineering team: developing great software for gameplay AND providing a rich, stable infrastructure that maximizes the ability for programmers to “program,” designers to “design,” and artists to “art.”

20121107-142941.jpg

Focusing on core competencies from our enterprise-scale, commercial software pedigree has allowed us to construct our (game development adapted) Lean-thinking house to accomplish our mission.

Although buzzwords and fluffy diagrams are always cool and certainly required for any self-respecting blogpost, I would like to specifically elaborate on the mindset and tangible systems that facilitate our commitment to this model. Developing engine functionality for spell casting, loot management, AI, etc. is the obvious responsibility of any engineering team, but the delivery, accessibility, and accuracy of this functionality is where we strive to differentiate ourselves. Specifically, in this post, I will explain our Respect for People pillar and give examples of how we remain committed to this principle.

Respect for People, from an engineering perspective, means that we are firmly committed to supporting those who create the essence of player experience. This requires a bit of humility which is difficult to swallow since it is obvious to everyone (in the universe) that engineering is the most important component of game development. Seriously though, it is easy to say we are “Design Driven,” but this is not easily quantified on a day-to-day basis. So, we have set ourselves up as a support group. We verbally and organizationally commit to “a spirit of service” toward our internal customers which manifests itself in things like:

  • Extending the classic software “continuous integration” to include art and design
    • Hourly builds
    • Each hourly build is stability-tested by automated gameplay scripts and level walkthroughs
    • Real-time visual feedback on displays throughout our work space (image above)
  • Prioritization of development tasks based on impact to artist and designers tasks
  • Avoiding 100% utilization so that we can immediately respond to technical roadblocks
  • Updating task tracking system so that internal “customers” know the status of their technical roadblock

Adopting this “support” mindset has allowed us to avoid the tension that often exists between engineering and design/art. Credibility is earned here by eliminating wasteful technical overhead so artists and designers can spend the maximum time “building awesome.”

  • Hourly builds of all code changes, including bug fixes, available to all artists and designers with a 5 minute installation
  • Instant feedback from our ErrorTrax game log monitoring
    • Detailed error information
    • Meta-information (location, camera angle, file information) for quick defect reproduction

Maintaining this level of service raises expectations among the entire team and provides a healthy feedback loop for requesting tools and optimizations to further enhance workflow.

Additionally, “gameplay developers” extend our engineering team by actually sitting in teams with designers. This proximity encourages rapid iteration and allows the developer to precisely experience the designer’s workflow to create best practices gameplay systems.

Our flat organizational structure requires that every team member is personally responsible for eliminating waste and increasing the speed and accuracy of the aforementioned processes. In future posts, I will discuss how we promote this “learning” environment and implement the other pillars of our team’s philosophy: agile development and continuous improvement.

Level Process: Game-play Collaboration (…and stomping the ego)

Posted on by
Comments

My name is Tim Lindsey and I’m the Design Director here at Xaviant. The articles that members of the Xaviant team are posting on this blog each two weeks are intended to give you a glimpse into our studio, our methods, or challenges and every so often, our products.  This week we decided to deliver a small video preview featuring a section of one of our levels.  The focus is on how the team members collaborate without killing one another. :-)

Commentary by:

  • Sam Elder on Level Design
  • John Grello on Concept
  • Dan Brown on Environment Art
  • Scott Warren on Lighting

As always, please click through and view the HD feed to appreciate our work. Thank you.

-tim

 

The Siege Report: Our Post Conference Post

Posted on by
Comments

My name is Tim Lindsey and I’m the Design Director here at Xaviant. The articles that members of the Xaviant team are posting on this blog each two weeks are intended to give you a glimpse into our studio, our methods, or challenges and every so often, our products. In this post I wrap up Xaviant’s trip to the Atlanta SIEGE Conference and Lichdom’s first public Pre-Alpha public testing.

siegetestroom01_v1

My initial attempt at writing this article was a summary geared towards a public audience and, frankly, was boring.  After some review I realized that anyone reading this far should really only care about one thing.  How is Xaviant using their SIEGE play-testers and the data the testers delivered to better their product?  Below you will find an internal email, quoted in its entirety, that I sent my staff Monday morning after the testing.  The message is honest, highlights where we must improve to impress our fans, and reinforces our core values as committed game developers.  Enjoy this peek into the studio culture.

From: Tim Lindsey

To: All Lichdom Staff

This weekend over a hundred gamers visited the Xaviant Play-test suite at the Atlanta Siege Conference.  This is a brief and, most importantly, honest update for all Lichdom developers on the experience.  There is no “blowing smoke” in this message.  After reading this please feel free to ask for more detail from any of the designers or myself.

Our Siege mission was to “build community.”  Instead of delivering a demo where the conversation can be very one sided we decided to host play-tests to encourage a cooperative experience.  To facilitate this experience volunteers received 20 – 30 minutes of game time and 20 – 30 minutes of interview time with Craig, Jim, Ben, Sam, Michael or myself.  There were always 3 designers in the interviews collecting notes and encouraging feedback.  To reinforce the community building goals we reiterated that testers were playing a “Pre-Alpha” so that Xaviant could respond more easily to the players concerns and interests.

The feedback was very consistent over the course of our 16 interview sessions and even continued to be consistent with impromptu interviews with other local developers from CCP Games, Hi-Rez Studios, and Tripwire Interactive.  Below are snippets of the feedback;
    • “This is like Skyrim.”
      • We are being associated with a AAA product.
    • “I want to dodge.”
      • Design for this in the works.
    • “I wanted to jump when I saw the scroll.”
      • Jump was a non-topic until players saw a location that felt like it necessitated a jump (the scroll on the ruins piece).  More work needed on cleaning up these heights.
    • “I hit Q and E by accident.”
      • We are fighting the taught norm on this one a bit.  More testing to come with a quick toggle between 1,2,3 and Q,E,R.
    • “I spammed AOE.” and “I didn’t get Cone.” and “I used Cone constantly.”
      • Believe it or not, this means we have different emergent play styles that players are disagreeing over.  I won’t say that we have our spell attacks perfect but this feedback is a sign that we are heading in a positive direction.  
    • “I liked the targeting.” and “I wish I could choose when to aim myself.”
      • Simply put, targeting was a topic when it failed to predict the target correctly.  It was appreciated for the majority of the test and allowed players to focus on the casting and the effects.  Speaking of effects…
    • “The Fire effects are beautiful.” and “I didn’t like the ice effects…I thought it would be more of a blizzard”
      • Fire is the bar for visual and auditory quality and was lauded all day long.  Ice lacks the impact of Fire in terms of game-play impact and vfx thus the comments.  We have some solutions for this on paper to discuss.
    • “I didn’t realize there was loot.”
      • Lots of work to be done on showing people what they have been awarded.
    • “More defensive abilities.”
      • There was a strong desire for spells that manipulated space and bought the player more time.  This feedback will very directly influence how our additional spells will be designed and balanced.
    • “The environments are awesome.”
      • ’nuff said
    • “I’ll buy it when your done.”
      • I heard this as people exited the interview and as I saw them in the halls.  This statement means two things to us right now.  First, this is someone saying that we’ve earned some trust.  Second, this is someone saying that our efforts have value – this game belongs in their collection.
    • In conclusion.
      • “It was fun.”
This is just the beginning, folks, we now have gamers (hopefully even Fans) interested in our ideas and looking for us to step up and deliver.
-tim

Comics Instead of Calendars

Posted on by
Comments

Hi folks. It’s Tim Lindsey again, the Design Director here at Xaviant. The articles that the Xaviant team and I are posting on this blog each two weeks are intended to give you a glimpse into our studio, our methods, our challenges and every so often….our products. I hope you enjoy.

Just accurately understanding the scope of what you are asking for when designing a game is difficult.  Communicating that scope to your team in a way that is clear and consistent across all the talent and skill sets: that’s tenfold the challenge.  Enter the comic…

Artwork by John Bridges, Story by Michael McMain and Ethan Skemp.  Actual verbiage disguised in this example.

When Production, Art, and Design sat down to plan our attack on this project we chose to fold the creation of a comic into our pre-production phase. Like a storyboard for film or animation, the purpose for this comic was to iron out and make complete the story we are using as a “road map” for art and content construction.  This road map quickly and clearly demonstrated what locations and characters we were most invested in and what locations we hadn’t shown enough attention to. Sketching it all out in comics form gives us a better visual tool to see these discrepancies and allows us to cut some areas back and build up others long before time is invested in the 3D assets and level building.

Comics are particularly strong at portraying character personalities and relationships, and in using this format we’ve enabled our artists and designers to get a better feel for the purposes of the NPCs and locations as well as the atmosphere their interaction creates. These relationships are built with the intention of creating scenarios that motivate our player to take action. With the comic, we can effectively vet the emotional impact on the player of each stage of the game. One thing the comic is not intended to do is to lock down the look or visual design of the characters or locations, and the sketchy art style serves more as a placeholder for concepts that will be fully developed at a later stage of production.

We also worked to tailor the comic into chapters of similar length, each one representing a smaller story arc that occurs in a region.  These regions equate to Releases or Milestones for our team.  As we move through the production of different parts of the game we can refer back to the comic and confidently say, “at the end of release X we knocked out the Riftwood chapter.”  This sense of accomplishment and completion is invaluable.  Not to mention that flipping a page of our comic to glance at the next chapter provides clarity and confidence in our production path.

On occasion you still see a couple of Devs hunched over their desks rereading the printed comic, flipping pages, and hopefully getting lost in what our world is to become.

 

I’m Board…

Posted on by
Comments

My name is Kenny Davidson and I’m a Content Designer at Xaviant. Last week Jim touched on how we have used different documentation methods to help refine combat design. This post will talk about how Ben Collier, Systems Designer and Engineer at Xaviant, and I take that documentation and use paper prototyping to give rapid iteration on their ideas.

gametablecropped_sm

When it comes to designing combat and gameplay it can sometimes take time to get into a working state so you can test it and see if it works like you want it to. Design has to work with engineering to discuss what they want out of it and then engineering has to put this into place in the engine. By the time the code has been placed and put through a playtest a week has gone by, sometimes longer. Having a paper prototype (Board Game) in place also helps us to iterate on things much faster.

A paper prototype is basically our own pen and paper game. By taking the elements of our combat styles and core gameplay mechanics and translating them to a pen and paper game we can rapidly iterate on what works and what doesn’t.

We recognize that not every player is the same and we strive to support different play styles. Signups for play testing and commenting on the table top experience is open to everyone at the Studio. I have on occasion given not so helpful feedback but many have jumped in and helped us discover new and better ways to handle our designs. Examples of features we’ve tweaked based on player feedback are things like spell dynamics, enemy movements and actions, and intensity of encounters.

In a ninety minute gameplay session we were able to test a new spell that quickly became an issue. By issue I mean that the spell didn’t have the desired effect that we wanted. It wasn’t as balanced as we would like and it wasn’t as useful as intended. Ben and I made a change in the middle of this game that drastically increased the effectiveness of the spell. This not only made the player much happier, but provided immediate feedback for engineer planning for these features.

By paper prototyping we can get rapid feedback and it has been an incredible asset to our team. Sometimes I have had to eat my own words but I was happier for it because it led to a much better product.