September Summary

Engineering Status
We have just completed our Milestone 7 objectives. In our last update, we introduced each person on the team and gave a few details about the area of work they do. In this status update, we’ll look at a few of our major goals for Milestone 7, and then talk about our completion of that section.

Inventory Interfaces
As we develop Horizons, we think of better ways to perform particular functions. Our designers put a spin on a concept, introduce something new, or someone in the company makes a suggestion that adds a lot of value. This process can result in the development of new interfaces, or revisions to existing ones. For this milestone, we looked at the interfaces we’d like to revist, came up with many, and after considering the timeframe and other tasks we had, selected one: Inventory.

Our first pass of inventory, as with most other user interfaces, focused on implementing core functionality without too much visual appeal (read programmer “art”). This allowed us to develop and refine the core UI systems and client to server messaging without having to worry too much about how the information was presented. An additional result of this process is that our inventory system is loosely coupled to the interface, allowing us to make changes to how the player interacts with the inventory system with minimal code changes. For Milestone 7 we really focused ourselves on trying to revise the interface so that it was intuitive and allowed a player to get what they wanted done in a quick and easy manner. Representative interface art was generated, which, while being superior to previous programmer art, will be iterated to achieve even better results. More careful attention to the user experience resulted in core UI improvements and the development of additional widgets. The inventory layout was carefully considered, and after much discussion and several proposals - motion sensitive headgear to navigate was my favorite - we implemented what we feel is styled a very good interface. Testing with people who are new to the interface will tell us how good a job we did, what needs to be changed, or if we need to reconsider our approach.

Community and Community Features
The concept of community in massively multiplayer titles is rather new. Our documentation for community has undergone many proposals, revisions and much reflection as to what we want our user to experience, as well as what our technology can support. Interestingly, the process of honing and refining this system design has brought us down some technology implementation paths that we would have otherwise not considered. In the software development process, the initial requirements list is only the beginning. Good design allows additions or changes to be gracefully implemented with minimal structural reworking. With community, our design team made requests that really required us to reconsider how we were solving the problem of representing the world within the simulation. Through this process, we came up with a much better solution. Instead of the designers asking for functionality and there being a pause in the conversation, our discussions are turning more towards the engineering team presenting to the design team all the functionality they are looking for, as well as features they never dreamed of asking. Our revised design provides the user (our game designers) the ability to do everything they are looking for, and contains a framework that allows their new and creative ideas to become a reality.

Combat Systems
The process of combat between two or more players over a network connection is probably one of the most complex and temperamental systems to develop. Combat requires fairness between opponents, strong ordering and reliability of messages, quick visual response and feedback, prioritization of visual feedback and impressive visual assets. In Horizons, combat is one third of the available game play, with community building and trade-skills making up the remainder, but we know that a portion of our user base will make combat the majority of their game experience. With this in mind, our combat system must provide our players with a smooth, reliable and enjoyable experience - and this is outside of the actual game play design. We spent a significant amount of time adjusting how combat assets were developed and improved the timing and prioritization of animations. This allows the combat experience to be smoother and more synchronous. The prioritization system makes the display of model animations that are far away less of a priority than the player’s, or any character close to the player. Adjustments to how we prioritize messages between the client and server, and our method of setting messages to be guaranteed or not guaranteed for delivery, depending upon the situation, has reduced our bandwidth and improved the player experience when there is a lot going on. We performed a large scale combat test using magic, melee, and ranged characters to attack a Rock Golem. Throughout the office we had very high end machines, as well as low end machines connecting to our testing shard. After some small tweaks and adjustments, we impressively saw our system in action. It’s very tempting to take things further, but any more optimization at this point would result in unnecessary code improvements that would require revisiting at the actual appropriate point in development. Regardless of computer type, we have a system that allows a fair, timely, and impressive experience that is rendered with those events most important to the player as the main focus. It’s very rewarding to see how good our experience is today, knowing that it will only get better as we work towards the end of the year.

What’s Next?
At the end of every milestone we review our status, refine the requirements of our next milestone and set a delivery date. We keep a high level schedule of deliverables, but allow ourselves the flexibility to adjust our requirements set between milestones to ensure that we develop solid and stable implementations, as well as the option to reprioritize a feature because of technical or asset considerations. This flexibility does not mean that we don’t meet a milestone because things don’t schedule just right - just ask the staff who did a marathon job to make this last milestone happen – but rather, we can create a solid product and in the end, create the best possible game. Our Beta is coming soon and we’re working hard to have everything you’ve heard about and a few surprises ready for play!

Rick Simmons
Director of Engineering

[ Return to Dev Journal Index ]