Origins of Nox Archaist

By: Mark Lemmert

This is a follow-up post to Why an Apple II Game?

---------

Return to Nox Archaist Kickstarter Page

My parents bought an Apple II+ computer in the early 1980s when I was 5 years old. I grew up watching my older brothers dabbling in computer programming on that machine and playing cool games like Ultima, Wizardry and Bards Tale.

At that age those games were so captivating and also such a mystery to me. The first 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 to disk screwing up their characters.  I had no idea what I was doing beyond using the arrow keys to move around, but it sure was fun! In the last year some of our younger relatives have playtested pre-alpha versions of Nox Archaist and it was very reminiscent of this experience.  

I began to explore Applesoft basic around the same time and the desire to created my own tile RPG grew quickly. Of course, I had no clue where to start. Over the years that followed I spent untold hours learning programming, playing games and studying them. I also spent a lot of time reading fantasy books like Dragonlance, watching nonsensical movies like 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 are 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 home to Wisconsin and write some code to test out my idea. 

Once back at a computer, I spent many hours programming a proof of concept in Applesoft. I remember the moment when I typed in “RUN GAME”.

The disk drive whirred.

It whirred some more.

It whirred for longer than any other program I had every 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 do not 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 tile-based graphics engine design actually worked.

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 question 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 on a regular basis and talk to other people who were experiencing the early personal computer revolution. Unfortunately, like me, he did not know how to write assembly language programs.  

But, he tried to help. He found the one and only assembly language book at the library at the high school where he taught. 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 program 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, assembler software like Lisa, or Merlin existed at the time, which could be used to write assembly language programs on the Apple II, but I did not know that back then.

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 adults I came into contact with who had programming experience on main frames. 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.

The book I was reading was not a book for a beginner, and assumed the reader already had an assembler program and knew the fundamentals of the language. At that time books on programming, especially assembly language, were hard to come by and this was the only one available to me. I was stuck.

Time Warp

I’m going to cover about two decades in two paragraphs. The RPG project was stuck on the back burner as I became interested in modems and computer bulletin board systems. 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 this new fangled 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 and future Nox Archaist project co-founder Mike Reimer. After several mergers and acquisitions, it became 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.

Nox Archaist Project: Modern Era

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 many of the Apple games we had enjoyed as kids. 

After playing though a few games, Mike commented that it would be fun to develop an 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 the Apple II RPG I started as a kid.

Explaining the reason is difficult. 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 tried to climb years ago, so to speak. And, 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.

Coincidentally, the tipping point that led to decide to renew my pursuit 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” copy on ebay because I wanted to make a disk image so I could play Ultima III 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 5.25” 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.

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.

Battling 6502 Assembly Language: Round 2

Eventually, I resumed my search for an assembly language book written for beginners. This time, I knew what kind of book I needed and found it: "Using 6502 Assembly Language" by Randy Hyde. It is written specifically for use with the Liza 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 in the book. By the time I finished the book I realized that I had learned enough assembly language to make a serious attempt at once again trying to develop an Apple II tile-based RPG. My motivation to crack the copy protection on Ultima III soon faded, replaced by the long dormant desire to create a game. 

Ok, this probably bears some explaining. How in the world does a finance/business guy who had a few computer science classes in the 1990s pickup one book on assembly language and suddenly know how to develop and Apple II RPG?

While the computer science classes were helpful, the many years of trial and error I spent as 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 write the other components of an RPG are very similar to those needed for the graphic engine. While there is much more to writing an RPG than the graphics engine, it is arguably one of the hardest parts.

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 that it would have been starting from square one with no conceptual understanding of how the engine mechanics worked. 

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 I/O. I had a basic understanding of the role of computer hardware, the operating system, application software and how they 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 boot loader.  Filling in the holes took months of tracking down old technical manuals and spelunking in old Apple II newsgroups. Eventually I found the comp.sys.apple2.programmer forum which is haunted by some of the few remaining true masters of 6502 assembly language.   

After launching the Nox Archaist project I also met Beth Daggert, a former 1980s game developer, and Peter Ferrie (aka qkumba), an assembly language grand master, who have been kind enough to brainstorm with me on a variety of technical challenges. The comp.sys.apple2.programmer newsgroup community has also been very helpful in answering questions. 

