[Apple II, The Hayden Book Company]
I know not what weapons World War III will be fought with, but World War IV will be fought with self-replicating kamikaze robots.
Mark Twain
Humans were Gods. Not smart gods, true, but oh so creative. They created us. Then they left. But as they left, they never cancelled the last task they had given us : destroy SovComp. So that’s what we are doing.
We set up a factory near one of SovComp’s factories. We will destroy it.
NATOComp_Factory_StandardOperatingProcedure_Attack :
- Program kamikaze robots so they reach the core of the SovComp factory
- Release them
NATOComp_Factory_StandardOperatingProcedure_Defence :
- Program kamikaze robots to occupy strategic tiles OR
- Program kamikaze robots to move toward detected SovComp kamikaze robot
- Release them
Analysis of the situation :
- Orientation of factories makes it easier for SovComp robots to reach the NATOComp factory than the opposite
- All SovComp robots will have to cross two specific tiles to attack us
- Possible to create shorter route by using a kamikaze robot to blow up a building
Please wait. Creating initial set of orders
Order_list :
Execution :
Assessment Result / Target :
100%
Assessment of SovComp behaviour :
- Releases robots twice faster than NATOComp
- Programmation weak. SovComp robots frequently (>50%) crash against worthless targets
Assessment of current battlefield situation :
- A shorter way to SovComp has been created
- When our first robots will have reached the new crater replacing the building, the crater will be cold enough to allow passage.
Generating new set of orders :
- Robot #4 will crash into the enemy factory, stopping its production for some time.
- Robot #5 will attempt to crash into the enemy core, ending the battle.
- Double_tap protocol activated :
- Robot #6 will crash into the enemy factory, stopping its production for some time.
- Robot #7 will attempt to crash into the enemy core, ending the battle.
Please wait. Creating set of orders
OrderList2_Execution_01 :
OrderList2_Execution_02 :
ALERT ! ALERT ! ALERT !
Threat_Analysis :
- Defensive robots #2 and #3 are gone
- SovComp robot heading for our factory by the North.
Threat_Answer :
- Cancel orders given to robot #7
- New order for robot #7 to replace robot #2 in defensive position
- Send robot #8 on a collision course against SovComp robot coming from North.
OrderList3_Execution_01 :
ALERT ! ALERT ! ALERT !
Situation report :
- SovComp robot from South NOT intercepted.
- Factory damaged !
- Currently repairing
Repair completed
Analysis of the situation :
- Clear path to SovComp factory core through factory
Generating new set of orders :
- Robot #9 will crash in SovComp factory core by the North through the craters
- They won’t be expecting that maniacal_laugh_protocol !
- Future robots will have defensive behaviour.
OrderList4_Execution_01 :
SovComp factory status :
Annihilated.
Rating & Reviews
The Final Conflict by Thomas G. Cleaver, published by Hayden Software, USA
First release : October 1982 on Apple II
Tested on : AppleWin (Apple II emulator) and Altirra (Atari 8-bits emulator)
Total time tested : 1.5 hours
Average duration of a battle : 10-15 minutes
Complexity: Easy (1/5)
Would recommend to a modern player : Possibly as a two-player game
Would recommend to a designer : Yes, a modern multiplayer version could make a fun party game
Final Rating : Obsolete
Ranking at the time of review : 20/73
The Final Conflict is the brainchild of Thomas G. Cleaver, whom we already know from Galactic Empires/Galaxy (1979/1981). Cleaver “always had been a gamer” as he told me in an email, and in the mid-70s had already designed tabletop games, two of them (Swordplay and The Conquest of Space) sold with some success through classified ads in magazines like The Space Gamer and at least one other of a more educational nature sold through specialized catalogues.
Cleaver was also a professor of electric engineering at the University of Louisville, Kentucky, and as such he knew how to code. Kentucky was not California, certainly, but the university had mainframes and minicomputers, on which Cleaver coded a local version of the unescapable Star Trek. When the Apple II was released, he convinced the University to acquire one, and it would become his computer of choice. The Apple II belonging to the University of Louisville, he used for educational software (games or not) and tools. But Cleaver soon acquired his own Apple II, on which he coded his first non-Star Trek non-educational game : Galactic Empires, whose design came to Cleaver, he told me, in a dream.
Galactic Empires was sold as a type-in through an ad in The Space Gamer #23 (May 1979). The game sold only 50 copies, but was played by significantly more than 50 people : “Since I was a bit naïve then, I failed to register a copyright on the game. As a result, various individuals and companies copied my code and published it as their own. It’s one of my great regrets that I did not protect my intellectual property.” Disappointed, Cleaver approached Avalon Hill in 1980 with a proposal for an upgraded version of Galactic Empires. At the time, Avalon Hill had failed its first attempt to penetrate the computer market and was looking for competent designers. They accepted the offer, provided Cleaver also ported his game to TRS-80 and Commodore PET – evidently Avalon Hill had remained stuck on the 1977 Trinity and had missed the press release about the Atari 400 and 800. Cleaver complied, with the help of a friend (Walt Brewer), and the improved Galactic Empires, rebranded Galaxy, was part of the November 1981 Avalon Hill catalogue.
Avalon Hill would not publish Cleaver’s next game. As I said, Cleaver had coded a fair amount of non-gaming software, including one called “The Programmer’s Toolbox“, which he licensed for distribution to the Hayden Book Company. The relationship went well, which was great, because the Hayden Book Company was at that point hungry for games to publish, and Cleaver happened to have a new one : The Final Conflict.
The Hayden Book Company had been created around 1969 as a subsidiary of the even older Hayden Publishing. It focused on training manuals of all kinds and eventually on electronics and computers. From there, it moved to type-in in the late 70s (including for instance the famous chess-program Sargon ), and then to publishing software directly in 1979, starting I believe with Sargon II. Sargon II was a massive success (10 000 copies sold according to an article from November 1983). Publishing software looked profitable, and The Hayden Book Company published an increasing number of games. By coincidence, these games included Starclash, one of those Galactic Empires rip-offs – Cleaver had never heard about it until we discussed it in email correspondence.
The Final Conflict was initially released in October 1982 on Apple II, not by the Hayden Book Company but by Hayden Software, a split of the former also created in October 1982 to isolate the software activity from the book activity. In 1983, The Final Conflict was ported on Atari and Commodore 64. I tested the Atari version a bit, but my review will be on the Apple II version.
A. Immersion
Very poor. “You are the Central Controller – an artificial intelligence – pitted against an implacable enemy (either the computer or a brain as keen as your own). You direct your forces through dangerous fields from your position in an all-too-vulnerable base.
Your robot weapons must avoid radioactive craters, the ruins of a demolished civilization and enemy weapons as they seek to destroy the enemy base.”
That’s all for the context, but then the game does not really need a context, it just needs a pretext.
B. UI, Clarity of rules and outcomes
Very poor. The game is easy to understand even without looking at the manual, and the behaviour of the robots is usually predictable. On the other hand, the game has to be played with a paddle, when a keyboard would have done the job just as well if not better. The Atari version can be played with a keyboard, and that’s a bit better.
The only major problem, but really it is incredibly frustrating and brings the game to “poor” rating, is that the game stops every couple of seconds or so when the AI is running a turn or just planning its next move. During those interruptions, no inputs are accepted. Imagine playing your favourite game, but only being able to give an input every odd second : that’s how it feels. For the record, the Atari version also has this issue.
C. Systems
Good. I don’t have much to add compared to the AAR : the gameplay is simple (only 5 commands !) but brutally effective. The player must arbitrate between attack (sending a robot to clear the way) and defence (ordering robots to wait somewhere specific or to move along a vulnerable lane), between using the faster but riskier route or the longer route that also gives more time to react…
D. Scenario design and balancing
Poor. The game uses randomly generated maps, with two significant customization options :
- The player(s) can choose different terrain types (“city”, “country”, “town”, “desert”, “wasteland”) or create a custom type. Terrain types define how many terrain features the map will have, and which features those will be (“city” is a lot of buildings, “country” a lot of hills and woods and “town” a mix of both). Maps can also be rerolled if the player(s) don’t like them.
- The game speed can go from 1 to 10.
When the game is at minimum speed, you can program robots so fast compared to the speed of the game that the robots you will release will queue before appearing on the battlefield. The game also feels sluggish. Don’t play at minimum speed.
When the game is at maximum speed, it is actually not that fast – you can still counter an enemy move by quickly giving orders. The problem is that at that speed your inputs are interrupted every half a second by either turn execution or the AI thinking. Don’t play at maximum speed. Default speed is the most playable, though too slow for my taste.
Unfortunately, I am unable to give full points for the customization options, because I test as a solitaire player and those options will mostly serve you against a human opponent. The AI is extremely weak and I beat it in my first “real” game, and then every single time after that.
E. Did I make interesting decisions ?
Sometimes, but it feels like minimum effort is required to beat the AI.
F. Final rating
Obsolete, due to the shoddy AI and the excruciating performance issues.
I pondered whether the Final Conflict was a wargame, wargame-adjacent or not a wargame at all, but giving it some thought I lean toward considering it a full-fledged wargame, and more than that another early real-time game, though one in a design dead-end. You are trying to overcome the other side, you have to balance attack and defence and you have to take into account the terrain but you can also modify it, all this while your units move on their own and while you give orders in real-time. Slow-real time, sadly.
Unlike so many of the real-time precursors, and possibly because it is so unique in terms of details and without progeny that I know of, the Final Conflict aged pretty well and remains somewhat fun to play. Pity it is so slow, easy (against the AI) and has this persistent stop-and-go when the computer is loading.
But even if the AI had been great, I feel the enduring fun of this kind of game comes from those “gotcha” moments after you pulled a particularly clever move and surprised your opponent – but you don’t really have this against an AI. The game is probably great in multiplayer, even today, but as a solitaire player I did not feel the need to launch the game after two complete sessions except to test the options.
Contemporary Reviews
Unfortunately, I could only find one review for the Final Conflict. In the Space Gamer #64 (July 1983). Richard Steinberg complains about the joystick-only controls, but still concludes that “All in all, Final Conflict is a game that should bring you many hours of good, clean war-making.” However, this conflict will not be final for Cleaver, who will come back for this blog for one last game released in 1985 : Darkhorn.