f13.net

Jumpgate Evolution owes the basis of its flight engine to NetDevil's first product, Jumpgate. Arguably a unique feature, the Jumpgate flight engine allowed the game to be distinguished as an online spaceflight simulator, rather than a run-of-the-mill MMORPG, which were only then (in 2001) beginning to be churned out by a nascent industry. Jumpgate's distinguishing element was that, as in prior spaceflight and combat games such as Elite, the Wing Commander series, the X-Wing series, Freespace, and Alliegiance, the player directly pilots their ship, often with a joystick instead of a mouse.


Though often described as realistic when compared with other games' flight models, the Jumpgate flight engine is neither strictly realistic, nor is it by any means arcade-style. Perhaps the simplest description is "playably realistic". Underlying the flight model is basic Newtonian physics: engines apply a force to the ship's mass, which accelerates in response. During experimentation with early builds, the original Jumpgate developers quickly recognized that a wholly realistic flight engine would be incompatible with their vision of hands-on flight. Strictly realistic spaceflight creates a demoralizing list of playability issues: unreasonably large potential speeds, impossible reaction times required of players, inability of ships moving at greatly different speeds to fight or even interact effectively, as well as complications to travel because of the need to slow down again to rendezvous with a destination, just to name a few of the problems. The ultimate goal of Jumpgate was to re-create white-knuckle fighter combat as seen in movies and TV such as Star Wars, Battlestar Galactica, or Babylon 5, so solving the gameplay problems by departing from the hands-on control paradigm just wasn't an option.

The original flight engine was made playable by adding an omnidirectional drag term in the equation of motion. Though unrealistic, the drag component offered huge playability gains, and became the necessary savior of the otherwise problematic Newtonian foundation. Ships suffered an upper speed cap due to drag, which in turn brought the reaction times needed for control well into the natural range of a human pilot, and simultaneously kept all ships able to easily interact. Jumpgate's "D.A.N.C.E.R." engine was thus born. The engine provided playable "spaceflight", while retaining the challenges and advantages the development team wanted to keep.

So much for our journey down Memory Lane. While the Jumpgate Classic flight engine succeeded in being playable, it failed to be accessible. It can be argued that this was not so much a drawback of the engine itself, but rather of the control scheme. Jumpgate Evolution continues to support joysticks (and by extension, gamepads), but first and foremost among our adaptations, the mouse and keyboard interface has been made much more straightforward for the player to use. The familiar WASD setup has become the default control core, with other keys chosen in a sensible and ergonomic pattern. Along with control adjustments, flight response has also been enhanced by tweaks to the default flight model. Drag has been slightly increased, and braking thrusters are more powerful, combining to offer the player greater control of their ship. Vertical and lateral thrusters have also been added, analogous to familiar FPS "strafing" controls, which offer the player new options for modifying their ship's trajectory. All these changes were implemented as part of a directive to make flight easier to understand, and the ship controls easier to use. However, it was quickly obvious that the drag changes in particular altered some aspects of flight so familiar to players of Jumpgate Classic - and that those aspects would be very desirable to retain.

The dilemma was only momentary, and its solution was simple. The original flight model, in which drag is weaker and momentum more significant, has been retained (including the new controls and directional thrusters). A toggle has been set up allowing the player to switch between the new default flight model and the original one. Fictionally, players are toggling the ship's "inertial dampers" - an idea with venerable science fiction roots. Offering this choice permits Jumpgate Evolution to keep the best of both worlds. Players begin the game set to use the new flight model, which is easier to understand and fly with, but can choose to turn it off to gain the performance of the original model. The pilot can switch on the fly, depending on what kind of flight profile is desired, even in the heat of battle.