Conclusion

By late 2015 I was writing code for Nox Archaist, though the game had not yet been named. One evening I met up with Mike Reimer for dinner and let him know what I had been up to and asked if he was interested in collaborating on an Apple II RPG instead of an RPG for mobile devices.

Soon after it was official. We formed 6502 Workshop and began work on a new Apple II RPG called Nox Archaist. On March 26th of 2016 we launched the Nox Archaist website and publicly announced the project. In September 2016 we welcomed our first team member, Bill Giggie, a professional graphics animator in the movie industry. Bill has been instrumental in providing new and innovative tile artwork for the game.

In addition to creating awesome games, a goal of 6502 Workshop is to be a modern resource for information on how to develop RPGs on the vintage Apple II platform. This is motivated in part by the fact that I’ve yet to find a book on the subject. Our intention is to provide information on our website describing this journey and providing insight into the development techniques we used to bring Nox Archaist to life. Hopefully this will help out people with similar crazy aspirations. We welcome any questions you may have!

Also, if you've enjoyed this post and/or are interested in Nox Archaist please post a comment and let us know. We really enjoy hearing from everyone!

Nox Archaist S1E1: Shattered Sword

Nox Archaist is a new role playing game in development by 6502 Workshop exclusively for the Apple II platform and emulators, with floppy and hard disk support.

We are excited to announce the first in a series of mini stories using the Nox Archaist engine to demo the newest features in the game. The Nox Archaist story line is still under development. Any names or characters used in these mini stories are not intended to depict real or imagined NPCs, events, or bovines in the actual game. Any similarities are coincidental.


Nox Archaist S1E1: Shattered Sword

In this episode our hero travels to town and faces an epic struggle to get his sword repaired after breaking it over an ogre's head.

New game play elements to look for in this video include:

• Conversation with NPCs 
• NPCs moving between locations on the map based on their daily schedule
• New interactive tile graphics

Most of the new graphics were designed by our team member Bill Giggie. Bill is a professional graphics animator in the movie industry and is really helping bring the world of Nox Archaist to life!


About Nox Archaist
Nox Archaist, by 6502 Workshop, is a 2D tile based fantasy RPG with a classic Apple II look and feel. Our mission is to 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.

http://www.noxarchaist.com

Tech Talk: NPC Pathfinding in Nox Archaist: Part III

An A* Implementation for the Apple II

Our mission for the Nox Archaist project is to explore how tile based RPG games may have evolved if significant development on the Apple II had continued beyond the 1980s.

One of the evolutions we explored was improving the intelligence of NPCs, and this is the third posting in a three part series of Tech Talk in which will discuss this topic. 

Before we begin:

Click here for Part I.

Click here for Part II.

This image contains a demonstration of Nox A* in action.

TOWN NPC SNEAK PEAK

The white character twirling a spear is the player and the other is an NPC whose movements are controlled by the algorithm.

====Solving the Resource Challenges====

Even with the modifications mentioned in Part II, it became quickly apparent that using A* in our environment resulted in unacceptable gameplay delays if the algorithm was used to calculate a path each time an NPC moved. The solution was twofold.

To solve the speed problem, Nox A* anticipates paths needed by NPCs who are scheduled to be in a different location in the next few game hours. These paths are calculated in the background and saved to auxiliary memory for future use. The Nox A* subroutine is designed to abort after 5 iterations if a player key press is detected and to resume after the player key press is processed. As a result, the player can go about his or her business in the town without observing significant delays in gameplay.

To solve the A* memory problem, we took advantage of the modular architecture we designed in the game engine. The main Nox Archaist engine resides in memory up to $9FFF and $D000-$FFFF. A swap area is reserved from $A000 - $BFFF where modules are loaded from disk for functions like NPC conversations, inventory management and combat. A* builds its database in this swap area, and when that area is needed by a module the A* database is swapped out to auxiliary memory.

Did anyone notice the logical hole in what we’ve said so far? J We mentioned that Nox A* enables NPCs to navigate around dynamic obstacles like the player and other NPCs. We’ve also said that paths are calculated in advance rather than every time the NPC moves. How is that possible, considering that the exact position of dynamic obstacles is not known in advance? 

