Monday, June 20, 2016

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.

Sunday, June 12, 2016

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.
 

Sunday, June 5, 2016

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.