The Making of Nox Archaist
In 2020, for the first time in 30 years, a commercial role-playing game was released for the Apple II computer. The goal
238 55 7MB
English Pages 257 [259] Year 2022
Polecaj historie
Table of contents :
Foreward
Introduction
I. Origins of Nox Archaist
My First Computer
A Dream Revisited
II. Building the Game Engine
Game On
Creating the Graphics Engine
Creating the First Bootloader
Creeping Mobs, Creeping Scope!
Nox Archaist Goes Public
The Second 90%
KansasFest to Kickstarter
Creating the Alpha Demo
III. Creating Content
Designing Game Content
Late-Stage Engine Changes
Kickstarter Redux
Return to KansasFest
The Apple II Speaks
The Apple II Reunion Party
IV. Testing and Release
To Flee or Not to Flee
My First Playthrough
Beta Testing Team
Floppy Nightmare
Release the Kraken!
The Future
V. Team Members
Beth “Nox Styx” Daggert
Electric Moo
Michael Pohoreski
Chris Torrence
VI. Appendix
Tech Talk
Acknowledgements
Index
My childhood Apple II User’s Guide. It got a lot of use!
RPGs faded as my interest grew in modems and BBSes.
An entire screen of trees.
Trying out icons, with the first prototype character.
A line-of-sight algorithm diagram.
Creating a tree in my Microsoft Excel pixel editor.
A typical DOS catalog.
Don Worth and Pieter Lechner’s Beneath Apple DOS.
Announcement of Nox Archaist on comp.sys.apple2.
The map from March 2016, with “6502” in the ocean.
My second appearance on the Open Apple podcast.
Juiced.GS cover, March 2021.
An early town using Mark and Mike’s art.
A tweet about Qkumba’s session at KansasFest 2017.
Mark Lemmert, Chris Torrence, and Peter Ferrie.
Surely, there must be a better name.
The pre-beta test island.
Pirate ship tryouts.
The brute squad. Anybody want a peanut?
Graph paper sketch of the character info screen.
Graph paper sketch of the inventory screen.
First iteration of the inventory display.
Inventory display, with the character list.
Character stats with tab icons but still the old font.
Inventory display with tab icons.
Final version of the inventory display.
Look at the shallow angle on that lightning bolt!
The mobs get impatient and attack the screen.
First iteration of treasure drops.
An early experiment on item selection.
The final version of the treasure drop screen.
Early design document for the Quick Combat screen.
Quick Combat in action.
The “Shop at Willy’s” ad during Quick Combat.
Hiking in the mountains. I started young.
The vacuum cleaner was there for cleanup.
Nox Archaist the Flamethrower!
The pre-alpha demo map was the highlighted area.
The demo area was blocked off with a cow barrier.
A comment from a beta tester.
After a tester said they just had to play one more turn.
Overworld map sketch.
Depths of Vacous, sketch of level 1.
Rough list of mob level distribution.
A tiny portion of the main State-of-The-Art-Chart.
The Weapon Damage Table in the STA.
The Master Spell Table in the STA.
The Nox Archaist Quest Log.
Main page of the second Kickstarter, May 2019.
Lord British in his Shrine.
Speedrun by Rikkles: 20 minutes, 45 seconds.
We used Applesauce for copying and a IIc for testing.
The Apple II Reunion Party, south of Praevoc Keep.
Richard Garriott’s Nox Archaist tweet.
Apple II Reunion guests and their in-game intro.
Steve Wozniak’s tweet a few days after game release.
Nox Archaist players fleeing from battle.
Final version of the “Flee” screen.
The Nox Archaist Apple II Test Lab.
Debug codes are circled. The !!!’s are from the bug.
The GSBug Apple IIGS debugger.
The Twelve Days of Nox Christmas.
Cowmageddon, by Bill Giggie. Moooo!
Lord British Undefeated t-shirt.
Jason Scott says HOLD UP on news of our release.
Countdown to launch!
Best Ultima-inspired game of 2017 on Ultima Codex
The RPG Codex top 10 best RPGs of 2020.
Apple II Forever award, KansasFest 2021.
John Romero’s tweet for our Steam release.
Gazing into the Nox Archaist crystal ball.
Early version of the inventory screen.
Inventory window with idealized number locations.
Brainstorming different icon border ideas.
Palette change due to shifting the icon locations.
The key and potion are blue again but the key is offset.
The 7×8 pixel cells on the Apple II’s hi-res screen.
Early versions drew on both graphics and text screens.
Final version of the merchant inventory screen.
Sir Edgar and Lady Susan, of Uharad Castle.
Edward III and the final Coin of the Realm.
Nox Archaist manual. Cover art by Denis Loubet.
Box #1 off the assembly line, sent to Richard Garriott.
Citation preview
THE MAKING of
THE MAKING OF
creating a modern role-playing game for a classic computer
MARK LEMMERT
6502 Workshop
Copyright © 2022 6502 Workshop, LLC. All rights reserved. Cover and interior design and layout by Chris Torrence. The typeface is 10.5/14pt Warnock Pro, designed by Robert Slimbach in 1997 and named after John Warnock, the co-founder of Adobe. Typeset using Adobe InDesign. Printed by Lulu Press. v1.1
To the Apple II and CRPG communities who embraced the Nox Archaist project and provided a continuous stream of encouragement and support to help us see it through.
Contents Foreward
xv
Introduction
xix
I. Origins of Nox Archaist My First Computer
3
A Dream Revisited
9
II. Building the Game Engine Game On
15
Creating the Graphics Engine
19
Creating the First Bootloader
27
Creeping Mobs, Creeping Scope!
31
Nox Archaist Goes Public
35
The Second 90%
47
KansasFest to Kickstarter
83
Creating the Alpha Demo
89
III. Creating Content Designing Game Content
97
Late-Stage Engine Changes
109
Kickstarter Redux
115
Return to KansasFest
123
The Apple II Speaks
127
The Apple II Reunion Party
131
IV. Testing and Release To Flee or Not to Flee
139
My First Playthrough
143
Beta Testing Team
153
Floppy Nightmare
165
Release the Kraken!
173
The Future
187 V. Team Members
Beth “Nox Styx” Daggert
191
Electric Moo
195
Michael Pohoreski
199
Chris Torrence
217 VI. Appendix
Tech Talk
225
Acknowledgements
231
Index
233
Figures 1. My childhood Apple II User’s Guide. It got a lot of use!
5
2. RPGs faded as my interest grew in modems and BBSes. 7 3. An entire screen of trees.
21
4. Trying out icons, with the first prototype character.
22
5. A line-of-sight algorithm diagram.
23
6. Creating a tree in my Microsoft Excel pixel editor.
25
7. A typical DOS catalog.
27
8. Don Worth and Pieter Lechner’s Beneath Apple DOS. 29 9. Announcement of Nox Archaist on comp.sys.apple2.
44
10. The map from March 2016, with “6502” in the ocean.
45
11. My second appearance on the Open Apple podcast.
46
12. Juiced.GS cover, March 2021.
46
13. An early town using Mark and Mike’s art.
48
14. A tweet about Qkumba’s session at KansasFest 2017.
51
15. Mark Lemmert, Chris Torrence, and Peter Ferrie.
51
16. Surely, there must be a better name.
52
17. The pre-beta test island.
56
18. Pirate ship tryouts.
57
19. The brute squad. Anybody want a peanut?
61
20. Graph paper sketch of the character info screen.
63
21. Graph paper sketch of the inventory screen.
63
22. First iteration of the inventory display.
64
23. Inventory display, with the character list.
64
24. Character stats with tab icons but still the old font.
65
25. Inventory display with tab icons.
65
26. Final version of the inventory display.
66
27. Look at the shallow angle on that lightning bolt!
68
28. The mobs get impatient and attack the screen.
68
29. First iteration of treasure drops.
70
30. An early experiment on item selection.
70
31. The final version of the treasure drop screen.
71
32. Early design document for the Quick Combat screen.
72
33. Quick Combat in action.
72
34. The “Shop at Willy’s” ad during Quick Combat.
75
35. Hiking in the mountains. I started young.
81
36. The vacuum cleaner was there for cleanup.
84
37. Nox Archaist the Flamethrower!
85
38. The pre-alpha demo map was the highlighted area.
90
39. The demo area was blocked off with a cow barrier.
90
40. A comment from a beta tester.
91
41. After a tester said they just had to play one more turn.
92
42. Overworld map sketch.
99
43. Depths of Vacous, sketch of level 1.
99
44. Rough list of mob level distribution.
100
45. A tiny portion of the main State-of-The-Art-Chart.
103
46. The Weapon Damage Table in the STA. 104 47. The Master Spell Table in the STA. 104 48. The Nox Archaist Quest Log.
113
49. Main page of the second Kickstarter, May 2019.
116
50. Lord British in his Shrine.
117
51. Speedrun by Rikkles: 20 minutes, 45 seconds.
119
52. We used Applesauce for copying and a IIc for testing.
121
53. The Apple II Reunion Party, south of Praevoc Keep.
131
54. Richard Garriott’s Nox Archaist tweet.
132
55. Apple II Reunion guests and their in-game intro.
133
56. Steve Wozniak’s tweet a few days after game release.
136
57. Nox Archaist players fleeing from battle.
140
58. Final version of the “Flee” screen.
141
59. The Nox Archaist Apple II Test Lab.
144
60. Debug codes are circled. The !!!’s are from the bug.
146
61. The GSBug Apple IIGS debugger.
148
62. The Twelve Days of Nox Christmas.
157
63. Cowmageddon, by Bill Giggie. Moooo!
162
64. Lord British Undefeated t-shirt.
163
65. Jason Scott says HOLD UP on news of our release.
173
66. Countdown to launch!
175
67. Best Ultima-inspired game of 2017 on Ultima Codex
179
68. The RPG Codex top 10 best RPGs of 2020.
179
69. Apple II Forever award, KansasFest 2021.
182
70. John Romero’s tweet for our Steam release.
185
71. Gazing into the Nox Archaist crystal ball.
187
72. Early version of the inventory screen.
200
73. Inventory window with idealized number locations.
201
74. Brainstorming different icon border ideas.
201
75. Palette change due to shifting the icon locations.
202
76. The key and potion are blue again but the key is offset. 203 77. The 7×8 pixel cells on the Apple II’s hi-res screen.
204
78. Early versions drew on both graphics and text screens. 206 79. Final version of the merchant inventory screen.
208
80. Sir Edgar and Lady Susan, of Uharad Castle.
219
81. Edward III and the final Coin of the Realm.
220
82. Nox Archaist manual. Cover art by Denis Loubet.
221
83. Box #1 off the assembly line, sent to Richard Garriott. 222
Foreward
Foreward
E
very once in a while, your dreams do come true. As a bespectacled, nerdy pre-teen in the early 1980s, I spent countless hours playing games and learning to program on my Apple II computer. I volunteered for the Boston Computer Society and went to AppleFest every year. I loved games of all sorts, but my deepest love was for computer role-playing games. I still remember the first time I played Ultima IV. I was absolutely transfixed! It seemed to me that just beyond the gently curving glass of my Amdek Color-1 CRT monitor, Lord British was really there, urging me to complete my quest and become the Avatar. I played the game constantly, and my early programming efforts were geared towards making something just like it, because I felt that nothing else on my Apple II was able to compare. When Ultima V was released about three years later, I was a freshly-minted teenager. If I was transfixed by Ultima IV, I was absolutely in awe of Ultima V. The depth and detail of the game world was beyond anything that I had ever seen. I had no idea that such an amazing game could be made, and I vowed I would learn how to do it. I spent some time researching Origin Systems, the company that made Ultima. As it turned out, the Lord British character was the alter ego of Richard Garriott, the head of Origin Systems. As I read more about him, I came to a decision that would profoundly affect the rest of my life. “This is it,” thought my fourteen-year-old self, “This is what I’m going to do. I’m going to work for Origin Systems, and I’m xv
going to make Apple II games with Richard Garriott!” I worked hard. I learned everything I could about Apple II computers and programming, eagerly gobbling up countless books on coding and working on my game with every spare minute of my time. I was ready, or so I thought. When I turned eighteen years old I wrote a detailed resume of my Apple II programming skills and sent it to Origin Systems, addressed to Richard Garriott. Sadly, I received no response. Unbeknownst to me, Origin Systems was in the process of being sold to Electronic Arts at that time, and within a year of that date, the Apple Computer Corporation completely discontinued the Apple II line, and I was devastated. The world was no longer interested in the Apple II, and my childhood dreams were snuffed out.
q
Fast forward twenty-five years or so, and you find a middleaged Jarrod Kailef who has dismissed his dreams of making a tile-based Apple II RPG game like Ultima. While I did manage to get an inkling of that dream by working on a few classic gaming projects over the years, and even got to meet and do a little bit of work for my childhood idol Richard Garriott, I was firmly entrenched in the comparatively mundane world of outsourced IT management. My thirty-five-year-old Apple IIe still sat on my desk, and I would boot it up now and again to enjoy some of the games of my youth. Then, quite by chance, I stumbled across a Kickstarter project that perhaps you might have heard about, by the name of Nox Archaist. I boggled at this. Someone was making a tilebased RPG for the Apple II computer? In 2017?! I simply had to know more! I immediately pledged towards this project, and reached out and spoke to Mark Lemmert, the author of this book and the lead developer of the game. I was so excited about the concept of a new Ultima-like Apple II game that I must have seemed a xvi
Foreward bit over the top. I’m eternally grateful that Mark did not dismiss me as a lunatic, as I wouldn’t leave him alone. The short version is, while it was a difficult road, my dream was reborn and fulfilled in spades. Mark Lemmert brought me on board as a team member and I was honored to participate in many areas of the production of Nox Archaist, from traditional game design and community management, to more esoteric items such as recording narration for videos and even vocals for the game itself. The team overcame great challenges in many areas. Some of those challenges were technical, such as adding Mockingboard music to the game. Some were truly daunting, like the eleventh-hour nightmare where the floppy version of the game was crashing. Other hurdles such as designing and launching a second Kickstarter campaign, and spreading the word across the classic-gaming community, required a lot of time and focus. Even the process of procuring, assembling, and shipping the finished product posed a great logistical challenge. But the team persevered, and in the end Mark Lemmert led us victoriously across the finish line, publishing the first commercial computer role-playing game on the Apple II platform in over thirty years. This book is a deep dive into something that, to my knowledge, hasn’t been explored in a book before, that being the development process of a retro videogame in the modern era. For those of us that grew up on 8-bit computers in the 1980s, bathed in the soft glow of our CRT monitors, you’re in for a treat. Jarrod Kailef https://www.kailef.com
xvii
xviii
Introduction
Introduction
I
t’s August 13, 2020, and the floppy disks aren’t working. We’re two months away from the release of 6502 Workshop’s first commercial game. Not only is it our first game, it’s also the first new commercial computer role-playing game for the Apple II platform in over 30 years. The game is Nox Archaist, and it’s been in active development for the past four years. We’ve already gone through several upheavals, including an unfunded Kickstarter, problems sourcing thousands of blank floppy disks, and incompatibilities with different Apple II machines. We’re also in the midst of a global pandemic. Today, however, we’re most concerned about a bug in the floppy disk controller. The game is supposed to ship with both a hard-drive version and on four double-sided 5.25-inch floppy disks. The hard-drive version is working fine, and has been stable for months. The floppy disk version, however, is crashing after a few hours of game play. Even worse is that the problem is intermittent. It seems to work fine on some systems (including our test machines) while crashing unpredictably on others. The 2019 Nox Archaist Kickstarter was a success and had a tentative ship date of March 2020. Delays in software development and testing have pushed that date out several months, but our backers have been more than understanding. They all say they don’t mind the delay, and would rather have a finished, stable release. But this floppy disk bug is a major unknown. We could have a fix in days, weeks, months or it could take even longer. Our upcoming backer update is supposed to include xix
the official release date, and we have to decide how to manage this crisis. How did we end up in 2020, worrying about floppy disk bugs for a computer platform that went out of production 27 years earlier? Starting with my early childhood memories of the Apple II computer, I’ll detail my love of computer role-playing games, and my early forays into creating games. We’ll then jump forward in time to the beginnings of the Nox Archaist project. I’ll talk about how the project grew from a one-man show to a project that spanned multiple continents and involved thousands of backers and supporters. Along the way, I’ll describe some of the technical hurdles we had to overcome, including learning 6502 assembly language, how to write a fast floppy-drive read/write routine, and how to get decent sound effects out of a one-bit speaker. We’ll also meet some old friends, including Richard Garriott (aka “Lord British”), Steve “Woz” Wozniak, and Burger Becky Heineman, and we’ll find out how they, along with many others, ended up in the Apple II reunion party room within Nox Archaist. Finally, we’ll hear from other 6502 Workshop team members and learn how and why they became involved in the project. Now, let’s travel back to 1981.
xx
Introduction
I. Origins of Nox Archaist
1
I. Origins of Nox Archaist
2
My First Computer
My First Computer
M
y parents bought an Apple II+ computer in the early 1980s when I was five years old. My earliest memories of the Apple II are playing Parachute, Lemonade Stand, and Gobbler, and my brothers writing a HELLO program. You can tell the computer to say “hello”? Of course the computer wasn’t speaking, but I was very curious. I grew up watching my older brothers John and Glen dabbling in computer programming on that machine and playing fascinating games like Ultima, Wizardry and Bard’s Tale. At that age those games were so captivating and also such a mystery to me. The first tile-based role-playing game (RPG) I recall experiencing was Ultima III when I was around 8 years old. Sometimes when my brothers were finished playing they would take out the disk and let me play the game without risk of accidental saves screwing up their characters. I had no idea what I was doing beyond using the arrow keys to move The origin of my in-game around, but it sure was fun! alias and online persona Nox I began to explore Applesoft BASIC Ffred dates back to this time. around the same time and the desire One day my brother Glen was to create my own tile RPG grew quickly. creating characters in Ultima III. The Apple II+ keyboard Of course, I had no clue where to was very slippery and he accistart. Over the years that followed I dentally typed “Ffred” instead spent untold hours learning program- of “Fred” as a character name. ming, playing games and studying We thought it was funny and he them. I also spent a lot of time read- decided to keep the character. I’ve been using it as my primary ing fantasy books like Dragonlance, character in RPGs ever since. watching nonsensical movies like 3
I. Origins of Nox Archaist Monty Python’s Holy Grail, and imagining some day being able to channel the fantasy creativity they sparked into something of my own creation. As a teenager in the early 1990s I had a light bulb moment. I figured out a possible method to create a tile-based map on the Apple hi-res screen. In theory it would allow the player to move across the screen when the arrow keys were pressed. I remember exactly where I was when the light bulb moment occurred: in a car on the way home from visiting my oldest brother in Oklahoma a few years after he joined the Air Force. Needless to say, I was very anxious to get In the winter of 2020, home to Wisconsin and write some code just before the COVID-19 to test out my idea. pandemic broke out, I was Once back at a computer in Wisconsin, driving through Oklahoma on a road trip and passed I spent many hours programming a proof over the exact stretch of of concept in Applesoft. I remember the road where the lightbulb moment when I typed in RUN GAME. moment occurred all those The disk drive whirred. years ago. In hindsight, it had turned out to be a It whirred some more. life-changing moment. It whirred for longer than any other program I had ever written. I began to wonder if I had broken the disk drive. The screen went black. The Applesoft prompt disappeared. I thought any moment now it might start working, but instead the Apple offered up a familiar BEEP! The net result of those many hours of work was an error message displayed on the video monitor. I don’t recall the exact error, but I knew it meant my program had exceeded the amount of memory reserved for Applesoft programs. At this point I was stuck because I could not find a way to allocate the additional memory required to my Applesoft program. As a result, for several years I didn’t know if my tilebased graphics engine design actually worked. 4
My First Computer
Fig. 1. My childhood Apple II User’s Guide. It got a lot of use!
Around 1992 my parents bought an IBM-compatible 386 computer. One of the first things I did on that computer was learn Microsoft QuickBASIC 4.5 and tried again to program my tile-based graphic engine design. Much to my delight it worked! Much to my disappointment, it was horribly slow! The tile map graphics appeared on the screen and the map moved in response to the arrow keys. However, it was painful to watch the incredibly slow screen draws after each player move. I didn’t know how to resolve this problem and shelved the project. This was the last attempt I would make for decades. Battling 6502 Assembly Language: Round 1 For any programmers reading this, the story so far probably begs the following question: why didn’t I try using assembly language? My dad is an incredibly smart guy and knew that most commercial Apple II games were written in assembly language. In the 1980s he was a high school chemistry teacher (now retired) and was constantly reading. He would read magazines like Nibble and talk to other people who were experiencing the personal computer revolution. Unfortunately, like me, he did not know how to write assembly language programs. 5
I. Origins of Nox Archaist But, my dad tried to help. He talked to the librarian at the high school where he was a teacher. He suggested that a book on 6502 assembly language would be a good addition to the library’s collection considering the computer revolution was picking up steam. The librarian agreed and my dad checked out the book once it arrived. I tried very hard to understand the book, but was not successful. At that point my experience with programming was limited to typing in Applesoft BASIC programs by turning the computer on and tying in the code at the first prompt that appeared. There was no compiler involved, and in fact I had no idea compiler programs were used for some languages. Of course, software like Lisa or Merlin existed, which could be used to write assembly language programs on the Apple II, but I didn’t know that. As a result, I was very puzzled when typing assembly commands like LDA $9000 at the Applesoft prompt did nothing other than produce a beep and a syntax error message. There were a couple of adults I came into contact with who had programming experience on mainframes. When I asked them about assembly language my vague recollection was that their responses collectively were something along the lines of “I’m not sure how it works on the Apple.” In hindsight I realize that I was asking the wrong questions. And, I had the wrong book. It was not for beginners, and assumed the reader had an assembler and knew the fundamentals. I only realized this after working at technology companies and gaining computer science knowledge that was unavailable to my dad and me back in the 1980s. My dad had done his best to help, but, at this point, I was stuck. Time Warp The RPG project was put on the back burner as I became interested in modems and computer bulletin board systems. 6
My First Computer
Fig. 2. RPGs faded as my interest grew in modems and BBSes.
I launched a BBS out of my parents house in 1994 and turned it into an Internet Service Provider in 1996, just as the general public started to become aware of the Internet. This ISP was one of only a few local options to explore the newfangled Internet and the business quickly took off. Not long after the company was launched I abandoned my computer programming studies at a local college to focus on the business full time with my brother Glen and future 6502 Workshop co-founder Mike Reimer. After making several mergers and acquisitions, I led the company to its height as the largest independent ISP in Wisconsin in the early 2000s. By 2004, my career had shifted from IT to finance and business. I returned to college part time and eventually completed a bachelor’s degree in finance, an MBA, and earned a CPA license. While I occasionally thought about it, the prospects of ever picking up the project of developing an RPG seemed further away than ever.
7
I. Origins of Nox Archaist
8
A Dream Revisited
A Dream Revisited
M
ike Reimer and I grew up living across the street from each other in Neenah, Wisconsin. We both enjoyed playing games on the Apple II and when he moved to another city, we spent countless hours talking on the phone while we were playing various games, especially Ultima V. This was back in the late 1980s and early 1990s when homes usually only had one phone line. We tied up our parents phone line for hours on end with our daily gaming chats. I vividly recall one occasion when the phone company operator broke into our conversation and said she had an emergency call from Jennifer Lemmert. Jennifer is my sister in-law, married to my brother Glen. He is seven years older than me and was married and serving in the Navy on a nuclear wessel in Alameda California while I was still in high-school. I do not remember For realsies, my brother Glen what the emergency was that Jennifer was a nuclear reactor operwas calling about, but I do remember ator on the USS Abraham that nothing was on fire and nobody Lincoln which at that time had died. I think she was just frustrated had a home port of Alameda, California. I even got a tour at getting busy signals for hours for the of the nuclear wessel when eleventieth time. In retrospect, as an visiting Glen one summer. adult, I can appreciate her frustration but I still chuckle thinking back on this. In 2014 I bought an Apple IIe on eBay because I thought it would be fun to play games like Castle Wolfenstein and Ultima again. Mike liked the idea as well and over the course of about a year we replayed numerous Apple games, me on my Apple 9
I. Origins of Nox Archaist IIe and Mike on an emulator. Just like when we were kids, we traded notes back and forth, but this time using text messages. After replaying a few games, Mike commented that it would be fun to develop a new RPG as a mobile app. We kicked the idea around for a while but it never got off the ground, partly because I still wanted to finish my Apple II RPG that I had started as a kid. Why did I want to finish my RPG? I’m not sure I fully understand it myself. To some extent it is probably a sense of unfinished business and wanting to summit the mountain I had tried to climb so many years ago. Also, I think it’s a good measure of whatever it is about Apple II computers that still keeps tens of thousands of people captivated with them to this day. Eventually, Mike and I would team up to create Nox Archaist but I didn’t bring the idea up with him until I was confident that I could tackle the technical side of the project. Coincidentally, the tipping point that led me to explore the technical aspects of developing an Apple II RPG involved Ultima III, the first RPG I played many years ago. In the fall of 2015, I purchased a 5.25-inch floppy-disk version of the game on eBay because I wanted to make a disk image so I could play it in emulators in addition to my Apple IIe. I quickly learned that the copy protection built into commercial software by developers in the 1980s prevented disk images from being made. I also learned that the solution to this problem required stripping the copying protection off the floppy disk, not just working around the copy protection with a program like Copy ][ Plus or Locksmith like I might have done back in the day. For some reason, I wouldn’t let the matter drop. Copying software for the purposes of making a backup or using the software in a different medium (i.e. an emulator) is legal and I wanted the software in a digital medium that would theoretically last forever. I started looking at solutions published in 1980s magazines for removing copy protection from various games. 10
A Dream Revisited The solutions I found involved typing in some assembly language commands and running a special copy program written in Applesoft. I couldn’t get the solutions to work. As I did research to try to figure out the problem, I found myself learning more and more about assembly language. Eventually I had learned enough that I could picture how to implement in assembly language the tile-based graphics engine design I had created years ago in BASIC. My motivation to crack the copy protection on Ultima III soon faded, replaced by the long-dormant desire to create a game. I set up a dinner with Mike Reimer in late 2015 to pitch him the idea of helping to create an Apple II RPG. Despite having been an Apple II gamer, he was a bit surprised at the choice of platform. However, he quickly warmed to the idea as we discussed the fun things we could do. I dove into writing the tile graphics engine and he worked on setting up a website. He also started thinking of words and concepts that might be interesting for a title (see p. 35). Over the course of the project, Mike would make many contributions including some sound effects, early tile art, work on the first Kickstarter, creating the prototype boxes and feelies, setting up our online Willy’s store, and lending his expertise on shipping physical products.
11
I. Origins of Nox Archaist
12
A Dream Revisited
II. Building the Game Engine
13
II. Building the Game Engine
14
Game On
Game On
W
hile I tinkered with game programming in the 1980s and 90s, I never finished a game. I was learning programming as I went and would frequently make breakthroughs that caused me to realize I could redo everything and make it much better. That cycle was not great for finishing games but was great for learning programming. All advice I’ve ever read from professional game developers given to programmers aspiring to write their first game shares a common theme: start small. Don’t jump in and try to create Ultima V (on a retro platform) or Skyrim (on a modem platform). Create a small functional game, celebrate the success, and then push your limits forward on another game. Rinse and repeat. It’s sound advice, really. So what did I do? I ignored it of course and proceeded to dive in feet first to create a game on-par with the technical complexity of Ultima V. I was making a calculated risk. I recognized the process described by the game devs as being pretty spot on for learning anything complex: start small and build on that knowledge incrementally. I had plenty of experience in not finishing dozens of games, culminating in my creation of a functional tile graphics engine. My thinking was that this experience might be a strong enough background that I could pull off a leap from that knowledge level to completion, especially considering other non-technical skills I brought to the table which seemed relevant to a large game project.
15
II. Building the Game Engine I think that there were four key factors to the success of the Nox Archaist project: large amount of available time, a diverse skill set, the hobby project mentality of the team, and finally, sheer stubbornness. Large amount of available time I’m single, with no kids. I’ve had a flexible work-from-home job for years. Diverse Skill Set I have experience with project management, finance, business, legal, operations, team building, marketing, customer service, and programming. To create an indie game, programming is of course a key skill but a successful project usually requires many other skills. For example, managing a Kickstarter requires creating forecasts and budgets, setting prices, interacting with backers, marketing your product, and the technical chops to create a solid demo of the game. Hobby project mentality of team The economics of a project like this result in nobody being paid anywhere close to market value for their time. Nobody, myself included, went into this expecting to make any money and we all had a profit-sharing agreement just in case there were profits. In other words, we all approached this project as a hobby, not as a business transaction. While we did make a modest profit, the project would not have been viable the other way around. Sheer stubbornness It is wired in my personality and DNA to finish things. There certainly have been times in my life when I haven’t finished things, especially as a kid. But, I learned from those experiences and in my professional career I’m very committed to finishing 16
Game On anything that I start unless there is an extremely good reason to do otherwise. This came into play during development. For example, there were plenty of times during the project when I was feeling frustrated and that, combined with it being hard to see the end of the project, was very taxing. Nevertheless, I trudged on. I definitely credit an amount of stubbornness for that; it’s just not acceptable to me to work for years on something and not finish it because I’m frustrated. The way I look at it, I’ve got to keep going, if for no other reason than not letting a multi-year investment go to waste. With these four key factors in my toolbox, it was time to start putting together a game.
17
II. Building the Game Engine
18
Creating the Graphics Engine
Creating the Graphics Engine
B
y the time I resumed programming in 2015, I knew that to produce the gameplay I envisioned, the graphics engine, and realistically the entire game, needed to be written in assembly language for both speed and memory efficiency. Accordingly, I resumed my childhood search for an assembly language book written for beginners using the power of the Internet. This time, I knew what kind of book I needed and I found it: Using 6502 Assembly Language by Randy Hyde. It was written specifically for use with the Lisa Assembler, one of several popular assemblers used in the 1980s. I read the book cover to cover, and typed in most examples. The college classes I had in the 1990s on computer architecture really helped in understanding the material. Okay, this probably bears some explaining. How in the world does a finance/business guy who had a few computer science classes in the 1990s pick up one book on assembly language and suddenly know how to develop an Apple II RPG? While the computer science classes were helpful, the many years of trial and error I spent as a kid trying to put together a working tile-based graphics engine were the most significant factor. What I found during the process of creating Nox Archaist was that the skills needed to code the other components of an RPG are very similar to those needed for the graphic engine. Although there is much more to writing an RPG than the graphics engine, it is arguably one of the hardest parts. 19
II. Building the Game Engine Battling 6502 Assembly Language: Round 2 To build the knowledge base needed to start programming the game I essentially had to figure out the assembly language required to produce results similar to my old Applesoft and QuickBASIC code. This was much easier than it would have been starting from square one with no conceptual understanding of the game engine mechanics. My computer science classes from the 1990s helped in figuring out a plan of attack and providing context to what I was reading. For example, I knew that programming languages at their core are very similar, each containing a mechanism for performing flow control, arithmetic, and input/output (I/O). I had a basic understanding of the role of computer hardware, the operating system, application software, and how they all interacted with each other. This made it possible to understand the structure of assembly language and picture how I could use it to do what was necessary to replicate the tile-based graphics engine I had written years ago. While Using 6502 Assembly Language by Randy Hyde is an excellent book, it certainly did not contain all the information that I needed. Some major holes that remained were disk I/O, random numbers, hi-res graphics, printing text to the hi-res graphics screen, and a mysterious thing I didn’t know I needed called a bootloader. The next order of business for me was to learn more about Apple II hi-res graphics in assembly so that I could stand up a bare-bones graphics engine. The other knowledge holes were more relevant to other aspects of the game engine, which I planned to work on later. There were two books which were my primary knowledge source for the machine language interface to video memory and the hi-res screen architecture: Hi-Res Graphics and Animation Using Assembly Language by Leonard Malkin, and Apple Graphics & Arcade Game Design by Jeffrey Stanton. 20
Creating the Graphics Engine I couldn’t find a PDF of the Jeffrey Stanton book anywhere on the Internet. I ended up tracking down a physical copy and buying it via an online auction for over $ 500. A PDF of the book can now be found on the Internet. Both books are designed to teach techniques for drawing animated shapes on the screen in arcade games. Even though I was working on a tile-based graphics engine, I figured that once I learned how to draw a shape on the screen I could just roll that code into the engine architecture which I already understood. That worked out, and it wasn’t long before I drew a tree, then a row of trees, and then an entire screen of trees (Fig. 3). And soon after, I wrote the tile-graphics engine and rolled in the shape drawing routines and it worked! It took several iterations of the graphics engine to get it to an acceptable level of performance. For example, in the first design I created an RLE compression algorithm to store compressed map data in memory and did an on-the-fly uncompression for the on-screen part of the map. I did that to save memory, always a scarce resource on the Apple II. I was able to get this design
Fig. 3. An entire screen of trees.
21
II. Building the Game Engine running, but the player movement was way too slow. I had to redesign the graphics engine without that type of compression and hope I would have enough memory down the road. Once the graphics engine was able to scroll the screen, allowing the player to explore the map, the next order of business was to create a line-of-light (LOS) algorithm. I puzzled over this problem for a while and decided to cold-contact Beth Daggert and ask for her advice. I had come across Beth’s personal website a while back which mentioned her work coding Apple II games in the 1980s and even a letter she received from Lord British around that time. Beth graciously replied to my email and was able to point me in the right direction with line-of-sight algorithms (see Fig. 5). Later on Beth would formally join the 6502 Workshop Team and advise on several key technical topics including NPC pathfinding, game stats balancing, and the storyline. Beth also helped with beta testing and was roughly tied with community tester Rikkles for being the first person to win Nox Archaist.
Fig. 4. Trying out icons, with the first prototype character.
22
Creating the Graphics Engine
Fig. 5. A line-of-sight algorithm diagram. The red tile is the player while the white tile is an obstacle like a mountain. The algorithm sets the state of the tiles within the black squares as “not visible.”
Side Trek on Apple II Hi-res Graphics The Apple II hi-res screen architecture is very complex and interfacing with it at a programming level is difficult. Despite the Apple II’s seeming ability to display four colors (green, purple, orange, blue), it is really a black-and-white computer. Placing black and white dots in certain combinations produces interference in the color carrier of the NTSC signal. By using this design, Steve Wozniak reduced the number of chips required in the computer, and thus the cost. There were no color computers on the market when the Apple II was released, so this design was quite innovative for the time. In addition to the unusual color display, the addresses of the hi-res screen lines are not contiguous in memory. The memory addresses in hexadecimal notation for the first ten lines are shown in the box below. Notice that the increments between the memory address for each line is $400 bytes until line 9, which loops back around and uses some of the memory space 23
II. Building the Game Engine between lines 1 and 2. The entire high-res screen is interleaved in this way. When drawing hi-res shapes, this adds an extra layer of processing to translate between the shape line numbers and the correct memory addresses. Another oddity lies in the size of video Hi-Res Graphics memory and the hi-res screen. There are 8192 Line Address 1 $2000 bytes reserved for video memory. However, the 2 $2400 hi-res screen is 40 screen bytes wide x 192 3 $2800 4 $2C00 lines which adds up to 7680 bytes. There are 5 $3000 512 unused bytes scattered throughout video 6 $3400 7 $3800 memory in 8-byte chunks known as “screen 8 $3C00 holes.” Such small memory chunks are not 9 $2080 particularly useful, but I designed the Nox 10 $2480 Archaist game engine to use the screen holes to store variable values. This was one of many optimization techniques that we used to squeeze every last byte of memory we could out of the Apple II. The Pixel Editor In this stage of development we also started to make some toolchain decisions. The first such decision was to create a pixel editor. I recalled hearing Richard Garriott talk many times about creating the graphics for Ultima. The Garriott method required him to draw the graphic on graph paper, convert the pixels to binary, flip the nibbles, then convert to hex and input into the assembly code and wonder which step had the error when something didn’t look right. I went through those steps several times to make sure I understood the details. Then, I created a pixel editor based on that method. My choice of development tools for the pixel editor has raised eyebrows: Microsoft Excel (see Fig. 6 and Fig. 52). There were a couple of reasons I chose Excel. First, given that I was not a programmer in my day job, I knew that I would have 24
Creating the Graphics Engine
Fig. 6. Creating a tree in my Microsoft Excel pixel editor.
a significant learning curve to create the tool using a modern programming language. Second, as a finance professional I know Excel very well. For me, creating the tool in Excel was the faster option, at least in the short term. A Difficult Decision At this point, in December 2015, game development was off to a solid start. But, we had not formally created a team or launched the project. The project was just me fiddling with some code, Mike Reimer agreeing, in concept, to get involved at some point, and Beth Daggert answering a few email questions. I was not past the point of no return in terms of commitment. In this context I faced a difficult decision. Prior to my starting to explore Apple II RPG development, I had spent several months networking with people at a local technical college about the possibility of becoming a part-time instructor in finance or business management. I made contact with a department head who said that based on enrollment they didn’t need any help for the next term, but she thought I was a great fit and was encouraging about an opportunity in the future. 25
II. Building the Game Engine The ball was in my court to follow-up before the start of each term. Except, I didn’t see how it would be possible to take on a part-time job and make any meaningful progress on developing an Apple II RPG. It was a hard decision and I decided to stop pursuing the part-time instructor position and instead focus on development. It was time to take the next steps in the creation of Nox Archaist.
26
Creating the First Bootloader
Creating the First Bootloader
W
hen you turn on an Apple II computer with a standard DOS-formatted 5.25-inch floppy disk in the drive, the computer usually displays a “]” prompt and will often display a list of the files stored on the disk called the “catalog” (see Fig. 7). This process loads the disk operating system into memory, which is then responsible for reading and displaying the disk catalog. Many programs and games used DOS as it provided programmers with a helpful bundle of functionality such as file management and easy access to files within Applesoft BASIC. Even some programs written in assembly language, like Castle Wolfenstein, made use of the DOS environment. However, the most advanced games for the Apple II needed so much memory that there was no room for DOS. Beth Daggert
Fig. 7. A typical DOS catalog.
27
II. Building the Game Engine once humorously remarked that “DOS is a big fat pig in memory.” As I began to write Nox Archaist, I quickly saw how true this was. To maximize available memory, most advanced games ran on the bare metal without an operating system. This is not an intuitive concept outside of old-school computer science so I’ll take some time to explain it. When the Apple II power switch is turned on, the computer is hardwired to execute instructions stored in its ROM (read-only memory). There are just enough instructions stored in ROM to read track 0, sector 0 from the floppy disk in drive 1. The computer will read that information from disk and execute it as instructions. Whatever code is stored at that disk location has to take it from there. In the case of a DOS-formatted disk, the information at track 0, sector 0 contains instructions which will load the DOS operating system in memory. For games that run on the bare metal without an operating system, this sector contains instructions to load the game directly from disk into memory. This chunk of code is known as a bootloader because it finishes the task of booting up the computer which the operating system would normally perform. Unfortunately, most games still need to read and write disk data, functions normally provided by an operating system. Games that run on the bare metal have small routines for performing these input/output functions. Since the total size of these routines is much smaller than the entire operation system, a significant amount of memory is saved. Incidentally, Apple II routines that read and write floppy disk data are referred to as an RWTS (read-write-track-sector). I didn’t know any of this when I started developing Nox Archaist. I noticed Beth’s blog comment about DOS being a big fat pig in memory, rolled up my sleeves and did a lot of research. As I spelunked around the ancient archives of the Internet, I found newsgroup posts dating back to the early 1990s which 28
Creating the First Bootloader
Fig. 8. Don Worth and Pieter Lechner’s Beneath Apple DOS.
brushed on the topic. One of them mentioned a book called Beneath Apple DOS which was said to contain all sorts of information about how to interface directly with the hardware of the computer when DOS isn’t in memory. I tracked down the book and dove in. It was pretty advanced but I was able to comprehend enough of it to attempt to write a bootloader. One key detail that was not mentioned in Beneath Apple DOS or in any of the old newsgroup posts I sifted through was the track and sector which the computer’s ROM boot code would read and execute. I decided to put some code at track 0, sector 0 for the lack of any definitive information on the subject. All the code was designed to do at this point was print the letter “M” to the screen and then halt execution. I put the disk in the drive and powered up the computer. The moment of truth was upon me. I saw a letter M print to the video screen. It was the most exciting M that I had ever seen. 29
II. Building the Game Engine I was overjoyed that the test had worked, confirming that track 0, sector 0 was the location where I should put my bootloader code once I wrote it. It was such a simple and obvious location that I suppose nobody ever bothered to mention it. Mike Reimer happened to stop by my house that day and saw I was oddly very excited about a screen that was blank except for the letter M. I wish I had taken a picture of the screen. Later on, Peter Ferrie (aka Qkumba) joined the 6502 Workshop development team and wrote a new bootloader. His bootloader had hard drive support and was also compatible with ProRWTS. ProRWTS is a file system controller that he developed for Nox Archaist and other games which was extensively tested and iterated on using Nox Archaist.
30
Creeping Mobs, Creeping Scope!
Creeping Mobs, Creeping Scope!
O
riginally my goal for Nox Archaist was to create a tile-based game with similar game play technology as Ultima III. This was in part because Ultima III was the first RPG I ever played and is tied with Ultima V for my favorite of the series. This was also an attempt to avoid taking on too much as Ultima III is a significantly less advanced game than Ultima V, the last Ultima released on the Apple II computer. Nevertheless, once the core tile graphics engine was up and running, Mike Reimer and I revisited a feature wishlist that we had accumulated. There were some features on this list which I had thought were highly unlikely when Mike suggested them, such as multi-tile mobs, swimming, and mobs hiding in tall grass. These were features that didn’t appear in any Ultima or any other tile-based Apple II game as far as I knew. I thought surely there was a technical reason that this wasn’t attempted before. As I developed the core tile graphics engine I kept waiting for the reason to become apparent and it never did. I went ahead and took a shot at implementing these features and to our great delight, they worked! These early successes motivated us to reconsider what innovations might be possible within Nox Archaist. If we could implement features beyond those found in Ultima V there was potential to push the frontier of game play technology forward on the Apple II. I realized that going down that road was an enormous undertaking. That meant writing code for features such as day/ night cycles, NPC (non-player character) schedules, a 256×256 31
II. Building the Game Engine Overworld map, joinable NPCs, 100+ hours of content, and more, because Ultima V had all of those things. However, I was overwhelmed with curiosity about how far we could push gameplay technology on the Apple II. Of course, I knew the legendary tale of how Origin Systems started to write Ultima VI for the Apple II and switched gears and wrote it for the IBM PC instead. From this, I had assumed that Ultima V pushed the Apple II to the very edge of its capability. But, we saw some clues that suggested otherwise. What we didn’t know was whether our unique features and the most notable Ultima V features would fit in the Apple II’s memory. This would be a big gamble. However, it was just a gamble of time spent on a fun hobby project and exploring the frontier sounded like so much fun. We decided to go for it and the mission statement of the Nox Archaist project was born and later posted on our website:
“
Develop a modern evolution of the Apple II RPG genre, while exploring how gameplay might have advanced in tile-based RPGs if large scale development had continued on the Apple II platform after the 1980s.
A reasonable question at this point is why we didn’t stick to the original scope and then circle back to make a sequel which pushed the frontier. The answer is that I didn’t know if making Nox Archaist was going to be a one-off for me as a game developer or if I would write more games. As a result, I was thinking about it as possibly being a “now-or-never” decision. As of the writing of this book, the jury is still out on whether Nox Archaist will be a one-off. My current thinking is that I would like to 32
Creeping Mobs, Creeping Scope! make a sequel at some point and several team members have expressed interest as well. Time will tell if the keys are found to unlock that door. In retrospect, it’s clear to me that game development in the 1980s didn’t reach the edge of the Apple II’s capabilities. Close, but not the edge. Market events simply intervened and commercial development shifted to the Macintosh and IBM PC platforms. We decided that it was up to us, while standing on the shoulders of giants, to find out what else could be done. Thanks to a lot of hard work from the 6502 Workshop team and the Apple community, the gamble paid off. We were able to include all of the features mentioned above, as well as a streamlined menudriven user interface, multiple save game slots, a quest log, game state awareness by NPCs, storms, linear storyline elements in an open world, colorful spell effects, clear human speech during the splash screen, and much more.
33
II. Building the Game Engine
34
Nox Archaist Goes Public
Nox Archaist Goes Public
I
n preparation for our Wall Street initial public offering, I gathered a team of investment bankers and other advisors to discuss the strike price of the class B shares to be issued and… Okay, of course not. An IPO for a game for an almost-fortyyear-old computer? That’s just silly. Much like many things in Nox Archaist. In reality, we prepared to make a public announcement about the existence of the Nox Archaist project, which at that time had no actual name. It was just known to us as that Apple II game we were working on. Before we could go public, we decided that we needed to choose a name. Many people have asked me over the years how we came up with “Nox Archaist.” I’ll repeat here the answer previously provided and also give a more detailed explanation. The short short version Mike Reimer and I brainstormed a list of cool sounding words and then looked for a combination that also sounded cool. We picked Nox and Archaist because we liked the unique sound and there were no google search results for it. And, I figured that since Nox means dark/night in Latin and Archaist means the study of old things that would fit most any fantasy story, we just needed to decide who or what was “Nox Archaist.” The more detailed explanation Mike and I had a long text message conversation when choosing the name of the game. I took screenshots because I had a 35
II. Building the Game Engine feeling that someday, someone would ask. I also strove to follow Richard Garriott’s example of preserving early development materials. At the time I didn’t imagine anyone would be interested in reading a book about it, I just thought it would be fun for Mike and me to look back at some day. I’m thrilled that the story behind the game turned out to be something of interest. Here are some excerpts from that conversation (Mark is blue; Mike is gray): Day 1 - Archaist Name thoughts - take a word we like and add a color or number on either side of it Grey Malice 2nd Void Descendent 7 not feeling any of these yet, but it’s an angle I’m working on. thoughts? Grey Spectre. 2nd Spectre I still like Mendacity if there is a significant lie/ deception component to the plot Now, about my tuba..... Found a good potential source for names. You might get some rapid fire ideas acantha (s) ; acanthae (pl) the color idea seems to have some potential Number idea also seems to have some potential....2nd Void in particular may be promising I think the number should be before the word. If it is after, my first thought is that it is a sequel where a name like Acantha sounds cool and googles to very little It’s a bit like Ultima though. Starts/ends with vowel
36
Nox Archaist Goes Public we talked once about not having a wrap around world due to technical problems (now a non-issue but a decision still pending), and having a flat world with a black void surrounding it (which would effectively be dark tiles on the map at the edges) so maybe the dark lord or one of the dark lords is responsible for trapping the world in a void and he’s done it before this is the latest incarnation i.e. 2nd void if you’re liking void I could try to come up with a unique title that includes void the void could play out in a variety of ways....i.e. maybe it is there until the end of the game, or maybe it is removable after some quest mid-game and the world becomes wrap around anyway, yeah, it may be worth trying to come up with something similar to void what if the void is in the center of the map could do that too I’m not stuck on the void thing for a name open to other ideas let me see what other names shake loose sounds good diacanthous Having two spines. two dark lords, conjoined twin. magically separated. player might be second twin not feeling that np aciculate (adjective) aciculum (s), acicula (pl) (nouns) some general grammatical thoughts my gut feelings is that a one word title (not that we’re set not that), should be a word that is at least somewhat recognizable. for a multi-word title, I think that’s more flexible, especially if the uncommon word is a noun agreed
37
II. Building the Game Engine the words should also be easy to figure out how to pronounce I’m ok with a word that is uncommon but looks like a word and is easy to pronounce like this one acrasy I agree, that’s more digestible that I think, for example, something like “aciculate” would be yeah ok, sounds like we’re thinking similarly on this. I’m expecting to send a lot of rejects. so I think a good general efficient protocol would be, send the stuff like your doing, and I’ll let you know if something jumps out. If I don’t comment assume it didn’t jump out. If I don’t comment on something you have a strong feeling on, point that out to me and I’ll give it more thought if it jumps out feel free to reply with a simple rating. A, B or whatever algetic nocebo (antonym: “placebo”) apeiron arbuscular A reference to or pertaining to a dwarf tree; shrublike. that one was a joke archaist Imitatively archaic; affectedly and deliberately antique. Atrioc - made up word derived from Atrocity arbuscular - LOL Archaist - A (not sure on the context given the meaning of the word through, just saying A based on how it sounds) Like “The ____ Archaist” sounds cool, again not sure on context archaist (plural archaists) A person who studies archaic things; an antiquary Vestige of the Archaist that’s a mouthful I like the sound of it but yeah
38
Nox Archaist Goes Public Void of the Archaist Fens of the do you think it would work to use Archaist in a context that really doesn’t fit the definition? for example, maybe it’s a title. it could The Archaist is somebody in the game, but may not have anything to do with studying archaic things per say right ok, if you think we’ve got some room to wiggle there, Void of the Archaist seems like a good possibility, if it’s ok with google searches sect etc Sect of the Archaist (sect was a typo but just sparked an idea) it could work. I could see making it so he’s looking for some old [stuff] for some reason that make his name make sense cool but yeah, it might be better to not be too literal about it right....blurring the lines is arguably part of the creative element Sect sounds as good or better than the rest. So Sect of the Archaist and Void of the Archaist are two top candidates then, it sounds like I think I lean toward Sect a bit more than Void because if we have a void, we may want to keep more of a lid on it Sect of the Archaist googles to nothing specific awesome. should be easy enough to invent a Sect for a dark lord :-0 SOTA googles to a few things but nothing significant Good consideration I’ll keep going but I could see this being the name agreed. I like it better than anything else I think I’ll keep this chat in case we choose it, the way we came up with it is a fun story
39
II. Building the Game Engine Day 2 - Nox I also notice that games often have two parts to the title example: Wizardry 3: The Legacy of Llylgamyn so perhaps we could do : Sect of the Archaist I can get behind that and in that format, maybe the part can just be a cool sounding word and maybe as less meaning Alluvion: Sect of the Archaist I’m liking that for the name of something in the game Descent of the Archaist those two words are tricky for me to spell if we can come up with a good one or two word name, then what comes after the : I think can afford a bit more trickiness so I think : Descent of the Archaist is a good idea too Vestige: The _____ of the Archaist Tazamir: _____ of the Archaist Tazamir could be the name of the kingdom / world Tazamir: Sect of the Archaist Tazamir: Descent of the Archaist DOTA is a thing already I like the descent thing but I think DOTA would be confusing agreed I like SOTA just as well though what do you think of Tazamir is the primary name? it seems very flexible I’m on the fence on that one ok do you like the concept of : where is a word that could refer to the name of the kingdom or world the game is set it? that would enable us to use in sequels as the world would likely continue on
40
Nox Archaist Goes Public I like that Atajo: Sect of the Archaist Aegrus: Sect of the Archaist Implador: Sect of the Archaist I’m out of ideas at the moment, I looked a the words on the sheet for most of them. but, in concept, what I’m feeling the most is : Sect of the Archaist, where possibly refers to the name of the world/kingdon what if archaist is the first part of the name I’m really liking something more neutral for the first part because that makes it easy to setup sequels. The part that hints a the plot I think is better for the 2nd part oft he name, after the colon ok I’m still open to other idea, but it seems like the above formula puts [us] very close because a) we both like Sector (or something) of the Archaist), b) we both like the concept of refering to the world and c) we need to come up with a world name anyway so for those reasons, it feels like we are 99% there with that approach but if something else come up out of the blue, then of course worth considering Aros: Sect of the Archaist Volros: Sect of the Archaist valadon Turnera Tozros Taros Wagunos an topping the list of names not to use: Zirankexuejijin ok
41
II. Building the Game Engine how about something more vague like Nox Archaist maybe that is part of an in game language cool site Nox I think means Night in latin or unit of illuminance I think Nox Archaist has a nice flow and sounds cool memorable not married to it but give that one some time to simmer sure What do you think generally about Nox as the first work of a word of a two word title? Nox Dominion it’s growing on me. I think Nox Dominion sounds good, though dominion is probably a more common word than archaist So Nox Archaist. Night Archaist. I’m liking it maybe Nox is a title in the game. Nox Archaist. Nox Catalyst. like darth. like Nox: Archaist ? No. not game title. as in like an honorific title like Duke John, Duke Bob. Nox John, Nox Bob maybe the dark lord is known as the Archaist. and his title is Nox...so he’s Nox Archaist. and maybe others in the history of the world have that title I’m starting to feel like Nox Archaic might be a way to go vs Nox Archaist Nox Archaist has grown on me. I may be biased because I can imagine how “Archaist” plays into the draft storyline in my head but not so much with “archaic” No Archaic is a little less of a mouthful but Nox Archaist is bold and cool
42
Nox Archaist Goes Public Deciding who or what Nox Archaist would be in the game took a long time. I was not in a rush and my focus was on writing the game engine first. My plan from early on was to follow a design method pioneered by Richard Garriott which involved writing the game engine first and then telling the best story possible using the features of the game engine. This is in contrast to writing the story first and then trying to force the game engine to support that story. I bandied around several ideas for the in-game meaning of Nox Archaist. I considered making Nox Archaist the name of the final boss and also the name of the cult, the final name of which was Vha’ak Oblicae. In the end, I decided to make Nox Archaist the name of the order of wizards because the cult is potentially specific to this game, whereas I could see the order of wizards being relevant in a whole series of games. Conveniently, the backstory I had already written about the origin of magic aligned well with the name. In summary, the backstory was that ages ago a group of philosopher adventurers discovered a powerful energy emanating from deep underground. They learned to harness this energy with their minds and project it to kinetic and psychological effect. This became known as magic. With Nox meaning dark/night, this tied in with the source of magic being found deep in the Depths of Vacous. With Archaist meaning the study of old things, this fit with a bunch of wise folk obsessing over this ancient source of power that they had found. After naming the game, I did the legal work to set up 6502 Workshop, LLC. Then, on March 26th of 2016 we launched the Nox Archaist website and publicly announced the project. I decided to post the announcement to comp.sys.apple2 because the folks there were really helpful in answering my numerous questions about 6502 assembly.
43
II. Building the Game Engine We are excited to introduce Nox Archaist, a new role playing game we are developing exclusively for the Apple II platform and emulators. Currently we are targeting a release date sometime this year. Nox Archaist is a 2D tile based fantasy RPG with a classic Apple II look and feel. We are taking advantage of the full 128k available on the IIe and later models which will help us create features and effects that may not have been seen in vintage 1980s Apple games. Game play videos and screenshots showing the current evolution of the Nox Archaist game engine are available below.
6502 Workshop Mission Ѽ Develop a fun game CRPG enthusiasts will enjoy playing Ѽ Include ideas and feature sourced from the Apple II community when possible Ѽ Explore a modern evolution of the Apple II RPG genre Ѽ Create a repository of hard to find technical information on developing Apple II games Ѽ Determine how many two layer shrubberies with a path down the middle will fit on the Apple II hi-res screen
Nox Archaist Technical Details Ѽ Runs on any 128k Apple IIe or later system Ѽ Physical machines and modern emulators are supported Ѽ Current game testing is being done on a physical Apple IIe and in AppleWin Ѽ Coded entirely in 6502 Assembler, no construction sets used
THANK YOU Special thanks go out to Beth Daggert for brainstorming on darkness algorithms, loader zones, and much more. We would also like to thank San Bergmans, developer of the SBASM cross assembler, for extensive product support including feature additions. Finally, thanks go out to the comp.sys.apple2.programmer forum community including David Schmidt, Michael Pohoreski, Oliver Schmidt, Qkumba, and many others for their time and advice on assembly language questions. Fig. 9. Announcement of Nox Archaist on comp.sys.apple2.
44
Nox Archaist Goes Public The announcement mentions a target release date by the end of 2016. The graphics engine was done and that was the part of the game engine which I had found so technically daunting as a kid. I thought surely that was 90% of the project. Well, take a look at the title of the next chapter. After making the announcement on comp.sys.apple2, much to my delight, the Apple II community quickly embraced Nox Archaist. I was invited as a guest twice on the Open Apple Podcast: first to talk about the project in general and later to talk about our first Kickstarter Campaign. Shortly after Nox Archaist going public on comp.sys.apple2, I met Ken Gagne, the publisher of Juiced.GS. The Juiced.GS magazine has been in publication since 1996 and is currently the only Apple II-focused print magazine.
Fig. 10. The map from March 2016, with “6502” in the ocean. As far as I know it’s still downloadable from comp.sys. apple2. I often thought that the test island looked like a sultan riding an elephant. That was totally unintentional!
45
II. Building the Game Engine Over the years, Ken and I worked together on several Nox Archaist articles for Juiced.GS. To our delight, he put Nox Archaist on the cover of the March 2021 issue and included a full review of our recently released game. The road was long to get there, but well worth it!
Fig. 11. My second appearance on the Open Apple podcast.
Fig. 12. Juiced.GS cover, March 2021. Cover art by Ludovico Tellatin. Plus, back cover ad from Dec 2020.
46
The Second 90%
The Second 90%
S
everal years into the project I had a Skype call with Burger Becky. We met through our mutual friend Beth Daggert and then later met in person at KansasFest 2018. As the creator of games like Bard’s Tale III, Dragon Wars, and Tass Times in Tonetown, it was a real thrill to have the opportunity to talk to her. We talked about a lot of things and one that stuck with me the most was when she said “when developing a game, the first 90% is a lot harder than the second 90%.” Yeah. That was the mental trap I had fallen into. Several times. It was pretty much an annual tradition that I would update the release date to the end of the next year. When my family would ask me when Nox Archaist was going to be done, my typical response was “by the end of the year or the end of next year.” Eventually one of them called me on it and said “but that’s what you said last year!.” While talking to Becky, I also took the opportunity to tell her how much I enjoyed the spell name “Summon Herb” and the temple monk’s Gregorian Chant. About Herb she said, “watch out, he’s got a big walking stick” and about the chant she said that the whack sound, of the monks hitting themselves in the head with a holy board, was created by her dropping a thick Apple II manual on her desk. After the call, I noticed in Skype that the tagline on her profile said “Magical girl for hire. No monster too big. No fee too big.” I chuckled because it reminded me of an odd and hilarious line in the movie Ghostbusters. After the Ghostbusters became a 47
II. Building the Game Engine huge success, Peter Venkman was talking to a gaggle of reporters and said “No job is too big. No fee is too big.” The next time I talked to Becky I made a point of asking her if her Skype tagline was an homage to Ghostbusters. She confirmed that it was and we had a fun laugh about it as it is a fairly obscure line. She’s the first person I ever met who took note of it. Qkumba is OP Prior to the March 2016 Nox Archaist announcement, I added the code to support entering towns. This required reading data from disk. This turned out to be fairly challenging. During my work on the bootloader, I used the RWTS from DOS 3.3 to read the game engine into memory. This saved a lot of memory because the RWTS is much smaller than the entire operating system. For the bootloader to use the RWTS to read the game engine from disk, I had to pass the parameters for the track and sector
Fig. 13. An early town using Mark and Mike’s art. All of these tiles were redone by Bill Giggie.
48
The Second 90% to read from. Adding support for entering towns required the game engine to make similar calls to the RWTS, but specifying the track and sector of the town map data. The problem is, as data was added to the disk, the track/sector location of preexisting data would change. The track/sector changes needed to be dynamically updated in the source code. I could see how that would get unwieldy in a game the size I envisioned, which had dozens of towns, castles, keeps, ruins and caves, each of which would have data stored at different track/sector locations. I’m confident that I would have figured out a solution, but as it turns out I didn’t have to. One of the people who responded to the March 2016 Nox Archaist announcement on comp.sys. apple2 was Peter Ferrie (aka Qkumba). In his response he said that he might be able to do a ProDOS conversion so the game could run on a hard drive and he mentioned it would be better to do it before the game was finished. By March 2016, I had seen Qkumba’s posts and knew he was very knowledgeable. He had answered several questions I posted to comp.sys.apple2. When I saw his reply about a ProDOS conversion I was confused. I wondered how we could possibly fit ProDOS in memory and build the game I was envisioning. I had gone to great lengths to write a bootloader so Nox Archaist could run on the bare metal without DOS in memory and just use a small RWTS to read/write disk data. But, seeing how knowledgeable Qkumba was, surely I was misunderstanding something. I began discussing with Qkumba how a “ProDOS conversion,” as he put it, would work. What I eventually came to realize was that “ProDOS conversion” was shorthand for something much more complex and amazing. When I read Beneath Apple DOS to learn enough about the ROM boot code to write a bootloader, I read about how to interface with the disk drive. The hardware controller board in Apple II disk drives is extremely limited in functionality. It can 49
II. Building the Game Engine translate the electrical signals from the drive into zeros and ones but can’t control the drive arm position. Instead, the drive requires a software controller (the RWTS) to tell it what to do. Writing an RWTS involves writing code to turn the drive motor on, move the drive arm to the position of the data you want to read, and then read a byte off the drive head. When the drive arm is moving, the software controller has to loop to “wait” until the drive arm is at the correct position. If the controller doesn’t wait, then when it reads a byte off the drive head, the byte value will be garbage because the drive arm is not in the correct position. These wait loops must be timed down to a single CPU clock cycle of accuracy, which is extremely difficult to do. When it’s not done correctly, problems occur, which programmers usually describe as being “timing problems.” When I read the chapter about the mechanics of the floppy drive interface under the hood of a RWTS, I was stunned. I was able to generally understand the concept of what was involved but the reality of actually doing this was daunting. The book specifically said that they advise that the only people who should do this are pretty much nobody because Steve Wozniak took care writing the DOS RWTS back in the 1970s. The only other person I had ever heard of attempting such a thing was Roland Gustafsson, the legendary copy protection developer for Brøderbund Software. After talking with Qkumba for a while I realized that “ProDOS conversion” was his shorthand for writing a custom RWTS, which happened to be compatible with the ProDOS file system. Doing this would mean being able to read and write files with the correct ProDOS format and headers without the ProDOS operating system in memory. It would also mean that Qkumba would need to write code to directly move the arm of the floppy drive, and craft his delay loops down to a single clock cycle of accuracy. This is when I realized that I was talking to a grandmaster 6502 assembly programmer. 50
The Second 90%
Fig. 14. A tweet about Qkumba’s session at KansasFest 2017.
Qkumba would later live up to that in many ways, delivering on his proposed RWTS and optimizing the game engine code so tight that it would create a diamond if a lump of coal had been in it when he started. He would eventually formally join the 6502 Workshop team and work on a variety of programming activities including ProRWTS, optimizing the Mockingboard driver for in-game music, splash screen optimization, game engine optimization, and rewriting our bootloader. At the same time, Qkumba continued contributing to many other community projects including working with 4AM to preserve Apple II software and helping to write Total Replay, a
Fig. 15. Mark Lemmert, Chris Torrence, and Peter Ferrie. KansasFest 2019. Qkumba (Peter Ferrie) became my 6502 mentor and go-to person for Apple II questions.
51
II. Building the Game Engine compilation of hundreds of arcade-style games which were converted to ProDOS using the RWTS developed in the Nox Archaist test bed. I recall an occasion at KansasFest, hanging out by Mark’s Pilgrim’s House of Crack in the dorm commons (Fig. 16), when he and Qkumba were working on cracking a particularly difficult copy protection scheme, so that they could preserve the software. Peter was watching the machine dump output on his terminal and reporting values to Mark. One of the people watching noticed that Qkumba seemed to be running the machine code in his head, tracking the register values, and then converting the hex to nibbles and shifting the bits in his head in order to give the feedback to Mark. The person watching asked Qkumba if that’s what he was doing and Qkumba just smiled as if to say “what, is there another way to do it?” It’s no wonder Qkumba has had an exemplary career cracking the most difficult virus and cybersecurity problems for companies like Microsoft, Symantec, and Amazon.
Fig. 16. Surely, there must be a better name. Mark’s House of Crack, KansasFest 2017.
52
The Second 90% All of these stories are the backdrop for my delight when one day during beta testing I saw this alert on the Nox Archaist Discord server:
Discord displays these messages when any new user joins a server. They appear to be random and this is the only time I’ve seen this particular message. The acronym OP is gaming chat for “overpowered” and “nerf” is gaming slang for making something significantly weaker. Somehow Discord’s algorithm just knew. ProDOS RWTS Once I understood that Qkumba wanted to create a ProDOScompatible RWTS, not actually run Nox Archaist within the ProDOS operating system, I was all in. We rolled up our sleeves and began what ended up being months of grueling work. It didn’t take long for Qkumba to write the first iteration of his ProDOS-compatible RWTS, later to be named ProRWTS. What followed was a months-long process of debugging with me running a variety of tests, running floppy diagnostics, reporting bugs, and receiving fixes from Qkumba. Rinse and repeat. One of the earliest and most difficult bugs had cropped up when I tested the capability of ProRWTS to read and write from drive #2. My Apple IIe had two different models of disk drive. It turned out that the second disk drive moved the drive arm at a slightly different speed and Qkumba had to adjust the delay loops to account for this. 53
II. Building the Game Engine After a few months we had ProRWTS working in Nox Archaist on emulators and on hard drive cards such as the CFFA3000 on physical Apple II hardware. However, disk-drive grinding and occasional crashing would occur when using floppy disks on physical hardware. These were particularly difficult bugs and they took over a year to solve. One of the things ProRWTS does before a read or write operation is send codes to the floppy disk drive telling it to power up the drive motor. ProRWTS needs to wait for the power up to complete before attempting to move the drive arm. If the wait isn’t long enough, the drive arm would run out of power before reaching the destination track, thus ending up in an unexpected position, often between two tracks. When a read operation occurs with the drive arm between two tracks, the drive is able to detect this based on the electromagnetic patterns on the disk surface. The drive then tries to correct itself by moving the arm to the farthest edge of its travel, causing an audible grinding noise. There were also crashes when writing data because some floppy drive models required the write-protection state to be read before the drive would allow write operations. For those drives the write operation would fail silently, creating an intermittent problem that was eventually solved by changing the ProRWTS code to always read that state. The check was initially omitted to save memory, relying on the hardware to prevent writing to a write-protected disk. Another write-related crash was caused by accidentally writing data on the half tracks in between full tracks. Data on the floppy disk surface is stored as a magnetic transition where the polarity switches from north to south or vice versa. When a transition is detected the floppy drive sends a 5 volt signal for one microsecond to the floppy controller card, which the card interprets as the presence of a bit with a value of one. If four microseconds elapse without the card receiving a 5 volt signal, 54
The Second 90% it interprets that as a bit with a value of zero. (Although the placement of the transitions on the disk is roughly four microseconds, the controller actually waits six microseconds before declaring a zero because the hardware isn’t precise down to a single microsecond.) The floppy disk is spinning at 300 revolutions per minute (RPM) inside the drive, so the four microsecond lapse is a result of the physical spacing of the magnetic transitions on the disk surface. In other words, the physical spacing between magnetic transitions is critical to reading the correct data values. When we accidentally wrote data on half tracks, that interfered with the way the magnetic transitions were interpreted on the legitimate full tracks. This problem presented itself as a random crash or hang which resulted in a damaged disk. We eventually narrowed this bug down to only occurring during write operations such as entering a Castle or Town from the Overworld. An examination using Copy ][ Plus showed that the disk had bad sectors after the crash and from there a targeted examination of the low-level disk code revealed the actual problem. By 2017, the ProRWTS floppy controller and hard drive controller were working on both emulators and physical Apple II hardware. Or so we thought. Unbeknownst to us, another bug lurked deep beneath the surface which triggered very infrequently from a testing perspective but was catastrophic for people playing the game for hours at a time. We didn’t find that bug until the eleventh hour, only a few months before the game was released—more on that later. Bill Giggie’s Amazing Art In June 2016 we announced a graphics contest, challenging the Apple II community to create tile art for Nox Archaist. Although we hoped to get some fun tile art, the primary reason was to find a graphics artist interested in joining the 6502 Workshop team. 55
II. Building the Game Engine Near the end of the contest, we were contacted by Bill Giggie. Bill is a graphics animator in the movie and TV industry. He also used Apple II computers in the 1980s and had recently acquired one again. He came across the 6502 Workshop website while looking for information about his Apple IIc. Bill won the graphics contest and joined the team. Over the course of the project he created over 1000 unique tiles, almost a dozen large merchant images, the camping screen and treasure drop image, and the splash screen art. He also created the map design for Nourtheld Castle. Diligent map makers will find his initials embedded in the castle map. In the pre-beta copies of Nox Archaist, there was a test island in the upper left corner in the Overworld map, shown in Fig. 17. When Bill would create tile art, I would set up the art to appear on the test island so we could see it in-game. One of the mobs in this screenshot is the Novice Cultist. As you may recall from playing the game, the Novice Cultist is
Fig. 17. The pre-beta test island. We usually worked on several art pieces at a time, so the island was often a hot mess.
56
The Second 90% animated and whacks himself in the head with a book repeatedly. Bill created this design as a joke, but when I saw it I knew “that’s the one!.” Bill thought it might be too silly but was more than happy for it to be used. Much of the silliness in Nox Archaist is contained within Castle Foolery but this bit of silliness managed to escape into the rest of the game. Bill would frequently create several versions of the same tile and we would choose which one or a couple we liked best and he would make revisions to those. Fig. 18 shows the pirate ship tryouts. The salty sea dogs in the second ship on the second row made the final cut. Bill was an exemplary team member, constantly pushing us to make Nox Archaist the best game that it could be and putting in many long hours doing the heavy lifting of art creation. Looking at the early development screenshots in this book, you can see what Nox Archaist’s art would have looked like were it not for Bill’s contributions. Bill also recruited two other team members: Robert Padovan, who created some tile art pieces and helped with video editing on the first Kickstarter, and Electric Moo, who wrote the music for the second Kickstarter and the game’s soundtrack.
Fig. 18. Pirate ship tryouts. Only the saltiest sea dogs will survive.
57
II. Building the Game Engine NPC Schedules and Nox A* At this point, 6502 Workshop had five team members: Mike Reimer, Beth Daggert, Peter Ferrie, Bill Giggie and myself. My role was evolving quickly from strictly coding to coding and project management, which is solidly in my wheelhouse. There was a lot of work to do and there were many dependencies between different tasks. I sorted it all out and turned the project into shovel-ready small tasks that each team member could work on as they had time. I was constantly switching back and forth between different activities in order to make sure I was never, or rarely, the bottleneck to progress. From 2016 to 2018, amidst working with Qkumba on ProRWTS, Bill on graphics, Mike on sound effects, Tom Porter and Eric Rangell on Mockingboard support, and Michael Pohoreski on the splash screen, I was pushing forward with adding core game engine functionality like NPC schedules, combat, the inventory and merchant interface and more. During this work, Beth was always there for me when I asked for advice on game balance, design considerations, and technical concepts. One such occasion was tackling the challenge of non-player character schedules. In nearly all 8-bit role playing games, NPCs were assigned to a specific position on a specific map. They might move around a bit on a “tether” to that position, but that’s about all the moving they would do. This changed with Ultima V, which assigned each NPC to several different positions throughout the day, to simulate a daily schedule of “work, eat, sleep.” As I pondered the implementation of this feature, I could only come up with one solution: hard code the map coordinates between each of the NPC’s scheduled positions. By creating a list of the coordinates and the times of day for the NPC to change positions, I could picture how to break things down into mechanical chunks that I could code. However, I was reluctant to commit the huge amount of disk space that this solution 58
The Second 90% would require, keeping in mind that an Apple II floppy disk only held a little over 140 000 bytes per side (less space than some email messages). I reached out to Beth to see what advice she could offer. She explained several approaches that retro games had used to solve this problem. One of them was to predefine a series of flocking points between the NPC’s assigned locations and use magnet algorithms to make the NPC travel between them. The flocking points would be placed to guide the NPC around fixed obstacles, like walls. This would significantly reduce the disk space since we wouldn’t be storing all of the coordinates along the path. Another solution she mentioned was to write an A* algorithm. The algorithm would receive the start and destination coordinates as inputs and then crawl around the map until it found a path and then save the path in memory. This approach was more complex to code on the front end but would automate the pathfinding process whereas flocking points would require manual calculations and data entry for each NPC. The kicker was, she wasn’t sure whether the Apple II’s 6502 processor could handle the algorithm. The A* algorithm was invented by Peter Hart, Nils Nilsson, and Bertram Raphael of Stanford Research Institute (now SRI International) in 1968. However, it did not come into widespread usage in gaming until the 1990s, when computers were quite a bit faster than the 6502. This was just one of many tough technical decisions I had to make which had significant stakes for the project outcome. A wrong decision could at best cause months of lost work, and at worst crater the project if a critical limitation affecting gameplay were not found until the entire game engine was implemented and the “cement was poured.” I didn’t always make the right decision in these cases, but I usually made a decision that worked out well enough and didn’t have catastrophic consequences. In this case, I decided to go 59
II. Building the Game Engine for it and attempt the A* solution. It turned out to be the right decision or at least a workable one. As far as I know, Nox Archaist is running the first A Wrong Decision A* style algorithm ever writAs an example of a “wrong” decision, in ten on a 6502 platform, which the first iteration of the graphics engine I kept the map data compressed in I named Nox A*. Getting it memory and then uncompressed it on to work took a huge amount the fly to draw to the screen. Each time of optimization. For examthe player moved, I would uncompress ple, the A* algorithm tracks the appropriate row or column. a massive amount of data as It worked but it was way too slow. I’d it crawls through the map; estimate that the movement speed was searching through that data is five times slower than the final graphics very slow on the 6502. I had to engine. In the final architecture, map data is stored compressed on disk, and rewrite the search algorithm a 48×48 region of the map is stored in Nox A* several times to cut uncompressed in memory. This is a down on clock cycles. small slice of the 256×256 map, but large enough so the player has to move a fair The 6502 was far too slow distance before the game needs to load to run Nox A* on the fly when and uncompress the next chunk. the NPC was ready to move. I had to change the design so that the algorithm ran in the background, working on calculating paths for NPCs scheduled to move in the next two hours. Running in the background meant using the spare clock cycles while waiting for the player to press keys during game play. By running Nox A* in the background, the paths would be ready for the NPCs to use by the time they were needed. In the process of creating Nox A*, I took the opportunity to add features that I had never seen in an 8-bit RPG: Ѽ NPCs can appear on different maps. Ѽ NPCs do not take the same route every time. Ѽ NPCs can navigate around dynamic obstacles. Ѽ NPCs are aware of player “harassment.” 60
The Second 90% The awareness of player harassment was inspired by my harassment of NPCs in Ultima V. For example, I would stand in front of them and block their path, just to see if the game was capable of moving them around me. It wasn’t. NPCs in this situation would plant their feet and refuse to move. The sun would rise and set with the NPC standing in the same spot, until the player ran out of food and starved to death. In Nox Archaist, I wrote an extension to the traditional A* algorithm which enabled NPCs to detect if the player or another NPCs was standing in front of them. In this case the NPC would try to navigate around the obstacle. I went one step further and thought some devious player might move to block the NPCs path over and over and never let them navigate around. I wrote code to detect if that happens and trigger the NPC to speak out in protest. The first draft of the text (Fig. 19) may hold some humor for fans of the Princess Bride.
Fig. 19. The brute squad. Anybody want a peanut?
61
II. Building the Game Engine The Inventory System Another part of the game engine we spent a lot of time on was the inventory, character management and merchant transaction system. Mike and I wanted to apply modern sensibilities to the design and do something really innovative for an 8-bit game. We spent hours sketching screen layouts on a white board. One key consideration was a completely menu-driven interface. We didn’t want the player to need to refer to items using arbitrary letters. For example, a typical 8-bit RPG interface would involve multiple keyboard commands to ready an item. You might press R to ready, then press 1 to select character #1, and then press B to ready a dagger because B is the letter that was assigned to the dagger item. In contrast, in Nox Archaist you navigate your inventory in a menu system using the arrow keys; when the item you want is selected, you just press enter. We also wanted the player to be able to see their inventory when buying or selling items. This avoided the need to exit the merchant dialogue and then launch inventory, which took a non-trivial amount of time on an 8-bit system. Finally, we wanted to stop the player from selling items to the merchant which the player had readied, preventing accidental sales when the player was just trying to dump their extra items quickly. There were games well into the 1990s which didn’t have this safeguard. Once we settled on a design, I translated it to graph paper, giving me the space measurements that I needed to mock it up on the hi-res screen using the game engine’s subroutines for printing hi-res text and drawing lines. Standing up the design in 6502 assembly was a long process, even though I already had the subroutines. The images on the following pages show our progress along the way.
62
The Second 90%
Fig. 20. Graph paper sketch of the character info screen.
Fig. 21. Graph paper sketch of the inventory screen.
63
II. Building the Game Engine
Fig. 22. First iteration of the inventory display.
Fig. 23. Inventory display, with the character list.
64
The Second 90%
Fig. 24. Character stats with tab icons but still the old font.
Fig. 25. Inventory display with tab icons.
65
II. Building the Game Engine
Fig. 26. Final version of the inventory display.
The final design for these systems took a huge amount of memory, more memory than I could spare. And, even if I could spare the memory, the load time to read the entire inventory module from disk was unacceptably slow from a gameplay perspective. To get it to work I had to break the inventory module into submodules and load each submodule from disk on the fly when needed. For example, the ready/unready item submodule is only loaded from disk when the player presses the enter key to ready/unready an item. To save additional memory, I was also able to reuse most of the code with the merchant transaction module which displays the player’s inventory on the left side of the screen. Pushing the Combat Frontier The combat system took about 6–8 months to develop. As with other systems, this is in part because we wanted to push the Apple II RPG frontier. Some of the combat system features I’m 66
The Second 90% most proud of are the ability to flip between targets using the key, allowing the key to do both target selection and attack, and the removal of newbie penalties such as the forfeiture of a turn by pressing the wrong key. This design was inspired by watching my nieces and nephews playing 8-bit RPGs from the 1980s. I saw how they wanted to play those games but were frustrated by the interface, which required attacking along the cardinal direction lines. They would often attack in the wrong direction or press an invalid key and lose the turn for that character. In Nox Archaist they could just mash the attack key and accomplish something since executes target selection and also initiates an attack. Once they had the hang of that, it was a small leap to press and then the key to flip between targets. I also took the time to give the mobs as much intelligence as I could manage in 8-bit. Many players have commented that the mobs have an uncanny ability to figure out who your archers and spellcasters are and target them. Another major undertaking was graphical effects for spells. Fireballs explode dramatically, while lightning bolts streak smoothly across the screen at widely-varying angles (see Fig. 27). This was not the norm for tile-based 8-bit games: shapes in those games tended to move in discrete jumps between tiles. This was another case where I wasn’t sure if it hadn’t been done because of a technical obstacle or if developers just hadn’t got around to it yet because there was lower hanging fruit. It turned out to be the latter. I explained the technical issues and solutions in detail in my first interview on The Lost Sectors. To check it out, search on YouTube for “Lost Sectors,” then look under “Developer Discussions” in October 2017.
67
II. Building the Game Engine
Fig. 27. Look at the shallow angle on that lightning bolt!
Fig. 28. The mobs get impatient and attack the screen. Due to the lengthy development time for combat, we had several incidents of this nature. Those responsible have been sacked.
68
The Second 90% Treasure Drops For the treasure drop system, I considered placing the treasure as icons on the battlefield for the characters to pick up but in the end decided on managing it via a text window. This decision was partly made due to space constraints within the tile system. The game engine has seven tile sets, each with 256 tiles. Each map type (Castle, Keep, Overworld, Ruin, Town, Underworld, Underworld Town) has its own tile set. To manage treasure drops with icons, we would need tiles for each icon in every tileset because combat could happen in any map type. Some tile sets ended up completely full, creating a bottleneck for any features requiring “universal” tiles (see the sidebar below). As shown in the following screenshots, it took a lot of code iterations to select the items to drop, add them to the inventory, print the text in the correct location, polish the interface for selecting which items to pick up, and squash all of the bugs!
Tile Optimizations Tile range $E1–$FF was reserved for tiles which needed to be in all tilesets and have the same ID, such as player icons and summonable monsters. This “duplication” was actually an optimization to trade disk space and memory in exchange for a faster load time when entering a new map. We could have stored the tiles once and loaded each one from disk based on their tile ID. But, in addition to extra code to calculate the file offsets, the disk loads themselves would take more time if done one tile at a time rather than all 256 tiles in one read.
69
II. Building the Game Engine
Fig. 29. First iteration of treasure drops.
Fig. 30. An early experiment on item selection.
70
The Second 90%
Fig. 31. The final version of the treasure drop screen.
Quick Combat The Quick Combat feature was a personal stretch goal for myself and became a formal stretch goal in the second Kickstarter campaign. I became extra motivated to implement Quick Combat after reading many comments during the Kickstarter campaign from people that said, in essence, they loved Ultima but found combat to be very tedious. In my opinion, Ultima has a great tactical combat system. Nevertheless, the problem with 8-bit tactical combat systems is that they are time consuming and can get tedious in battles with low-level mobs where the outcome is not in question. I thought that having a Quick Combat option, in addition to the Tactical Combat system I already developed, was a great solution. I went ahead and added Quick Combat and it turned out better than I thought, at least in terms of the polished screen layout.
71
II. Building the Game Engine
Fig. 32. Early design document for the Quick Combat screen.
Fig. 33. Quick Combat in action.
72
The Second 90% However, Quick Combat became very controversial, mainly due to the artificial intelligence limitations which I could not solve within the Apple II constraints. In order to save memory, the AI doesn’t simulate a battle using the full Tactical Combat system with the computer controlling the character’s actions. Instead, the AI simulates a battle using a much simpler scenario where the mobs and player characters are organized into front and rear groups, similar to the combat systems in Bard’s Tale and Wizardry. Some players expected that Quick Combat would always produce the same win/loss results as Tactical Combat with the same mobs and player characters. This was a reasonable expectation from a modern gaming perspective. However, that didn’t change the fact that I was boxed in from a resource perspective with no room to maneuver. The reality is that Tactical Combat and Quick Combat don’t always produce the same results. During beta testing this was a hot topic of conversation on Discord. I tried a variety of adjustments to decrease the frequency of this issue, including: Ѽ Decrease mob power if player is level 1 or 2. Ѽ Decrease mob power, regardless player level, if the game doesn’t advise the player to use tactical combat. Ѽ Increase power for all characters with ranged weapons because in tactical combat they’d get to fire before the enemy reached melee distance, whereases in quick combat the mobs and characters are in melee range at the start of the battle. After making adjustments, I concluded that it was as good as I could make it. The only decision left was whether to keep the feature in the game for public release. In the end, I decided to leave the feature in because it was still very beneficial when used as I originally envisioned it. If Quick Combat is used in a battle when the player massively overpowers the mobs, then the player will win in both Quick Combat and Tactical Combat every time. Using the feature in this way significantly reduces 73
II. Building the Game Engine the tediousness of combat in the mid-to-late game. Many players were using the feature this way and were big proponents of keeping it. It was a tough call and I’m not 100% sure I made the right decision to keep the feature in but I think so. Shop at Willy’s The origin of the “Shop at Willy’s” joke actually originated with the development of the Wait feature, which the player can use to rapidly pass time in the game. After seeing the Wait feature, Bill Giggie gave feedback that he didn’t like the screen going all black. Bill is a graphics animator, working on movies and TV shows, so I queried him about instances of black screens I’ve seen in that context. This was the exchange we had (Mark is in blue, Bill is in gray). On a side note, I think the screen going black briefly is supposed to represent the rapid passing of time, like when the curtain closes at a play and then reopens to a changed set (and the set can change in the tile worlds as different NPCs might be on screen at different time of day... day might change to night etc.). Isn’t this a technique used in the cinematic world?
Yes they are called commercials but the side benefit is they pay for the content ;^) Maybe we could add a small commercial for Willy’s weapons or others.
Based on this feedback I added several random text strings to the Wait screen such as “The party waits impatiently” and “The party counts its gold.” I also added a commercial for Willy’s. The joke spread and eventually “Shop at Willy’s” was added to the Quick Combat status (Fig. 34). I also added an armory shop called Willy’s in an area the player wouldn’t encounter until later. My hope was that people would assume the text on the Wait and Quick Combat screens was nonsense, and then laugh when they find out much later that there really is an in-game shop called Willy’s, and then laugh even more when they find our “Willy’s” merchandise store on the Internet. 74
The Second 90%
Fig. 34. The “Shop at Willy’s” ad during Quick Combat.
Mockingboard Music When Mike and I played Ultima on the Apple II back in the 1980s, we didn’t have Mockingboard cards. We enjoyed games just fine with the sound effects coming out of the stock Apple II speaker. A few years before the Nox Archaist project, we played a fan game called Ultima IV Part II which was absolutely amazing (check it out) and it played the Ultima IV soundtrack during gameplay. Neither Mike nor I really liked the soundtrack and we turned it off. No criticism is intended to the composers of the soundtrack, it just wasn’t how we were used to experiencing that kind of game. For these reasons, when we launched the Nox Archaist project, we did not plan on having in-game music. We focused our time on other things, such as pushing the limits on graphics. We periodically got questions from people in the community asking about Mockingboard support and eventually we started answering the question with “maybe.” My plan was, at some point, to look into what would be involved in adding Mockingboard 75
II. Building the Game Engine support and assess whether it was viable from a system resource perspective, specifically memory and CPU. In September 2017, I was a guest on the Open Apple Podcast, hosted by Em Maginnis and guest host Fake Quinn (aka Carrington Vanston). When Fake Quinn asked me the Mockingboard support question, I said “maybe.” Eric Rangell later listened to the podcast and heard this. Eric Rangell has been active in the Apple II community for sidebar by Eric Rangell years working on a variety of I started with songs I wrote in my 20s projects related to sound and that were never published anywhere. music (see sidebar). He would Using code that let me play piano through a Mockingboard I experinot take “maybe” for an answer. mented with various open chords to That man, he never gives up! find combinations that sounded good He asked me if I would be for each song and wrote three-part open to talking to Tom Porter, arrangements for them. The music driver in the game plays the three parts another sound and music in stereo through the Mockingboard. programmer, about having him write a Mockingboard Later we decided to use short clips of up driver. I said sure. to 30 seconds for each music segment in the game, so I edited the songs to make Eric tracked down Tom them fit that structure. I was able to and initiated a discussion break longer songs into multiple songs. with him on the Nox Archaist Bach was a definite influence for me, as forums. The prospects early I read Godel Escher Bach in college and on did not seem promising. entered the Musical Offering canons Nox Archaist was extremely into Bank Street Music Writer. I also memory constrained and the selected pieces by Tielman Susato from the 1560s that I felt were good for the requirements Tom and Eric game. Electric Moo provided me with estimated for a Mockingboard tracks for the game which I converted driver well exceeded what we to three-part Mockingboard arrangehad available. ments to the best of my ability and technical capabilities available. We even Around this time I was used a public domain version of Yakkety catching up with Burger Becky Sax for one song. and happened to mention that 76
The Second 90% we were looking into Mockingboard support for Nox Archaist but it didn’t look good because of memory constraints. She shared with me that the Mockingboard driver she wrote for Bard’s Tale III was only 512 bytes in size, significantly less than Tom and Eric’s estimate. I was intrigued because I thought we could spare 512 bytes. Becky wrote up some specifications which I shared with Tom and Eric and they agreed it was doable. It was a long project and we went through several design iterations before finalizing on the short streams of music that you hear in the public release of Nox Archaist. Eric and Tom were very dedicated and I very much appreciate their efforts despite my initial hesitation on music. In the meantime, another teammate, Electric Moo was quietly working on a masterpiece that would become the Nox Archaist soundtrack, a series of modern music pieces for players to optionally play on their sound system while playing the game. Electric Moo is a professional musician and put forth his best effort for this work. Some of the in-game music tracks that Eric created were based on songs from the Electric Moo soundtrack. The final design of the Mockingboard driver in Nox Archaist came about as a result of a conversation with Apple II community member Ian Baronofsky at lunch during KansasFest 2018. I shared with him that I really wasn’t a fan of music constantly playing like in Ultima. I also shared that we were having technical problems due to Nox Archaist’s above-average frequency of disk loads. The increased disk usage was a direct consequence of features and designs which were pushing the frontier forward, such as breaking the inventory into sub-modules and loading graphical spell effects. This was a problem because the Apple II couldn’t play Mockingboard music and load data from disk at the same time without the music sounding choppy. This was because the disk controller is software-based and must run delay loops waiting for the drive arm to reach the correct position. Mockingboard 77
II. Building the Game Engine drivers are interrupt driven, meaning at any time the CPU can be pulled away to process the interrupt. If that happened while the disk controller was running a delay loop, that would unintentionally lengthen the delay, the drive arm would be in the wrong position, and garbage data would be read. The standard 1980s solution to this dilemma was to turn off interrupts before initiating any disk operations and turn interrupts back on when the disk operation was complete. However, due to Nox Archaist’s frequent disk access, the result was unacceptably choppy music. It sounded awful. Ian suggested playing 10-to-15-second music clips after the player changes maps. That would make music more of a special thing since it wasn’t playing constantly. And, in conjunction with a fade-out feature that Tom Porter added, the game engine could gracefully stop the music if the player did something that initiated a disk operation such as conversing with an NPC or looking at their inventory. If you appreciate the music in Nox Archaist, thank Eric Rangell, Tom Porter, Burger Becky, Electric Moo, and Ian Baronofsky. I would also be remiss if I didn’t mention Qkumba, who was a great help in working through the intense issues of debugging the interrupt-driven Mockingboard code. In the end, I really like the final result, with the Mockingboard music clips playing as the scene changes. Chess I learned to play chess when I was around five years old, about the same time my family bought an Apple II computer. Both hobbies have stuck with me over the years. I currently have a 2000+ rating on chess.com and found My username on chess.com is some unexpected parallels between ace_rothstein, hit me up for a chess and Apple II game development game if you’d like to play! in assembly language. During the project I would occasionally comment that 78
The Second 90% developing Nox Archaist felt like I was playing a game of chess against the Apple II. The reason actually has to do with the difference between the way people play chess and computers play chess. Good chess players will think multiple moves ahead. Grandmaster chess players will think dozens of moves ahead. But no human can calculate every possible move variation forward from the current position. The combinations are exponential. It is estimated that 10120 different games of chess are possible. Since humans have unavoidable limits in the number of chess moves ahead they can calculate, they focus on a lot of principles. One of those principles is to keep your position flexible so you can adapt to unexpected developments. If you don’t keep your position flexible, then your opponent will win if he or she can calculate more moves ahead than you can. Modern computers can use brute force to calculate nearly every possible chess move forward from the current position but they couldn’t always do that. It took until 1996 before the first computer (IBM’s Deep Blue) defeated a human grandmaster because focusing on the principles allowed humans to outmaneuver the raw calculation power of the computer until it reached a critical level. Keeping your position flexible in 6502 assembly language relates to managing memory. When designing a computer game and considering whether to add a particular feature, it’s not just a question of whether there is enough memory left at that moment. If the feature is nice-to-have but not mission critical, you also have to consider whether you’ll still have enough memory for that feature after all the critical features have been implemented. Sounds easy, right? Just estimate the memory required for all the critical features and see what’s left. If only it were that simple. Such estimates are very rough and the earlier in development you are, the more risk there is that the estimates will 79
II. Building the Game Engine be off so much that you run out of memory before all critical features are added. That would be check-mate. Running out of memory and having to rewrite massive parts of assembly code is the stuff of nightmares. So, is there really enough memory for that nice-tohave feature? It’s almost an unanswerable question. The way I dealt with this was to keep my position flexible. I wouldn’t write 100% of any module at any given time. I did some work on the graphics engine, then on NPC schedules, then on NPC conversation, then on the combat system, and so on, but I would also circle back to add more features to each one as the risk of inaccurate estimates decreased because more of the critical features were implemented. Of course, I also had to consider the efficiency of writing the code for additional features while code of a given module was fresh in my head. Balancing out these conflicting considerations and making a decision was very tricky. It was difficult even in the final stages of development because I needed to leave a slush fund of memory to deal with bug fixes. The final version of Nox Archaist only has a few bytes of unused memory. It was also difficult to make resource allocation decisions because of the interrelationship between memory, disk access, speed, and code readability. Increasing the efficiency of one of those elements often decreased the efficiency in one or more of the others. For example, reading data as-needed from disk rather than storing it in memory improves memory usage but decreases speed because reading from disk is slower than from memory. Laying out the logic of a subroutine step by step makes for very readable code, but in assembly language many shortcuts can be taken to make the code faster and decrease the memory usage. Taking those shortcuts, however, makes the code less readable as more mental gymnastics are necessary to follow what’s going on. 80
The Second 90% I’ve talked a lot in this chapter about developing various game engine features and systems in order to share some of the activities involved in making a game like Nox Archaist. There are many more features and systems which I did not comment on. During the project, it felt like it would never end. Just when I thought I could see the end I would remember a couple more features which I thought the game needed to function and play in the way I envisioned. There were times when the amount of work needed to finish the game felt absolutely overwhelming. I did my best not to dwell on it and channeled a philosophy from my mountain hiking hobby. The way to climb a mountain is to put one foot in front of the other. To climb a mountain and to develop a game, big-picture planning is very important, but also important is focusing on the immediate next thing you need to do and not letting the rest weigh on you. As it turns out, the size of the Nox Archaist “mountain” is over 450 000 lines of code, comments, and data in the final build. This includes over 880 000 bytes of machine code and data, as well as almost 5000 lines of dialogue.
Fig. 35. Hiking in the mountains. I started young.
81
II. Building the Game Engine
82
KansasFest to Kickstarter
KansasFest to Kickstarter
I
first became aware of KansasFest from Ken Gagne, the publisher of Juiced.GS magazine and a former KansasFest Committee member. He shared with me that KansasFest was a group of Apple II enthusiasts from around the world who got together each year in a college dorm at Rockhurst University in Kansas City, Missouri. The event has been held since the 1980s and while it hit a low point of attendance around 2010, since then it has been on the rise with over 100 attendees for the past few years. In 2020 and 2021, the event was held virtually due to the COVID-19 pandemic. Ken encouraged me to come to KansasFest 2017 to give a session on Nox Archaist and provide a demo of the game engine. He also forwarded me a link to a Kickstarter campaign for a Commodore 64 game. That Kickstarter campaign had raised over $ 100 000 to produce digital and boxed-set editions of their game, complete with all the feelies. Up to this point Mike and I had talked about how cool it would be to have a boxed-set edition of Nox Archaist but it never really felt like a practical thing to do. Even though the other Kickstarter was targeted towards the Commodore 64, which has a much larger market compared to the Apple II, we were very encouraged by their results. This marked the turning point when a Nox Archaist boxed-set edition went from wishful thinking to something we committed ourselves to doing. We quickly laid plans to give a session about Nox Archaist at KansasFest and launch a Kickstarter campaign during the session to raise funds to produce a Collector’s Edition. 83
II. Building the Game Engine The Nox Archaist session was a great hit. I brought my physical Apple II and showed the in-person and live-stream audience the Nox Archaist game engine, which was in a state where the player could walk around, enter towns and castles, engage in combat and many other basic activities. After the demo, I shared prototypes of the game manual, box, and map (Fig. 37). The reason I’m laughing so hard is because the whole flamethrower bit refers back to the merchandising scene in the classic 1980s movie Spaceballs, where Yogurt hawked a series of products culminating with “Spaceballs the Flamethrower.” I never imagined that I’d have the opportunity to give a nod to one of my favorite movies of all time. I did not think of it right away but fortunately my nephew Isaac, also a Spaceballs fan, did and “Nox Archaist the Flamethrower” was created. As it turned out, we did not press the launch button for the Kickstarter during KansasFest, as we needed more time to polish up the campaign page and video. Instead, we announced the campaign would launch a month later in September 2017.
Fig. 36. The vacuum cleaner was there for cleanup. Andrew and Ivan Hogan had just demonstrated an Apple II controlling a popcorn machine. Only at KansasFest!
84
KansasFest to Kickstarter
Fig. 37. Nox Archaist the Flamethrower!
85
II. Building the Game Engine The First Kickstarter The first Kickstarter for Nox Archaist was also my first crowdfunding campaign of any kind. It was a learning experience for sure. As a financial and business management professional I have a conservative mindset when it comes to risk. I had read many horror stories where the creators promised too much in rewards and as a result they didn’t raise enough funds to produce their product. This was the last thing I wanted to have happen to us. Fortunately, with my finance skill set I was well equipped to calculate costs, make projections, and ensure that we didn’t end up losing money. In this I succeeded even though the campaign itself did not reach its funding goal. However I don’t consider the Kickstarter to have “failed.” There were several factors that I think prevented us from reaching the funding goal. One of the most significant was that there just wasn’t enough awareness of Nox Archaist within the retro community. We had solid awareness in the Apple II community but not the retro gaming community at large. The buzz, flap, scuttlebutt, and hullabaloo created by our first Kickstarter campaign helped grow the awareness of Nox Archaist in this larger community. We had 150 Twitter followers as of the launch of the 2017 Kickstarter and 750 by the time it was over. By the 2019 Kickstarter there were over 1200 followers of Nox Archaist. During the Kickstarter campaign I received a message from Chris Freeman, the co-host of The Lost Sectors YouTube Channel. At that time The Lost Sectors only had 50 subscribers. Chris pitched me on coming on their show to talk about Nox Archaist, warned me that they only had a few subscribers, and seemed to expect me to say no. I said yes, as I loved talking about the project. Over the course of the next few years, The Lost Sectors would grow to over 1200 subscribers. During this time they would do an episode on the Nox Archaist alpha demo, another interview 86
KansasFest to Kickstarter with me, and finally, their Nox Archaist live stream, which is up to dozens of episodes and still going. Their channel is truly a hidden gem. Chris and Matt Herrick, his co-host, have a free-wheeling style, talking about both retro games they’ve played and 80s pop-culture, which makes for a very entertaining experience. The 2017 Kickstarter also attracted the attention of other retro gaming enthusiasts who had wanted to create an RPG like Nox Archaist, had some relevant skills, but did not have the time to take on such a project. They saw Nox Archaist as an opportunity to help make the game better and get the satisfaction of being one of the few people on the development team of a commercial 8-bit RPG. I met Chris Torrence at KansasFest 2017. By the end of the 2017 Kickstarter campaign, he joined the 6502 Workshop team and would later take the lead in creating the 2019 Kickstarter campaign, running the assembly line to create and ship boxedsets, and edit the official Nox Archaist Book of Hints and this book. Chris has been a tremendous help to the project. I also met Jarrod Kailef during the 2017 Kickstarter campaign. As a veteran CRPG player and Apple II fan, he has a sharp sense of game design. He is also very active in the retro gaming community and excels at communications. He joined the 6502 Workshop team shortly after the 2017 Kickstarter campaign and went on to assist with high-impact design elements related to animation, screen layout, sound, and speed. He was also central to the messaging in the 2019 Kickstarter campaign and played a key role in the networking for the Apple II Reunion Party within the game. Michael Pohoreski also joined the 6502 Workshop Team after the first Kickstarter. I had been reading his posts on comp. sys.apple2 for years and could tell that he, like Qkumba, was also a grandmaster 6502 assembly programmer with a somewhat different focus. Qkumba specializes in hardware interface 87
II. Building the Game Engine programming, operating systems, and code optimization whereas Michael specializes in graphics programming. Michael is also one of the developers of AppleWin, a popular Apple II emulator, which I was using extensively to debug and test Nox Archaist. So, when I got a message from Michael asking if we needed any help I was thrilled. Michael took the lead on creating the Nox Archaist splash screen, collaborating with Bill Giggie on the artwork. Michael also created a font-editing tool that Bill could use to design the fonts, added the numbers to the inventory menu, and did a late-stage memory optimization of the font blitter. This memory optimization allowed us to fit in some last-minute features, including the one where the town guards neutralize any mobs chasing you. In hindsight, I look back at the 2017 Kickstarter as a combination test run and marketing event. It was also a lot of fun. The original campaign video, assembled by Robert Padovan, was done very informally, shot in Mike’s backyard, and featured a real flamethrower which I used to escalate the “Nox Archaist the Flamethrower” joke started at KansasFest 2017. The “flamethrower” video was eventually swapped out for a more formal Kickstarter version created by Chris. Since we were having trouble reaching the funding goal, we thought maybe a more traditional video might help. The flamethrower version can still be found on our 6502 Workshop YouTube channel— look for “Nox Archaist Kickstarter promo (Meet the Creator).”
88
Creating the Alpha Demo
Creating the Alpha Demo
B
y the fall of 2018 the core game engine features were complete. As each feature was added, I tested that feature individually and resolved any bugs I had found. I decided it was now time to create a small amount of game content in order to make a fully playable demo area. This would enable us to test all of the game engine features together and, of course, find more bugs. I named this build the “Pre-Alpha Demo.” I used the term pre-alpha because there were still a few features I was holding back on until the content creation process was fully tested and I had a better idea on memory usage. I decided to make the demo area be the same as the player’s starting area in the world (see Fig. 38). This would give us a solid baseline to evaluate the balance of the character stats and economy. The demo had a town, castle, cave, mountains, and a coastline. This was enough variety to test most of the game mechanics and how they worked together. Then, once I was ready to create the rest of the content, I would just expand the map from the demo area, leaving it largely unchanged. This approach worked out very well. During final content creation we added the shipwreck and tutorial where the player starts. And, I also smoothed out the difficulty at the start of the game. When the pre-alpha demo was booted up, there was no main menu or character creation screen. I wanted to make sure that the character stats system worked before writing the character creation code, just in case some of the stats changed. 89
II. Building the Game Engine
Fig. 38. The pre-alpha demo map was the highlighted area.
Fig. 39. The demo area was blocked off with a cow barrier. For the Matt Chat livestream I changed it to a rat barrier.
90
Creating the Alpha Demo Game Balance The content was a lot harder in the pre-alpha demo, and we spent a lot of time tuning the balance at the start of the game. In the demo, the player started with a hunting knife and set of cloth armor, but, unlike the public release, the player didn’t have the opportunity to find a shortsword and didn’t start out with enough gold to buy one. Instead, the player had to grind and earn gold to buy any equipment upgrades. This was particularly difficult because there were no rabble rousers back then, and hooligans and rabid dogs were a lot tougher. I was committed to preserving a sense of old-school difficulty in Nox Archaist. My target was a game with a rich storyline like Ultima, with an emphasis on character development and combat like Wizardry and Bard’s Tale, but stopping short of some of the chaos of spinners, darkness, and teleporter rooms like later games had included (although I did sneak in two teleporters for old times sake). Fig. 40. A comment from a beta tester. Comments like this made me confident the game was plenty difficult.
My reasoning for the high degree of difficulty in the demo was based on my experiences with the first Bard’s Tale. It was a brutal start, requiring numerous reboots until you got a character to level two. Then, once you got a character to second level, you rebooted any time that character got killed until a second character reached level two. You then rinsed and repeated until your party was powerful enough to hold your own with the starter mobs. I found it very satisfying to learn how to deal with that challenge even if it did involve some meta gaming. 91
II. Building the Game Engine For Nox Archaist, making the start of the game somewhat easier was a big decision for me. One of the most common pieces of game development advice I heard was “make the game you want to play.” I wanted to make a hard game and I didn’t care if that meant less people would want to play it. Nox Archaist would be a game for people like me, who wanted to play a hard game. Eventually, during beta testing, I adjusted the starting difficulty because it became clear that the game as a whole was very challenging. Making the start of the game somewhat easier wouldn’t really reduce that. And, by adjusting the game start difficulty, it gave players a fighting chance to learn the game mechanics before being tossed into the deep end of the lava pool. When I started receiving responses like the one in Fig. 41, I became confident that the level of difficulty was fun, and there would be no harm in reducing the starting difficulty to make the game a little more approachable.. The beta-testing group helped with many things, but helping me dial in the difficulty was one of the more important. Fig. 41. After a tester said they just had to play one more turn.
The Lost Sectors The pre-alpha was not a public demo. It was tested by my teammates and by Matt Herrick and Chris Freeman of The Lost Sectors. Matt and Chris are the most knowledgeable CRPG players I’ve ever seen. They’ve played hundreds if not thousands of different games. I knew that if they played the demo and liked it, we were headed in the right direction. As it turns out, they loved the demo. And, to help promote our second Kickstarter campaign, 92
Creating the Alpha Demo they did an episode covering the demo in April 2019 and a live stream a month later. There are a number of things in Nox Archaist which were inspired by comments on The Lost Sectors either by the hosts or viewers. For example, on the 2019 live stream my teammate Jarrod Kailef commented in the chat that there should be a mob called Dysentery just so you can be killed by it. This is a reference to the meme that arose from the Apple II game Oregon Trail where dying of dysentery was a common fate of the player. I thought it was a great idea and made a note to make it happen if possible. Over the following year, I eventually was able to work in a mob called Dysentery and Bill Giggie drew art for it in the shape of a covered wagon with pestilence wafting from it. I knew many players would appreciate the joke, but I couldn’t have imagined it would be appreciated as fully as it was by Lady Ailuros on her Twitch live stream of Nox Archaist. After a look of complete surprise, she remarked that “this is the funniest thing in the history of ever.” You can see her entire reaction during the outtakes of the Nox Archaist session at KansasFest 2021. Another piece of game content inspired by The Lost Sectors is NPC $68, the ranger in Castle Foolery who will join your party. When I set up the NPC dialogue subroutines I also created a template data file which contained records for 32 NPCs, the maximum any single location could have. Each NPC has a hexadecimal record number and, to aid in troubleshooting, I set up each NPCs “hello” text block to contain the word “NPC” and their record number. Only a few of the NPCs had dialogue set up in the pre-alpha demo. The rest still had the template dialogue text. As a result, when Chris Freeman and Matt Herrik talked to one of the archers in Suurtheld Castle the archer’s greeting to them was “I am NPC $68.” Chris and Matt thought that was hilarious and I thought it would be fun to keep NPC $68 in the game. In the 93
II. Building the Game Engine public release of Nox Archaist, NPC $68 explains to the player that the developers forgot to configure her and she’s just doing the best she can. I was going to set up a quest for the player to escort NPC $68 to Lord British to receive a full configuration but there wasn’t enough memory to do this. Perhaps my favorite piece of inspired content is the Wand of Suggestion, found in the ruins of Grymvi’s Keep. In April 2019, The Lost Sectors were discussing the game Spellbound. Chris Freeman was frustrated by the ineffectiveness of an item called the Wand of Control. Given its ineffectiveness, Chris remarked that it’s more like a Wand of Suggestion. I thought that was hilarious and I imagined a wand in Nox Archaist that would fire a random projectile shape, including an occasional cow. For the most part it was straightforward to code, mainly just using a random number to calculate the index to the range weapon shape tables. However there was a little bit of custom code to do this so I didn’t add the feature until late in the development process.
94
Creating the Alpha Demo
III. Creating Content
95
III. Creating Content
96
Designing Game Content
Designing Game Content
T
he pre-alpha demo had some game content but virtually no story. Before creating more content I decided it was important to flesh out the story as that would help me determine what content was needed. For example, how many towns would be needed to support the storyline? How many NPCs would there be in each town? What special items would exist and where would they be located? By looking at the size of the world and the available system resources, I had a vague idea of the answers to these questions. However, I needed a solid story outline to really nail down these metrics. Over the years, I had written down many pages of notes containing random ideas for the game story. Before attempting to turn these into a story outline, I asked Beth Daggert for advice. She SPOILER ALERT suggested reading a book called In Nox Archaist, the end of Story: Style, Structure, Substance, Act II comes with the defeat of the High Cultist. Rather and the Principles of Screenwriting than the expected victory, the by Robert McKee. It’s actually a player instead causes the Dark book about screenplays but she said Shadow to enter into the world instead of preventing this. storytelling principles in films and in From what I can ascertain from games share some similarities. player comments, this gambit One of the main things I learned seems to have worked: most from the book was the power of an people think the objective of the game is to defeat the cult Act II climax that is so moving that and are surprised to discover the reader thinks the story is over the truth. (see sidebar). 97
III. Creating Content Another key thing I learned was the importance of developing the lore of the world. Much of the material won’t be used in the story, so it takes discipline to perform this important task. It is through this lore that different threads of the story stay anchored. The process of transforming my story notes into a story arc was hard. Using what I learned from the book, I discarded ideas which didn’t fit with the world lore or didn’t advance the story. Once the story arc was developed into an outline format, I then defined the gameplay quest objectives. When working on the story arc I always kept in mind what would work well as a quest objective so when it came time to define the objectives I’d have some solid material to source them from. Beth was a great help in the process, as a general sounding board and helping to brainstorm ideas to plug holes and polish up rough sections. Making Maps Once I had developed a story outline and tentatively defined some quest objectives, I proceeded to draw the final Overworld map on a sheet of paper and some rough sketches of the Underworld maps (see Fig. 42 and Fig. 43). I thought this was the right time because knowing the quest objectives gave me some idea of how many town, castle, and dungeon locations would be needed. When I created the alpha demo, I also created the process for making maps and NPC dialogue. A lot of the content creation phase was repeating that process over and over with the unique details for each location. During this process, I developed some systems for organizing content to make it easier for the player to remember things. For example, I developed a scheme for the placement of weapons, armor, and spells with the various merchants of the realms. Each level group was assigned a location, such as level one weapons 98
Designing Game Content
Fig. 42. Overworld map sketch.
Fig. 43. Depths of Vacous, sketch of level 1.
99
III. Creating Content and armor in Everton, level two in Suurtheld Castle, or level three in Knaerwood. Items above level six were split between Knomewaer and the Magus Tirrus towers to make it more challenging and tie into the story. I also created charts which tracked the location of each quest clue. This was useful for ensuring that no location had dramatically more or less clues than the others. I learned about this method from Richard Garriott, who tracked quests in the Ultima games using a series of physical notebooks. For Nox Archaist, I used Microsoft OneNote.
Fig. 44. Rough list of mob level distribution.
100
Designing Game Content The alpha demo included some level one and two weapons, armor and spells. This was helpful to make sure that the various armor pieces, shields, and two-handed weapons were balanced. During the primary content creation phase, I scaled up this basic structure to hundreds of unique items. Castle Foolery On second thought, perhaps I shouldn’t have created Castle Foolery—’tis a silly place.
Actually, I’m quite glad that I created Castle Foolery because in addition to it being fun for me personally, it solved a vexing design problem. Early on in the project I knew that I wanted to incorporate humor into the game to a greater extent than the Ultima games. Bard’s Tale, with its shop names like “Roscoe’s Energy Emporium” and spell names like “Summon Herb” gave me confidence that a retro RPG could include humor and still have a plot which could be taken seriously. Coming up with the humorous material was not a problem. Mike Reimer and I have a nonsensical sense of humor. The challenge was not coming up with material, it was how to prevent the material from overrunning the entire game. This is where Castle Foolery came into play. At first I thought that a castle ruled by jesters would just be another funny thing in the game. However, as I thought more about it, Castle Foolery seemed like a perfect place to house much of the nonsense that was spinning around in our heads. By concentrating the nonsense within Castle Foolery, it made it easier to sprinkle humor throughout the rest of the game, 101
III. Creating Content without overdoing it. And, overdoing it would have been easy to do if the alternative was exclusion from the game. This also helped when deciding where to place items named by Kickstarter backers as part of their pledge rewards. The goal was to weave them into the game world as seamlessly as possible. For example, it’s no coincidence that the Q*bert Zirconia gem is found in Castle Foolery while the Sword of St. Giles is found in the Depths of Vacous. Both are great names and we found homes for each that suited their nature. I was not sure whether the humor balance was right until after beta testing and then public release. We’ve received many complimentary remarks about the humor in the game, so it seems this all worked out fairly well. Weapons and Stats Balance Humor was not the only balancing act that I was doing. Character stats, combat formulas, and the economy all needed to be balanced or Nox Archaist would be nothing more than a pretty 8-bit walking simulation. This was particularly challenging because I didn’t really know what I was doing. My extensive experience playing 8-bit RPGs and the assortment of programming knowledge I had acquired did not really prepare me for this challenge. As a kid in the 1980s I had done some tabletop role playing, such as Dungeons & Dragons, but not a lot and I never really poured over the stats tables to the point of truly understanding what made them tick. I had two things going for me at this point: first, as a finance professional I am a spreadsheet whiz, and second, I’m not afraid to ask for help and I’m pretty good at finding people who know whatever it is I need to learn. I started by creating a spreadsheet called the STA, which stands for State-of-The-Art Chart. My high school algebra teacher, who had an odd sense of humor, used to refer to pretty much any chart used in class as a State-of-The-Art Chart. Mike 102
Designing Game Content and I proceeded to mock up some numbers for player and mob hit points at each level, and a target weapon damage and armor defense value for each level (see Fig. 45). Before going too far, I reached out to Beth to ask her advice on this challenge and whether she thought the STA was headed in the right direction. In my discussions with Beth, she explained that for Apple II game development, stats and balancing had typically been a seat-of-the-pants operation. However, since I was looking to push the frontier on complexity, I wanted Nox Archaist to have a huge number of weapons, armor pieces, shields, and special items. I also wanted characters to be able to wield two weapons and was hoping for a variety of modifiers to affect final damage such as critical hit, resist magic, and strength and dexterity buffs. To top it off, I wanted to do all of this in a classless system. Beth said no problem! As a games developer in the 1990s and 2000s, she had many principles to share which were relevant to constructing a complex system like this. It was my job to figure out what I could squeeze into the Apple II and create a draft in the STA based on those principles.
Fig. 45. A tiny portion of the main State-of-The-Art-Chart.
103
III. Creating Content The STA became extremely detailed. For example, the total weapon damage was based on the base damage, the skill modifier, and, for melee weapons, a strength modifier. I then had to create formulas that would scale up the base damage throughout the weapons progression. Every detail that I could think of was rolled into the calculations. As examples: range weapons have a lower base damage
Fig. 46. The Weapon Damage Table in the STA.
Fig. 47. The Master Spell Table in the STA.
104
Designing Game Content than melee weapons, damage modifiers can include strength and critical hits, and separate tables are needed to calculate single target and area-of-effect spell damage while still remaining balanced with weapon damages. The STA even had a detailed combat “simulator” which used the in-game combat equations to run through various scenarios, and allowed me to see the effects of various parameter changes on game balance. Economic Balance For the economy, I wanted gold acquisition and item drops to be balanced. The player needed enough gold to buy some equipment upgrades and also needed to find meaningful items during combat and exploration. As a player I find it very satisfying to save up for an equipment upgrade and finally be able to afford it. At the same time, I also find it exciting to randomly get an item drop of a useful weapon or even occasionally something awesome like the Crossbow of Puzwang. In my experience, equipment upgrades in RPGs are primarily acquired through either spending gold or finding items, but not both. I thought balancing the two would be a huge boon for players who like to get really immersed in character development. To balance the economy I had to project how much gold the player would earn from combat and loot drops and how much they would spend on services like food, healing, resting at inns, and training. I also had to project how much gold the player would earn from selling unwanted equipment and items. After rolling all of this into the STA, I tinkered with input variables, like the average gold drop and item price at each level, until the balance felt right. The basic form of the equipment and economic balance that was included in the alpha demo seemed to work. Once we were in the primary content creation phase, I decided to go big. I created all of the items, maps, NPCs, merchants, mobs, and special treasure drops for the rest of the game without doing 105
III. Creating Content more than spot testing to make sure the screens looked correct and no crashes occurred. In doing this I was making a big bet that the systems I designed and tested in the demo were scalable. Chris Torrence and Bill Giggie did some excellent work in support of this effort. Chris created the dialogue text for some NPCs and did the text layout for the Scrolls of Nobility and the in-game credits. Bill created the map for Nourtheld Castle. Using his unique insight as the tile artist, he was able to come up with tile layouts that I had never considered. As a consequence, Nourtheld is my favorite map in the game. One reason that I decided to create the rest of the game content before any further major testing, was because of the nature of an open-world game. I thought it would be difficult to truly assess the overall balance without all options being available to the player which they would have in the final game. Fortunately, it seems to have worked out. Content creation was completed in early June 2020. The next step was for me to play the game from start to finish and see how the balance felt and what bugs I could flush out. There were some bugs to fix and some balance tweaks to be made, but what I found was that the dart I threw had landed on the inner half of the board and not on the edge or missing the board entirely, which was a very real concern that I had. Too Many NPCs While everything eventually worked out, there were some tense moments during content creation. The processes that I had designed during creation of the alpha demo scaled well but with an 8-bit game on original hardware, nothing is truly a rinse-and-repeat process. One issue that required ongoing monitoring and management was floppy disk space. When creating the demo I sketched out how the eight disk sides of the game would be used: Boot, Main, Overworld, Underworld, Castle, Keep, Town, and Ruins. 106
Designing Game Content This gave me a general guide for deciding where to put data as I created the content. Eight disk sides meant that the game would have four doublesided floppy disks. By the end of 2019, we were committed to that number of disks and no more, due to floppy disk costs and by the size of the game boxes, both of which had already been ordered. Increasing the number of floppy disks required to play the game would have been a major problem. As I added content however, the risk was that one or more of the disks would fill up before all content for that portion of the game was created. Shuffling content to a less space-con- While working on the game manual, strained disk wasn’t a straightfor- Chris Torrence and Beth Daggert created some NPC names for flavor ward solution and could create text. Where possible, I tried to other problems. incorporate these into the game to Each map was assigned a tie the two together. One of these was a name Chris created: Nox map type code, such as $07 for Tremmel. Chris had intended this Castles and $06 for Towns. The as a nice homage to me, as Tremmel game engine used this map type is Lemmert spelled backwards. code to look for the map files on Without giving it much thought, the disk that was currently in the I used this name for a mage in floppy drive. If the files weren’t Ezel’dyv. Months later, Andrew found, the type code was used Schultz wrote a trivia section about this NPC in the Nox Archaist Book of to display a prompt to insert a Hints, and mentioned that Tremmel different disk. For example, if is Lemmert spelled backwards. I was the map type code was $ 07, so focused on game development the prompt “Insert Castle disk” that when creating the NPC I hadn’t even noticed. would be displayed. If I moved some Castle maps Once I realized it, I thought it was onto the Keep disk because the very funny. The only wrinkle was, Castle disk was full, the player when writing the dialogue for Nox Tremmel, I made him something would receive the “Insert Castle of an asshole! Actually, I think that disk” prompt and have no way of makes it even funnier. knowing they should insert the 107
III. Creating Content Keep disk instead. One solution may have been to add logic to parse the map code assigned to each individual map and force the correct disk prompt. However, that would have required more memory than we had available. For this reason, I periodically did detailed projections of disk space requirements knowing that a disk overflow could be catastrophic. Each time I would start by updating the free space remaining on each disk and then update the estimated space for all unfinished maps for that disk. It was an efficient method but it assumed that everything I was expecting to already be on a disk was actually on there, otherwise it wouldn’t be reflected in the free space. In March 2020, long after the number of disks was locked in, I noticed that the Town floppy disk was missing one of the NPC dialogue text (TLK) files. This meant that the supposedly free space number in my Town disk space projections was too high. The absence of this file would result in a crash if the player talked to NPCs in that town. However, the floppy build got minimal testing during the development process once it looked like the floppy controller itself was working properly. This was because it was much faster to test content via the hard drive build, which avoided all of the disk swapping. This was a tense moment as I knew the potential implications quite well, which was why I had been doing the periodic disk space projections. As calmly as I could, I examined the files on the Town disk, looking for a way to free up space. Soon enough, I noticed that a couple of the TLK files seemed too large for the small number of NPCs in those locations. After reviewing the file contents, I found that I had forgotten to remove the records for unused NPCs. I trimmed off the unused data, ran the build again, and waited. I was thrilled when the build completed without errors and I verified that all of the correct files were on the Town disk, with a few blocks to spare. 108
Late-Stage Engine Changes
Late-Stage Engine Changes
A
lthough by this stage I was focused on creating content, I would occasionally make tweaks to the game engine, either to adapt to the storyline or when there was a compelling and viable idea from the team. One example of adapting to the storyline is the music in Castle Foolery. Normally, music plays just once upon entering a map. In Castle Foolery, the music randomly plays as the player walks around. This required injecting code into the main game loop to detect if the player was in Castle Foolery, check if music was already playing, if not generate a random number to determine whether to start playing music, and if yes then call the start music routine. Fortunately, I didn’t overcommit Spoiler Alert on core game engine features. This enabled me to have a slush fund of As another example of adapting the engine to the memory available to make high-impact storyline, after the battle customizations like these. While these with the High Cultist, the kinds of tweaks were in my view part characters are automatically of the project content phase, I was in teleported back to Nourtheld Castle. This required hard general very reluctant to add core game coding conditional logic into engine features, modify screen layouts, the combat exit routine to or do further optimizations. From my trigger the teleport subrouperspective, those kinds of activities tine. The teleport subroutine were part of earlier phases of the proj- is actually the same code used for portals and the Sally ect and at some point we had to move Forth spell. on or the project would never get done. 109
III. Creating Content Nevertheless, when working with teams and engaging with a community, feedback doesn’t roll in on an orderly schedule. People, understandably, suggest ideas and share observations as they think of them. It is very important as a project manager to stay positive and encourage feedback while at the same time explaining the threshold for changes at each stage of the project. Failing to encourage feedback can create a chilling effect resulting in no feedback and missing out on something important. This was the approach I aspired to and while I wasn’t always successful, I think I was successful most of the time. Once we were in the content creation phase, I explained to my team that, at this point, for a feature change to make it into the game, it had to not just be a good idea, it also had to align with the storyline and other game mechanics, be viable with available memory and disk space, and be achievable in a short amount of time. That was the sweet spot. I used an analogy to illustrate this. I said that coming up with an idea that meets all those criteria is like lobbing a pea across the room and landing in an upside down funnel. Once everyone was on the same page, I sometimes responded to suggestions with “funnel” or simply sending the picture below. Several team members hit the jackpot and lobbed one into the funnel late in development. For example, Bill Giggie suggested the mechanic for digging in ruins and suggested using the existing open door subroutine to do most of the work. Yes, that’s right—from the game engine’s point of view, when you dig in ruins with your pickaxe, you are opening a door that happens to look like a pile of rubble. Adding features late in development is risky business for the reasons mentioned before. And, even if a feature seems like it meets the criteria, there is still a risk of something unforeseeable. For example, it’s kind of weird and confusing that you can dig 110
Late-Stage Engine Changes in ruins but not in the caverns of the Underworld. If the feature had been added earlier, we could have prioritized resources differently and made digging work in the Underworld as well. It was the late-stage timing that caused this wrinkle because by that time our position wasn’t flexible enough to adapt (see Chess p. 78). I still think adding this feature was the right decision because ruins really needed another puzzle mechanic. However, I share this story to illustrate how difficult these kinds of decisions are and how much uncertainty exists. In hindsight, I’m surprised and delighted that we got it right as often as we did. Jarrod’s Ideas Once we were in the content-creation phase, I was always very reluctant to add core game engine features, modify screen layouts, or do further optimizations. However, during this stage, Jarrod Kailef had a way of focusing my attention on high-impact changes. Having worked on several gaming projects like Richard Garriott’s Shroud of the Avatar and Sundog: Resurrection, he has a keen sense for what players expect and how that would translate to a modern CRPG. Jarrod only made a few suggestions and that was quite intentional on his part, as they were ones that he thought were really important. Sometimes his suggestions were simple, such as cutting the sound effect for bumping into obstacles in half, making it much less annoying. Other times his suggestions were more complicated such as changing the animation scheme. Originally the Nox Archaist engine would draw the next animation frame for every object on the screen on every animation cycle. This caused all animated objects to animate at the same time and be in sync with each other. When a lot of mobs or NPCs were on the screen, some people said it looked like a Michael Jackson video. 111
III. Creating Content Jarrod focused my attention on the issue, pointing out that the original implementation fell below the benchmark we were shooting for, and sketched out the logic of an alternative, where not all objects were animated on each cycle and those that did were not in sync. He shared that he had worked out the logic as a teenager when he hoped to one day develop a game like Ultima. I thought that was pretty cool, noting the similarity to my own roots. I reworked the animation code based on his sketch. Jarrod also made the case for an optimization which significantly increased the speed of player movement. Finally, he proposed that we add the vertical blue lines around the gold, food, and time area on the right-hand side of the screen. Originally, we had a minimalist design with no lines, but Jarrod made the case that adding in the vertical lines would make the game look more professional. Since the screen layout was essentially complete, it was really hard to add the lines. Looking back, after seeing the final product, I understand now the importance of each change that Jarrod pushed for. The Quest Log Another feature added late in the development process was the quest log. I waited until around March 2020 to add this feature because I was so uncertain whether we’d have the memory and floppy disk space to make it happen. For context, this was only a few months before the game was feature and content complete, just before the start of final testing. Fortunately, with a quest log in mind, I had designed the game engine and organized the content to support the structure of individual quests. This made a quest log architecturally possible as long as we had enough system resources. This was a bet that very much seems to have paid off. The quest log is one of the features I’ve heard people mention the most when talking about Nox Archaist being more approachable than games typically were in the 1980s. 112
Late-Stage Engine Changes
Fig. 48. The Nox Archaist Quest Log.
In addition to the quest log itself, a secondary stretch goal was integrating the quest log data with the NPC dialogue for Lord British. In Nox Archaist, when talking to Lord British the player can ask him for ADVICE. Lord British will respond with a suggestion of what the player should do next in their quest. This was accomplished by writing some extra code in the NPC Talk module. The code first determines the oldest quest on the mainline that the player has acquired but not completed. Then, the quest ID is used as an index to a lookup table which contains the memory addresses for all of the hints. Using this architecture, when asked, Lord British can then bestow an appropriate piece of advice for every milestone on the mainline quest. I was very happy to be able to add this feature. It gave Lord British an active role in helping the player without repeating tropes about resurrection and healing. And, it helped me to dial in the difficulty of the game. Some of the quests, especially late in the mainline, are very difficult. By embedding a hint with Lord 113
III. Creating Content British I was able to achieve the degree of difficulty I wanted for old school die-hards while also providing a sanctioned in-game mechanism for players to decrease the puzzle difficulty if they chose to do so.
114
Kickstarter Redux
Kickstarter Redux
T
he second Kickstarter for Nox Archaist, in May 2019, was an amazing success. Within the first two hours we had reached over 400% of our funding goal. On the first day, we sold out of the higher-end tiers such as the Limited Edition, Game Designer, and Lord of the Realm. I recall being on the phone with Chris Torrence around 2AM brainstorming ideas to create additional high-end rewards. I think the success of the second Kickstarter was due to increased awareness of Nox Archaist, a lower funding goal, and a more polished presentation. Chris had joined the team shortly after we ended the first Kickstarter campaign and he quickly went to work researching alternative vendors, streamlining reward tiers, and creating an amazing Kickstarter video. Chris tapped Jarrod Kailef for the video’s voiceover and Electric Moo for the music. Chris’s masterful video editing skills, Jarrod’s commanding voice reminiscent of James Earl Jones, and Electric Moo’s epic music combined to introduce 8-bit RPG fans to Nox Archaist in a spectacular fashion. Jarrod’s community outreach with groups like the Ultima Dragons and his networking assistance with Richard Garriott and Dr. Cat greatly helped the Nox Archaist rocket take off. When this project started, I did not fathom that four years later I would have the opportunity to chat with Richard Garriott and host Lord British as an NPC in Nox Archaist (see Fig. 50). It was a dream come true and, as I said to several people, the entire project was worth it just for that. 115
III. Creating Content
Fig. 49. Main page of the second Kickstarter, May 2019.
116
Kickstarter Redux
Fig. 50. Lord British in his Shrine.
Success led to success. In addition to Richard Garriott, John Carmack, and Lane Roathe (iD Software), Burger Becky (Bard’s Tale) and Robert Woodhead (Wizardry) also backed the Nox Archaist Kickstarter. More importantly, and much to my delight, 566 fans of 8-bit RPGs backed the Kickstarter and paved the way for us to produce the game as a boxed set with floppy disks, manual cover art by Denis Loubet, a cloth map, and other feelies. Some of those backers pledged for naming rewards which I incorporated into Nox Archaist. The Sword of St. Giles, the Q*bert Zirconia gem, and the Shadow Knife were all named by backers. There are a few backer-named items which players have expressed curiosity about. First, the Chesterfield Sofa. This item is a nod to the Hitchhiker’s Guide to the Galaxy books by Douglas Adams. One of the books talked about a phenomenon known as the “Somebodyelse’s Problem Field” which could be triggered by aliens being carried across a cricket field atop a Chesterfield sofa, because surely something that outrageous must be somebody else’s problem to deal with. The LOOK text 117
III. Creating Content in Nox Archaist for the tile where the sofa is found says “SEP spell research site.” Players have also asked how Tharock’s Heart ended up in a tree stump. Tharock ventured into the Tracts of Yrstweld one spring and was confronted by one of the forest’s centaur guardians. After a great battle the centaur slew Tharock and put his heart into a tree stump as a warning to those who might enter the forest from that direction. From a game design standpoint, I made a point of hiding something in a tree stump as a nod to Ultima V in which a magic axe could be found in a tree stump in Jhelom. This of course is the magic axe that John Miles infamously made a beeline for in the speedrun contest he won against Richard Garriott. Speaking of speedruns, we would be remiss if we didn’t mention the Nox Archaist speedruns done by Rikkles (see Fig. 51). One of Rikkles’ speedrun playthroughs is detailed below: Open your cell door. Start the fight with the rat. Keep pressing the spacebar until your dodge skill is up to 80+. On real hardware you will need to weigh the spacebar down with your phone or a toothpick and go make coffee. Kill the rat. Go to Suurtheld and say ACCE to the lord of the castle (get 500 gold) Buy 40 lockpicks and horse and exit Go to the shrine and get ANKH from British Go to Bayport, say HELP to coadjutant, get 250g. Get Ffred spellbook. Go buy the big ship Go to Ezel’dyv to the mage building, talk to the coadjutant to get 300g and buy Quick Exit and Greater Heal Go E to the great shark area, fight them! Wait until night for more mobs. Use the onboard cannon in the fracas. Reach level 10. Sail West to Nourtheld. Buy an ice staff, cloak, necklace (if you didn’t get any of those from the sharks), and Sally Forth. Equip weapon, armor and spells
118
Kickstarter Redux
Fig. 51. Speedrun by Rikkles: 20 minutes, 45 seconds.
Go down to Vacous towards Uharad. Go up to the basement and grab the 3 orbs. Be careful with the lockpicks. Go back through Vacous 2 and go down to the dragon. Fight drakes. Heal up and get to the chests area. Grab the scales and the Chaos Wand. Equip the Chaos Wand. If you didn’t already find a strong protection ring, set orb 3 next to the top chest.Teleport to orb 3 as much as necessary to grab a protection ring +6. Quick Exit to Nourtheld entrance. Set orb 2 Get on the boat again and go all the way NE to the back door of Praevoc Island. Talk to Max, say PORT and NO, enter portal Lavaheal™ to the Dark Shadow. Set orb 3 at right by the castle. Teleport to orb 2 to heal and back to orb 3. Enter castle. Cast summon ffred x2 and greater heal until the shadow is out of magic. Chaos his ass. You win. That said, there’s even simpler but it needs luck: Do the first steps above until the sharks (but you don’t need lockpicks or ffred). Then if you get a storm staff, prot ring +7/8 and mage cloak and necklace from the sharks, go straight to the dark shadow. You’ll need a few restarts but you can win.
119
III. Creating Content Fulfillment After the fun and excitement of our Kickstarter campaign, we turned our focus to finishing the game and to producing and delivering the physical rewards. One of the biggest unknowns that existed well into the development of Nox Archaist was how we would acquire floppy disk media in a large quantity. During the project it became clear that there had been no production of new 5.25-inch floppy disks since the 1990s. Finding a few floppy disks was not hard but it was challenging to find a large quantity of unused floppy disks without any manufacturer labels and which had plain white sleeves. Most floppy disks produced in the 1980s had manufacturer labels on them. Memorex, Maxell, BASF, Elephant, and other manufacturers all did this for marketing purposes. We were concerned that if we put our Nox Archaist disk labels over the top of a manufacturer label there would be a visible bump. Fortunately, before the Kickstarter launched, we had identified one supplier who sold floppy disks which seemed to meet our criteria, and we did a small test order. Unfortunately, while the disk sleeves were white, they seemed to fit very loosely. It looked like they were actually microfiche sleeves which had been paired with sleeveless floppy disks. Our only option seemed to be to pay a premium to have custom white disk sleeves made. Setting aside the complexities of bulk sourcing obsolete media, an order of this size would likely require a large upfront commitment, and a mistake here could be costly. One day out of the blue I received a message on the vintage-computer.com forums from someone claiming they could provide the thousands of plain-sleeve-no-label floppy disks required to pull off our big box game vision for Nox Archaist. It seemed too good to be true and I was initially skeptical. The seller claimed they had a pallet of new-old-stock floppy media bought as government surplus that they had been saving for a large Apple II project for over 10 years. They thought Nox 120
Kickstarter Redux
Fig. 83. We used Applesauce for copying and a IIc for testing.
Archaist might be a good fit for this treasure trove of vintage media. After chatting with the seller, it turned out he was a friend of a couple of people I knew from KansasFest. The KansasFest folks were able to vouch for him and the product sample we received was perfect for the Nox Archaist game floppies. I was comfortable proceeding with possibly the largest modern day order of 5.25-inch floppy disks and it worked out very well. Out of more than 2400 disks imprinted with Nox Archaist we only had two bad floppies. Meanwhile, Chris Torrence was working hard doing the layout and ordering for the game boxes, cloth maps, and other feelies. He also began writing the Nox Archaist manual, using contributions from Mark and Beth, and coordinating with a variety of artists for the illustrations. Once the game was released, Chris managed the fulfillment of all of the boxed sets. The original plan was to have a boxing party at his house in Colorado. We were going to party like it was 1989. But, COVID shut down those plans and Chris and his 121
III. Creating Content family put forth a Herculean effort to manage the assembly and shipping. Chris continues with his efforts to this day, managing materials acquisition and fulfillment for the second and third production runs of the boxed sets. He also manages our online store which, in addition to the game, has Nox Archaist t-shirts, mugs, posters as well as products like the official Book of Hints. Electric Moo One of the most fun Kickstarter rewards to see take shape was the game’s soundtrack, created by Electric Moo. When Electric Moo is not busy finding ways to sneak cow sounds into Nox Archaist he is a professional musician. When he went to work on the Nox Archaist soundtrack he pulled out all of the stops (see his chapter, Electric Moo p. 195). The soundtrack was originally conceived as an alternative to in-game music, before Mockingboard support was added. It was intended to be fantasy themed but not particularly retro sounding since there would be no way to make it authentic enough without actually doing the real thing. We hoped that people would listen to the soundtrack on their modern devices while playing Nox Archaist. Eventually Mockingboard support was added to Nox Archaist (see p. 75), but the original direction with the soundtrack was working out so well that we stuck with it. Electric Moo did an amazing job capturing the feel of the world of Vali as I imagined it and incorporating various references to in-game content. He also incorporated voice cameos from myself, Bill Giggie, and Jarrod Kailef. My favorite part of the soundtrack is in the song “Into Town”, where a gate guard proclaims “none shall pass, except by order of the Margrave!” That phrase even made it into the manual, as the soundtrack was completed shortly before the manual was written. 122
Return to KansasFest
Return to KansasFest
K
ansasFest was an inspiring environment for creating Nox Archaist content. After attending most of the sessions during the day, after dinner I would typically settle in at the Corcoran Hall commons with my laptop and work on Nox Archaist maps while being immersed in Apple II chatter. At KansasFest 2018, I created the maps for Suurtheld Castle which I planned to be the centerpiece for the Nox Archaist alpha release in the fall. In 2019, I worked on the map for Ezel’dyv and imagined how to incorporate a town of mages into the storyline. A mage tower wasn’t originally planned there due to lack of map space but Chris Freeman (co-host of The Lost Sectors) had made a clever suggestion. The maps within Nox Archaist had a buffer around the edges which blocked line-of-sight and prevented the player from seeing past the edge. Chris suggested filling this unused map space with a bunch of small mage tower levels. Up to this point in Nox Archaist, the maps for different levels had all lined up so that the X/Y coordinates for a stairway were identical between the two levels. However, as long as the walls didn’t have windows, the player would never know that the tower levels were actually located next to each other on the map grid instead of on different vertical levels. This new technique worked out well and was also used by Bill Giggie to great effect when creating the Nourtheld Castle 123
III. Creating Content map. Yes, it’s true: when you’re climbing the stairs in those huge towers you’re really out in a memory no-man’s-land. What does this have to do with KansasFest other than being the place I was creating Ezel’dyv? Using the buffer area was brilliant on Chris Freeman’s part. But, it also created some nasty intermittent bugs because other parts of the game engine, such as the NPC pathfinding algorithm, were not expecting that map space to ever be used. One of the best tools I had for troubleshooting intermittent bugs was the MicroM8 debugger. It contains a time-travel feature which was inspired by a session given by Tom Phelps at KansasFest 2017. To demonstrate, Tom played Choplifter in his prototype AIIEE emulator, crashed the chopper, and then “rewound” the game to a point before the crash and just continued on his way. The time-travel feature cached snapshots of the machine state and allowed the user to fast forward or rewind through those stored states. As soon as I saw this I immediately thought about using it to troubleshoot intermittent bugs. These bugs are so difficult to solve because you often have no idea what conditions are necessary to trigger them. It may only happen when the player presses keys in a certain sequence or only if certain events based on random numbers occurred before an exact key sequence is entered. My thought was, if I can rewind to a machine state just before the bug was triggered, then I could step through the code in a traditional 6502 debugger to identify the problem. I met Melody and April Ayres-Griffiths at KansasFest 2018 and learned to my delight that they had added time travel support to their debugger in MicroM8. We worked together on a number of improvements to time travel, and I was able to use it to solve a number of bugs in Nox Archaist, including the one that cropped up when using the no-man’s-land map space to create the very tall mage towers. 124
Return to KansasFest It was also at KansasFest 2018 when Melody, April, and I agreed to work together to create the Nox App, based on a fork of their MicroM8 emulator. The Nox App is the application bundled with Nox Archaist which automatically launches the game, allowing easy use of the game on Mac, Windows, and Linux, while still retaining the authentic Apple II nature of the game with a full emulator. At KansasFest 2019, I demonstrated how I used MicroM8’s time travel feature to solve intermittent bugs in Nox Archaist. At the end of the session I announced that, after the initial game release, Burger Becky would do a port of the game to the Apple IIGS and add 16-bit enhancements. Lane Roathe, formerly of id Software, was watching the live stream and called me afterwards to chat about the announcement and wish us well. Later on, Lane helped test the floppy build of the game.
125
III. Creating Content
126
The Apple II Speaks
The Apple II Speaks
W
hen the game boots up, Jarrod Kailef ’s voice says “Nox Archaist,” followed by several drum beats and then music. The music is played using the Mockingboard, an add-on sound card for the Apple II. The human voice and the booming sounds after it are coming from the Apple II’s one-bit speaker, frequently called the Apple II squeaker because it looks like something you might buy at Radio Shack, with its small 8-ohm 0.5W paper cone and two-pin motherboard connector. Despite the limited speaker, Jarrod’s voice saying “Nox Archaist” is quite clear. It was done with a technique called 5-bit pulse width modulation (PWM), which until Nox Archaist had never been used in a commercial Apple II game. The technique was invented by former Origin Systems programmer Dr. Cat in the late 1980s, and was featured on a Softalk demo disk. By the time Dr. Cat developed 5-bit PWM, Origin was working on what turned out to be their last game for the Apple II, Windwalker by Greg Malone. As Dr. Cat recalls, Greg Malone didn’t believe it was possible to produce a high-quality human voice on the Apple II and was skeptical of the technique. Greg told Dr. Cat that if he got it to work, he’d buy him a cheeseburger and consider using it in the game. Against all odds, Dr. Cat got it to work. Understandably, Greg Malone decided not to incorporate PWM in Windwalker because it was late in development and he didn’t want to risk problems. Dr. Cat says to this day Greg Malone owes him that cheeseburger! 127
III. Creating Content During Nox Archaist development, my teammate Jarrod Kailef introduced me to Dr. Cat, who told me about the 5-bit PWM technique and strongly urged that it be included in Nox Archaist so that it would live on in at least one Apple II game. I agreed and thought it would be totally awesome. Actually implementing and using the PWM feature turned out to be very difficult. While I understood what Dr. Cat was talking about at a high level, I had no idea how to approach the project from an implementation standpoint. Audio programming is a specific skill set which I didn’t have. Dr. Cat generously offered to write the PWM player code if we created the sound data. But, I had no idea how to create sound files in the requisite format. As we talked about how to proceed, Chris Torrence and I recalled a demo that Kris Kennaway had done at KansasFest 2019. Kris had demonstrated how to stream video and audio from an Apple II computer, and had used the PWM technique for the audio. We reached out to Kris to see if he’d be up for taking the lead on the Nox Archaist PWM project, which included creating the sound data, writing the audio player, and integrating it into the double hi-res splash screen. To our relief, Kris agreed! Peter Ferrie was also ready to help with the integration of Kris’s changes to the splash screen code and Jarrod and Chris were excited to collaborate on making the sound recording. We had all the skill sets we needed. However, by the time we started collaborating we were getting close to our May 2020 code freeze deadline. This marked the start of final testing and there was a lot of planning connected to it. I wasn’t sure whether Nox Archaist would have PWM until about a week before the deadline. As project manager, I communicated with each person about what needed to be done and helped coordinate the workflow. But, at a certain point, I had done all I could and just had to hope there was enough time for my teammates to do their work. Much to my delight they somehow managed to thread the needle and make it happen! 128
The Apple II Speaks The 5-bit PWM Technique The PWM audio data takes approximately 10 000 bytes of memory per second of audio. In addition, the 6502 processor isn’t fast enough to load the audio from disk (even if there was disk space) and play simultaneously. As a result, it really isn’t practical to use the PWM technique aside from something like a splash screen or game-ending sequence. As awesome as it would have been to do things like play Richard Garriott’s voice when talking to Lord British, that just wasn’t practical. So how does the technique actually work? The Apple II has a one-bit speaker with only two states: on or off, controlled by setting a softswitch (at $C030 if you’re curious). When the speaker is toggled it produces a pulse of sound in the form of a square wave. Toggling the speaker hundreds or thousands of times per second creates tones of that particular pitch. The typical twangy sound heard in thousands of games that us Apple II fans love is produced by square waves. In contrast, the PWM technique works by turning the speaker on and off very precisely. The speaker still produces a square wave, but with a variable frequency, or duty cycle. This varying duty cycle modulates a high-frequency carrier wave (in this case 20 kHz) with lower frequency audio. This has the effect of taking a low quality one-bit audio signal and simulating a higher quality 5-bit audio signal. Writing the code to do this on the relatively slow 6502 processor requires maximum efficiency and high precision. As Kris Kennaway notes, although implementing this PWM audio playback was challenging, it still followed in the footsteps of many others in the Apple II community, including Dr. Cat in the 1980s, and Michael Mahon, who in the 1990s released his DAC522 sound player with a high-quality 22 kHz carrier wave. The true challenge that Kris faced was integrating his PWM code into an Apple II graphics animation, something that had seemingly never been done before. Using Bill Giggie’s artwork, 129
III. Creating Content Michael Pohoreski had created the original double hi-res splash screen animation and added the initial Mockingboard support. Peter Ferrie had then added significant optimizations to improve performance. Kris needed to use the built-in delays in his PWM algorithm to instead make calls into the splash screen code, while at the same time not disturbing the PWM cycle counts. With Peter’s help integrating the code, Kris succeeded brilliantly. The splash screen animation smoothly appears while Jarrod’s “Nox Archaist” booms out of the Apple’s one-bit speaker. This part of the project was quite an adventure and was very satisfying from both a technical and project management standpoint. I smiled when one day I received an email from Kent Dickey, author of the KEGS Apple IIGS emulator, in which he said “The ‘Nox Archaist’ during the intro was so good I had to check that it wasn’t using the Ensoniq.” The Ensoniq is the 16-bit sound chip native to the Apple IIGS. What had seemed almost impossible back in the 1980s had finally been achieved in a commercial Apple II game in 2020.
130
The Apple II Reunion Party
The Apple II Reunion Party
H
ave you been to Praevoc Keep? All of it? On the south side of the third floor, in an area of the map that is inaccessible from Praevoc, the developers of some of our favorite games are partying like it’s 1989! In this room players of Nox Archaist get to meet the NPCs of Steve Wozniak, Richard Garriott, Roger Wagner, Robert Woodhead, Brian Fargo, Burger Becky Heineman, Jordan Mechner, John Romero, John Carmack, Dr. Cat, and the ghost of the late Silas Warner! Many thanks to all these fine folks for participating in Nox Archaist’s Apple II Reunion Party!
Fig. 52. The Apple II Reunion Party, south of Praevoc Keep.
131
III. Creating Content Of course, those who have been to this room will recall it is reached via a portal in Lord British’s shrine. The concept came together late in development, and there wasn’t enough floppy disk space to create another map. But, I was determined to make this special content come to life and I found a place to cram it in. In Praevoc Keep, the player cannot see this content because the walls of the keep prevent the player from walking far enough south to see it. Such are the ways of 8-bit developers! But, how did this party get started? The short answer is networking, networking, networking. In my finance and business career I’ve done a lot of networking and have had some formal training in this area. This turned out to be a helpful skill set in a variety of areas during Nox Archaist development. As the project progressed I kept in touch with my teammates and learned more about their backgrounds and made a mental note of contacts each had (okay, I’ll admit there were some actual notes too!). When the time came to ask Richard Garriott for permission to include Lord British as an NPC in the game, I knew exactly who to ask for an introduction. Jarrod Kailef did some music work for Richard Garriott on Shroud of the Avatar and had kept in touch with him over the years. Jarrod was instrumental in bringing Lord British and Nox Archaist together and even worked with Richard on some of the wording for his tweet.
Fig. 53. Richard Garriott’s Nox Archaist tweet.
132
The Apple II Reunion Party
Apple II Reunion Guests and opening lines Steve Wozniak: Creator of the Apple II computer. You see a man playing an Apple II computer like a guitar. Richard Garriott: Creator of the Ultima series, founder of Origin Systems. A man dressed like a medieval monarch says, “Hello! Welcome to our gathering!” Roger Wagner: Assembly Lines, publisher of the Merlin Assembler. The man jumps up and greets you happily. Robert Woodhead: Sir-Tech Software, co-creator of Wizardry. This man is wearing a satin jacket embroidered with a dragon. The man shouts “Dumapic!” Burger Becky Heineman: Tass Times in Tonetown, Bard’s Tale. This woman is holding a hamburger and a copy of Bard’s Tale. Jordan Mechner: Karateka and Prince of Persia. The man holds out a floppy disk labelled “Karateka Source Code.” Brian Fargo: Co-founder of Interplay. The man waves you over. “Look at this cool new computer game!” John Romero: Wolfenstein 3D & Doom. A man with long flowing black hair and black glasses nods and smiles. John Carmack: Wolfenstein 3D & Doom. This man is wearing a virtual reality headset. Dr. Cat: Furcadia; Origin Systems programmer and designer. You see a man with a bushy beard and a fedora. Silas Warner: Muse Software, Castle Wolfenstein. You see the ghost of a giant man with a happy smile. Fig. 54. Apple II Reunion guests and their in-game intro.
133
III. Creating Content Having Richard call out the game on twitter was a huge deal for me and my teammates, all of us having grown up playing his Ultima games. This announcement occurred shortly before our successful second Kickstarter in May 2019. The campaign attracted a lot of attention in the retro-verse and was backed by several 1980s Apple II game developers including Robert Woodhead, Burger Becky Heineman, John Carmack, and of course Richard Garriott. At some point either during the Kickstarter or shortly thereafter, Mike Reimer and I were talking about how awesome this all was, especially considering how at the start of the project, we didn’t know if anybody was even going to play our game. We cooked up the idea of throwing an in-game Apple II reunion party as a way to give recognition to our Apple II heroes and heroines in a way that players could participate in. After that conversation, I rolled up my sleeves for a bunch of networking to get permission from each person to include them as an NPC. I contacted Burger Becky first. My teammate Beth Daggert had introduced me to Becky early on in the project and we became friends over the course of several KansasFests. Then I contacted Robert Woodhead and John Carmack, both Kickstarter backers. I also asked Dr. Cat, another contact from Jarrod Kailef, with whom I was working on the cool PWM sound for Nox Archaist (see p. 127). My teammate Chris Torrence reached out to Roger Wagner. All of these Apple II luminaries graciously agreed to participate. At that point the reunion party was established and I asked some of the guests for introductions to other 1980s Apple II developers, and then asked those developers for introductions to others. In each case I explained the concept, who was participating, and asked if they’d like to participate as well. As this played out, the idea of contacting Steve Wozniak was always in the back of my mind. Eventually, I was able to get a referral to him but before acting on it I remembered meeting 134
The Apple II Reunion Party Roger Wagner when he gave the keynote address at KansasFest 2018. He had a couple pictures of himself and Steve Wozniak from back in the day. They knew each other well. I also recalled that Chris Torrence was friends with Roger from their work together on Assembly Lines: The Complete Book, a compilation of the assembly language articles that Roger had written for Softalk magazine in the early 1980s. In a third-degree networking feat, I asked Chris if he would ask Roger for an introduction to Woz so we could invite him to participate in the Apple II reunion party! Thanks to Roger, Chris and I made contact with Woz and extended the invitation, which he graciously accepted. I kept in touch with each of the reunion party guests, sharing video clips of the room and their NPC’s dialogue. This led to some edits and additions, such as the Easter egg triggered if the player says BURGER to Burger Becky. Go ahead and try it. John Romero shared with me that he worked for Origin Systems briefly while Ultima V was being developed. That was a key piece of history that I had missed and made sure to add in. After I sent him a video clip of the reunion party, John remarked that he had been startled by the audio of the Castle Wolfenstein character, just like back in the day. Achtung! When Nox Archaist was released, many of the guests excitedly tweeted out about their appearance in the first commercial RPG released on the Apple II in over 30 years. These folks are all very busy and we really appreciated them taking the time to recognize the game. Woz is probably the busiest of the bunch with his nearly non-stop worldwide speaking tour. Chris and I asked if he’d be up for posting a tweet mentioning his participation. We crossed our fingers and held our breath, as an endorsement from Woz would be like getting a blessing from the Pope for an Apple II game. At first it looked like he might be too busy, at least for a while. And then, a few days after Nox Archaist released, my phone 135
III. Creating Content started exploding with activity. Then it rang. It was Chris—he was frantic and said “Check your email! Check your email!” I opened the Twitter link he had sent me and nearly fell off the exercise bike I was riding. As it turned out, Woz found a few minutes for us after all!
Fig. 55. Steve Wozniak’s tweet a few days after game release.
136
The Apple II Reunion Party
IV. Testing and Release
137
IV. Testing and Release
138
To Flee or Not to Flee
To Flee or Not to Flee
T
hat was a question I debated when developing the combat system. The only tile-based RPGs I ever played which had a flee mechanic were Ultima IV and V. In those games, the player could flee by moving their characters off the edge of the combat screen, provided that the mobs didn’t kill them first with range attacks. If the player’s attempt to flee was successful, the mob icon would disappear from the Overworld map. In other words, the battle would be permanently avoided. That design worked fine in Ultima IV and V because these were games in which combat wasn’t really a central activity even though it was frequent. The penalty for fleeing was simply a hit to your valor virtue score. This had implications for gameplay but avoiding any particular battle didn’t have much of an impact. My vision for Nox Archaist was a game where combat was a more central activity. Similar to Bard’s Tale and Wizardry, developing characters to become more and more powerful would be necessary to win the game. To this end, I foresaw areas of Nox Archaist that would be gated off by powerful mobs. In other words, if the player could flee and the mobs would just vanish from the map, the player could breeze right past them and enter an area much earlier than I had intended. With this in mind, and the fact that Ultima I–III didn’t have a flee mechanic, I decided Nox Archaist wouldn’t have one either. A guiding design decisions I made early on was that Nox Archaist would have old-school difficulty. No flee, no problem. There were a few comments about the absence of flee during beta testing but no major concerns were expressed. I didn’t 139
IV. Testing and Release anticipate the ruckus that would ensue after the public release of the game. Very quickly I became aware of some players expressing a lot of frustration about it. I engaged them in some discussion and eventually I thought of a way to resolve my original design concerns. The question was whether the issue warranted taking the risk associated with adding a feature post release since that could introduce bugs.
Fig. 56. Nox Archaist players fleeing from battle.
The idea I had was to keep the mob on the main map after the player flees, force the player to drop half their gold during the hasty escape, and then cause the mob to lose a couple of turns to give the player a head start at getting away from them on the main map. It felt so obvious once I saw it. The player could flee from battles in large open areas, but would not be able to easily flee in tight corridors or in areas that were gated by powerful mobs. I did some polling on Discord and found a bell curve. The vast majority of people thought a flee mechanic would be a positive thing but the absence of it wasn’t a major issue for them. There was a small minority of people on either end of the curve who thought a flee mechanic was a major issue, one group for it and the other against it. The results made it clear that even though only a small (but vocal) minority thought the absence of a flee mechanic was 140
To Flee or Not to Flee
Fig. 57. Final version of the “Flee” screen.
a major issue, if we added the mechanic, the vast majority of people would consider it to be an improvement. I will admit that I was somewhat frustrated with the situation, but I aspire to make decisions objectively and the data was clear. I added the flee mechanic in the first software update to Nox Archaist, about a month after the public release. Personally, if I was playing Nox Archaist in an emulator or on physical Apple II hardware with a hard drive, I would take the 10 seconds to reboot the game before I would take the gold hit. But, to each their own.
141
IV. Testing and Release
142
My First Playthrough
My First Playthrough
B
y early June 2020 the game was feature complete and content complete. Nox Archaist weighed in at over 450 000 lines of code and data. All that was left was testing, bug fixing, and balance adjustments. I really wasn’t sure how long this final phase would take. For all I knew it could take a year or more, though I was shooting for three months. As it turns out, the game was released roughly six months later. Looking back now, I feel pretty good about that. Why was I afraid it could take a year or more? By this point, the game had not had any heavy testing since the alpha release a few years prior. The time since then was mostly spent on adding content rather than adding features, and I had just been testing each new piece of content rather than testing the game as a cohesive whole. As a result, a whole lot of assumptions were lurking beneath the surface relating to game balance. The statistics behind the combat math and economy held up during alpha testing but there had only been enough content to get characters to level three. Given the extraordinary items and experience points that came later in the story, would the statistics scale smoothly to level 10? I thought they would but I didn’t know for sure. The alpha testing was also focused more on game mechanics rather than computer platforms. I had tested the game on the Apple IIe, IIc, and IIGS physical hardware but only occasionally and never for more than an hour or two at a sitting. More rigorous testing didn’t seem productive earlier in the project since things were still rapidly changing. 143
IV. Testing and Release As the first order of business I decided to play the game from start to finish, fix any bugs I could flush out, and make a first pass at adjusting the combat and economy game balance. In my first playthrough I alternated between the most popular emulators and physical Apple II hardware using various hard drive cards such as the BOOTI and CFFA3000. I didn't do floppy disk testing at this stage because if I ran into problems, it would be difficult to determine if they were related to the game engine or to the ProRWTS floppy controller, which had yet to be used in a released game. Since the hard drive controller was stable, my goal was to achieve a stable hard drive build first, and then do heavy testing on the floppy build. That way, if any problems occurred I could be fairly sure they were floppy related. As I made the round robin between emulators and physical Apple IIs I fixed a metric buttload of minor bugs and tweaked the combat and economy stats. I was pleased to find that the stats scaled well up to a party of level 10 characters. During testing I also noticed a handful of intermittent bugs. These bugs would occur occasionally and could not be reliably reproduced with a known set of actions. Intermittent bugs are generally the most difficult to solve. Many folks without a
Fig. 58. The Nox Archaist Apple II Test Lab.
144
My First Playthrough programming background may have experienced calling technical support and been asked what they were doing when the problem occurred, and then being told by the support tech that they can't get the problem to occur. Some support reps have better customer service skills than others, but in these cases, it’s usually not that the support rep doesn’t believe the problem happened. Instead, by reproducing the problem themselves, they can run tests to narrow down the root cause. For example, if the bug occurs with steps A, B, C, and D, they might try with just steps A, B, and C to rule out step D as the problem trigger. On modern computer systems, programmers have a lot of resources to tackle intermittent bugs. For example, software is often designed to generate a debug log file. This allows the programmer to glimpse back in time to see what was happening before the problem occurred. However, Nox Archaist was written for the Apple II with 140KB floppies, not nearly enough space to store a robust log file. Nor was there enough room in the code to write to a log file in a large RPG like Nox Archaist. Intermittent bugs can be a 6502 assembly language programmer's worst nightmare, especially if they only occur on physical hardware. If the bug can be reproduced in an emulator, we have some tools that can help track down the bug, though it is still very difficult. For example, some Apple II emulators have debuggers, including my favorites Virtual ][, MicroM8, and AppleWin. Using a debugger we can set breakpoints at specific code locations, and then move the breakpoints forward or backward to get some clues as to what general area of the code is triggering the bug. We can also observe the values in memory and even alter their values while the program is running. On the physical Apple II, there is no debugger. Sometimes bugs will cause a crash to the system monitor where we can at least observe the values in memory. Other times, however, when an intermittent bug occurs, the system just hangs. 145
IV. Testing and Release One of my favorite tricks for this scenario is to alter the program code to print debug codes to the screen at various points along the expected code path (see Fig. 59). This provides similar diagnostics to breakpoints, though it is much more tedious and sometimes there isn’t enough memory to add the debug code. Even if there is enough memory, just adding the debug code may alter the behavior because it shifts the addresses where the main code resides. None of these are issues when using a debugger in an emulator or in protected memory, which the Apple II doesn’t have. Another challenge occurs when the debug codes print too fast. This can happen if the program is clearing the screen at various points along the code path. Several times when this happened I used my iPad to record the Apple IIe’s CRT monitor so I could rewind and see all debug codes. The most difficult bugs that I encountered were specific to the Apple IIGS. They didn’t occur in IIGS emulators nor did they occur on physical or emulated Apple IIe or IIc hardware.
Fig. 59. Debug codes are circled. The !!!’s are from the bug.
146
My First Playthrough I remember as a kid in the 1980s there were some games that were designed for the Apple IIe which would hang or crash on our Apple IIGS. Most worked fine but a few did not. It always puzzled me because the Apple IIGS was promoted as backwards compatible with the IIe and IIc. By the time Nox Archaist testing was done, I had learned the reasons why this wasn't always true. One reason that some games designed for the Apple IIe and IIc don’t run properly on a IIGS include ROM differences. For example, the IIGS interrupt handler uses more bytes on the stack. Some machine-language opcodes that are illegal on a 6502 and 65c02 processor (Apple IIe/IIc) do nothing but could do something unexpected on the 65816 processor (Apple IIGS). These illegal opcodes sometimes weren’t found because they didn’t cause a problem on the original system. Code that is harmless on the Apple IIe/IIc could accidentally flip the bank register on the IIGS. The IIGS memory is organized as a series of 64 KB banks. An 8-bit program is expected to only use banks 0 and 1, to give it the 128 KB which existed on the Apple IIe and IIc systems. Now, there was good news and bad news about the presence of Apple IIGS specific bugs. The good news was that, unlike the Apple IIe and IIc, the Apple IIGS had a build-it debugger, known as GSBug (see Fig. 60), which was made possible by its much greater memory capacity. The bad news was that using the debugger crashed the system. I was stuck, so I reached out to the IIGS brain trust in the Apple II community. Burger Becky, Kent Dickey, John Brooks, Antoine Vignau, and a respondent named Richard all suspected the crash to be related to the fact that Nox Archaist was designed for the Apple IIe. It turned out that GSBug used 1 KB of memory in bank 0. Since 8-bit programs run in banks 0 and 1, GSBug was clobbering part of the Nox Archaist game engine code. Geoff Wise provided definitive confirmation with a link to an archived discussion from 1991 on America Online. 147
IV. Testing and Release America Online APPLE II DEVELOPMENT FORUM CONFERENCE LOG Tuesday, February 12, 1991 10:00 p.m. Eastern Time Topic: Resource Programming Forum Leader: Dave Sugar (AFL Dyfet) AFA Gary J Anyone know where GSBug puts it's stack? (Like maybe $000100 area???) ShanoJ According to NiftyList it only owns one block, and it's not in bank $00... A2GS It probably pulls everything off the stack (ex. return address, etc...) when it first becomes activated. AFA Gary J I'll ask a question about it later. I guess my problem is when I switch to emulation mode :) Dave Lyons GSBug owns 1K in bank 0 while you're actually in GSBug; it keeps the stack in that 1K some of the time, but it also uses a bit of “your” stack. It also doesn't manage the $010100 byte right AFA Gary J That's the problem :) Dave Lyons when switching in and out of the page-1 stack, so if you're tracing some code that has the stack in page 1, try typing 01/0100:80 first; this way interrupts will use 100..180, and your program being traced can use 181..1FF. AFA Gary J Ah, exactly as I've been doing. That seems to help :) AFA Gary J (I just wanted to confirm my suspicions)
Fig. 60. The GSBug Apple IIGS debugger.
148
My First Playthrough GSBug would crash about half of the time when I entered it, and it would crash all the time when I tried to resume the game. Thus, if I could encounter a bug enough times to get lucky and successfully enter GSBug, I could peek at bunches of useful information about the system state. Using this trick, I was able to solve one major bug that was causing the game to hang intermittently. By successfully entering GSBug, I was able to peek into the system state and determine that under certain circumstances the stack pointer was wrapping around from $FF to $00, but only on the IIGS. The reason the wraparound caused a problem is because I had hijacked part of the stack memory and used it for game engine code. This hack was common in 1980s games because memory was so limited, and was based on an estimation by the programmer of how much stack space the computer really needed. But in this case, the wraparound caused the computer to clobber game engine code with stack data. The wraparound was a symptom but not the root cause. The root cause was in the code I wrote to handle the transition from one map to another, such as when the player enters a town or castle. The code wasn’t properly cleaning up the stack when it terminated and was leaving a few bytes on the stack each time the map changed. The bug only triggered on the Apple IIGS because the interrupt handler for the Mockingboard music used more stack space than the handler on the IIe. Because of my leaking bytes, this caused the pointer to wrap around sooner. The problem would have eventually happened on the Apple IIe if the game was played long enough. Intermittent stack pointer bugs can be really hard to solve. However, that was not the most difficult bug that we were confronted with at this stage. The most difficult was an intermittent bug that only occurred once every few hours of game play, caused by the firmware of the CFFA3000, an aftermarket Apple II card which was generally 149
IV. Testing and Release considered to be rock solid. In other words, just about the last thing anyone would expect. I spent a good chunk of the summer of 2020 chasing down this bug. After solving several IIGS bugs which caused the game to hang randomly, the frequency of the hangs decreased but didn't go away. That suggested the presence of another bug which just happened to display similar symptoms. Through trial and error I was able to observe that the bug seemed to occur when the player entered a different map such as a town or castle. Since the bug only happened on the physical IIGS, I added logic to print out debug codes in the subroutine which handled map changes. The last debug code printed out was just before my file system wrapper called the file system controller (ProRWTS). The debug code after the return from ProRWTS was never printed. That suggested the problem might lie somewhere in ProRWTS. At this point I called for backup and contacted grandmaster 6502 assembly programmer Peter Ferrie. Peter couldn’t find anything wrong in ProRWTS or in my file system wrapper. We puzzled over this for months. As time went on I chatted with several other heavy hitters in the Apple II community. The decisive conversation was with Quinn Dunki at KansasFest 2020. She raised the specter of a hardware problem because nothing else made sense. Initially we thought maybe it was a bad Apple IIGS. Mine had came from a garage giveaway at an earlier Kansasfest and I had not spent much time using it. Before finding another Apple IIGS, I kept Quinn’s advice in mind as I tried a few other troubleshooting ideas. One idea was to put a different CFFA3000 card in my IIGS. The CFFA3000 is a modern card which uses a USB memory stick as an Apple II hard drive volume. I had one card in my IIe and one in my IIGS. The CFFA3000 has a dip switch setting (#7) for “GS Mode.” I had this dip switch set to ON for the card in my Apple IIGS and 150
My First Playthrough OFF for my Apple IIe, which is the proper configuration. Since the bug didn’t occur on my Apple IIe, my plan was to move the CFFA card from the IIe to the IIGS and observe if the bug still occurred. As I was doing that, I put my hand on dip switch #7 to flip it to ON, and then hesitated. Flipping the switch ON would be the proper configuration for the Apple IIGS, but by making that change, the CFFA card would no longer be in the same state as it was in the Apple IIe. I recalled that when I first purchased my CFFA cards I was not aware of “GS Mode” because I didn't adequately read the manual, and yet the card in my IIGS had seemed to work fine. I had later read the manual and turned the switch ON. Thus, I decided to move the CFFA card from my IIe to my IIGS but leave the dip switch OFF. I booted up Nox Archaist and after many hours of testing observed that the bug did not occur. Then, I flipped the dip switch to turn “GS Mode” ON and saw that the bug occurred in the usual time interval. I immediately emailed Peter like Janine in Ghostbusters pulling the fire alarm yelling “We got one!” After consulting with Peter, I contacted Rich Dreher, the creator of the CFFA card. He introduced us to Dave Lyons, the programmer who wrote the firmware code. Peter and Dave discussed the issue and came to the following conclusions. The CFFA3000 has a IIGS-specific feature called the CDA (Classic Desk Accessory), which is enabled when the card is in “GS Mode.” The CDA allows the user to access the CFFA configuration menu at any time with a key sequence whereas on the Apple IIe the menu is only accessible on bootup. The CDA feature uses a small slice of memory in bank 0. However, 8-bit games like Nox Archaist expect that they have exclusive access to all of bank 0 and bank 1 because those two banks simulate the 128K of RAM of an Apple IIe. Many 8-bit games would not be affected because they don't use the entire 128K of memory. 151
IV. Testing and Release While a conflict is rare, Nox Archaist was not the first game to experience it. Peter said he’d received reports of infrequent crashes on the IIGS from users of Total Replay, a packaged version of hundreds of Apple II games. The bug reports were a mystery until the cause came to light with Nox Archaist. The fact that the bug was triggering with ProRWTS was a coincidence, as that code just happened to be using the same memory space as the CFFA’s CDA feature. Unfortunately, there was no way to mass-update the firmware on an Apple II card that had already been installed on thousands of machines. Instead, using specifications provided by David Lyons, Peter added code to the ProRWTS bootloader to disable “GS Mode” on the CFFA before Nox Archaist was loaded. There were times when I thought about the implications if we were not able to solve this bug. If an intermittent bug happens rarely enough, it’s not really a big deal, especially by modern gaming standards where many games are plagued with bugs. On the other hand, if an intermittent bug happens very often, they are much easier to solve. The problem with this bug was it was occurring after a few hours of gameplay. That’s often enough that it would be really annoying for Apple IIGS players but still infrequent enough that it made troubleshooting really hard. In the end, we didn’t give up and eventually it worked out.
152
Beta Testing Team
Beta Testing Team
A
fter I played through the game start-to-finish for the first time and fixed as many bugs as I could, I turned it over to the beta testing group. Beta testing is a term that seems to refer to a lot of different things from one studio to the next. For 6502 Workshop, what we called beta testing is what we did when the game was feature and content complete. I recruited two groups of beta testers, with a dozen or so people in each group. I expected the first group to find lots of bugs and balancing issues. Once I’d addressed those, I wanted the second group, who had never played the game, to join in. The second group would have a fresh set of eyes and would not be affected by the memories of how things used to work. Thanks to everyone in both groups, this worked out very well and helped us release a very stable game. This was heralded as a breath of fresh air by RPG fans who had grown tired of the buggy release state of certain Triple-A games on modern computers. Working alongside the beta testers, my teammates and I fixed many bugs and made numerous balance adjustments to the combat and economy stats. Some bugs were corner cases that caused the game to crash, while others were oversights in the user interface or quest design which made the game feel broken. Some of the most difficult bugs to solve were ones that caused data corruption. I described in My First Playthrough (p. 143) about the difficulty of intermittent bugs. While the CFFA bug was difficult, the data corruption bugs were almost as hard. 153
IV. Testing and Release The reason they are so difficult is because they appear to the testers as a persistent bug. The tester will open a bug report giving exact steps for reproducing the problem, such as the game crashing when launching inventory. When I dig into the cause of the crash I find that the inventory data has somehow become corrupted. But, understandably, neither the tester nor I have any idea how the corruption occurred. Invariably it was triggered by something the tester was doing before the crash, sometimes long before. In modern software, a bug like this can usually be tracked down through log files. In an 8-bit environment, the best approach I’ve found is to ask the tester to document everything they can remember about what they were doing before the problem occurred. Then, we wait for the Beta Testers problem to happen again, and again, and again. Each time documenting as much Henri Asseily (Rikkles) Liam Asseily as possible about what the player was Arnaud “Harcolas” Colette doing prior to the problem. Eventually Dominik a pattern will emerge and with careful Douville-Bélanger analysis and some luck, we’ll be able Fahed Bradley A. Hooker to identify the root cause of the data Tobias Hübner corruption and solve the bug. Bert Isla For the most part there were no Bill Lange Forrest Lowe major bugs that came up which I didn’t Bill Martens think we could solve. The only exception Daniel McTyre was one that related to the High Cultists Ryan Musante (see sidebar on next page). Andrew Schultz Joseph Seeley the Greater There were also some design issues Joseph Seeley the Lesser which we did not solve for one reason Lord Dave Slotter or another. John Stallings For example, there are two grass tiles Joseph Stallings John Talent in the archery range in Suurtheld Castle Nick Walton and one tile near the range weapon Andre Zadrazil trainer in Knaerwood which all report 154
Beta Testing Team SPOILER ALERT After defeating the High Cultists, the dark void expands to swallow most of the Wynmar Isles. To make the expansion, I had written code to overwrite the Overworld map with an alternate map stored on the Boot disk. Late in beta testing, a tester reported that after winning the game, they started a new game and the Overworld map still had the expanded dark void. This was happening because the Overworld map wasn’t stored in the saved game file. If it had been, the file would have been 14k larger, a large amount for a 140KB floppy. It was a veritable “oh crap” moment. I had no idea if this was going to be solvable given disk space limitations and the tight memory in the game loader. The implications to the storyline and game content were huge if we were to remove the dark void expansion. Fortunately, I had been rationing disk space very carefully and we had just enough room on the Boot disk to fit a copy of the unmodified Overworld map. So, I set out to add code to the start-new-game subroutine: if the Overworld was in the dark-void state, the code copied the normal map from the Boot disk. In effect the map data on the Overworld disk became a working copy while the master map for both states was stored on the Boot disk. The state detection was used to avoid a time-consuming copy since the time to initialize a new game was already getting long when using floppy disks on physical Apple II hardware.
“blocked” when the player attempts to walk on them. This relates to a game engine mechanic which I call “occupied tile swaps.” This mechanic is used in many ways throughout the game. For example, the “bed” tile changes from an empty version to an occupied version when the player or an NPC walks on the bed. When drawing each tile on the screen, the game engine checks if the tile uses the “occupied tile swap” feature and if the player or an NPC is standing on that tile. If both checks pass then the engine increments the tile ID of the shape tables by one. The shape tables for occupied tile swaps are stored adjacent in memory so that adding one to the tile ID will cause the game engine to draw the occupied version of the tile. 155
IV. Testing and Release One fine day, our graphics artist Bill Giggie whipped up some archery target and shooter NPC tiles. The archery tiles were cool but I explained that we didn't have enough memory to add a feature to support it. The kind of feature I was envisioning would cause the presence of an NPC archer a certain number of tiles away to trigger an occupied tile swap at the archery target’s coordinates. By this point in development Bill had a good feel for features in the game engine. He said something like “Well, what if you just create an NPC that looks like grass and schedule him to stand on the target at the same time as the archer walks to his station, and have the target change its tile like a bed.” I thought this was very clever. It used existing game engine features, and thus had zero additional resource costs per use. The wrinkle was that if the player bumps into the “grass” NPC, the “blocked” message appears which seems strange because they can normally walk on grass. There are a number of cases in Nox Archaist where a really cool feature came at the price of a few oddities but I thought it was worth it. Another example is the jester in the Nourtheld or Suurtheld Castle courtyard. When juggling, the jester appears to occupy two tiles. The game engine only supports NPCs that occupy one tile or four tiles, but not two. The jester’s top half is an adjacent occupied tile swap that toggles between a floor tile and the objects being juggled. The oddity is the LOOK command text on the top tile says “floor” because the command bases its text response on the primary tile. It has no awareness of whether the swapped tile is active since that code is only in the screen draw subroutines. With some 3D imagination, perhaps the player is looking behind the jester in that case. The beta testers and development team did a lot of work together and also had a lot of fun. As the holiday season approached, one of the testers started up a parody of the Twelve Days of Christmas (see Fig. 61). 156
Beta Testing Team
Fig. 61. The Twelve Days of Nox Christmas.
157
IV. Testing and Release Beta tester Rikkles was the first to do a lot of things. He was the first to figure out you could put a portal by the dragon and farm the treasure, which caused me to change most of the chests to have a persistent state rather than chests that could be looted over and over. He also made the first maps, a few by hand, then he integrated an automated mapping tool into the Apple II emulator AppleWin. Rikkles was also the first to attack Lord British. After a few trouncings, he made a beeline for a hex editor and hacked the game. He swears the ensuing battle with Lord British was a tie. A unique and commendable feat for sure but not to be confused with beating Lord British in normal gameplay. I like to tease him that Lord British remains undefeated (which is true!). Legless and armless on the battlefield, Rikkles looks up and shouts to Lord British, “Alright, we’ll call it a draw!” The following pages contain the chat transcript from Discord.
158
Beta Testing Team
159
IV. Testing and Release
160
Beta Testing Team
However, most people don’t know just how close Lord British came to being able to be killed through normal gameplay before Nox Archaist was released. Beth Daggert was the first person to win Nox Archaist, ahead of Rikkles by only a matter of hours. Beth reported that when she first encountered the Dark Shadow (the final boss), she killed him but the game crashed. I was very puzzled because the Dark Shadow was supposed to be invincible in the first encounter. Beth explained that she dropped a cow on his head by casting the Cowmageddon spell (see Fig. 62). When I reproduced the sequence, as soon as the cow dropped, the Dark Shadow boss disappeared from the screen, the game paused for a second or two and then crashed to the system monitor. The game has one invincibility mechanic. It is used for Lord British, the Dark Shadow, and the developers at the Apple II reunion party (say BURGER to Burger Becky in-game to learn more). My heart skipped a beat as I realized that if the 161
IV. Testing and Release invincibility failed with Cowmageddon against the Dark Shadow then it would surely fail to protect Lord British in the same situation. The Lord British character in the Ultima games was designed to be undefeatable, however there was always a way to do it. In the first six games, players found a loophole which allowed the defeat to occur. By Ultima VII, attempting to defeat Lord British had become somewhat of a tradition and Richard Garriott found the whole thing quite amusing. So, the developers started adding Easter eggs which allowed Lord British to be defeated in one specific and obscure way. This continued until the conclusion of the series with Ultima IX. Presented with this cow paradox, I mulled it over. On one hand, I was pretty sure that if I fixed this bug there was a fair chance that Lord British would be truly undefeatable in Nox Archaist. On the other hand, I considered the tradition of Easter eggs in the later Ultima games. If I proposed a cow Easter egg to Richard Garriott, I thought he’d be fine with it, and Nox
Fig. 62. Cowmageddon, by Bill Giggie. Moooo!
162
Beta Testing Team Archaist would quite possibly have the most ridiculous Easter egg for defeating Lord British in the history of the character. On behalf of Castle Foolery, Nox Rhumoid Cowwagon voted to include the Easter egg. However, I couldn’t resist the temptation to test my programming skills against the hordes of players who would, in the name of tradition, make a run at the King. I fixed the bug and, as of one year after the release of Nox Archaist, Lord British remains undefeated. According to former Origin Systems developer Dr. Cat, Nox Archaist is the only computer game that Lord British appears in where this is true. Richard Garriott gave his blessing for us to have some fun by releasing the “Lord British Undefeated” t-shirt, available at Willy’s, our Nox Archaist online store. Of course, had we gone the other way, maybe we could have released a t-shirt with a mad-eyed cow hovering over Lord British’s head.
Fig. 63. Lord British Undefeated t-shirt. Still available at willys.noxarchaist.com.
163
IV. Testing and Release
164
Floppy Nightmare
Floppy Nightmare
U
p until August 2020, just a few months before release, we thought that the ProRWTS floppy disk and hard drive controllers were working fine. However, as mentioned earlier, hidden in the depths of the game was a catastrophic bug that only surfaced after playing the game for long periods. To explain how this situation arose we have to go back to the early days of the project. Each time I would add a new feature to the game engine, or later content, I would test the specific thing that was added. As the code grew, I’d also do my best to spot test the interaction between related features. For example, when I created portals which required a specific item to use them, I tested the portals with and without the item and also both of those cases when on foot, on a horse, and on a wyvern. However, this spot testing was nowhere near as rigorous as a tester playing the game and seeing what shakes loose. This was especially effective when the tester was not me (i.e. not the primary programmer and designer). While I did some coding early on in the project on a physical Apple II, I quickly switched to using the SBASM cross-assembler running on Windows. My testing was primarily done using the MicroM8, AppleWin, and Virtual ][ emulators. I periodically tested on hard drives and floppy drives using physical hardware. For years the periodic testing that I did on the floppy version seemed fine. Then, in August 2020, as the hard drive version seemed stable, I rounded up some testers and turned them loose on the floppy version. Reports started rolling in of 165
IV. Testing and Release random crashes occurring between five minutes and two hours of gameplay. I was immediately nervous. Years earlier I spent many months working together with Peter Ferrie (aka Qkumba) using Nox Archaist as the test bed for developing his ProRWTS floppy disk controller. We worked through many bugs and one thing I learned is that floppy disk bugs are extremely difficult to solve, even for Peter who is one of the most knowledgeable people in the world on this subject (see p. 48 for his background). Would this be an easy bug to solve or a hard bug? I didn’t know and I feared what a hard bug might do to our target release date only a few months away. The reason bugs of this type are so difficult is because the Apple II disk I/O architecture is somewhat different from other 8-bit systems. The disk controller on the Apple II is 100% software based. This requires code running on the CPU to control the movement of the disk drive arm rather than firmware on the drive itself. Games in the 1980s used a disk controller developed by Steve Wozniak in the late 1970s. By the time games in the 1980s were made, the controller software was rock solid. The ProRWTS controller in Nox Archaist was brand new, and had never been used in a released floppy game. Standing on the shoulders of giants, ProRWTS dramatically improved disk access time and provided several other benefits. By taking advantage of this advanced disk controller, Nox Archaist was able to provide a much larger game with better gameplay. The code in ProRWTS is where software logic integrates with the reality of the physical world. On a floppy disk, the magnetically-stored data is organized in circles, or tracks, on the disk surface. To read data from the disk, ProRWTS sends signals to the arm on the disk drive instructing it to move. In the meantime, the surface of the disk is spinning inside the drive. ProRWTS has to control the timing of the drive arm precisely. 166
Floppy Nightmare When the drive arm is moving ProRWTS enters a loop state until the drive arm reaches the desired track. Once the desired track is reached, ProRWTS reads a stream of data from the drive head which interprets the magnetic signals stored on the drive surface. If the loop state is not timed precisely, the drive head will not be in the expected position, ProRWTS will return garbage data back to the program, which will then hang, crash, or have other undesirable side effects. Writing the code for the loop state involves precision down to the level of CPU clock cycles. The CPU in the Apple II is processing one million clock cycles per second. Being off by a single clock cycle can be enough to throw off the drive head position and cause a catastrophic failure of the program requesting the disk data. Making matters even more complex, there are several different models of floppy drives used on the Apple II, including the Disk ][, UniDisk, and DuoDisk. These all have slight timing differences which must be taken into account in the floppy controller code. I had a few drive models in my test lab (Fig. 58) but not all of them. Additionally, earlier in development we were constrained by the amount of content that had been created. In other words, it’s hard to find a bug that can take up to two hours to trigger when there isn’t two hours of game content. In parallel with solving the floppy controller issues, I was coordinating with the primary testing group who were focused on testing with emulators and physical Apple II computers using the hard drive build. I was also in frequent contact with my teammate Chris Torrence, who was preparing to ship the physical boxed sets. I did my best to synthesize all of these testing data points into target release date decisions. Chris was with me in the “virtual situation room” in early November when we were rapidly approaching the late-November target release date. The hard 167
IV. Testing and Release drive testing was going well, but we still had some remaining floppy disk issues. We did not want to delay the release until the floppy disk issues were fixed. My assessment was that they might be solved quickly, if we got lucky, or they might take months, or even longer. At the same time, we didn’t want to release the game as digital-only and hold up shipment on the boxed sets that people had pledged for in the Kickstarter and preordered on our website. For financial and logistical reasons, we also did not want to ship the boxed sets without the floppy disks and then ship the floppy disks later. To thread this needle, on November 8, 2020 we offered our physical reward backers the option of receiving the boxed set with the floppy beta version or having us wait to ship their boxed set until the floppy version was stable. Most backers decided to wait it out and nearly all backers were extremely understanding and supportive. After addressing the important task of backer communications we turned our focus back to testing and bringing this plane in for a landing. More than once I thought about the answer that Indiana Jones gave to being asked if he could fly a plane: “Fly, yes. Land, no!” While this was a very stressful time, I was confident that we would find a way to navigate through the issues and deliver a stable game that people enjoyed. Around this time more people stepped up to help test the floppy version, including Lane Roathe of id Software fame, Peter Neubauer, Forrest Lowe, Rikkles, Bill Lange, and others. We were ready to beat this bug. And then the 40-year-old floppy disk drives threw us a spiked curve ball. Qkumba had fixed an obscure timing issue in late November. During regular operation, if drive 1 is powering down while drive 2 powers up, then an increased power draw occurs. The increase affects the speed of the drive arm, causing it to be in 168
Floppy Nightmare a slightly different position than was expected by ProRWTS. Since Nox Archaist rapidly switches between drives 1 and 2, we were affected by this timing variance. After that variance was accounted for in ProRWTS we were not able to produce any more problems on known good floppy drives. Rikkles and Forrest Lowe had in their extensive collections some bad floppy drives that wouldn’t boot any software, Nox Archaist or otherwise, which they had repaired. In the repaired state, the drives would run any software they tried without problems but would hang while playing Nox Archaist. The drives would pass all 1980s disk utility checks, but using an oscilloscope, Rikkles identified that the repaired drives were not working properly. Thus, they weren't 100% good and they also were not 100% bad. However, the degree of “badness” that existed was not enough to hang any software but Nox Archaist. At this point I started to get seriously concerned. How many drives actively in use by retrocomputing enthusiasts are semibad drives but their owners don’t know that because the only software that appears to react to the semi-bad state is Nox Archaist, a game not yet released? When people with semi-bad drives had problems with Nox Archaist, would they blame us? If a player had an all-bad drive that ran no software, I figured that was manageable. Everybody who grew up in the 1980s watching the Princess Bride knows what to do then: take apart the drive and look for loose change. But, I was concerned that most people would be skeptical that their drive was the root problem when all software other than Nox Archaist worked fine and disk utilities reported no problems. I would be skeptical myself if I were in their shoes. Standard troubleshooting and the scientific principle of Occam's Razor would point towards Nox Archaist as being the root cause. However, this is one of those rare cases where the simplest explanation was not correct. For two months I worked with the testers and Qkumba, trying to determine how best to proceed. 169
IV. Testing and Release In many ways, Nox Archaist had pushed the Apple II hardware farther than any game before. This included the ProRWTS floppy controller, which increased disk access speed significantly from Steve Wozniak’s original controller written in the late 1970s. In Qkumba’s assessment, the reason why we had problems on the semi-bad drives was because Nox Archaist pushed the disk drive hardware farther than had been done before. In addition, the disk utilities from the 1980s were not written to detect this semi-bad state, likely because it was not causing problems for the developers of the day. The oscilloscope observations from Rikkles seemed to align with Qkumba’s assessment. Once again I found myself in the “situation room” with Chris. There appeared to be no technical path forward. And, even if we explained the situation to affected backers, in the end it wouldn’t really matter that players had semi-bad drives. If those problems were only happening because we pushed the hardware further than games of the 1980s then arguably we pushed the hardware too far for real world conditions and that would be a mistake on our part. A potentially unrecoverable mistake since the game was built around ProRWTS. Going back to the 1979 floppy controller would have required a massive rewrite of the game engine and a redesign of much of the game content. I gave a heads up to Martin Haye and Seth Sternberger of the Lawless Legends project, an Old-West-themed Apple II RPG inspired by Bard’s Tale. Qkumba had set them up with the ProRWTS controller and they were considering releasing their game in the next six months. While all this was unfolding, I noticed that no problems had been reported by backers who had asked us to send them their boxed sets with the beta version of the floppy controller, containing Qkumba’s final bug fix. I developed a theory that maybe semi-bad drives were fairly rare in general circulation. Perhaps the risk was more related to repairing a 100% bad drive with the repair job sometimes resulting in a “mostly good” drive, 170
Floppy Nightmare possibly because the hardware was just too far gone to be fixed. In that case the situation would be manageable: if the semi-bad drives were mostly the result of repair jobs, the incident rate would be low and the folks affected would be of the highest technical caliber and in a good position to address drive issues. I reached out to the backers who had received the beta floppies and asked them if they had seen any issues. As time went by, I got several dozen responses reporting no issues. And, in total, we’d sent out over 100 boxed sets with the beta floppy version. By late January, I felt pretty sure that the “unsuccessful drive repair” theory was correct, and I gave Chris the green light to ship out the remaining boxed sets for the backers who opted to wait for the floppy version to be stable. In the end, the final floppy disk version had some minor tweaks compared to the beta version, but overall the beta version that we had shipped in December was rock solid in terms of crashes or hangs. Months went by and much to the delight of everyone involved, there were nearly zero reports of floppy disk issues. As I’ve mentioned, sometimes this project has felt like a game of chess against the Apple II, sometimes it’s felt like climbing a mountain and at this moment it felt like a game of poker. While there were several very real timing problems that were fixed at the 11th hour, the final issue with semi-bad drives turned out to be a bluff by 40-year-old hardware and we put all our chips on the table and called its bluff. Looking Back A big part of project management is assessing risk. Large projects are a minefield of risk. I knew there was some risk that there would be problems with the floppy version. I certainly underestimated the risk and the options to mitigate the risk were not good which factored into my decisions on priorities. One thing I wonder is what might have happened if I had started a testing group on the floppy version in early June 2020 171
IV. Testing and Release when the game was feature and content complete. As mentioned earlier, I focused on the hard drive version so that if there were problems on the floppy version we could be sure they were floppy related. Accordingly, if floppy testing of the full game had started in June 2020, theoretically we might have discovered the floppy controller issues sooner. On the other hand, we could have been spinning our wheels for months as it wouldn’t have been clear whether the issues were game engine or floppy related. I usually troubleshoot from the top down, so I likely wouldn’t have suspected the floppy controller until exhausting many other possibilities. Looking back on projects and learning from mistakes is important. Clearly, with what I know now, if I could go back and do it over again I’d do something differently. I am still mulling over exactly what that something would be.
172
Release the Kraken!
Release the Kraken!
I
t’s December 12, 2021. The big day had finally arrived—we were ready to party like it’s 1989! And, the excitement in the community had been building for weeks. Preorders started to flood in after Jason Scott of archive.org picked up his megaphone a few days prior and told the retroverse to “HOLD UP.”
Fig. 64. Jason Scott says HOLD UP on news of our release.
173
IV. Testing and Release
The Nox Archaist Discord was hoppin’ as the final countdown ticked down. Jason Scott’s HOLD UP proclamation worked so well, I decided to try it out myself on the Nox Archaist discord server (see Fig. 65).
174
Release the Kraken!
Fig. 65. Countdown to launch!
175
IV. Testing and Release Everything was going great and then I got a DM (direct message) from Qkumba that there was a zero-byte file called SRTN.MERCH on the hard drive image. That was very concerning and immediately made me think I had made a mistake when assembling the final build for release. At this point, I'm in a state that I can only describe as the fog of release, like the game developers equivalent of the fog of war. After doing the countdown on Discord, my focus shifted to making release announcements on social media. Then I jump back into Discord after doing the announcements and there are messages flooding in everywhere. I see Qkumba’s message and I can see there is a whole bunch of chatter in the technical help channel. I skim through the chatter and get a sense that there are some boot issues with physical Apple II hardware and Qkumba and Michael Pohoreski are sorting it out with the players, so I start looking into the zero byte file. A zero byte file on a disk image usually meant that the file wasn't created by the cross-assembler or it didn't get copied by the build process to the folder where the Cadius disk image utility expects it to be. When the utility program can't find a file, it fails silently by creating a zero byte file. It also kicks out an error but it flies by so fast during the build that it is easily missed. That’s why I was initially thinking I made a mistake or this was some goofy build process issue, which was pretty rare. Then I started thinking about SRTN.MERCH, which is where most of the merchant subroutines are located. This has nothing to do with boot up so I assume somewhere in the morass of Discord someone is having trouble with merchants. Before trying to verify the problem, I sent a message to Chris Torrence who had set up the download on our store front. I gave him a heads up that it looks like we might need to do an emergency patch. I was also thinking about the implications of going through the software update process on day one and how we weren't 176
Release the Kraken! quite ready. We had done dozens of updates with the testers and had added an import saved game tool in the main game menu. We even had videos showing the step-by-step process, but the videos were out of date: they didn't show the layout of the final ZIP and DMG files. As a result, the existing videos would direct players to locate files in folders that didn’t exist. Some players would figure it out, while others wouldn't. That was the mess that I was contemplating at that moment. To verify the problem, I tried talking to the food merchant in Everton and didn’t have any issues, which I thought was odd. At this point I jumped into the source code and continued thinking about how to track this down. Then, I got a chat from Chris saying he thought the file had been merged into another file called SRTN.INVENTORY. I'm not sure how he deduced Sidebar by Chris that, but at that point, he was no I did a search through the source doubt thinking more clearly than code for SRTN.MERCH. In a file me. Once he said that I remem- written by Mark called “MY NOTES” bered exactly what had happened I found the following: and my heart rate slowed. (DONE) Player Disk: Merge SRTN. In the end, the zero byte file MERCH into SRTN.INVENTORY was not a problem and I had in fact merged it into a different This seemed highly suspicious and relevant. file. The reason for that is kind of interesting in itself. Nox Archaist takes up four double-sided floppy disks, so eight disk sides at 140 KB per side. Some disks had a fair amount of space free, and some had practically none. It also matters which disk each file is stored on. As my bug fixes occasionally caused the Player disk to overflow, I would free up space by eliminating files. I did this by merging the contents of one file into another, and changing the pointers in the game engine to open the correct file and seek to the correct track and sector position of the merged contents. This freed up disk space because each 177
IV. Testing and Release file has overhead so that the disk controller can determine what track/sector it's located on. Every file I eliminated made the code more confusing but also freed up about 512 bytes of disk space. This was an example of the constant tension between disk space, memory, speed, and code readability. In this case I was reducing code readability to increase disk space. With that crisis averted, I returned my attention to the marketing side of launching Nox Archaist. The next few weeks were a blur as I hopped on any podcast and YouTube channel that would talk to me or unbox the game, including Matt Chat, Metal Jesus Rocks, LGR, The Lost Sectors, Game Wisdom, Spam Spam Spam Humbug, and 8-bit Show & Tell. In a rare endorsement of a game produced in the modern era, CRPG Addict also posted a write-up on Nox Archaist a few weeks after release. Then, several live streams of Nox Archaist started up, two of which streamed the entire game from start to finish: Retro Metal (Lady Ailuros) and The Lost Sectors. Also, much to my surprise and delight, Nox Archaist even caught the attention of the mainstream gaming media. VICE Magazine wrote a nice article and Wired.com invited me to be on their Geek's Guide to the Galaxy podcast, whose previous guests had included many gaming celebrities and John Cleese of Monty Python. I felt very honored, and lucky, to have developed a game that was catching the interest of the wider gaming community. Overall Nox Archaist was well received by players. I received more complimentary emails and Discord messages than I could count and I very much appreciated every one of them. Veteran game developers say “make the game you want to play” and I’m just thrilled that so many other people wanted to play the same kind of game as I did. In 2017, Nox Archaist had been voted the best Ultimainspired game of the year on Ultima Codex (Fig. 66). After release, much to my shock, Nox Archaist was voted #10 in the top 10 best RPGs of 2020 on RPG Codex (Fig. 67). This wasn’t 178
Release the Kraken!
Fig. 66. Best Ultima-inspired game of 2017 on Ultima Codex
Fig. 67. The RPG Codex top 10 best RPGs of 2020.
179
IV. Testing and Release a ranking that was exclusive to retro games. Instead, it was a ranking of all RPGs in 2020, including games like Cyperpunk. From what I understand, the RPG Codex algorithm parses game reports and ratings made by users on the site. The algorithm takes into consideration the positive or negative aspect of the reports, not just how many people are playing a certain game. The data from the game rankings showed that Nox Archaist had overwhelmingly positive feedback from nearly everyone who played it, whereas the other games in the top 10, all modern AAA games, had many more reports from people playing them, but not nearly as much positivity. Amazingly, that was enough to place Nox Archaist in a top 10 slot! The award I was secretly hoping to receive was the Apple II Forever award given each year at KansasFest. Previous recipients included such giants of the Apple II world as Steve Wozniak, Burger Becky and John Romero. Modern day contributors to the Apple II community who receive the award usually have been involved in the community for a long time and contributed through many projects. As a relative newcomer, I didn’t dare to hope very much. However, one day during KansasFest 2021, Peter Neubauer sent me a message asking if I was going to be online Saturday morning at 9AM. He didn’t say why, but I knew Peter was on the KansasFest organizing committee and I knew that the event scheduled for that time was the “Apple II Forever Awards Announcement.” Saturday morning arrived, and Peter announced that the 2021 Apple II Forever Award was being given to “Mark Lemmert and the Nox Archaist Team” (see full quote on the next page). When Peter asked me to say a few words, I did my best to convey the surprise I felt when I got the hint from him the day before. Never one to miss an opportunity for a Monty Python joke, I said “I wouldn't have expected it any less if the Spanish Inquisition had showed up on the Zoom this morning.” 180
Release the Kraken!
“
This one group stood out, not only for their technical accomplishments but their artistic accomplishments and, at least in my mind, the teamwork, the ability of this group to draw together multiple people over multiple years to deliver something that’s greater than any one person could do. It’s always so difficult to take an idea, a hobby project, and turn it into something that’s a success that can be consistently sold….[Nox Archaist is] one of the few examples of an Apple II project that’s gotten attention outside the Apple II community.” —Peter Neubauer, KansasFest 2021
181
IV. Testing and Release There could not have been a better capstone to the Nox Archaist project. Also, Peter’s remark about the difficulty of turning a hobby project into something that can be consistently sold also captured an interesting dynamic that had emerged. Nox Archaist blurred the boundaries between a hobby project and a small business. Mike Reimer and I started it purely as a hobby project with the two of us fooling around with some old computers. But, once it was clear that a lot of people were interested in the game, we started thinking about boxed sets and cloth maps, which led to Kickstarter. The next thing I knew
Fig. 68. Apple II Forever award, KansasFest 2021.
182
Release the Kraken! I had setup an LLC (Limited Liability Company) to house the project and a business bank account. Several people have asked me, in all seriousness, how to build a career developing Apple II games. My advice was: if they wanted to pursue Apple II game development, they should do so with no expectation of making a livable income. For me and my teammates, Nox Archaist has always been and still remains a hobby project. In my case, it was a hobby project that took over my life for a while but for all of us it was always driven by our desire to push the boundaries of Apple II gaming and make the best game possible. In the end, Nox Archaist did generate some profit, which allowed the game to be completed sooner than it otherwise would have been. However, the profit didn’t have any allocation for labor costs. The development team, myself included, were happily making our contributions under profit sharing agreements I set up with everyone at the beginning. At the time, none of us were expecting any profit, but I insisted we do this because in my experience in business, it is important to have a plan for success. Everyone knows what to do when things don’t work out and I’ve seen teams fall apart because they didn’t have a plan for how to share success among themselves. While I think everyone would agree that Nox Archaist is a success, at a scale of thousands of copies a project like this is not viable for providing a full-time income, let alone a team of people. For context, Ultima IV sold over a million copies back in 1985. The market for retro games, while growing, is nowhere near as big as it was in the heyday of these computer platforms. While Nox Archaist was never destined to become a financial blockbuster, it was an extremely rewarding project in many other ways and I am very glad to have done it.
183
IV. Testing and Release Steam and GOG Nox Archaist was the first Apple II game to ever launch on either Steam or GOG.com. However, we did not plan this at all. We were so focused on releasing Nox Archaist on floppy disk and an emulated version for Windows and macOS that we did not give much thought to pursuing a relationship with two of the largest modern distribution platforms. One reason was because I saw Steam as a platform for modern games. I didn’t think many people would buy our game on Steam who wouldn’t have bought it anyway through other means. And, from everything I read, GOG was a curated platform that was pretty difficult to get onto. Nevertheless, after Nox Archaist was released we turned our attention to giving it a shot. Chris Torrence set up a Steam account and worked through the technical issues to get Nox Archaist running in their proprietary environment. At the same time, I worked on the application for GOG.com approval. Luckily, our application managed to get GOG’s attention and they approved us, I suspect due to the novelty of the game and the endorsements of Steve Wozniak and Richard Garriott. Whatever the reasons, we were very excited to accomplish this Apple II “first”! As things turned out, Steam and GOG drew eyeballs onto Nox Archaist that otherwise might not have found the game. This was mostly in a good way, although I still chuckle every time that I log onto the Nox Archaist Steam forum and see the thread: “Why creating this game on the Apple II was a mistake.” Clearly, some people just don’t understand why we made Nox Archaist in the first place.
184
Release the Kraken!
Fig. 69. John Romero’s tweet for our Steam release.
185
IV. Testing and Release
186
The Future
The Future While Nox Archaist looks somewhat different from what I had originally envisioned, the core vision I started with is very much embodied within the game. I also hope that what comes across is the unique character of a game that was developed by someone who understands the entire thing, which has been very rare in game development for decades. While I had help from many people, all of whom made Nox Archaist a better game, there were only a few technical “black boxes” that I didn’t understand at an intimate level. This made it much easier for me to make the game content feel cohesive and also create special game scenarios through targeted game engine customization. It was a lot of fun to see, and really feel, it all come together.
Fig. 70. Gazing into the Nox Archaist crystal ball.
187
IV. Testing and Release Now, looking ahead, many people have asked me if 6502 Workshop will release more games. I don’t know for sure, but I think it is likely that we will. Eventually. In the first year or so after release we’ve been having fun working on less intense complimentary projects like the Book of Hints and this book. Nevertheless, I have occasionally thought it would be fun to develop a “Remaster” of Nox Archaist, along the same lines as the 2017 Bard’s Tale Remaster which introduced modern graphics and sound into the classic game. In addition, I do have a rough outline for an expansion pack and a sequel, so who knows. Perhaps we’ll all meet again in Nox Archaist II: The Quest for More Memory!
188
The Future
V. Team Members
189
V. Team Members
190
Beth “Nox Styx” Daggert
Beth “Nox Styx” Daggert
W
hen Mark first reached out to me in 2015 about creating an Ultima-like game, I was amused. “Here’s another fresh face,” I thought, “let’s see how long this guy lasts.” It wasn’t the first time someone had reached out to me about Apple II coding, or inquired about how to create modern versions of games I’d had an association with in the ’80s or ’90s. But unlike most of those other people that quickly gave up when the going got tough, I discovered Mark was in it for the long haul. He wrote me time and again to bounce ideas, to share his development successes and stumbles, his every communication alive with enthusiasm. It was infectious and I felt something stir in me that I’d long since put to the side. You see, Mark had that same rare combination of passion and grit that once drove me to enter the games industry. Many years before I’d tried and failed as a teenager to create an Ultima V clone on the Apple II, and though I’d gone on to professionally build many other games I’d never returned to that first effort. Mark’s enthusiasm drew me in as like draws like. I volunteered to help in whatever ways I could with the limited time my modern adult life would allow. My contributions came in waves across the years it took to develop Nox Archaist. There were times when I spent regular weekends and evenings, and there were times Mark and I didn’t speak for months on end. From my perspective there were five phases to my efforts. The First Phase was a series of deep discussions of algorithms for darkness (line-of-sight), for NPC pathing, and the like. The Second Phase was about creating 191
V. Team Members game balance, statistical analysis, character classes and more. The Third Phase came when game content began to be created in earnest, in discussions of creating lore to cover for game engine limitations and describing how to unfurl a story over time across a sandbox experience. The Fourth Phase happened when it came time to add content to the manual, filling out spell descriptions, creating conversational Easter eggs and more. If you haven’t yet discovered any of the fun asides in the Nox Archaist manual, I encourage you to look a bit closer. You might, for example, want to ask Nox Styx about WHISKERS or Irene about FIREBALLS. The final Fifth Phase occurred the first time I sat down to play Nox Archaist from beginning to end. I volunteered to be the first “story tester” and take a polish pass through the game. My inexperience with the content put me in the unique position of knowing how the game should mechanically work while allowing me to see flaws in the way stories, puzzles, and progression were set to unfold. My goal was to provide feedback on puzzles and continuity, to create logs of progression to tweak balance through the leveling grind, and to experience the story-breaking bugs so others wouldn’t have to. Diving in that way, I was shocked and surprised when I stumbled across the first Monty Python reference. Was Mark not taking this game seriously? But my shock quickly turned to delight that grew with every subsequent callback and ’80s reference. Somewhere in my journey through Nox Archaist I made my own personal progression; my feelings for the 6502 Workshop team changed from the camaraderie of co-collaborators to a love of truly kindred spirits. One of the unique opportunities in creating a retro-game with the benefit of decades of hindsight is that as creators we can learn from those years of experience. What works to enable players, not punish them? What are modern sensibilities in gameplay, interface, and storytelling that we didn’t have at the time? Could we be informed by those lessons? I thought we 192
Beth “Nox Styx” Daggert could and I believe we were. I am proud that throughout development, I and others advocated continuously that Nox Archaist needed to not recreate the wheel, that it should instead reimagine what the Ultima-style games could have become. There’s only so much one can do on an 8-bit platform with limited memory, but thinking outside the box, challenging the 128K wall (we don’t dare stop at 48K or 64K!), and providing as much breathing room as possible for all the little quality-of-life things paid enormous dividends. As time went on, I was delighted to see that extra effort giving rise to modern features like a quest log, menu systems, advanced UX sensibilities, complex character mechanics, and so much more. In the end I feel humbled and privileged to have been a part of this project. Nox Archaist completed a long-dormant dream for me and gave me a chance to meet some wonderful, crazy people. You now hold the fruits of our efforts in your hands and a whole new generation now has easy access to this classic style of interactive storytelling. I hope it has brought you as much joy as it brought each of us. And oh, by the way, Whiskers made it safely home again. Thank you for playing!
193
V. Team Members
194
Electric Moo
Electric Moo
T
he soundtrack was originally going to be completely separate from the game, to be played on a stereo or computer as accompaniment, as it was not possible to play any music in-game. However the guys working on the Mockingboard emulation did a fantastic job, and it was nice to get some of the soundtrack music into the game itself. I did some beta testing of the game, but I had to refrain from playing it too much, as my primary concern and highest priority was completing the soundtrack! Thinking back over the time I spent working on the music for Nox Archaist, these are some standout memories that come back to me. A dark chilly January night, 2AM. Stomping around a muddy, empty lot, wielding a handheld stereo recorder while wearing hiking boots, to record many of the footfall sound effects for the project. I believe that particular recording ended up at the beginning of Track 2, “Into Town.” I had to do it at night so there wouldn’t be any city noise in the recording; there is a lot more noise during the day, so recording sound effects was mostly a nocturnal activity. Crouched on the north shore of Lake Ontario, propping a stereo microphone down between the rocks, to get wave and water sound effects. And doing my best to avoid boat or airplane noise overhead! A family of raccoons moved into my attic while I was working on the project, so to encourage them to move out I played extremely loud recordings of wolves, coyotes, dogs barking and 195
V. Team Members growling; even some lions and tigers, which are particularly ferocious and must have freaked the raccoons right out of the attic. In fact it worked, and they voluntarily left after a few days of sonic torment. As further revenge, I also put a terrified raccoon in the soundtrack. You can hear it near the beginning of Track 3, “Travelling by Night.” Another fun moment was shuffling around in the basement, rattling chains and grunting to emulate the orcs marching. And then recording the ramshackle band chanting their marching tune. Another time, again recording at 2AM to minimize any outside traffic/neighborhood noise, I was in the basement recording barefoot sound effects on the concrete floor. But the mic was picking up my clothes rubbing as I moved! So I had to strip down and run around naked to get a clean footstep sound. I am glad my neighbors had no idea what I was doing, they’d think I was insane! That ended up in the Track 8 “Underworld” section. The giant was originally going to be an ogre, but I realized a giant would be a more appropriate foe, to wipe out and then subsequently eat the entire party (spoiler alert). It was sheer coincidence that the giant in the game was also located behind a door. When I was playing that part of the game, I thought it was great! I also thought it would be a novel idea to get some of the voices of people who worked on the game into the soundtrack, so I pitched the idea and the team was receptive. Mark contributed the Mysterious Traveller, and the voice on the wind saying “Vazarath.” Jarrod sent some spellcasting, Bill added some spellcasting, as well as a lot of background dialogue. Some other members of his family helped out with dialogue too. The invoked spells all match the Latin wording of the actual spells in the manual. Bucinem Flama even has some audible evil laughter, as mentioned in the spell description. I like paying 196
Electric Moo attention to small details like this, as it helps tie the project together and give some continuity. I tried to add as much game-related banter as possible, so I queried Mark and Bill about story points and comments I could script into the soundtrack dialogue, that made sense with the game. One mistake though: It’s impossible to outrun pirates! Oh well, maybe we can assume the party fought them successfully. Regarding the “Calamari for dinner, mates!” after the sea monster is killed, I found out afterwards that some of the beta testers were also cheering “Calamari!” after defeating them in-game, so that was a fun coincidence. “Into Town” starts on a somber note. A town is a place you often limp back to after adventuring, to heal, rest, and recuperate. It also ties into the game story, with the character climbing out of a shipwreck and swimming to the first town at the start. One thing I am proud of was using a real balalaika that my mother brought home from Russia in 1972. It can be heard during the tavern section, while the itinerant pub musicians are playing. I used as many real instruments as possible, and had access to some pretty cool stuff. There is a list somewhere on my website at electricmoo.com. However, short of kidnapping an entire symphony orchestra and feeding them scraps of food in my basement, I had no alternatives to using sample libraries for the orchestral bits. Another fun moment: The church bells ring for so long before the storm rolls in, someone suggested the bell ringer get hit by lightning, which was a funny gag to throw in! The most challenging thing was recording the singing parts, as I am not a great vocalist. So the Cultist Temple choir was a bit of work, and I spent a substantial amount of time on the shamans too, trying to emulate Tuvan throat singing, with the high harmonics. That didn’t work out though, and eventually I did something completely different. I did add some subtle Moog filter resonance though, as nod to the throat singing. 197
V. Team Members Track 7 “Underworld Prelude” was somewhat inspired by a painting by Arnold Bocklin called “The Isle of the Dead” and associated music by Sergei Rachmaninoff, who was also inspired to write a piece after viewing the artwork. Both the painting and the music portray a dark, ominous mood I was trying to emulate: The characters are heading towards the foreboding Underworld, the Depths of Vacous. As mentioned, due to daytime outside noise, my routine evolved into working all night and sleeping during the day. At 6AM I would head out for a bike ride, to exercise and blow off steam, then shower, and pass out until later that day. Then about 6PM it was back up and continue working on the soundtrack. The soundtrack was a lot of work. Compared to something fairly straightforward like recording a four-piece band, there are countless sound effects and dialogue bits to record and source, then mix and pan, and keep track of. Very time consuming! Plus your ears get numb to things after repeated listening, so it’s easy to miss small details like panning and levels. Luckily I was able to send Mark revisions when I discovered any obvious mistakes. My premise going in was to create mostly ambient background music, generating a mood and atmosphere representative of gameplay but avoiding too many blatant distractions. I assumed players would loop the entire soundtrack, so I tried to segue between pieces with some continuity. It is almost like a journey of sorts. I also wanted enough sonic variety to stand up to repeated listening, so there are a lot of different instruments and musical themes in there. I hope everyone enjoys it. As with the game, it was a real sense of accomplishment to have completed the project. I am proud to be part of the team and also make some new friends in the process! I’m looking forward to meeting the rest of the team in real life, some day at KansasFest.
198
Michael Pohoreski
Michael Pohoreski
D
uring beta testing there was feedback that some QoL (Quality of Life) would be nice for the character inventory and merchant screens. Looking at the initial merchant screen in Fig. 71, there were several issues. Ѽ First, while we had icons for the tabs it wasn’t obvious that the tabs could be selected with the number keys. Ѽ There were no hotkeys to cycle through the tabs. Ѽ Although there were blue lines around the selected tab icon it wasn’t easy to tell which tab was selected at a quick glance. Ѽ The disk icon (6) was incorrectly displayed when talking to a merchant. Mark added the TAB key to forward-cycle through the inventory tabs which solved one of the problems. Unfortunately, the Apple II is physically unable to detect a SHIFT+TAB key combination so we couldn’t use that to cycle backwards. Using another key meant we lost “symmetry.” Being able to cycle backwards was deemed a low-priority QoL feature since it was an uncommon case and the player could either press TAB a few times, or press the corresponding number for the desired tab. This is one of those hard management decisions where there just isn’t enough time to get every QoL into a game before shipping; features have to be prioritized which sometimes means making the reluctant decision to cut it. This is the reason for the pithy saying “games are never done, just abandoned.” This still left the other problems unresolved. Bill Giggie and I decided to spearhead improving this. 199
V. Team Members The best option would be to display a white border around the selected icon tab with a small number below each. These numbers would be 14×5 pixel images centered under the icons (see Fig. 72). The problem of easily identifying what tab was selected still persisted so we started brainstorming borders. After half a dozen revisions the border was thinned on non-selected tab icons so that the selected tab had a wider border, making it easier to tell apart (see Fig. 73). Unfortunately, after talking with Mark and discussing how tight RAM was, there was no room for 14 extra number sprites plus the code to display the unselected and selected icons! Going back to the drawing board we realized we could use the existing font blitter for drawing numbers. After some discussion it was decided that showing numbers with the selected number in inverse might work and would address all the issues. Where to put the numbers though?
Fig. 71. Early version of the inventory screen. It has all seven tab icons but no numbers.
200
Michael Pohoreski
Fig. 72. Inventory window with idealized number locations.
Fig. 73. Brainstorming different icon border ideas.
201
V. Team Members The obvious place would be to draw the numbers in front of the icons, but this meant moving all the icons to the right by seven pixels. However, this caused a palette shift due to the nature of the Apple II’s graphics and even/odd bytes (Fig. 74). The problem was that some tab icons were now orange such as the key and potion. The team agreed that the orange icons didn’t look as good as the “magic” blue ones so I touched up the art to put them back to blue. Yet once again we ran into another problem: the blue key wasn’t centered in the border! Due to the low fidelity of the Apple II hi-res graphics most people would probably never notice this so with reluctance we let it slide, as seen in Fig. 75. You can’t win them all. The numbers on the same line still didn’t look good. Bill asked if the numbers would fit below the icon? There was room, but barely. We shifted the inventory tab icons up so there was only a two-pixel gap at the top but then ran into another problem: the new vertical location for the numbers meant that the glyphs needed to straddle a hi-res 7×8 pixel grid.
Fig. 74. Palette change due to shifting the icon locations.
202
Michael Pohoreski Why was this a problem? During development of Nox Archaist, programmer Qkumba had been constantly optimizing for both performance and size. He had done minor optimizations for font rendering but it was largely untouched from the code Mark originally wrote, which was loosely based on Roger Wagner’s High Resolution Character Generator (HRCG) utility in Assembly Lines. The original HRCG drew a glyph on the graphics screen and then called the ROM to put the character also on the text screen. This meant that characters were aligned to a seven-pixel horizontal grid and an eight-pixel vertical grid (see Fig. 76). This was done for simplicity and speed. Unfortunately, without more work the font blitter couldn’t handle the special case of straddling the vertical eight-pixel grid. This meant more code for which we didn’t have room. To explain why glyphs are naturally aligned to an imaginary 7×8 pixel cell we need to examine how the Apple II’s screen uses RAM.
Fig. 75. The key and potion are blue again but the key is offset.
203
V. Team Members The HGR screen is 280 pixels across with 40 bytes per scanline. The high bit of each byte is a palette flag for every seven pixels: Ѽ Off = Odd pixels are magenta, even pixels green. Ѽ On = Odd pixels are blue, even pixels orange. The bottom seven bits turn those seven pixels on or off. Normally, when you have a two-dimensional array each row is sequentially after the previous one. Unfortunately, on the Apple II while a single scan line is contiguous in memory the vertical scan lines are not. This is due to Woz’s clever design to minimize the amount of RAM needed for text and graphics. Worse, video memory is interleaved into three banks which are further subdivided. A hi-res screen of 280×192 pixels with six colors uses only 8192 bytes of RAM. There are two graphics pages which can provide smooth animation with page flipping. The hi-res page 1 uses RAM from address $2000–$3FFF and it has the memory layout given in the following table.
Fig. 76. The 7×8 pixel cells on the Apple II’s hi-res screen.
204
Michael Pohoreski
Y Address
Y
Address
Y
0
Address Screen Holes
$2000
64
$2028
128
1
$2400
65
$2428
129
$2450
$2478–$7F
2
66 ⋮
$2828 ⋮
130
⋮
$2800 ⋮
⋮
$2850 ⋮
$2878–$7F ⋮
7
$2050
$2078–$7F
$3C00
71
$3C28
135
$3C50
$3C78–$7F
8
$2080
72
$20A8
136
$20D0
$20F8–$FF
9
$2480
73
$24A8
137
$24D0
$24F8–$FF
⋮
$28A8 ⋮
138
⋮
$2880 ⋮
74
⋮
$28D0 ⋮
$28F8–$FF ⋮
15
$3C80
79
$3CA8
143
$3CD0
$3CF8–$FF
16
$2100
80
$2128
144
$2150
$2178–$7F
⋮
$2528 ⋮
145
⋮
$2500 ⋮
81
⋮
$2550 ⋮
$2578–$7F ⋮
63
$3F80
127
$3FA8
191
$3FD0
$3FF8–$FF
10
17
Believe it or not there is actually a pattern to this: Ѽ Within a group of 8 scan lines every time we move down one scan line we add $400 to our 16-bit address. Ѽ Crossing an 8-scan-line gap we need to add $80. Ѽ Finally every 64 scan lines we need to add $28. The formula for converting a row into an address is: HGR = 8192 + 40×(y ∕ 64) + 1024×(y % 8) + 128×((y ⁄ 8) & 7) where & is the bitwise AND operator, ⁄ is integer division, and % is integer modulus. In short, a font blitter is basically a glorified memory copy. It copies a glyph contiguous in RAM from a source address to the noncontiguous HGR framebuffer (the destination addresses). For example if we have a glyph of 7×8 pixels from $6000–$6007 and we want to draw it to raster location (0, 0), the resulting addresses would be $2000, $2400, $2800, $2C00, $3000, $3400, $3800, $3C00. 205
V. Team Members Now the problem is the original HRCG font blitter always drew eight scan lines by adding multiples of $400 to the destination address of the first row. This worked fine when our glyphs were vertically aligned inside a 7×8 cell but didn’t work for our new glyphs which needed to cross a vertical cell boundary. The New Font Blitter I noticed that the $300–$3FF section of RAM (256 bytes), where the font blitter lived, was mostly free. Excited at the prospect of spare memory I started optimizing code. One of the features left over from the original HRCG utility was that the font blitter would draw the glyph on the HGR screen and then chain to the ROM COUT function ($FDF0) to also put a character on the text screen (see Fig. 77). Since we didn’t need to draw to the text screen, I removed this ROM call in order to free up the 1024 bytes from $400–$7FF. Unfortunately this caused the game to crash. Whenever Nox Archaist crashed it would turn off the font blitter and dump some debug information to the screen to show
Fig. 77. Early versions drew on both graphics and text screens.
206
Michael Pohoreski the location. It turned out that due to a missing return (RTS) instruction, the function to turn off the font blitter and restore normal text output was incorrectly “falling through” to the function below it, which just happened to be code that turned the font blitter back on! This was a good reminder to always exercise and verify complete code coverage. The next optimization was removing a ROM call to VTAB ($FC22) that would calculate the HGR Y address when a character was printed. Since this call was in the upper 16K, which was banked between RAM and ROM, there was additional code to save the read/write status of RAM. With the ROM call removed the code to deal with the bank switching shenanigans could also be removed, speeding up the text rendering even further. Unfortunately this change required that our code now needed to calculate the HGR Y addresses corresponding to the 24 lines of text. Optimizing code on the 6502 is always a balance between speed vs. size. The good news is that we only needed to store a lookup table for 24 HGR rows, not all 192. The 16-bit addresses doubled this but there was enough room to squeeze in the 48 bytes for our mini HGR Y-lookup table. You can see the 24 table entries in the code on p. 215. Another complication was that the character inventory screen could be displayed from three states: Ѽ In combat Ѽ Out of combat, not talking to a merchant Ѽ Out of combat, talking to a merchant Due to the limited memory the game doesn’t keep the code to talk to a merchant in RAM, instead it loads it on demand. As a result, in early versions there were three different functions that duplicated drawing the icons. Part of the reason for that is because when the player is in the merchant screen the character tab icons 1 and 6 are not supposed to be visible. At the beginning of the project it was simpler for Mark to just have each function be responsible for drawing what it needed. 207
V. Team Members Some of the rules of thumb of programming are to (1) get a reference version working, and (2) DRY (don’t repeat yourself ). This allows for smaller code, plus when a bug is fixed you don’t have to duplicate the fix. Due to the huge scope of the project Mark didn’t have time to do DRY cleanup for the merchant and character inventory screens; the team was just too busy creating content. Instead, I ended up refactoring the duplicate code by moving it to the font blitter code in low memory. Since the number of icons was dynamic I used a bitmask to select which ones were visible. Other cleanups in the code included: Ѽ An array of seven pointers to the inventory tab icons was created. Ѽ An array of seven columns for the inventory tab icons was created. Ѽ Six out of the seven inventory tab icons were reorganized to be contiguous in memory. This didn’t affect performance but improved source code navigation.
Fig. 78. Final version of the merchant inventory screen.
208
Michael Pohoreski Originally all the inventory tab column locations were hard coded, which required touching up code in three places if the locations needed to be tweaked. By putting the data in a table, something called a data-driven approach, it made it trivial to make changes because only one location had to be changed for all three screens. The font optimization code still had one last bug. The ROM used the last few bytes of page 3 (at $3FD) to determine where the 6502 should temporarily jump to when an interrupt was triggered. For Nox Archaist, the Mockingboard sound card used those interrupts to request the next notes for the currently playing song. Thankfully, it was easy to tell the assembler to print out an error when our font optimization code spilled over into the IRQ vector location. After a bit more optimization everything fit (again). How many spare bytes did we end up having left over in page three? Zero. It isn’t just a joke that we say Nox Archaist used every bit of spare RAM that it could!
209
V. Team Members ; FINAL FONT BLITTER CODE ; ============================================ ; Copyright (C) 2016-2020. 6502 Workshop, LLC ; ============================================ ;CUSTOM CONTROLLER FOR HI-RES CHARACTER GENERATION .TF CONT.HRCG.BIN,BIN .OR $300 ;LOCAL VARIABLES @START BASL .EQ $28 ;*contains the LO/HO address of the text screen line associated with VTAB. Updated by UPDATE.CHAR.POS. ADDRESS. See page 302 in Assemblylines cookbook for a chart with the memory address for each line of the text screen. CH .EQ $24 ;*Applesoft is one-based. Equal to HTAB-1 @END COUT.LOAD.ADDRESS ;============================ ; Common setup code to draw a partial glyph ; ON ENTRY: ; A = Last scanline in glyph to draw (normally 8) ; X = HGR Y address Hi ; Y = HGR Y address Lo ; NOTE: ; It is also possible to set the first scanline in the glyph to ; draw, which normally is 0, via setting COUT.CUSTOM.TOP_SCANLINE+1 ; prior to calling us. ;============================ COUT.DRAW.PARTIAL STA COUT.CUSTOM.BOT_SCANLINE+1 STY BASL STX BASL+1 ;**FALLS THROUGH** COUT.CUSTOM.USE.HTAB LDX HTAB ;**FALLS THROUGH** ;============================ ; ON ENTRY: ; X = HTAB or CH ($25) ; HRCG.BUFFER = 8 bytes of font glyph to draw ; HRCG.PAGES ; 1 = Draw only on HGR Page 1 ; 2 = Draw only on HGR Page 2 ; 3 = Draw on both HGR Pages 1 and 2
210
Michael Pohoreski ; ; ; ; ; ; ; ; ; ;
COUT_CHAR_TYPE = normal or inverse BAS = HGR Page 1 Y address ON EXIT: A = ?? X = HTAB (no change) Y = last scanline (normally 08) C = 1 NOTES: This does NOT increment the cursor X position due to needing support for drawing “half” glyphs. That functionality was moved to COUT. ; ALSO, this function supports any number of scanlines in a glyph ; LDA #0 ; STA COUT.CUSTOM.TOP_SCANLINE+1 ; LDA #8 ; STA COUT.CUSTOM.BOT_SCANLINE+1 ; Called from: ; File: Routines_Text.asm ; Func: COUT ;============================ COUT.CUSTOM LDA #$9D ; OPCODE: STA $abs,X LDY #$2C ; OPCODE: BIT $abc STA SCRNX1 STA SCRNX2
; Default to common case: write to both pages
LDA HRCG.PAGES ROR ; BCS .COUT.PAGE1 STY SCRNX1 ; .COUT.PAGE1 ROR ; BCS .COUT.PAGE2 STY SCRNX2 ; .COUT.PAGE2
If C=0 only draw on page 2? *** SELF-MODIFIES! If c=0 only draw on page 1? *** SELF-MODIFIES!
COUT.CUSTOM.TOP_SCANLINE LDY #$00 ; *** SELF-MODIFIED! copy 8 scanlines from glyph LDA BASL STA SCRNX1+$1 ;PAGE1 STA SCRNX2+$1 ;PAGE2 LDA BASL+1
211
V. Team Members CLC COUT.NEXT.SCANLINE STA SCRNX1+$2 ;SCRN = BASL, X = HTAB, DST = SCRN+X ADC #$20 STA SCRNX2+$2 ;PAGE2 LDA HRCG.BUFFER,Y EOR COUT_CHAR_TYPE ;($00 = normal, $7F = inverse) SCRNX1 STA $1234,X ; draw page 1 *** SELF-MODIFIED SCRNX2 STA $1234,X ; draw page 2 *** SELF-MODIFIED INY LDA SCRNX1+$2 ; Move to next start of scanline address COUT.CUSTOM.INCR_HI ADC #$04 ; This ONLY works if the VERY FIRST scanline is a multiple of 8 COUT.CUSTOM.BOT_SCANLINE CPY #HRCG.SHAPE.SIZE+1 ; *** SELF-MODIFIED! See NOTE for why +1 is needed BCC COUT.NEXT.SCANLINE RTS ;============================ ; ON ENTRY: ; A = Bitflag: which menu icons & numbers to draw (e.g.%00111111) ; Menu: -7654321 ; Bits: 76543210 ; ON EXIT: ; A = 00 ; X = ?? ; Y = ?? ; Called from: ; * SWAP.ROUTINES.INV.entrance_exit.asm ; * Combat.stats_summary.ASM ;============================ INV.DRAW.MENU_ICONS_NUMS @START LDX #0 .DRAW.MENU_ICONS.NEXT LSR ; any more icons to draw? PHA BCC .DRAW.MENU_ICONS.SKIP JSR INV.DRAW.MENU.NUMBER.X ; returns Y=column of menu number INY STY SCREEN.DRAW.CURRENT_BYTE LDA INV.MENU_ICONS.POINTER.LO,X
212
Michael Pohoreski STA LDA STA JSR
SHAPE+$0 INV.MENU_ICONS.POINTER.HI,X SHAPE+$1 INV.DRAW.MENU.ICON
.DRAW.MENU_ICONS.SKIP INX PLA BNE .DRAW.MENU_ICONS.NEXT RTS ; caller: INV.DRAW_ERASE.INVENTORY_WINDOW @END ;============================ ; ON ENTRY: ; A = 0 .. 6 inventory menu number to draw ; C = 0 draw normal ; C = 1 draw inverse ; HRCG.BUFFER ; ON EXIT: ; A = 0 .. 6 inventory menu number to draw ; X = 0 .. 6 inventory menu number to draw ; Y = column of number before icon ;============================ INV.DRAW.MENU.ACTIVE.NUM @START TAX LDY #0 BCC .INV.DRAW.MENU.ACTIVE.NUM LDY #$7F .INV.DRAW.MENU.ACTIVE.NUM STY COUT_CHAR_TYPE ;**FALLS THROUGH** ; -------------------; NOTE: ALSO called by INV.DRAW.MENU_ICONS_NUMS ! ; -------------------INV.DRAW.MENU.NUMBER.X LDY INV.MENU_ICONS.COLUMNS,X STY HTAB TXA PHA
CLC ADC #’1’
; convert $00->‘1’ human readable, HIGH ASCII
213
V. Team Members JSR COUT.GET.GLYPH TYA PHA ; Top half of glyph LDX #$31 ; HARD-CODED to HGR Y = $14, addr = $3100 LDY #$00 LDA #4 ; Last scanline of glyph is 4 JSR COUT.DRAW.PARTIAL ; Bottom half of glyph LDA #4 ; First scanline of glyph is 4 STA COUT.CUSTOM.TOP_SCANLINE+1 LDX LDY LDA JSR
#$21 ; HARD-CODED to HGR Y=$18, addr=$2180 #$80 #8 ; Last scanline of glyph is 8 COUT.DRAW.PARTIAL
; Restore drawing full glyph LDA #0 ; We don’t need to restore bottom since STA COUT.CUSTOM.TOP_SCANLINE+1 ; it was done above STA COUT_CHAR_TYPE ; Turn off INVERSE if it was set
PLA TAX RTS
PLA TAY
@END
; These are the HGR column offsets the icons are drawn ;MENU ICONS INV.MENU_ICONS.COLUMNS .DB $01 ; 0 Note: Tempting to put this in code .DB $04 ; 1 since every entry except for the last one .DB $07 ; 2 has a constant delta +3 BUT there is .DB $0A ; 3 less code to just use a simple table .DB $0D ; 4 .DB $10 ; 5 .DB $1C ; 6 ; 0-5 misc.main_memory_only.asm ; 6 swap.routines.inv.merchant_transactions.asm INV.MENU_ICONS.POINTER.LO .DA #MENU_ICON0.STATS ; 0 .DA #MENU_ICON1.WEAPONS ; 1
214
Michael Pohoreski .DA .DA .DA .DA .DA
#MENU_ICON2.ARMOR #MENU_ICON3.MISC_ITEMS #MENU_ICON4.SPELLS #MENU_ICON5.GAME_SETTINGS #MENU_ICON7.MERCHANT_INV
; ; ; ; ;
2 3 4 5 6
INV.MENU_ICONS.POINTER.HI .DA /MENU_ICON0.STATS .DA /MENU_ICON1.WEAPONS .DA /MENU_ICON2.ARMOR .DA /MENU_ICON3.MISC_ITEMS .DA /MENU_ICON4.SPELLS .DA /MENU_ICON5.GAME_SETTINGS .DA /MENU_ICON7.MERCHANT_INV
; ; ; ; ; ; ;
0 1 2 3 4 5 6
; Text Row HGR Y Text Row ; $0400 0 $2000 0 $0428 8 ; $0480 1 $2080 8 $04A8 9 ; $0500 2 $2100 16 $0528 10 ; $0580 3 $2180 24 $05A8 11 ; $0600 4 $2200 32 $0628 12 ; $0680 5 $2280 40 $06A8 13 ; $0700 6 $2300 48 $0728 14 ; $0780 7 $2380 56 $07A8 15 ; TEXT_TO_HGR_Y.LO ; 0 1 2 3 4 5 6 7 .HS 00.80.00.80.00.80.00.80 .HS 28.A8.28.A8.28.A8.28.A8 .HS 50.D0.50.D0.50.D0.50.D0
HGR $2028 $20A8 $2128 $21A8 $2228 $22A8 $2328 $23A8
Y 64 72 80 88 96 104 112 120
Text $0450 $04D0 $0550 $05D0 $0650 $06D0 $0750 $07D0
Row 16 17 18 19 20 21 22 23
HGR $2050 $20D0 $2150 $21D0 $2250 $22D0 $2350 $23D0
Y 128 136 144 152 160 168 176 184
; Fixed COUT.CUSTOM & WRAPPER.UPDATE.CHAR.POS to not use VTAB $FC22 ; which normally sets BAS to point to the text screen. ; By pointing to HGR Page 1 we can remove the ADC #$1C to convert ; a TEXT address into an HGR address. TEXT_TO_HGR_Y.HI ; 0 1 2 3 4 5 6 7 .HS 20.20.21.21.22.22.23.23 .HS 20.20.21.21.22.22.23.23 .HS 20.20.21.21.22.22.23.23 CONT.HRCG.END .DO CONT.HRCG.END>$3EF .ER F,*** Font blitter spills into IRQ vector!!! .FI
215
V. Team Members Even if you are not familiar with 6502 assembly code, one thing you may notice is the multiple levels of indentation. A lot of algorithms tend to do operations in pairs. For example, push a register onto a stack, do some operations with that register, then pop that register. By manually indenting code sections it becomes easier to see if you missed one of the corresponding “dual” operations. It is always risky optimizing code at the 11th hour. When the game is getting dangerously close to shipping, every code change, no matter how tiny, can introduce new bugs. However, looking back at the last-minute changes that made it into the final game: Ѽ Text rendering was faster, with tests showing a 30% speedup. Ѽ We freed up 1K of RAM (which of course got promptly used). Ѽ The font blitter could draw the top or bottom half of a glyph. Ѽ We discovered several bugs in non-rendering code. Ѽ The new code had a hi-res Y mini-lookup table. Ѽ We removed duplicate code to draw the tab icons and replaced it with a single table of column offsets. Ѽ The new code displayed numbers for the character and merchant inventory screens. I would say it worked out rather nicely. Not a bad day “at the office.”
216
Chris Torrence
Chris Torrence
M
y involvement in Nox Archaist started relatively late in the project, when I met Mark Lemmert at KansasFest in July 2017. By that point, development of the game engine was well along, and the in-game artwork, although not finished, was in a recognizable state. I had always been a fan of computer role-playing games (CRPGs), from way back in 1982 when I purchased the original Wizardry game by Sir-Tech Software. Looking at the current state of Nox Archaist during Mark’s KansasFest presentation, I realized that this was the game I had been waiting for. It evoked the old-school feeling of CRPGs from the 1980s but removed much of the tedium and also added modern user-interface elements. After seeing Mark’s presentation, I really wanted the Nox Archaist project to succeed. Mark clearly knew what he was doing, both in programming and project management. He had gathered a top-notch team of artists, developers, and musicians, and he was well on his way to launching on Kickstarter. Nevertheless, as the first Kickstarter progressed, it seemed like there were a few areas where I could contribute. A few years earlier, I had worked with Roger Wagner on Assembly Lines: The Complete Book. The book included all of the articles on assembly language programming from Assembly Lines Volume 1 (1982), along with the remaining articles from the unpublished Volume 2. During that project, I realized that my passion was not only for the material itself, but also for bringing the work to a highly polished state, and creating a physical 217
V. Team Members product for the community. Maybe I could play a similar role with Nox Archaist. I began working with Mark on the second Kickstarter. One of the concerns from the first Kickstarter was the price of the boxed and collector’s sets. These prices were all based upon reasonable estimates that Mark and Mike had made for the production of boxes, manuals, cloth maps, and the other items. With Mark’s blessing, I began research on all of these items, and, after crunching the numbers, we realized that we would be able to achieve the same or higher quality at a much lower price. The lower production costs also meant that we could have a much lower Kickstarter goal. The second Kickstarter, in May 2019, was a resounding success. We reached our $8500 goal within two hours of launch, and finished the campaign with $42 323 and 566 backers. Now the real work could begin: finishing the game and creating all of the physical reward items. By then, Mark had the game engine mostly complete and was working on creating the story and content. Mark asked if I wanted to work on the dialogue, including the characters in the Apple II Reunion Party. These included Steve Wozniak, Roger Wagner, John Romero, Burger Becky, and many others. Mark had rough ideas for what he wanted each person to say, but left most of the details up to me. I also got to have fun creating the nonsense book titles for the bookshelves in Nox Archaist, as well as the dialogue for some minor characters. My two favorite creations were Lady Susan and Sir Edgar, in Uharad Castle (see Fig. 79). There was just something compelling about Lady Susan’s ambivalence towards Sir Edgar, and his sad, unrequited love. That minor subplot has no impact on the overall story, but was very satisfying to write. In between writing the dialogue, I continued work on the physical reward items. Some of them were straightforward to make. Gordon Mackay had already created the artwork for the 218
Chris Torrence
Fig. 79. Sir Edgar and Lady Susan, of Uharad Castle. Will he win her love? Will she finish her book?
game box and map, and these just needed to be laid out on a template and mass produced. The crown jewel artifact was an off-the-shelf product, while the USB stick was produced by a company specializing in trade-show giveaways. Although the disk labels were simple to design, we needed to wait until the last moment in case the files needed to be rearranged. We had hoped to ship the game with 6502 Workshop disk sleeves. Unfortunately, the technology to mass produce disk sleeves was long gone and the quotes we received from the printer were prohibitively expensive. It might have been possible to use a custom rubber stamp, but the thought of copying and labeling 1600 floppy disks was daunting enough without adding 219
V. Team Members in the complexity of stamping the sleeves. We decided to go with the simplicity and understatement of plain white disk sleeves. For the Coin of the Realm, Mark and Mike had concluded that a custom coin was too expensive and were looking into buying generic fantasy-looking metal coins. I did some more research, and realized that while custom fantasy coins were unusual and expensive, custom challenge coins were common and cheap. But what about the design? Serendipitously, my brother-in-law had just sent me a photo of a coin he had seen in the Münzkabinett coin collection at the Bode Museum in Berlin. The coin (Bode Museum #18204699; Fig. 80) featured a medieval monarch in a sailing ship, and was a perfect symbol for Queen Isa’s island realm. My daughter Elyssa had just done some artwork for the Nox Archaist manual, and I asked her to try her hand at the coin. Her sketch ended up becoming the design for both the Coin of the Realm and Queen Isa’s wax seal. That left only the game manual, which was by far the most complex and time-consuming piece of the physical items. Mark had a rough outline, and Beth had written some brilliant spell and monster descriptions. We also had a few pieces of blackand-white artwork by Gordon Mackay. Mark had originally envisioned one or two small, staple-bound books, similar to the rule books within the original Ultima series. To me, it felt like Nox Archaist was a big game that deserved a large, fully-illustrated manual.
Fig. 80. Edward III and the final Coin of the Realm.
220
Chris Torrence
Fig. 81. Nox Archaist manual. Cover art by Denis Loubet.
One of the stretch goals for the Kickstarter was a full-color digital piece by Denis Loubet, the fantasy artist who had done the original covers for some of the earliest Ultima games. That took care of the cover for the manual. The rest of the Kickstarter funds were earmarked for the production of physical rewards; we didn’t have money for salaries or additional art commissions. Luckily, a few of the backers had expressed an interest in creating artwork. After we put out a call for artists in one of our monthly backer updates, the sketches started flowing in. On Nov 12, 2020, we put in an order for almost 600 copies of the Nox Archaist manual. The 125-page manual had 37 pieces of artwork by seven different artists, and contained 39 spells and 80 monster descriptions. By the end of November 2020, all of the reward items were stashed in my basement, ready to ship. All we needed were the bits themselves. Mark has detailed the issues we ran into with the floppy disk builds. In the end, for me it turned into a blessing in disguise. Since the pandemic had prevented the team from getting together to fulfill the orders, I was faced with the daunting task of duplicating 1600 double-sided floppy disks and assembling 221
V. Team Members all of the boxes. By breaking up the Kickstarter backers into two groups (those who wanted the beta floppies early, and those willing to wait), it also divided my job into two smaller pieces. We shipped the early-adopter group in December and the remainder after the New Year. By March 2021, all of the Kickstarter rewards had been shipped. Today, our work continues on Nox Archaist. Since the beginning of 2021, we’ve done two more runs of physical items, launched the game on Steam and GOG, launched an online merchandise store, and published an official Book of Hints. There are rumors of ports to different platforms and maybe even a sequel. I’m excited to be part of the project, and looking forward to whatever comes next for Nox Archaist and 6502 Workshop.
Fig. 82. Box #1 off the assembly line, sent to Richard Garriott.
222
Chris Torrence
VI. Appendix
223
VI. Appendix
224
Tech Talk
Tech Talk
C
learly this book was more focused on telling the story of developing Nox Archaist than as an instructional book on coding a retro CRPG. The latter is a whole other book that perhaps could be called “Beneath Nox Archaist: Coding an 8-bit RPG.” If you’d be interested in a book like that, and are still awake reading this one, please send me an email at [email protected]. In the meantime, this chapter provides a bit more technical discussion.
Nox Archaist Technical Overview Nox Archaist is written 100% in 6502 assembly language. It runs on the “bare metal,” which means that the game does not load an operating system like DOS 3.3 or ProDOS. Nox Archaist uses a bootloader and ProRWTS to load the game engine into memory and then transfer controls to the engine. The splash screen uses double hi-res graphics, 5-bit pulse width modulated speech, and Mockingboard music. The game itself uses hi-res graphics, the Mockingboard, and regular Apple II speaker sounds. Most of the Mockingboard pieces were composed using Bank Street Music Writer. (see p. 75). The in-game graphics and maps were created with a custom pixel editor using Excel spreadsheets. The splash screen involved Adobe Photoshop, the Lawless Legends image converter, the Buckshot Apple II image converter, and the 816 Paint program. 225
VI. Appendix Map Architecture The Overworld map data is stored compressed on disk using the ZX7 algorithm. This map is 256×256 tiles, divided into 256 zones of 16×16 tiles each. The Underworld maps all use the same architecture as the Overworld map. There is no overlap of tiles between zones. Instead, to ensure that the map scrolls smoothly, a “regional” map is stored in memory which consists of nine zones (nine 16×16 tiles, or $900 bytes). When the player nears the edge of a regional map, the zones in memory are scrolled and new zones are loaded from disk and uncompressed into memory. The main view screen is 11×17 tiles, stored in a “screen array” in memory ($BB bytes). As the player moves, tile data is copied from the regional map array into the screen array. Graphics Rendering The first time the screen is drawn, the tile set is stored in the lower 48K of auxiliary (AUX) memory. The graphics engine parses the screen array and, based on the tile ID, calculates an offset and copies the tile bitmaps from AUX memory into the background HGR page. The background HGR page is flipped to the foreground and the map is then visible. When the character moves, the tile bitmap data in video memory is scrolled via a memory copy. The edge row or column in the direction of movement is drawn by parsing the screen array and copying the tile bitmaps from AUX memory. This is the same process as the first screen draw, but with much fewer tiles. For animating the tiles, the first step is to increment the animation frame counter. Next, we parse the screen array. For animated tiles (the tile ID has the high bit set), we use the frame counter as part of an offset calculation to the tile bitmap data in AUX and copy the bitmap to the background HGR page. When the screen array parse is done, we flip the background HGR page to the foreground and the animation updates. 226
Tech Talk There is also code that counts the number of animated tiles on the screen and adjusts a delay loop. For example, if the player is near the ocean with lots of waves, the animation speed is roughly the same as for standing in the forest. The animation routine also contains a recursive subroutine, called by NPC.TALK, which keeps the animation running on the map while waiting for the player to press a key. Screen Scrolling Compared to 8-bit RPGs from the 1980s, Nox Archaist has the largest map viewport that we know of. Getting the graphics to render fast enough with an 11×17 tile viewport was challenging. One of the key design elements to achieve this rendering speed was only drawing the entire screen once. The screen is not fully redrawn until the player enters a new map or they open a pop-up window such as the inventory or NPC dialog. When the player moves on the map, only one row or column of new tiles is drawn. The rest of the tiles are scrolled by copying their data in video memory to the addresses associated with the updated screen position. Scrolling the graphics with a video memory copy is much faster than drawing each tile individually. Within the copy routine, I used self-modifying code at the bottom of the nested loops, reducing the number of CPU clock-cycles during the video copy by over 50%. Self-modifying code is code that alters its own instructions while executing. This is possible in assembly language because instructions are just values in memory and there are no protected areas of memory like in higher-level languages. As a result, an assembly language program can simply alter the values of memory (and hence instructions) on the fly. Rather than using an indirect lookup to load and write the shape values, we can save a couple of clock cycles per loop iteration to modify the instructions in memory. The loop is run so many times that saving two clock cycles adds up to hundreds 227
VI. Appendix of thousands of clock cycles per player move. This is all in the context of a CPU that can only process a million clock cycles per second. It’s a race to update the screen before enough time goes by that the human eye notices a significant lag. Of course, we’re talking about a 1980s human eye. Everything about retro games looks slow to a human eye conditioned by modern gaming. Non-Player Characters The NPC dialogue text is stored compressed on disk using a ZX7 compression algorithm. When the player talks to an NPC then the text is uncompressed into a buffer just for that NPC. The dialogue text contains scripting codes for an interpreted high-level language I wrote called Nox Talk. For context, Applesoft BASIC is another interpreted high-level language for the 6502. Nox Talk is smaller in scope and is dedicated to bringing conversations with NPCs to life. The Nox Talk language provides a variety of capabilities such as text restricted by time, text restricted by state flag, text which pushes values to state-flags, and text restricted by voice mode. As an example, the Town Elders at Ol’ Rev’s Tomb in Ghrodwir use the time-restricted feature so that the dialogue is different when they are standing in front of the tomb versus when they are standing in the town hall. The state-flag features were used extensively to adapt dialogue based on events that already occurred in the game. For example, for a multi-part “fetch” quest (such as the Nox Vortex spell quest), this was how NPCs knew what parts of the quest the player had completed. NPC schedules were used for NPC movement between areas of the map, which I called anchor locations. For example, each NPC has anchor locations for sleeping, working, eating, and sometimes one additional location. The NPC schedules were 228
Tech Talk also used to get the Town Elders to show up at Ol’ Rev’s Tomb in the middle of the night. They weren’t happy about this! I wrote the Nox A* algorithm to calculate the path on the tile grid from the NPC’s current anchor location and their destination anchor location. A* didn’t become prevalent in games until the 1990s and, as far as I know, Nox A* is the only A*-based algorithm in a commercial Apple II game. Nox A* is very processor and memory intensive so I set it up to calculate paths in the background a few game hours in advance of when they are needed. However, if a player holds down the movement key, the calculations are skipped. Accordingly, if you hold down on the movement key long enough you might catch an NPC in a location they aren’t supposed to be (like in their shop past closing). Additionally, if the player enters a town a few minutes before the changing of the hour, the game might not have enough time to calculate the paths needed for any NPCs scheduled to move during that hour change. I decided that this behavior was a feature, as it introduced the appearance of some randomness to NPC activities. Resources Nox Archaist was written using many tools, most notably: Ѽ SBASM: cross-assembler for 6502 code Ѽ Notepad++: code editor Ѽ Cadius and Apple Commander: floppy disk image creation Ѽ Ciderpress: floppy disk image manipulation Ѽ Virtual ][: Apple II emulator with debugger (Mac) Ѽ AppleWin: Apple II emulator with debugger (Windows) Ѽ MicroM8: Apple II emulator with debugger (cross-platform) Ѽ Microsoft Excel Ѽ Microsoft OneNote Ѽ Google Docs Ѽ Github 229
VI. Appendix References My starting point for learning 6502 assembly language was Using 6502 Assembly Language by Randy Hyde. I also used the following books for general reference and a few specific topics: Ѽ Assembly Lines: The Complete Book, by Roger Wagner, edited by Chris Torrence Ѽ Hi-Res Graphics and Animation Using Assembly Language by Leonard Malkin Ѽ Apple II User’s Guide by Lon Poole Ѽ Apple Graphics & Arcade Game Design by Jeffrey Stanton Additionally, I spent a lot of time spelunking in old news groups and posting questions in the comp.sys.apple2 forum.
230
Acknowledgements
Acknowledgements
M
any thanks to the 6502 Workshop team: Mike Reimer, Bill Giggie, Robert Padovan, Gordon Mackay, Electric Moo, Peter Ferrie (Qkumba), Elizabeth Daggert, Jarrod Kailef, Michael Pohoreski, and Chris Torrence. Special thanks to our community contributors: April and Melody Ayres-Griffiths, Eric Rangell, Tom Porter, Kris Kennaway, Alan Yee, Denis Loubet, Jose Argibay, Nick Gazzarari, Robert Gomez, Tony Rowe, Elyssa Torrence, and Eddie Haskell. Thanks also to our level 10 party of beta testers: Henri & Liam Asseily, Arnaud “Harcolas” Colette, Dominik Douville-Bélanger, Fahed, Bradley A. Hooker, Tobias Hübner, Bert Isla, Bill Lange, Forrest Lowe, Bill Martens, Daniel McTyre, Ryan Musante, Andrew Schultz, Joseph Seeley the Greater, Joseph Seeley the Lesser, Lord Dave Slotter, John Stallings, Joseph Stallings, John Talent, Nick Walton, and Andre Zadrazil. And, last but not least, thank you to the entire Apple II community and the retro-gaming community at large. Your enthusiasm and support kept us going during the dark days of a failed Kickstarter and floppy disk woes, and enabled us to achieve our goal of developing a modern evolution of the Apple II RPG genre, while exploring how gameplay might have advanced on the Apple II platform. We’d love to hear what you think of this book and Nox Archaist! Email us at [email protected] and join our Discord server at http://discord.noxarchaist.com.
231
Index Symbols 4AM 51 65c02 processor 147 816 Paint 225 6502 Workshop xix, 7, 43, 58, 192 65816 processor 147 A A* algorithm 59, 191, 229 Act II climax 97 AIIEE emulator 124 alpha testing 89, 97, 101, 105, 143 America Online 147 animation 111, 226 ankh 118 AppleFest xv Apple II+ 3 Apple IIc 146 Apple IIe 9, 53, 146 Apple II Forever Award 180 Apple IIGS 125, 146 Applesoft BASIC 3, 6, 27, 228 AppleWin emulator 88, 145, 158, 165, 229 archaist 38 assembly language 5, 11, 19, 79, 216, 225 Assembly Lines 133, 135, 203, 217, 230 auxiliary (AUX) memory: See bank memory Avatar xv Ayres-Griffiths, Melody and April 124 B bank memory 147, 151, 207, 226
Bank Street Music Writer 76, 225 Bard’s Tale 3, 47, 73, 77, 91, 101, 117, 133, 139, 170 Bard’s Tale Remaster 188 Baronofsky, Ian 77 Bayport 118 Beneath Apple DOS 29, 49 Bergmans, San 44 beta testers 154 beta testing 92, 153 Book of Hints 87, 107, 188, 222 BOOTI card 144 bootloader 28, 48, 152, 225 Boston Computer Society xv Brøderbund Software 50 Brooks, John 147 Bucinem Flama 196 Buckshot image converter 225 C Cadius disk creator 176, 229 Calamari 197 Carmack, John 117, 131, 133 Castle Foolery 57, 93, 101, 109, 163 Castle Wolfenstein 9, 27, 133, 135 CDA (Classic Desk Accessory) 151 CFFA3000 card 54, 144, 149 Chaos Wand 119 chess 78 Chesterfield Sofa 117 Choplifter 124 Ciderpress 229 Coin of the Realm 220
233
Collector’s Edition 83 combat system 66, 105 Commodore 64 83 comp.sys.apple2 43, 49, 87, 230 Copy ][ Plus 10, 55 COUT function 206 COVID-19 pandemic 83, 121 cow barrier 90 Cowmageddon 161 Crossbow of Puzwang 105 Cyperpunk 180 D Daggert, Beth 22, 27, 44, 47, 58, 103, 107, 134, 161, 191, 220 Dark Shadow 97, 119, 161 dark void expansion 154 data corruption bugs 153 debugger 124, 145, 229 dialogue 98, 106, 108, 218 Dickey, Kent 130, 147 difficulty: See game balance digging in ruins 110 Discord 53, 73, 140, 158, 174, 178, 231 disk drives 167 disk sleeves 120, 219 Doom 133 DOS 3.3 27, 48, 225 double hi-res 130, 225 Dragonlance 3 Dragon Wars 47 Dr. Cat 115, 127, 131, 133, 163 Dreher, Rich 151 Dungeons & Dragons 102 Dunki, Quinn 150 Dysentery 93
234
E easter egg 135, 162, 192 economy 105 Electric Moo 57, 76, 115, 122, 195 Electronic Arts xvi Ensoniq 130 Everton 100 Ezel’dyv 107, 118, 123 F Fargo, Brian 131, 133 Ferrie, Peter: See Qkumba Flamethrower 84 flee mechanic 139 floppy disks xix, 54, 107, 120, 144, 165, 177 font blitter 205 Freeman, Chris 86, 92, 123 fulfillment 120 funnel 110 G Gagne, Ken 45 game balance 91, 102, 113, 143, 192 game engine 69, 112 game release 173 Garriott, Richard xv, xx, 24, 36, 43, 100, 111, 115, 118, 129, 131, 133, 162, 184 Ghostbusters 47, 151 Ghrodwir 228 Giggie, Bill 55, 58, 74, 88, 93, 106, 110, 122, 123, 129, 156, 162, 196, 199 Gobbler 3 GOG.com 184, 222 graphics engine 19 Grymvi’s Keep 94
GSBug debugger 147 Gustafsson, Roland 50 H half tracks 54 Haye, Martin 170 Heineman, Burger Becky xx, 47, 76, 117, 125, 131, 133, 147, 180, 218 Herrick, Matt 87, 92 High Cultist 97, 109, 154 High Resolution Character Generator 203 hi-res graphics 20, 23, 202, 226 Hitchhiker’s Guide to the Galaxy 117 Hogan, Andrew and Ivan 84 hooligans 91 Hyde, Randy 19, 230 I IBM PC 32 intermittent bugs 124, 144 Interplay 133 Into Town (song) 122, 195 inventory 62, 154, 199 Irene (NPC) 192 J jesters 101, 156 Juiced.GS magazine 45 K Kailef, Jarrod xvii, 87, 93, 111, 115, 122, 127, 132, 196 KansasFest 52, 77, 83, 93, 123, 128, 150, 180, 217 Karateka 133 KEGS Apple IIGS emulator 130 Kennaway, Kris 128, 129
Kickstarter xix, 16, 45, 57, 71, 83, 86, 92, 102, 115, 134, 168, 217 Knaerwood 100, 154 L Lady Ailuros 53, 93, 178 Lady Susan 218 Lange, Bill 168 Lavaheal 119 Lawless Legends 170, 225 Lechner, Pieter 29 Lemmert, Mark xvi, 180, 191, 196, 199, 217 Lemonade Stand 3 line-of-light algorithm 22 Lisa Assembler 6, 19 Locksmith 10 Lord British xv, xx, 22, 94, 113, 115, 129, 132 Lord British, attacking 158 Lord of the Realm 115 Lost Sectors 67, 86, 92, 123, 178 Loubet, Denis 117, 221 Lowe, Forrest 168 Lyons, Dave 151 M Mackay, Gordon 218 Maginnis, Em 76 Magus Tirrus 100 Malkin, Leonard 20, 230 Malone, Greg 127 Margrave 122 Matt Chat 90, 178 Mechner, Jordan 131, 133 melee weapons 104 merchant screen 199 Merlin Assembler 6, 133
235
MicroM8 emulator 124, 145, 165, 229 Microsoft Excel 24, 229 Microsoft OneNote 100, 229 Microsoft QuickBASIC 5, 20 Miles, John 118 mission statement 32 mobs 67 Mockingboard 51, 58, 75, 122, 127, 130, 149, 195, 209, 225 Monty Python 4, 178, 192 mountain hiking 81 N Neubauer, Peter 168, 180 Nibble 5 non-player characters 31, 58, 106, 228 Nourtheld Castle 56, 106, 109, 118, 123, 156 Novice Cultist 56 Nox A* 60, 229 Nox App 125 Nox Archaist (game title) 42 Nox Rhumoid Cowwagon 163 Nox Styx: See Daggert, Beth Nox Talk 228 Nox Tremmel 107 Nox Vortex 228 NPC: See non-player characters NPC $68 93 NPC pathing: See A* algorithm NPC.TALK 227 nuclear wessel 9 O occupied tile swaps 155 Ol Rev’s Tomb 228
236
Open Apple Podcast 45, 76 Oregon Trail 93 Origin Systems xv, 32, 127, 133, 135, 163 Overworld map 55, 98, 106, 139, 154, 226 P Padovan, Robert 57, 88 page flipping 204, 226 Parachute (game) 3 pathfinding: See A* algorithm Phelps, Tom 124 pickaxe 110 Pilgrim, Mark 52 pirate ship (arrr!) 57 pixel editor 24 Pohoreski, Michael 44, 58, 87, 130, 176 Poole, Lon 230 Porter, Tom 58, 76 Praevoc Keep 119, 131 Prince of Persia 133 Princess Bride 61 ProDOS 49, 225 ProRWTS 30, 51, 53, 144, 150, 165, 225 pulse width modulation (PWM) 127, 225 Q Q*bert Zirconia gem 102, 117 Qkumba 30, 44, 48, 58, 78, 87, 128, 150, 166, 176 Queen Isa 220 quest log 112 Quick Combat 71, 75
R rabble rousers 91 rabid dogs 91 Rangell, Eric 58, 76 range weapons 94, 104, 154 read-write-track-sector: See RWTS Reimer, Mike 7, 9, 30, 35, 58, 101, 134, 182, 218 Reunion Party 87, 131, 218 Rikkles 22, 118, 154, 158, 168 RLE compression 21 Roathe, Lane 117, 125, 168 Rockhurst University 83 Romero, John 131, 133, 180, 185, 218 RPG Codex 178 RWTS 28, 48 S SBASM cross assembler 44, 165, 229 Schmidt, David 44 Schmidt, Oliver 44 Schultz, Andrew 107 Scott, Jason 173 screen holes 24 screen scrolling 227 Scrolls of Nobility 106 self-modifying code 227 SEP spell research site 118 Shadow Knife 117 shape tables 94, 155 sharks 118 Shroud of the Avatar 111, 132 Sir Edgar 218 Sir-Tech Software 133, 217 Softalk magazine 127, 135
soundtrack 57, 77, 122, 195 Spaceballs 84 speaker (Apple II) 127 speedruns 118 Spellbound 94 spell damage 105 splash screen 51, 56, 88, 225 Stanton, Jeffrey 20, 230 State-of-The-Art chart 102 Steam 184, 222 Sternberger, Seth 170 storyline 97 Summon Ffred 119 Summon Herb 47, 101 Sundog: Resurrection 111 Suurtheld Castle 93, 100, 118, 123, 154, 156 Sword of St. Giles 102, 117 T Tass Times in Tonetown 47, 133 teleport 91, 109, 119 Tharock’s Heart 118 tile optimization 69 tiles (game) 69, 155 TLK files (NPC) 108 Torrence, Chris 51, 87, 106, 115, 121, 128, 135, 167, 176, 184, 217, 230 Torrence, Elyssa 220 Total Replay 51, 152 Town Elders 228 track/sector 49 treasure drop system 69 Twelve Days of Christmas 156 U Uharad Castle 119, 218
237
Ultima 3, 15, 24, 71, 75, 77, 91, 100, 101, 133, 162, 220 Ultima Codex 178 Ultima Dragons 115 Ultima III 3, 10, 31 Ultima IV xv, 139, 183 Ultima IV Part II 75 Ultima IX 162 Ultima V xv, 9, 31, 58, 61, 118, 135, 139, 191 Ultima VI 32 Ultima VII 162 Underworld map 98, 106, 111, 198, 226 V Vacous 43, 98, 102, 119, 198 Vali 122 Vanston, Carrington 76 Vazarath 196 Vha’ak Oblicae 43 VICE Magazine 178 Vignau, Antoine 147 Virtual ][ emulator 145, 165, 229
238
W Wagner, Roger 131, 133, 135, 203, 217, 230 Wand of Control 94 Wand of Suggestion 94 Warner, Silas 131, 133 Whiskers 192 Willy’s store 11, 74, 163 Windwalker 127 Wired.com 178 Wise, Geoff 147 Wizardry 3, 73, 91, 117, 133, 139, 217 Wolfenstein 3D 133 Woodhead, Robert 117, 131, 133 Worth, Don 29 Wozniak, Steve xx, 23, 131, 133, 135, 166, 180, 184, 204, 218 Wynmar Isles 154 Y Yakkety Sax 76 Yrstweld 118 Z ZX7 algorithm 226, 228
About the Author Mark Lemmert is a Finance and Business Management consultant who began developing retro computer games on the Apple II in 2015. His interest in programming, gaming, and the Apple II began at age five when his family purchased an Apple II+ computer. When Mark is not immersed in retro gaming, he enjoys traveling and mountain hiking. He is currently training towards a goal, a few years from now, to ascend Mount Elbert, the tallest mountain (14 439 feet; 4401 meters) in the Rocky Mountain range and the second tallest in the United States outside of Alaska. Mark happily lives in Wisconsin, USA where he is surrounded by cheese and cows.