This was a fun problem for us to solve. If you think you know the solution, email us at contest@6502workshop.com before Nov 30, 2016. The first response with the correct solution will receive a complimentary 5.25” floppy disk copy of Nox Archaist when the game is available, targeted for 2017.  The answer will be posted in the December 31, 2016 issue of Juiced.GS and on our blog. 

Tech Talk: NPC Pathfinding in Nox Archaist: Part II

An A* Implementation for the Apple II
 

Our mission for the Nox Archaist project is to explore how tile based RPG games may have evolved if significant development on the Apple II had continued beyond the 1980s.

One evolution we explored was improving the intelligence of NPCs, and this is the second posting in a three part series of Tech Talk in which will discuss this topic. 

Before we begin:

Click here for Part I.

This image contains a demonstration of Nox A* in action.

TOWN NPC SNEAK PEAK

The white character twirling a spear is the player and the other is an NPC whose movements are controlled by the algorithm.



===Inside Pathfinder Algorithms===
 

A* combines the principles of several pathfinding algorithms, which we’ll review as a starting point.

Consider the villager NPC in figure 1. How did the villager figure out which tiles to walk on to locate the door and enter the town hall without bumping into a few walls? The human brain can easily see a path between any two tiles on the map. We “see” the whole map at once. However, for a computer to find a path it must examine one tile at a time.

Figure 1: A villager makes his daily visit to the town hall.

The examination process involves looking at each tile to see which paths (north/south/east/west) are open and which paths are blocked by obstacles. One approach to pathfinding is for the computer to examine every tile on the map and store the open paths for each tile in a database, then look for a combination of tiles with open paths that connect the starting position to the destination. This approach is known as the Breadth First Search algorithm. It gets the job done, but it is very CPU intensive and not practical for our application. It also doesn’t take into consideration variable movement costs for terrain. For example, hills might be slower to move across than flatland.   

To start building the database, in the first iteration the algorithm examines the tiles adjacent to the starting position. Any open paths are added to the database as “neighbor tiles”. After the algorithm examines all start tiles, it examines one of the neighbor tiles it found in the first iteration and adds any new neighbors found to the database. The process of acquiring neighbors and examining neighbors continues until all tiles on the map are examined.

A more advanced algorithm known as Greedy’s Best First Search dramatically reduces the CPU cycles required by examining only a small subset of the total tiles on the map. This algorithm prioritizes by maintaining a neighbor tile queue and sorting the queue by distance with every iteration. Tiles with a shorter distance to the destination are examined first. Distance refers to the number of tiles to the destination, ignoring obstacles.

A* incorporates the techniques in Greedy’s Best First Search for finding the shortest distance and adds a terrain movement cost component to determine the shortest path.  The process is similar to the techniques used in the modern day networking protocol OSPF (open shortest past first).

========Optimizing A*========

Adding Realism & Randomness

While A* does a great job of finding the shortest path, we didn’t want our NPCs to suffer the boredom of following the same routes day in and day out. Realistically, a merchant is of course not always going to take the exact same route home every day. Not to mention, bored NPCs might mutiny and ruin the game for everybody. Just sayin’.

We found a way to inject realism into path selection and speed up the algorithm at the same time and we call this implementation Nox A*. Our method doesn’t sort the prioritization queue nearly as often as Greedy’s. With Nox A* if a new neighbor tile is found with a shorter distance to the destination than the last tile examined, the new tile is examined immediately and the queue sort is skipped for that iteration. For some paths this decreases the CPU cycles required by over 400%.

By skipping instances of queue sorting, the Nox A* algorithm will miss shorter routes that it might find if it sorted every iteration. As a result, Nox A* causes NPCs to take a slightly meandering path between two points.  However, with this change alone, the path would still be the same every time. An additional modification was needed to inject some randomness into the path chosen.

Since Nox A* immediately examines a new neighbor tile if its distance to the destination is less than the last tile examined, the order in which new neighbor tiles are identified impacts the algorithm’s prioritization. For example, if the algorithm searches for new neighbors in the order of north, east, south, west, then the tiles to the north will always be preferred over tiles to the east even if both tiles are the same distance from the destination and have the same movement cost.

