Steve Hartmeyer, programmer of Jumpgate Evolution, is this week’s guest writer as we present our second Jumpgate Evolution dev diary. Today, he discusses the process of ship development in their upcoming Sci-Fi MMORPG. If you would like to read the previous Dev Diary entry by Steve Hartmeyer, click here.
Ship development in Jumpgate Evolution is more a story of our art pipeline than anything else. Many of the ship roles derive from standard types that were set in Jumpgate Classic, and we’ve only just begun modifications to our codebase that will support the variations we want that will be specific to Jumpgate Evolution. The process of putting a new ship into the game begins with generation of a style, then a concept for the specific ship asset. A model is built from the concept and put into a form that our render engine can use. Finally, stats are chosen that will define the ship in-game, at which point it’s ready to be flown. The entire sequence generally takes several days of work for each of the artists involved, and the stats for ships certainly won’t be considered final until the game releases, if then.
Our ship design process actually began more than a year ago, when Kirk Lunsford, our concept artist, joined the Evolution team and was tasked with creating new styles for each of the nations in the game. Over a period of several weeks, he chose general forms for each nation based on background information he was given about their cultures and outlook. Once these styles passed team review and became the “look” of each nation, Kirk began developing specific designs suited to different ship roles, such as fighters or transports. These each start as black silhouette drawings, with value and hotspot glows gradually shaded in. Kirk typically paints dozens of these in a group, but only a tenth to a third are chosen for detailed work-up.
The detailed concepts are given color and texture treatments, and become individual works of art in their own right. We have adorned our team workspaces with an abundance of glossy prints and paper printouts from this phase of asset design, and we add more by the week as Kirk works. After review by NetDevil’s Art Director and other members of the art team, the forms and material types may receive modification, but these mature concepts are generally the starting point for the next phase: 3D modeling.
Kirk’s main tool is Adobe Photoshop, but on rare occasions he employs a 3D tool, such as Autodesk’s 3ds Max, or even modeling clay, to convey a more complete concept. When a concept representing a new style is handed off for modeling work, Kirk often stays closely involved in a joint creation process with the artist doing the modeling and texturing. Once the first model of a style is completed, though, much of the design responsibility is passed to the modelers for further assets that use that style.
The design methods Kirk originally used for each of the three major nations are revisited for each new group we add to the game. We’ve only just begun the process of developing all the subfactions and independent groups that will populate Jumpgate Evolution, so Kirk’s workload remains considerable.
Modeling and Texturing
Once each ship concept is ready, it is passed to the two members of our art team who do 3D modeling, Darrin “RoGLaRiCoN” Klein and Cole “KonStruCt3D” Eggen. The starting point is generally a single three-quarters view, though occasionally a 3D work-up is used. The first step for the modeler is to block out a rough mesh in 3ds Max, but after that there’s considerable latitude in procedure. The first complete low-poly mesh is usually set aside at the bottommost level of detail (LOD). From there, the artist may choose to move directly to the highest-poly mesh, or may work gradually up to that point by adding further details every step of the way, setting aside each completed LOD mesh as each one is completed.
Basic texturing, or the color map, occurs as a natural part of the modeling process. Once a high-poly version of the asset is in progress, a combination of the high and low poly meshes is used to bake detail into the textures used by the lower LOD meshes. Our modeling process employs four separate texture maps: the diffuse, or color map, a specular map, used to define specular color, a normal map, used to define lighting volumes, and a composite map called the “GES” map. “GES” means “Glow, Environment, and Specular”, and each non-alpha channel of the map holds data for one of those three texture features, which are independently processed by our render engine.
After the texture maps and LOD meshes are created and exported, our 3D artist’s work is almost done, but not quite! Special effects still need to be defined and linked to points on the model, which we call control points, or CPs. CPs are also used as physical anchors on the model for other processes handled directly by the game code, such as an interaction point. Since our art team is small, our modelers also double as special-effects artists, so any unique effects needed for a specific ship asset are also their responsibility. We use Fork for many of our particle effects but some are created and executed through an in-house particle engine instead.
To store all the information about the meshes, textures, and special effects used by a particular model, the modeler manually creates a metafile that our asset loader can read. Making up for all the seeming drudgery of mesh and file creation, our modelers have a large amount of creative freedom. They aren’t required to follow a concept religiously, and often are given chances to create variant assets within a style entirely on their own.
When a ship model is ready to be put into the game, it’s a simple matter of adding the metafile name to an object list. Our asset loader reads the metafile and determines what textures and meshes are required for the model, placing those into client memory as necessary. We’ve gradually made our loader more sophisticated as work on the project has progressed, and we may perform further iterations on the technology if we find we need them to maintain our minimum client specification.
The final but ongoing step of the ship definition process is to choose stats representing the ship’s in-game attributes, such as power needs, gun hardpoints, cargo space, pitch and yaw rates, and the like. These are manually entered into a database used by both client and server applications. Most of our ships were initially populated with stats from the original Jumpgate Classic game, but as the Jumpgate Evolution codebase has diverged from that of its predecessor, the ship attributes have likewise begun a process of redefinition and adjustment that will surely continue through the beta test phase of the game.
The process of putting ships into Jumpgate Evolution, or any asset model, really, is demonstrably an art-intensive exercise. Aside from occasional tweaks to tools which support the art pipeline, the programming side of this effort was largely complete once the render engine and asset loaders were written, early in the development process. Though our art team consists of only three individuals, they are now able to create assets and place them into the game at a steady and rapid rate. The screenshots and in-game video released thus far are a testament to the talents of our art team and their unfailing efforts to make Jumpgate Evolution all it can be.