We've discovered that being able to switch flight models in real time adds a fun and slightly unexpected tactical dimension, in addition to the convenience that was fully intended. During routine testing, some of us on the team now find ourselves using the toggle frequently. For example, when creeping through a clump of asteroids, I'll leave the dampers on so I have tighter control over my speed and direction. If I attack some pirates I find among the rocks, I might cut the dampers out in the firefight, so I can pivot and fire at a pirate on my six while still pursuing his buddy. The encounter could doubtless be handled successfully by using either flight mode throughout, but by yielding the option to the player, we hope that the additional element of personal choice is received as an enhancement to the fun piloting experience we're trying to build into Jumpgate Evolution.

Article By: Steve "Istvan" Hartmeyer, Programmer

The screenies look good.  Action packed.  But then again, so does EvE, which turns into an excel snooze.

Is JG:E lots of pew pew pew zoom!!! or is it EvE?  Diku ships instead of diku cars (Auto Assault)?

What's the skinny?

There isn't wind resistance in space!

Wouldn't realistic space combat be more like pushing a button on a computer and having the system do a metric fuckton of calculations, fire some smart missle, and then watch a blip disappear on a screen?

[/pedant] I know, there's always a trade off between realism and fun.  :oh_i_see:

There isn't wind resistance in space!

However in space, once you go in one direction you won't stop unless some other force acts against you.  If you accelerate on a flat surface in a car, you will slow down due to friction of your tires and the air.

In a Jumpgate ship, you have a "forward" control which engages some fictional propulsion mechanism. My complaint is, in any reasonably designed ship there would also be a "brake" mechanism which engaged said fictional propulsion mechanism in the other direction, but set up as a simple "slow the ship down" control.

Just because a ship obeys Newtonian physics doesn't mean that the ship's controls have to be low-level and hard to use. That's all I meant.

Ok, I guess I was guilty of writing a short response when clearly a longer one was necessary.

Indeed a car will slow down due to wind resistance and friction. But if you're trying to maneuver in a parking lot, what you're actually using is your brakes. In a car, you have a simple user interface where you have one pedal to speed up, and another which slows you down. This user interface works nicely because you don't need to have any knowledge of how acceleration and braking are "implemented" - you simply need to step on the pedals.

In a Jumpgate ship, you have a "forward" control which engages some fictional propulsion mechanism. My complaint is, in any reasonably designed ship there would also be a "brake" mechanism which engaged said fictional propulsion mechanism in the other direction, but set up as a simple "slow the ship down" control.

Just because a ship obeys Newtonian physics doesn't mean that the ship's controls have to be low-level and hard to use. That's all I meant.

Personally, I hate it: give me Freespace or X-Wing type controls anyday.  It's all about the fun baby!

I-War 2 had Freespace-type controls, optional, or unassisted Newtonian, also optional, toggle between them by hitting N.  That simple.

Yes, but cars don't rely solely on wind resistance to provide a braking function, now do they? The problem with classical Jumpgate was that (despite the "drag" they added) there's no reasonable way of slowing down, short of turning around and going the other way.

In space, hauling back on the stick should whip your nose around a LOT faster than your vector is changing, without it being a special

If you though a fighter in JG had a hard time stopping in a docking ring, try a cargo tow with a couple hundred tons of cargo aboard.  The brakes, they do nothing!!

Isn't weight kinda meaningless in space?

I'm a little rusty on my elementary school science, but that kinda doesn't make a whole of sense to me.

So, you basically want to remove G forces from a space fighter.  Makes sense. 

We've spoken a great deal in interviews and other articles about just how excited we are about Jumpgate Evolution's AI system. It has rapidly gone from being a system intended to solve one or two things, to becoming the tool of choice to address all sorts of interrelated game issues. Although we try to maintain perspective and recognize that employing the AI system is not always the proper solution to a problem, this is truly a case where the excited kid inside each of us tends to burst out and enthuse, "We can make the AI do that! Wouldn't that be great?" It's simply the case that our AI system is turning out to be very capable and versatile, so it's extremely tempting to make quite extensive use of it.
 advertisement

