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 on the graphics card which the card periodically drew to the screen. This method of access allowed the card to continually refresh the screen without interrupting 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 to be displayed. By comparing the two frames, the differences could be extracted, and only those copied into the memory-mapped frame buffer. The frame buffer on the card thus held a composite of all the frames ever drawn, which was identical to the most recent image in the computer. 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 over large areas. 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 sort of rendering was common, 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.^[3] 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 focused 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.^{[citation needed]}

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.^{[citation needed]} 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.^{[citation needed]}

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.^[4] It also won many "comparison" articles when judged for realism,^[5] 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.