1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
  2. Greetings Guest!!

    In order to combat SPAM on the forums, all users are required to have a minimum of 2 posts before they can submit links in any post or thread.

    Dismiss Notice
  3. Greetings Guest! Tonights Maintenance is complete and the Stratics Community Wiki is now live. Please see this thread for more details.
    Dismiss Notice

[Developer Blog] Turret System Renovation

Discussion in 'EVE News' started by EVE News, Jun 21, 2011.

  1. EVE News

    EVE News RSS Feed
    RSS Feed

    Apr 12, 2011
    Likes Received:
    My apologies for the length of this piece, as it is an art blog, which are usually long as we don't do many of them, and there's quite a bit I'd like to cover. Forewarned is fore-armed. ;)

    With this blog, I am proud to present our new turret system.

    Why turrets? Why not X, Y, or Z instead?

    It has been nearly a year since we started this renovation, and we have accomplished much in that time. Even though there was a partial renovation of, at least, the look of the turrets during the Trinity expansion, the system itself had been pretty much as it was when EVE Online launched. For the time they were an impressive piece of engineering; made up of a multitude of bases, bodies, and barrels all assembled in-engine on the fly, all of which shared a single texture, and costing practically nothing in load. Their singular purpose and clever simplicity (although the number of geometry pieces were quite complex) was also their greatest drawback, as they did not age well. With the introduction of normal maps in Trinity, for instance, the sharing of a single texture was no longer possible. Whenever you have different geometry, you need a different normal map. Surface detail can be added or overlayed, but the underlying normal maps need to be unique to the geometry it was created for. This became obviously apparent as during the Trinity expansion we added a shared normal map to the other shared textures. We did not however, have the time to rework the entire system, so the minor improvement was deemed acceptable for the time.

    Another nail in the coffin for the old system was that the original design didn't allow for us to add new turrets. The siege weapons used by dreadnaughts serve as an example of that. The clever coding that allowed them to function correctly worked for a time, but broke down over subsequent expansions, and though their function was not impaired, they have been broken visually on Tranquility for some time now. Time and again we have had requests for content involving new turrets, but being unable to add additional turrets to the system, had to either come up with other solutions where turrets would not be required, or label a feature not possible due to technological restrictions. This is why the Sleepers from the Apocrypha expansion, for instance, do not have turrets, and fire beam weapons from points around the ship.

    As you can see we had many reasons (and adding more with nearly every expansion) to replace the old turret system with one that would be easier to manage and maintain, while looking to the future. And thus the work began.

    In our first vision meeting the art director brought up many points that he wanted to see back when the original system was designed, but could not be implemented due to limits in technology. Turrets deploying from a packed state was one of them. More detail in their functionality was another. We knew that we were looking at a very long release cycle, and therefore had to visually justify the time spent on the system - If we were going to rework them, we'd better make them look the part. As animation always breathes life into a still scene, we latched onto the idea of deployable turrets. As mentioned before, this was tried back in the first turret system, but now, just as back then, we couldn't find the appropriate point to deploy the turrets.

    The turrets had to be deployed and ready to fire as soon as you had locked your target. Leaving them inactive, and deploy when locking a target was the first thought, but due to some insanely quick locking times because of maxed out skills and implants, some animations would look unnaturally sped up, even comical. We also toyed with the idea of a "safety" button, which you'd have to hit to bring your turrets to a readiness level, prior to entering combat. This would of course be a great disadvantage if you ever found yourself having a need to return fire in a hurry. Then one day during another planning meeting our technical artist made the suggestion of why not just deploy when exiting warp, and pack when entering warp. There was a moment of silence as the team looked at each other and realized how simple and obvious it was, and how we had not seen it before. We also decided at that point that turrets should be in the "inactive" state when a ship is docked inside a station, and later in the development cycle we added the feature that when a turret is off-lined or on-lined, it would also move between its packed and deployed states.

    The original turret system had very little difference visually between the different types of turrets, often opting for simply changing out one barrel for another (there were many different barrels, though). We thought that it would serve our purposes better to have less variation in number, but greater variation in form, opting to change the entire profile of the turret, which would also allow us to do more elaborate animations.

    We ended up going with roughly 5 variations per size class for each of the four races, to service all the sub-classes under each weapon type. Hybrid weapons were of course a small exception, as they are shared between both Gallente and Caldari. Their design was not to be so much racial specific either, for the same reason. We thus ended up with a design calling for 67 unique models, with their own animations, which would be used to produce all 613 variations of turrets in-game today.


    Originally there were more turrets planned, like Targeted and Area-of-Effect Utility turrets, the first being an omnidirectional emitter visible on the ship's hull, covering effects such as Energy Vampires, Target Painters, Remote Repairers, etc. (in an attempt to correct the beams starting from a mysterious point in space somewhere around your ship, since we really disliked the whole "ships casting spells" effect they produced), and the latter for focusing the effects like ECM and Sensor Boosters on a visible module on the ship, making them smaller and less obtrusive as a whole. Missile Launchers too were included in the initial plan, but all of these had to be scoped out of the first release due to complexity and time constraints.

    Improved Target Tracking

    With work on the system underway, we improved the way turrets tracked their target. Before I explain the improvement, I need to highlight that a single turret module had up to this point been visually represented by a pair of turrets on the hull of the ship. Now, if a target would move from the firing arc of one turret to that of its counterpart in the pair, the first turret would no longer snap back to its rest position while the other snapped into the tracking position, as was the case with the old system, but would continue to track the turret in 1 axis to allow a smooth handover regardless of target position.

    Firing Arcs and Turret Position

    As turret range of motion and firing arcs, as well as turret placement on the hulls are related to tracking, I can highlight another improvement over the old turret system. The range of motion for turrets in EVE Online is a 360 degree rotation, and a 105 degree barrel pitch (90 degrees positive pitch, 15 degrees negative pitch). During Apocrypha we were working on the Tech 3 ships, and with their modular nature, we ran into some difficulties with puzzling out turret placement. Finding two corresponding flat areas in parallel on opposite sides of the ship to place the turret pair on and ensure that their fields-of-fire overlap, proved to be quite difficult. At the time I requested a triad of turrets to represent the single turret module, in addition to the pair-system we were using. Again, that was not possible then, as it would have required a total rework of the system, which we did not have the development resources for.

    Adding a third turret to the group would mean the fields-of-fire could be smaller for each individual turret, and would no longer need to be in parallel, and thus make it easier to overlap them. To illustrate what I mean, in the first image below we have a Rifter (which suffers from the same problem with one of its turret pairs) fitted with small projectile weapons. The turret pair at the front on the two pontoons are on opposite sides of the ship, but the hull angles are not parallel to each other, thus with this configuration a blind spot is created directly above the ship as the firing arcs of the two turrets can never overlap. This leads to graphical errors as the turrets are unable to fire at a target positioned directly above it.


    With the addition of the third turret, the fields-of-fire overlap and surround the ship, allowing the single turret module to always fire at its target, no matter where that target might be around the ship.


    Turret Position and Hi-Slot Configuration

    Originally, Tractor Beams and Salvagers were going to be associated with the omnidirectional Utility turret, but were considered too important to be cut from the first release, so we opted for making them full-fledged turrets in their own right. This lead to the not-so-slight problem that up to this point, turret locators on ships directly corresponded to the number of turret slots on a ship, but now needed to correspond to the number if hi-slots instead, as Tractor Beams and Salvagers do not occupy turret slots.

    And while the artists were adding the additional locators to all the ships, the programmers upgraded the hi-slots so that a turret slot could now occupy any hi-slot. Locator pairs or triads on ships are numbered 1 through 8 (of course not all 8 are present on all ships, there just isn't enough room) and static, and now hi-slots correspond to them left-to-right, so slot 1 is where turret pair/triad 1a,1b,/1c would fit - which means, if you don't like the layout of the turrets, move it to another hi-slot and the turrets will shift their position on the ship. (Prior to this update, turrets used to fill the turret locators numerically regardless of which hi-slot you used.)


    Turret Preview Window

    We had quite a project on our hands, and needed an easy way to view each individual turret in the client, something like the ship-preview window, but for turrets, which of course didn't exist yet. Our programmers made a modified version of the ship preview for us to use as an internal testing tool, which we never intended to put out to Tranquility, but once the Creative Director and Art Director got hold of it, they insisted be improve upon it and make it a part of the feature. So, with some inspiration from icons used in Dust 514, we refined it into what you see in the image below.


    Turret Color Adoption

    We also wanted to improve the cohesion of the look of the turret with that of the ship, and thus devised a shader system in which the turret would read the faction (or manufacturer, if you prefer) of the ship it is fitted to, and then select from a list of presets, a turret shader that would match the colors of the ship. This now meant that no matter what type of turret weapon type you have fitted to your ship, be it energy, hybrid or projectile, they would look like they'd been produced by the same manufacturer.
    Just to be clear, the shader on the turret is not the same as the shader on the ship, however similar they may seem. The turret shader, for instance, is only a dual-material shader, while a ship uses a tri-material shader. We needed to drop the third material in favor of adding a heat glow to the barrels of turrets under sustained fire.


    Odds and Ends: Firing Effects, Recoil Animation, Timing Offset

    One point the Creative Director was quite insistent upon, was the addition of a slight random timing delay when turrets fire, so that when turrets are grouped and fire together, they don't all fire at the exact same time. When the old turrets fired in perfect unison, the effect produced felt to perfect, and most would agree that it is the imperfections that make things seem more "real".

    As for the effects, they were not to be included in this renovation, as they are part of a different and much larger system, which we do want to revisit and overhaul in the future. However, we had to touch them at least, in part, as the new turret system, being completely animated, required the effects to be attached to the moving locators at the end of each barrel of a turret. Since the old system didn't require this, a single effect for a dual-barreled turret included both beam/firing effect, which leads to when we placed these effects onto a new dual-barreled turret, it would be firing 4 beams, one from either side of the two barrels. This would clearly not have been acceptable, so your effect artist spent quite a bit of time going over all the turret effects and updating them in this manner.

    I'd be amiss if I didn't at least touch on the subject of recoil. :) With the new animation system the turrets were built on, we of course were able to add recoil to nearly all the turrets. The initial thought was that laser weapons should not have recoil, but this made it quite hard to test when the turrets shifted from the "active" state into the "fire", as it was only late in the process that we could hook the firing effects up to the turrets (due to technical reasons). We needed to see the shift visually and without the effect, the recoil animation was the only option. Why not then remove it afterwards? Well, we came to like some of those recoil effects, and simply did not feel that the amount of work required to remove them outweighed our affinity for them.

    As you can see, it is quite a big system, integrated into many aspects of the game, and I'm sure I've only listed the most important of its features in this blog. It brought with it its own set of problems, many of which we've already overcome, and it is not without its flaws, although we've tried to address as many as possible. But we are confident that it is a more robust system than the one we had before, and one we can easily expand upon.

    We hope you have as much fun blowing each other up with it, as we had making it!