We began simply, with the AI system's chief task being to populate space. The plan was to make large numbers of AI ships that would travel around the game, performing real tasks in real ways, using a list of available behaviors and incorporating forms of mutual communication. To begin realizing this design, we considered the basic tasks that every player must employ simply to fly her ship around the Jumpgate game universe. Each possible role, be it hauling, mining, piracy, or whatever, was considered in terms of both its unique behaviors and common activities. Each process became an algorithm. Each major type of AI bot, as defined by role, became a class. The behaviors themselves became polymorphic functions inherited by the role-based classes from more generic parent classes, such as "mobile bots" or "stationary bots". As an example, nearly all mobile bots inherit and use a "Travel" behavior, which manages the process of long-range navigation. Likewise, there are common "Dock", "Launch", "Jump", and "Avoid" utility behaviors employed by everything that must move.

The list of behaviors becomes extensive when considering the special activities of each possible role. As an example, a bot simulating a mining vessel will employ a combination of common and unique behaviors to accomplish its task. First, the bot will be created with member data that includes such things as its location and what kind of asteroid it must find to mine. The bot will physically launch as the final step of its creation process. Once the launch algorithm ends, the bot must perform a detection step to see if there are any viable targets in the area. Failing that, it may travel to another location, avoiding collisions with objects along the way, and possibly jumping to an entirely different sector of the game to continue its search. At some point, we will assume for this example that a target match is detected, so the bot will approach the chosen asteroid using a unique mining behavior. Other bots would naturally use a collision avoidance behavior in the vicinity of an asteroid or similar object, but the mining bot instead must cozy up to a rock to do its job. The bot will halt close enough to the asteroid to use its mining equipment, functionally handing off to another behavior that controls the mining process itself. During mining, the bot will perform additional transactions with the servers that handle its inventory changes, much like any player would. Once the bot determines its inventory is full, it will revert to a common travel behavior to some destination to deliver its cargo. Upon arrival at the destination facility, the bot will execute a docking behavior, transfer the ore from member data to the facility's inventory, and be removed from existence by the system.

As can be seen by the example life cycle of a mining bot, even a pretty typical AI object must be able to accomplish a significant number of different things to serve its purpose in the game. The example doesn't even include most of the decision-making variability in the process, nor does it include any interesting interruptions; it's just the dull life of a pretty normal bot.

Interruption events turn out to be the real spice of life for a bot's decision making process, and from the start the AI system was built to make them a centerpiece of its operation. With the exception of collision avoidance, all the interruption events thus far defined for the system either are triggered by, or result from, some form of bot-to-bot communication. Just as with the behaviors, we built a list of types of bot-to-bot interactions, which became a list of message types. The messages function like invitations, "Attack me", "Pirate me", "Help me", and so forth. Every type of bot places specific messages in dedicated regional communications queues. Some types of bots poll these queues at intervals, and if they find an appropriate message type, they pick up the message and change behavior in reaction. A typical example of these interactions looks like this: a hauler bot, representing a cargo ship, jumps in and posts "Attack me" on the local queue, and continues traveling across the sector. An aggressor bot in the sector, representing a hostile alien Conflux, polls the queue, picks up the "Attack me" message, and switches from loitering to a set of behaviors that cause it to locate, fly to, and engage the hauler. The hauler, now interrupted in its travel by the attack, posts a "Help me" message in another queue. A defender bot, representing a factional fighter on patrol, polls the help queue and picks up the hauler's message. It breaks from its patrol behavior and streaks to the aid of the hauler, possibly posting its own version of "Help me" for other defenders to pick up on, gathering a posse. By choosing appropriate values for different polling cycles, we've already seen very exciting, lifelike activity in basic proof-of-concept work on the system. Broad implementation for all cases, though, is not yet completed. We fully expect to continue fleshing out the AI system through release.

