Dark or Light

Steve "Istvan" Hartmeyer Dev Journal

Guest Writer Posted:
Developer Journals 0

Jumpgate Evolution: Steve "Istvan" Hartmeyer Dev Journal

Why did NetDevil choose to create a new, updated Jumpgate? How did the project come together. These are two of the questions that Jumpgate: Evolution Developer, Steve "Istvan" Hartmeyer answers in this new MMORPG.com Dev Log.

In the middle of 2006, NetDevil's plans for Jumpgate changed substantially. Scott Brown, NetDevil's president, approached me with the news that he'd decided the company was at last in a position to once again put significant resources into the game. Returning to Jumpgate had never left the minds of the company founders, who are in fact all members of the original Jumpgate development team. Until 2006, however, NetDevil's efforts had perforce been focused on other projects necessary to building the company.

Scott's proposals were welcome news to me. Part of the team since 2002 and in charge of maintaining the game since 2004, I'd been battling Jumpgate's gradual decline for years. The biggest problem Jumpgate had was modernity - a lack of it. After its 2001 release, there hadn't been a large enough team maintaining Jumpgate to truly keep pace with general MMO developments. Features and systems that are taken for granted in newer online games just weren't present in Jumpgate, or weren't as polished as the average player now expects. We were well aware of these problems, but the rate at which a tiny team could solve them was far too slow. Despite my efforts and those of my predecessors on the Jumpgate team, by 2006 nearly everything about the game had become dated and demanded improvement. Usually, games in this condition are abandoned by their publisher. NetDevil is in the unusual position, for a game developer, of still being in direct control of its product. Scott and the other company officers had the power to decide that Jumpgate will have a fresh chance at success.

Jumpgate was originally developed with a team of six, still very small by industry standards, but larger than the maintenance group had ever been. By late 2006 we became a team of eight, and the revamp of Jumpgate began in earnest. It has been a whirlwind since then. Despite the fact that we began with a completely functional and already running online game, the amount of work to be done still was staggering for such a small group. We began with two major design inputs: a long laundry list of needs I'd built during the past several years, and a set of three key areas for work we knew Jumpgate needed no matter what else we chose to do. The three key areas had priority. First, everyone knew the graphics had to be modernized to give the game any chance in the market. Few people look twice at obsolete graphics, no matter how great the gameplay might be. Secondly, we knew the original game was very unforgiving to new players. We had to take steps in many areas, from billing to user interface, to ensure that new players found the game accessible, not painful to play. Lastly, we walked completely away from one of Jumpgate's original design principles, the idea that every ship would be another player. That principle had already been compromised in the original game by the addition of a basic AI enemy, but we wanted to carry the technology to its logical extent. It was readily apparent that our planned work would result in a serious evolution of the original game design. That idea lent the new game its name, "Jumpgate: Evolution", internally shortened to "JGE".

Given the huge amount to do and the small team to do it, our Producer reasonably chose to get us going using a well-known agile development methodology called "Scrum". Ideally, we designate target tasks from a huge master backlog of things to do, break the tasks down as far as we can, estimate how long it will take to do each bit, and based on that estimate either fit the work into our current two-week sprint or place it back in the backlog for consideration next sprint. Our driving mantra is a push to functionality, so no one is wasting time working on more abstract stuff that might be useful "later". We're using Scrum to provide focus, and that focus is proving itself extremely effective for getting the right things done fast.

From scratch, we have constructed an AI system that uses algorithmic flight behaviors and simple messaging to do just about anything a player's ship might do. We're also using this system to mimic the original game's adversary AI ships, but with vastly more capability. JGE will be full of AI ships to interact with either peacefully or violently, as appropriate to the nature of the player, the nature of the bot, or just plain happenstance. The result will be a living universe utterly ripe with potential, which will evolve naturally based on interactions among both players and AI. As a result of our drive to functionality, major components of the AI system already have been fully functional for months. Now, further types of bots we need can be added simply by extrapolating from existing classes, and adding refinements. One member of our small programming team has been entirely dedicated to building, extending, and maintaining this powerful AI system.

NetDevil hired a concept artist with an industrial design background specifically for the JGE project. He was tasked to re-imagine the look of the game, and the results were stunning. Two of NetDevil's experienced 3D modelers were brought onto the team to implement the new concepts, and every single asset in the game is now being recreated. On the programming side, we ripped out the old DX8 rendering system completely. A new art pipeline was established, and NetDevil's two top graphics programmers assembled an entirely new renderer based on DX9. DX9 was chosen over DX10 due to our other key motivation - accessibility. When you want a game to be available to the most people possible, using bleeding edge technology doesn't make sense. We also implemented a new particle system for JGE, based on an enhanced version of technology that went into Auto Assault. The original game, which we're internally calling "Jumpgate Classic", or JGC, didn't even use most DX8 capabilities. For instance, it lacked bump maps, glow maps, and barely had a particle effects system at all. Between using the high end of DX9 technology, and the new look created by our art team, the graphics quality of JGE quite simply blows JGC out of the water.

To improve the game's accessibility, we have been looking very specifically at the first thirty minutes of play. In JGC, there was essentially no guidance within the game at all. New players frequently had no idea of what to do, or even what they could do. If they hadn't read any documentation or arrived with some plan in mind, many of them were simply lost. A confused player who can't figure out how to play isn't likely to stick around. With JGE, we're addressing this problem by providing some structure for the starting players, and establishing firm control over the information they are given. The intent is to provide activity-driven guidance that teaches the players about the environment and their options, while temporarily hiding most of the game's deeper complexity until it's actually useful. However, rather than trapping people in some boring tutorial, we're accomplishing this through user interface and gameplay. Figuring out how to do this so that players can just jump in and start playing might seem like a hard problem, but we're getting the best possible teachers to show us how to do it - people who have never played Jumpgate before.

Playtesting with novices might seem counterintuitive, but it makes an incredible amount of sense when you see the process in action. We sit the player down, telling them nothing beyond how to start the program. Then we observe. We make notes about what they say, look at, press, and click on. Often they'll tell us about things they find odd or confusing. We let them play for 15 to 30 minutes, whatever seems appropriate. Then we decide what to change or add. After we make the changes, in a day or so, we get another victim to playtest. The key is rapid iteration, doing this over and over until almost anyone can sit down, understand the interface with no trouble, and have enough fun playing the game that they want to play more. Most of our former playtesters are now clamoring for their next chance to play JGE, so we believe we are making good progress toward our accessibility goals.

Even setting aside the three critical focus areas I've described, the JGE development agenda remains extensive. The user interface itself is entirely new, a big project in and of itself. By replacing the UI and the rendering systems, the team is being forced to touch practically every piece of the game, and thus getting an opportunity to rethink if not rebuild every system. The old codebase, dating back all the way to before 1997, is gradually being refactored, and the result will be a modern online game.

Players of JGC will certainly be able to recognize familiar features, but I think they'll find that everything in JGE has been enhanced in some way. The interface will be easier to use and understand, information will be better presented, tools will be more effective or new ones will exist that had always been needed. We are building in more things to do, more enemies to fight, more problems to solve, even more things to explore. There is a long road ahead for the development team, but a wise man once said, "Well begun is half done". We have a lot left to do, but we think we've made a very strong start.

- Steve "Istvan" Hartmeyer, Jumpgate Developer


Guest Writer