Nox A* randomizes the order in which new neighbors are searched which results in NPCs not always taking the same path between two points. This effectively prioritizes the directional choices. Consider the villager in figure 2. To make is easier to see the possible paths this NPC might take to reach the X, we’ve turned the Nox Archaist line of sight algorithm off that normally hides tiles behind obstacles such as walls and mountains. The impact of the directional priority calculation on the path selected is as follows:

Priority 1 = west, priority 2 = south: left/outer path will be taken.

Priority 1 = west, priority 2 = east: left/inner path will be taken.

Priority 1 = east, priority 2 = south: right/outer path will be taken.

Priority 1 = east, priority 2 = west: right/inner path will be taken.

Figure 2: Possible paths an NPC might take

The directional priority is randomized many times during the process of calculating a path. As a result, calculating a path between two points over a long distance with a lot of corners will result in many small variances.

Stay Off the Grass!

Another important piece of functionality is obtained through the use of movement costs assigned to tile types. For example, Nox A* treats floor and street tiles as having a lower movement cost than all other terrain. This is how we keep NPCs from taking bizarre routes around town like traipsing through neighbors’ lawns and schlepping through farms fields, all in the name of taking the shortest path. We were also lobbied heavily by the shopper keepers guild to make sure NPCs walked past their shops instead of taking shortcuts.

Detecting Player Harassment

Having the ability for NPCs to figure out how to get around obstacles, including the player and other NPCs, may create the temptation for the player to block the path of the NPC repeatedly. For example, every time the NPC tries to move around the player, the player moves to block the NPC’s path again. We can detect this by incrementing a counter each time an NPC is blocked by the player and this allows for event triggers if the counter reaches a specific value. For example, the NPC might tell the player “Get out of my way!”.

Tech Talk: NPC Pathfinding in Nox Archaist: Part I

An A* Implementation for the Apple II

Our mission for the Nox Archaist project is to explore how tile based RPG games may have evolved if significant development on the Apple II had continued beyond the 1980s.

One evolution we explored was improving the intelligence of NPCs, and this is the first posting in a three part series of Tech Talk in which will discuss this topic.

Tile-based RPGs of the era such as the early Ultima games, Deathlord (cira 1987) and Shadowforge (circa 1989) typically used a flocking style algorithm which enabled NPCs to move randomly while tethered to a specific area of the map. The most advanced implementation we found was in Ultima V (circa 1988), where most NPCs traveled between locations on a town map at scheduled time throughout the day. For example, a merchant might be found at home, at his/her shop, or at the local eatery depending on the time.

This feature was likely achieved by storing a hard coded set of x,y coordinates between locations. We observed Ultima V NPCs always took the same path and, if the player blocked that path, the NPC would stop in front of the player. Forever.

We saw an opportunity to improve gameplay by enabling NPCs in Nox Archaist to take different paths sometimes, navigate around the player and other NPCs, and detect player harassment. To this end, we decided to attempt the first ever (to our knowledge) implementation of an A* based pathfinder algorithm for regional maps in an Apple II tile based RPG.

Peter Hart, Nils Nilsson and Bertram Raphael of the Stanford Research Institute first mathematically described the A* algorithm in 1968. The documented history of the algorithm is sketchy on what happened next. It was likely implemented first on computers using low level languages such as C. Modern computers can effectively run the algorithm using almost any language. A* based algorithms have been used in many games such as Age of Empires (circa 1997) and Counter Strike (circa 2000). The challenge to implement it effectively on the Apple II was twofold:

1) How to fit it into very limited memory.

2) Make it fast enough so that the gameplay wouldn’t slow to a crawl.

In the next two posts in this series we talk about how pathfinding algorithms work, how we solved these challenges on the Apple II platform using 6502 assembly language, and how we optimized our implementation of the A* algorithm (Nox A*) for improved game play.

This image contains a demonstration of Nox A* in action.

TOWN NPC SNEAK PEAK

The white character twirling a spear is the player and the other is an NPC whose movements are controlled by the algorithm.

Sneak Peak: Towns and NPCs