The ultimate purpose, however, isn't to create a nifty network of thousands of bots that effectively play the game for us. That would make a delightful AI experiment and does have use as an excellent load testing tool, but ends up doing little for gameplay. The true power of the system will hinge upon tying the already operational message and queueing system into interfaces that players themselves have access to, and bringing the universe to life in ways that let players participate. Ideally, routine player activity will post similar messages to the AI queues for bots to react to, and players will be able to passively or actively perform some kinds of polling actions themselves, with appropriate and equivalent information displays to help them react to and participate in what will have become spontaneous events originated by the AI. This is really what has the development team so terribly excited about the potential represented by Jumpgate Evolution's AI system.

While the basic interlinks between the players' UI and the bots' queues are a significant part of what remains to be implemented, we surely intend to have some of this vast potential realized by release. Imagine that, rather than the defender bot rescuing the hauler, instead the nearby players see a HUD indicator flash with a message: "This is Free Trader Beowulf, calling anybody... Mayday, Mayday.... "*

- Steve "Istvan" Hartmeyer, Programmer

*partial box quote from the original Traveler game, by Marc Miller, (c) 1977, Game Designers' Workshop.

The ultimate purpose, however, isn't to create a nifty network of thousands of bots that effectively play the game for us. That would make a delightful AI experiment and does have use as an excellent load testing tool, but ends up doing little for gameplay.

Verisimilitude.

I've caught some shit in the past for wanting some kind of dedicated AI hardware, and I allow that it's not realistic after seeing the Ageia debacle. Maybe now that multi-core chips are coming out we might get good AI. I'm starting to think we won't get a good vibrant virtual world full of deep interactive AI before I die. That sucks. C'mon, devs. Your graphics are shiny, your sound is surround. But the AI is still like living in a world of autistic, non-functional retards.

The whole "attack me!" "pirate me" seems like a weird way to do it, though.  It would have made more sense to me if the transport bot was just broadcasting its position and the fact that it was a transport bot, and the aggressor bot was looking at the queue and reacting with "Ooh, a transport bot!  I'm gonna attack it!"

Same end result for the bots.  But the outcry from players when they find out that their character is silently broadcasting "attack me!" "pirate me!" to all the bots in a zone will be, I imagine, much bigger than if they found out their character was simply broadcasting its position so that the AI could "see" it with its limited pseudo-senses.

No avatars kinda kills it for me, as well as any resemblence of a 'ground' game - whether it's on a planet of another ship/space station. 

RE: the AI broadcasting. One thing that would suck would be if it acted like Freelancer, where the AI made a beeline for players over other AI (to the point where the other AI could destroy them while they chased you). Ruined that game for me, even more than the mouse-driven flight model.

But the AI is still like living in a world of autistic, non-functional retards.

Most developers are well aware that user interface can break a product. Sadly, it doesn't usually "make" a product. Players don't often think, "Wow. This UI is really well-executed!" If the UI is really well-executed, it's most likely that players hardly notice it at all. The trouble happens when the interface gets in the players' way, or is found inadequate. A game can be beautiful and have great features, but if the interface annoys, irritated players tend to simply pick something else to play.
 advertisement

Obviously, user interface has to be taken very seriously during development, which can require quite a significant investment of time and effort. Every feature needs a good interface, but there's a seeming infinity of presentation methods. How should we as developers decide how to build each interface component? There's certainly more than one way to approach the problem, but for Jumpgate Evolution, our team has elected where possible to let the players themselves guide us.

For a game that hasn't been released, such a pronouncement might sound ridiculous, but we're working to accomplish this very goal from three different directions. First of all, we're driven by the need to make the displays and controls very accessible and easy to use. Information must be available where and when the player needs it. Key choices must be practically self-evident. Frustration must be minimized, especially in the first fifteen minutes of play, when the new player is deciding whether the game is interesting or not. To learn how to do this, we test very frequently, in focused sessions lasting about fifteen minutes, using someone who has never seen the game before. We watch everything they do, asking them to tell us what they are thinking about as they do it. This teaches us what they are trying to do, where they are looking, and what they are, astonishingly enough, not seeing. We have found repeatedly that even though the information a player needs may be there, placed in a very obvious way from the designer's point of view, the player still may completely miss it. As UI designers, watching these tests can be brutal, agonizing, even maddening. Our response to the input that comes from the tests, though, is really simple. When the tests show us that things are being missed, we change those things. In this manner, many parts of our user interface are being adjusted every week, as we strive to make sure that needed information is clear and noticeable, and that it ceases to be intrusive when it's not needed. We’ve already gone through three major design iterations as well as scores, possibly even hundreds, of minor adjustments and it's not finished yet. Nearly every day we change some part of the UI again, little by little moving closer to our stringent accessibility goals.

