Hellcats over the Pacific
| Hellcats over the Pacific | |
|---|---|
| Developer(s) | Parsoft Interactive |
| Publisher(s) | Graphic Simulations |
| Designer(s) | Eric Parker |
| Platform(s) | Macintosh |
| Release date(s) | 1991 |
| Genre(s) | Flight simulator |
| Mode(s) | Single-player |
Hellcats over the Pacific is a flight simulator computer game for the Macintosh computer. It was written by Parsoft Interactive and released by Graphic Simulations in 1991. Hellcats was a major release for the Mac platform, one of the first 3D games to be able to drive a 640 x 480 x 8-bit display at reasonable frame rates in an era when the PC clone's VGA at 320 x 240 x 4-bit was the standard. The graphics engine was combined with a simple Mac interface, a set of randomized missions and a number of technical features that greatly enhanced the game's playability and made it a lasting favorite into the mid-1990s. The original game was followed with a missions disk, Hellcats: Missions at Leyte Gulf, which greatly increased the visual detail and added many more objects to the game.
After the release of Leyte Gulf, ParSoft began work on another flight simulator for Graphics Simulations, based around the McDonnell Douglas F/A-18 Hornet. The two companies parted ways during the initial development. ParSoft began work on a new networked flight simulator that would emerge years later as A-10 Attack! and followed by its own missions expansion, A-10 Cuba. Graphics Simulations continued work on the nascent F-18 simulator and released it as F-18 Hornet. They also licensed the basic flight engine to another group of programmers, who used it as the basis for early versions of the online game, WarBirds.
Description
Hellcats is a combat simulation of the F6F Hellcat aircraft in a series of fictional missions during 1943's Guadalcanal Campaign.
Hellcats focused almost entirely on the flying of the aircraft, with a minimum of setup or in-game controls. After starting the game the player finds themselves in a minimal interface consisting of a small number of dialog boxes for preferences and selecting missions. The entire interface was based on the Mac's built-in UI, as opposed to hand-rolled elements built out of the game engine itself. This made for a spartan but easy-to-use interface. After the initial setup the user rarely used any of the out-of-game controls except for the mission setup dialog box, where radio buttons allowed the player to select one of the eight missions, along with their fuel load and zero, one or two 500 lb (230 kg) bombs. Nothing else was required, and after selecting a mission the game switched to the in-cockpit view.
Due to the simplicity of the game engine, the flight controls were also quite simple, offering basic controls for the engine, rudder, flaps and landing gear. Primary flight control for roll and pitch was normally handled by the mouse, which included a scaler that improved the "feel", although the flight engine was also fairly insensitive to overcontrol. Joysticks could also be used, but were supported via "mouse mapping", not directly. View controls allowed for a number of different options, including tower views and similar, but also a "slow following" chase mode that slowed down transitions between different flight directions in order to reduce the total amount of movement when correcting for small adjustments in flight path (this is now common to most games). One feature that was lacking from Hellcats was a "snap view" that allows the player to look in different directions and then returns to a front view when the key is released.
One oft-commented-on feature of Hellcats was its "instant replay" view. The game logged out all actions in the game world to a buffer, and on command could play them back from an external viewpoint. The game would select a viewpoint that kept the "important action" in-frame. For instance, if the player was in the midst of dropping a bomb on a ship, during replay the camera would leave the aircraft and follow the bomb down to impact. On the other hand, if the player was in aerial combat and two planes collided nearby, the replay would instead keep the player's aircraft centered and rotate the camera to show this event relative to the player. The game rarely chose the wrong viewpoint, and the effect was often cinematic.
The game world consisted primarily of the player's Hellcat and enemy aircraft, normally the A6M Zero. Some missions included "friendly" F6F's and a B-17 Flying Fortress. Enemy aircraft also included the Mitsubishi G4M "Betty" in one mission. Ground targets included AA guns, cruisers, battleships, aircraft carriers, and sometimes static aircraft parked at the airbases. Many of these targets could be destroyed by bombing, which was "eyeballed" by diving on them. Smaller targets could also be destroyed with machine gun fire.
Air-to-air combat was relatively simple, normally degenerating into a turning fight which, unrealistically, the F6F could win by lowering its flaps. Actually shooting down the historically flimsy Zero was difficult in the game, at least at closer ranges, and often ended with the opposing aircraft's engine failing and the aircraft crashing while ditching. Although it was possible to directly "kill" the aircraft, this generally only occurred with hits at long range; at shorter ranges, most bullets simply went right through the aircraft.[1] Another issue with the combat system was sighting distances, which made targets practically invisible at even a few kilometers' range. To address this, the game included a radar display that showed, unrealistically, every aircraft above a few hundred feet altitude in a 360-degree view around the player's aircraft.
Although the damage modeling was simplistic, the game did track damage to the pilot and would "kill" them in certain circumstances. This could be avoided in many cases by quickly exiting the mission before crashing, although this did not help in the case of a direct hit on the pilot or a mid-air explosion. The pilot could also be lost in action after bailing out of a stricken aircraft. This was a bone of contention among players, as the system for deciding whether or not the pilot was lost was completely random; even landing in the middle of a friendly airbase would often result in a dialog stating the search and rescue teams could not find you, leaving that pilot MIA. The game had no built-in method of reviving dead or missing pilots, but there were 3rd party programs that were available to do this.
The game manual was typically sparse. Instructions for the UI and basic flight were included, the later being copied from an FAA manual that often disagreed with the basic flight model in the game. The manual also included a complete copy of the original F6F flight manual, useful for historical purposes only.
The key to Hellcats's long life was the overall simplicity of the game as a whole. Starting the game and entering a mission could be completed in a few seconds, and the in-game action demanded more situational awareness than outright flying skill. The lack of complex weapons also helped make the control system quite "thin." This resulted in a game that was much more approachable than its more complex follow-ons, and Hellcats was widely enjoyed by players that would not normally play flight simulators.
History
Incremental update
The Hellcats engine was based on an idea Eric Parker formulated while studying the SPARCstation 1. The SPARCstation allowed the memory of the graphics card to be mapped into main memory; any data the CPU placed in those memory locations would automatically be copied over the SBus to a frame buffer that the graphics card drew to the screen. This method of access allowed the card to continually update the screen independently of the CPU; if the two shared the memory directly it can lead to contention issues that will slow overall performance.
However, the path between the main memory and the frame buffer was relatively slow, so while both the CPU and the frame buffer could move memory quickly within their own private memory, they could not easily communicate those changes. Specifically, the CPU could create 40 MB/s of data in main memory, but this could only be copied to the frame buffer at 5 MB/s. The SPARCstation had a resolution of 1000 x 1000 x 8 bits per pixel, about 1 MB per frame, so at best the display could run at about 5 FPS at full resolution if each frame was being generated by the CPU and sent over the bus.
Parker began considering ways to reduce the amount of data that had to be copied to the card. He came up with the idea of having two frame buffers in main memory, one for the current frame and one for the next frame that would be displayed. By comparing the two frames, the differences could be extracted, and only those copied into the memory mapped frame buffer. This way the frame buffer held what was essentially a composite of all the frames ever played, which was identical to the most recent image. However, the data sent on a per-frame basis was greatly decreased. His first experiment drew a flat-shaded rotating cube, and was able to reach 120 frames per second.
This method only works well if the image as a whole is not changing. For instance, this technique is difficult to use with a texture mapped display, because in that case even minor changes in camera angle or position would require any portion covered by a texture to be re-drawn. This limited the engine to polygon-based flat-shaded graphics. At the time this was not uncommon, and with this engine many more polys could be drawn per-frame, greatly increasing visual fidelity.
Producing a game
Parker had always been interested in flight simulators, and started adapting the basic graphics engine as the core of a new game. Working at home at nights after his day job, he began the process of converting the workstation engine to a PC platform in his new company, Parsoft.[2] The choice to target the Mac was technical, as it was the only machine on the mass market at the time that commonly featured the ability to run at reasonably high resolutions, at that time 640 x 480 or higher. At lower resolutions the amount of data that had to move over the bus was limited in any case, so the "brute force" approach of drawing every frame to the buffer would work fine, and did for contemporary games like Red Baron. Only at the Mac's higher resolutions would the engine provide a real advantage.
Additionally, the engine was much less affected by changes in resolution than traditional engines. This allowed the game to be run at any resolution the Mac could support, including the then-extremely-high 1024 x 768 that was common on 21" monitors which could be found on some Macs of the era. In addition to having higher resolution than contemporary PC's, it was not uncommon to see more than one monitor attached to a Mac, especially in the desktop publishing market. The Parsoft engine was able to take advantage of this as well, allowing the user to put the game on up to three of monitors to allow for side or rear views.
Building out the system
With the graphics engine in place, what was left was to take the engine and use it to produce a game. ParSoft chose to model the area surrounding the successful U.S. campaign in and around the Solomon Islands. The game is focussed on the battle between the F6F Hellcat and A6M Zero that first took place over these islands, whose outcome changed the balance of air power in the Pacific war. A map of a large portion of the island chain was created, along with airbases and other fixed locations.
The low CPU cost of the graphics engine left the CPU with ample free time. To fill it up, the game included a number of live objects that other games generally lacked. For instance, airbases often had a number of AA guns arranged around the field, and they would track and follow the aircraft as it flew around. These objects were placed throughout the very large map area, so if the player ignored the mission and flew off to distant islands, they would still find operational airfields.
With a basic environment in place, Hellcats was fleshed out with the addition of the physics engine. The engine used a formulaic approach to calculate the forces on the aircraft, whereas most contemporary games used a lookup table approach. The latter has the disadvantage of having dramatic changes performance with small input; for instance, an aircraft might climb at 90 mph (140 km/h) at an angle of 20 degrees, but when the nose is raised even slightly, to 21 degrees, it suddenly slows to 80 mph (130 km/h). In contrast, the Hellcats engine was completely fluid throughout the entire flight regime. While by no means high fidelity in terms of matching real-world aircraft performance, Hellcats was nevertheless a major advance in terms of flight quality. For one of the first times ever in a PC flight sim, stalls were achievable and spins were possible with the proper control inputs.
The engine also lacked a number of features that reduced the realism. For one, the engine did not model gee-induced blackouts or redouts, which allowed unrealistic maneuvers. Additionally, the only structural limits the game checked on were the landing gear or direct impact, so for instance the flaps would not be damaged by lowering them at high speed. This led to a number of behaviors that would be impossible otherwise, notably dive bombing at hundreds of miles an hour followed by dropping the flaps to allow a multi-tens-of-gee pullout. More detailed structural limits were relatively common in other games of the era.
And then, a game
The game engine was placed within a shell using the basic Mac UI, in contrast to most games that have their own UI built inside the game engine. Missions were selected in a dialog box with radio buttons and a slider to select the fuel load. Settings for sound and graphics were likewise accessed entirely though the standard Mac menu and dialog system. A relatively large manual was included anyway, although the majority of this was "boilerplate text" taken from a reprint of the original F6F pilot's manual or a FAA flight training manual.
This is one area where Hellcats was significantly behind the technology curve compared to contemporary games. It included only eight pre-rolled missions, one of which was training, and no ability to edit or add your own. The missions also incorporated some degree of randomness, enough to make each play different, sometimes significantly. They also varied widely in difficulty, from simple missions against one or two other targets, to The Duel with about a dozen aircraft and five ships. However the long term appeal of the game was affected by the mission system's limitations. In comparison, games like Red Baron had hundreds of missions, and while they played exactly the same every time, there were so many of them there was less of a problem with lack of novelty.
Hellcats was released to huge acclaim, although the Mac gaming market was small. It is still listed at the No. 7 most influential Mac game of all time, according to Inside Mac Games.[3] It also won many "comparison" articles when judged for realism,[4] although most articles included a caveat about the graphics.
Leyte Gulf
After Hellcats shipped the Parsoft team started work on improving the engine. Tweaks to the graphics engine provided even better performance, allowing more cycles to be spent on other tasks.
These upgrades were released a year later as Hellcats: Missions at Leyte Gulf. Although it was marketed as an upgrade pack, it was actually an entirely new game with its own runnable application. The new version included dramatically improved detail at the airbases, added jeeps and trucks, more detailed ships, the P-38 Lightning and the Ki-84 "Frank", and rockets and torpedoes in addition to the bombs and machine guns.
The rest of the game remained otherwise similar to Hellcats. Both the physics engine and missions system were largely unchanged. The new game included another eight missions, this time with no training. Although they all had considerably more detail and a greater number of in-game targets, they had the same lack of user editability as the original.
Moving on
Parsoft moved on to new projects after the release of Leyte Gulf. GraphSim hired a new team and used the existing Hellcats code to produce a new game in 1994 as F-18 Hornet. GraphSim also retained the rights to the version of the software they had at the time, and later licensed the graphical engine to be used in the early versions of WarBirds.
Parsoft moved on to a completely new system. Aware that the major problems in the original engine were the lack of realistic structural physics and pilot effects, Parsoft's new A-10 Attack! included a complete rigid-body simulator in addition to a re-written flight dynamics engine. Another addition to the new engine was the "Virtual Battlefield Environment" (VBE), a plug-in system that allowed new vehicles and weapons to be added to the engine by dropping them into a directory. Although the game did not include a flexible mission editor, it did, in theory, allow missions to be added through the VBE system, missions that could include computer code to increase the customization. The VBE system was used by Parsoft to produce A-10 Cuba, a new mission set taking place at and around Guantánamo Bay. This was initially released as a stand-alone game on both the Mac and PC, and was later re-released on the Mac as a true VBE plug-in. VBE was replaced by a much simpler system, OpenPlane, that allowed all of the customization to be carried out in resource files with no coding or compiling required.
References
External links
- Macintosh Garden ReView
- Le Greniers Du Mac ReView
- GraphSim Entertainment – HomePage For The Original Company
- Hellcats Over The Pacific & Hellcats Over The Pacific: Leyte Gulf FAQs