Juiced.GS Magazine recently published an article we wrote providing a technical overview about Nox A*

Nox A* is a custom developed algorithm that NPCs in Nox Archaist use to figure out a route to take when traveling between locations on a town map at scheduled times throughout the day. For example, a blacksmith might be found at home, at his/her shop, or at the local eatery depending on the time.

The demo video below shows Nox A* in action, featuring a merchant walking from her living quarters to her store front.

Stay tuned to our blog for the premier of our first town featuring:

• Interactive objects such as portcullis, levers and doors.
• Many animated graphics such as fountains, wells, fireplaces and more!
• Dozens of NPCs moving about the town on their daily schedules.
• Conversation with NPCs in a pop-up window. 

Many thanks to our new team member Bill Giggie for his recent work on the town artwork. Bill is a professional graphics animator in the movie industry and is really helping bring the world of Nox Archaist to life!

TOWN NPC SNEAK PEAK

Graphics Contest Winners

We are pleased to announce that the three winners of the Nox Archaist graphics contest are:

• Bill Giggie               : shark and palm tree
• mmphosis-apple2    : portcullis
• Kurt Brenson           : street lamp

Many thanks to these individuals and everyone who participated in the contest! Please email us at contest@6502workshops.com to confirm your contact information for receiving contest prizes.


Here are gameplay video showing the winning tiles:

Shark and Palm Tree

Portcullis and Street Lamp 

Also, click here to check out the latest Nox Archaist feature - the ability for players to illuminate the night with a torch or other player generated light source.


Thanks,

6502 Workshop Team
http://www.noxarchaist.com

New Feature: Player Light Source

We are excited to announce a new feature in Nox Archaist. Capability for a player sourced lighting is (finally!) working. This will be used when the player equips items like torches and light generating spells.

We have a new gameplay demo showing the player light source feature in Nox Archaist that can be found here:

Tech Talk: How Does the Game Know Which Tiles Should Be Hidden/Dark? (PART II)

The sunrise/sunset feature recently announced simulates day/night by hiding some of the tiles on the screen, which leaves them dark or empty. Today we will continue with part II of the discussion about how the graphics engine figures out which tiles should be hidden/dark.

Click here for part I. 

 
For Review

• The darkness stencil array mirrors the grid of tiles which make up the view screen graphics.
• The graphics engine determines which tiles are visible vs. hidden/dark based on whether, for each grid coordinate, the darkness stencil array contains $00 (visible) or $01 (dark/hidden).
• The game set the values in the darkness stencil array based on the time of day, by copying preset values in memory into to the darkness stencil array, which in turn tells the graphics engine which tiles not to draw. 

Mountains, Walls, Etc.

The preset values used by the game to determine which tiles should be dark/hidden, with regard to the time of day, were calculated by humans in advance. In contrast, terrain/objects like mountains and walls that block line of sight are impractical to anticipate in advance and preset into memory. The computer would run out of memory and my brain would turn to jelly long before the task was complete, and not necessarily in that order.

The reason is because line of sight calculations depend on the position of the object(s) relative to the player. The number of possible screen layouts that exist are exponential. As a result, I found no alternative but to program some extremely rudimentary artificial intelligence into the 'ol Apple II.

First, it should be said that the line of site (LOS) calculation that is done is a very rough one. There are certainly some positions that look a little strange, which we'll try to avoid through map design.

The logical core of the LOS algorithm is centered on the screen being divided into 8 sections, with a specific darkness pattern associate with each section. For each obscuring tile on the screen (mountains, walls, etc) the algorithm determines which of the 8 screen sections the obscuring tile resides in. Conceptually the sections can be labeled, relative to the direction of the obscuring tile to player, Northwest, North, Northeast, East, Southeast, South, Southwest and West.

After the LOS algorithm determines the screen section a given obscuring tile is in, it applies the darkness pattern for that screen section to the tile grid coordinates around the obscuring tile's grid location and copies the results to the darkness stencil array. This process is repeated until each obscuring tile has been evaluated.

Conveniently, the time of day darkness calculation is done before LOS so the results of the LOS calculation override the time of day calculations.  Said another way, even if it's day time, the player still can't see over mountains.

Ok, that pretty much wraps this up then, have a nice -