Rapid iteration is one of our major development strategies, and for UI we're aided in this not only by our automated build system, but by the decision a year ago to license Scaleform, which allows nearly all of our UI development to be done using Flash. Instead of spending time building internal tools, which our team then has to get accustomed to, we've been using well-established commercial Flash development software and leveraging the prior knowledge of Flash that members of our engineering and art teams already had. As if this weren't enough benefit, we also have the option of opening some of our interfaces to customization by the many Flash developers who will doubtless be part of the game's eventual community.

While a focus on the experience of the new player drives design of the basic interface, our second big input into interface considerations comes from Jumpgate Classic and its existing player community. Lessons learned from the parent product's implementation help guide many of our decisions, and we also have 6.5 years of suggestions and ideas from the running game to draw upon. Rather than impacting initial gameplay, though, most of this input is influencing our thinking about what we term "advanced play". These are things that aren't often the concern of the new player or initial impressions, but instead are relevant to players who are making use of the real depth of the game. Directives originating from our experience with Jumpgate Classic include a need to have more economic tools and displays as part of the station interface, improved squad (guild) and facilities tools, new combat coordination tools and features to support situational awareness in battles, and inclusion within the game of information that had previously been available only on the game's website. These changes or improvements relative to the older product may be individually motivated by design issues specific to each feature, but all fall squarely within the realm of making functionality more accessible to the player in Jumpgate Evolution.

Finally, there come times when it's very hard to determine the "right way" to do something. Sometimes it just won't matter, but sometimes it's clear that the users are polarized into two or more camps, where the "right way" for one group will frustrate the other. In some of these cases, we as designers are simply taking the easy way out. Instead of dictating how to play our game, we're implementing systems that suit each camp, and allowing the players to decide for themselves which to use. One good example of this was mentioned in a prior article on flight dynamics, in which I described our decision to implement a toggle between two flight modes, letting the players control the "feel" of flying their ships. Another, purely interface related example, is what we've chosen to do with the game's radar display: we had all the signs of a religious war brewing between the supporters of an Elite-style radar and a Freespace-style radar. Each side claimed their style felt most intuitive, and that the other style was difficult to read. Neither side wanted to budge. Rather than possibly alienating some fraction of the game's audience, we've chosen to implement both styles of radar, again with a toggle, so the players are able to choose. Of course, this decision was a tad easier because the Jumpgate Classic code already implements an Elite-style radar, so that instead of two types we're really only implementing one, but that's part of the advantage of leveraging an existing product.

We're also applying the philosophy of "let the players choose" in more general areas of the game's interface. In addition to the obvious customizability granted by using Flash, we're making most portions of the UI summonable and dismissible, adjustable in terms of size and color, and movable. Players will be able to decide what they need to see, when they need to see it, what color they want it, and where they're willing to sacrifice space on the screen. This is not particularly novel in modern online games, but it's a far cry from what interfaces were like when other space games like Elite, Privateer, Freespace, and even Jumpgate Classic were released. Allowing players to personalize the interface is another tactic to minimize potential frustration caused by our decisions as UI designers, and should simultaneously provide a big boost to accessibility. Despite the time and effort that goes into building a user interface, ultimately we want it out of the way, so players can enjoy the game.

That's like a STO post  :awesome_for_real:

http://www.tentonhammer.com/node/28404

Interview from March 5th on control schemes.  Did we know they are allowing you to use joysticks? 

Interesting quick read.