Wait! You said that after the first screen after game launch is drawn, the game scrolls the existing tiles on the screen rather than drawing them all from scratch, except for the screen edges.  If that is the case, how do the $00 (visible), and $01 (hidden/dark) flags effect which tiles are visible in the area of the screen that was scrolled?

Great question. There is another array that tracks whether each tile on the grid was $00 (visible) or $01 (hidden) as of the end of the last player move. There are a bunch of calculations going on that consider whether tiles were hidden before but are visible now vs. visible before but hidden now, and therefore whether a few tiles need to be drawn or erased which were scrolled. This gets fairly ugly from a code structure point of view as it's done as the darkness algorithm is running in order to be speed efficient.
 
If anyone is interesting in taking a deeper dive on any of this let me know. I'm happy to share the charts and diagrams that map out how the LOS does it's calculations in each of the 8 screen sections too.

Tech Talk: How Does the Game Know Which Tiles Should Be Hidden/Dark? (PART I)

The sunrise/sunset feature recently announced simulates day/night by hiding some of the tiles on the screen, which leaves them dark or empty. Today we will talk about how the graphics engine figures out which tiles should be hidden/dark.

For Review

• Each tile graphic has a unique ID number "Tile ID" 

New Concepts

• #1 Each graphics screen the player sees is divided into a grid of 17 tiles wide X 11 tiles deep.
• #2 To draw the first graphics screen the player sees after launching the game, the graphics engine examines the Tile ID for each position on the grid and draws the graphic corresponding to the Tile ID, in each grid position. 
• #3 When the player presses a movement key, the graphics engine "scrolls" the tiles in the opposite direction which the player moved and then draws a new row or column of tiles on the screen edge. For example, if the player moves north, the tiles are scrolled down 1 grid row and new tiles are draw in the top grid row, representing the new terrain to the north that is now visible to the player. 
• #4 Screen scrolling involves copying the values in the memory addresses that control which monitor pixels are turned on. This process is much faster than drawing each tile graphic from scratch, as is done to generate the first graphics screen the player sees after game launch. 

The graphics engine keeps track of which tiles should be hidden/dark and which tiles should be visible via an array identical in size to the array which stores the Tile ID associated with each grid position on the screen. Since this array essentially mirrors the format tile grid, but contains additional information on each tile, we decided to call it a stencil array.

The darkness stencil array contains either the value $00 (visible) or $01 (hidden/dark) for each position on the grid.
 
That is what tells the graphics engine which tiles are hidden/dark. The more complicated aspect is generating the values in the darkness stencil array, where the actual determination is made on which tiles the player will see. That is the job of a subroutine known as the darkness algorithm. 


Sunrise and Sunset

The first thing the darkness algorithm does is stop and consider the time of day. If it is tea time, the darkness algorithm takes a break, orders some virtual tea from disk and the player is unfortunately left staring at a screen that isn't changing. Now you know what's really going on when the disk drive runs endlessly when entering towns and such in tile based RPG games.

Of course that isn't really what happens (except in the U.K. release). Actually, the darkness algorithm determines which of four phases the time on the in-game clock corresponds with: sunrise, day, sunset, night. Each phase of the day corresponds with a specific pattern of tiles which are set to $00 (visible) and $01 (hidden/dark) in the darkness stencil array.
 
Daytime is easy. The entire grid is set to $00s (visible)

Night is mostly $01 (hidden/dark) except for a few tiles right near the player in the center of the screen. We worked out this pattern on a mock tile grid and preset the values for nightime into memory. When it is nighttime, the darkness algorithm copies those values into the darkness stencil array.

Sunrise & Sunset are a bit trickier than night. Each has four phases of darkness in between full day light and full night time. Just like night, we drew the visible/hidden patter for each of those phases on a mock tile grid and stored those values in memory for the darkness algorithm to copy into the darkness stencil array at the appropriate time.

In summary, the game determines which tiles should be dark/hidden, with regard to the time of day, by copying preset values in memory into to the darkness stencil array, which in turn tells the graphics engine which tiles not to draw.


Part II is coming soon, where we'll talk about how the darkness algorithm calculates how terrain/objects like mountains and walls obscure line of sight.
 

Graphics Contest Update

Hey guys, one of our blog readers had a great suggestion to utilize Creative Commons licensing for graphics submitted to the Nox Archaist contest.

We've updated the contest details to clarify that any work submitted would be licensed under Creative Commons Attribution 4.0 International.

Using Creative Commons helps clarify our original intentions. Basically, the artist retains the rights to their work and can still license it to other people, while at the same time giving us the ability to include their art in Nox Archaist.

Graphics Contest Announcement

Hey Guys,

The 6502 Workshop team has been pounding out code for Nox Archaist and the game is starting to come to life.  One area that we have been kind of winging is tile graphics art.  We would like to offer a chance for members of the retro gaming community to participate in the design of Nox Archaist while hopefully improving the final result and getting the game into your hands more quickly.  

Starting today we are running a tile contest!

The top three submitted tiles will be determined on 7-31-2016 and the winners will receive the benefits below:

• One custom in-game NPC named and based on input from the winner 
• Copy of the initial release of Nox Archaist on 5.25” floppy disks
• Pre-release digital copy of Nox Archaist
• Printed manual
• Name mentioned in Nox Archaist game credits
• Announcement of winners on our blog and in this forum
• Any other goodies we can come up with 

To participate, just send us one or more tile designs using the criteria provided at the link below. Submissions can be sent via email to contest@6502workshop.com contest@6502workshop.com

Click here for contest details.

Nox Archaist featured in Open Apple podcast

Check out the recent Open Apple podcast! They discuss Nox Archaist: at 01:36:00

Stay tuned, we will be announcing new game features soon!

New Features: In-Game Clock and Sunrise/Sunset

We are excited to announce new features in Nox Archaist, a new role playing game we are developing exclusively for the Apple II platform and emulators.

An in-game clock has been implemented in Nox Archaist which allows us to trigger events based on the time of day.  The first events we've built off of this new game clock are automatic sunrise and sunset.

We have a gameplay demo showing sunrise/sunset in Nox Archaist here:

Stay tuned for a Tech Talk posting coming soon that will discuss how hidden tiles (/aka darkness) are generated in Nox Archaist to simulate sunrise, sunset and terrain such as mountains and trees blocking line of sight.



About Nox Archaist
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.

Sunset: 8:30pm

Sunrise 5:30am

Creating a Hard Drive Image For Emulator Use

Recently we found a bug where the game would crash when a user would boot to a hard drive before launching the game off of a floppy. We recreated this situation by using an AppleWIN hard drive image that booted to ProDOS Basic and then executing a ProDOS command from there to boot from the floppy drive.

Below are instructions on how to set this up and some challenges we ran into during that process. The instructions assume a basic understanding of the Windows Command Prompt, CiderPress, AppleWIN, and Copy II Plus. I’m happy elaborate on any steps involving use of this software, just ask.

When AppleWIN is setup with a hard drive it will only attempt to boot from the hard drive. In this scenario it is necessary to type a ProDOS command, after the hard drive is booted, if you want the machine to load an image on the floppy drive.  Keep in mind the command prompt is identical for both ProDOS and AppleSoft. The following ProDOS command will attempt a boot from a floppy disk drive in slot 6:

] PR#6

So, we found an interesting chicken-and-egg paradox in this process: booting an unformatted hard disk will result in a crash.

How do we load a utility to format a hard disk for the first time if AppleWIN automatically tries to boot from the hard disk once the hard disk is enabled? Hint: It’s not an AppleWIN setting. 

The answer is found below.

1. Create a 0 byte file using a Windows PC.

• Launch the command prompt with admin privileges
• Click Start and type cmd in the search box
• Press CTRL+Shift+Enter 
• A command prompt with admin privileges enabled will open 
• Create a 0 byte file in c:\applwin using the following syntax
• In Win7 - fsutil file createnew c:\applewin\applehdd.hdv 0
• Previous versions of Windows can use debug instead of fsutil to create the file

2. Use CiderPress to choose any random Windows file to add to applehdd.hdv

• This step prevents Windows from deleting the 0 byte file when it is accessed by an application
• It doesn’t matter what file type is added as all contents of the hard drive will be erased when it is formatted. I chose a text file

3. Enable the Hard Drive in AppleWIN

• Enter AppleWIN configuration
• Click on the Disk tab
• Check the box next to Enable Hard Disk
• Choose the applehdd.hdv file in c:\applewin
• AppleWIN will pop up a window saying it needs to restart. Proceed with the restart. 

4. Boot Copy II Plus version 8.2

• Other versions of Copy II Plus may work. This is just the version I used
• Note that Copy II Plus 9.1 requires the model in AppleWIN's configuration to be set to enhanced Apple IIe
• Insert the Copy II Plus 8.2 floppy disk in drive 1
• Click the boot button in AppleWIN using the Apple icon
• You should see the Apple monitor prompt (an asterisk with a bunch of hex numbers)
• This is because once a hard disk is enabled, AppleWIN will try to boot from the hard disk first. Since the hard disk isn’t formatted, the boot process crashes.
• Boot from the floppy after crashing
• Type C600G at the Apple monitor prompt. 
• This will execute the machine instructions stored in ROM for the boot0 process 
• AppleWIN attempts to boot the floppy disk in drive 1 at this point

5. Format Hard Disk

• Once Copy II Plus has launched, format the hard disk for ProDOS 
• Use Format menu option. Pretty much just follow the prompts
• The hard disk is slot 7, drive 1

6. Copy ProDOS onto Hard Disk

• If you're copy of ProDOS is stored on a .SHK file you'll need to transfer it to a disk image. If ProDOS is already on a disk image, skip ahead to the "Insert the ProDOS disk image" step below.
• To transfer ProDOS from a .SHK file to a disk image, start by using CiderPress to extract the file
• Select Keep Apple II Formats
• Create a blank disk image with CiderPress
• Add the extracted file to the disk image
• Insert the ProDOS disk image into the floppy drive. (I used ProDOS 2.03)
• Copy the file from the ProDOS disk image in drive 1 to the hard disk

7. Copy ProDOS Basic onto Hard Disk

• Insert any disk image that contains the ProDOS file BASIC.SYSTEM into floppy drive 1. Copy II Plus 9.1 contains this file and is what I used. 
• Copy the file BASIC.SYSTEM from drive 1 to the hard disk
• All done! 
• Clicking the boot button on AppleWIN should now result in the hard disk booting to the ProDOS basic prompt ]
• From the ProDOS Basic prompt, launch floppy disks by typing PR#6 
• Create folders using the Copy II Plus 9.1 menu option Create Subdirectories

Notes:

*All versions of ProDOS after 1.9 required an Enhanced Apple IIe. AppleWIN configuration options can be set to run the emulator in Enhanced Apple IIe mode.

New Feature: Fields of Green

Return to Nox Archaist Kickstarter Page


Across the landscape of the world in Nox Archaist both short and tall grass can be found in abundance. Tall grass hides the lower half of mob icons and player icons from view.

The player and mobs think they are pretty clever (the player is probably right). When standing in tall grass they go into stealth mode and stop waving their weapons around.


Tech Talk:


For Review

• Each tile graphics has a unique ID number. 

New Concepts

• Each tile is 14 pixels wide x 16 pixels. (in assembly language terminology, 2 screen bytes x 16 lines) 

The tech topic for this post is drawing tiles.

Each tile in the game has it's own shape table which stores the hexadecimal data used by the Apple II hardware to turn on the pixels on the hi-res graphics screen. The shape tables are stored on disk and loaded into auxiliary memory when the game boots. 

There is a subroutine called DRAW.TILE at the core of graphics engine which will draw any shape table at any location on the view screen's tile grid (currently !17 tiles wide X !11 tiles deep). The tile grid location and the shape table to use are passed as parameters.

Since the shape tables are 14x16, as noted above, DRAW.TILE is designed to draw 14x16 shapes. It does this using a loop. Like all loops, it has a stop value that triggers the end of the loop.

How does this relate to tall grass and the lower half of the tile being hidden? 

If the player is standing on a map location with the tile ID for tall grass, a parameter is passed to DRAW.TILE which tells the routine to use a different stop value, thus triggering an end to the loop after only the top half of the shape is drawn.