Hello! It’s me, Jeddy—your Jeditor-in-Chief. I’ve given James the day off and have taken over his column. I’m going to be discussing some very similar topics, but from a different perspective.
If you’ve listened to the GameCola Podcast in recent months, you’ve likely heard that I’m also playing The Dev Game. Out of an incredible coincidence, I’ve also been making a first-person dungeon crawler just like James, only my game is being developed for the NES. Yes, that NES. I’m programming a game for the original Nintendo Entertainment System using MOS 6502 assembly.
So, what does the game look like so far?
Avid readers of this column may notice that this is significantly, uh, narrower than James’ code from the first edition. That’s mostly because assembly is much “simpler” than modern programming languages, not in the sense that it’s easier, but that it has fewer capabilities. I like to compare it to juggling: You can only perform one action at a time on one value, and anything else you want to do you have to toss and pick back up later. Other than that, you can really do most of the things you’d do in normal programming languages.
As long as those things are adding, subtracting, and comparing integers between 0 and 255. There’s no command for multiplication or division. There are no such things as objects or functions or arguments because the concept of variable scope doesn’t exist. Whenever you do addition or subtraction you have to manually consider whether the “carry the 1” flag was set by some previous operation, otherwise your basic math will be wrong. I mean exactly what I say when I tell you that it really is that simple.
I hear some of you saying “You can multiply and divide by two using bit shifting!” and some others saying “You can use subroutines and the stack to replicate functions and arguments!”, but this only really goes along with what James was saying before: As the developer, you have to find ways to do all these things yourself.
Oh, but I haven’t actually told you about my game! Allow me to introduce what the GameCola staff affectionately calls “Space Door Locke”, in which the player must debate the source of consciousness with 17th-century philosopher John Locke who has found his soul transferred into the door of a 21st century space ship explore space ships in which they occasionally encounter doors which are locke locked. Much like James’ game, this is a sci-fi “first-person” dungeon crawler, albeit in only two dimensions.
As I contribute to this column, I will compare and contrast the work James is doing and the work I’m doing. As we’re making very similar games, we’ve independently arrived at very similar solutions to very similar problems. However, the actual implementations can be quite different due to the limitations of the NES compared with the freedoms of a modern PC.
For example: What kind of format do you use to store level data? Those readers with some programming experience may immediately think “two-dimensional array”. A two-dimensional array is the obvious choice for four-directional movement: You can jump to the next tile by incrementing or decrementing the index of each dimension. Except that 6502 assembly doesn’t have the concept of “arrays”, only memory positions. We can emulate something similar by saying “increment or decrement by 1 to move left or right, and increment or decrement by the width of the map to move up or down”. This isn’t incredibly complex. But, what if you want to have empty tiles in your map—areas that are inaccessible by the player and contain no meaningful data? Do you store a 0 in those positions?
You’re going to be storing a full byte for every empty tile in your map? With the storage space limitations of the NES??? That may be fine in an emulator where we can pretend we have an MMC5 chip with all the bank switching we want, but what if we want to do a physical release? Think of the manufacturing costs!
No. If I’m going to do this, I’m going to do it the old-fashioned way. If discrete mappers were good enough for Dragon Quest and Gradius, they’re good enough for me!
Some development-minded readers may be shouting “multi-linked list!” at this very moment, and this is the way I’ve decided to go. This will make certain features more difficult to implement in the code, but will give a significant savings on space (very important for a sci-fi game). Instead of relying on the layout of the data to tell you where the adjacent tiles are, each tile stores the destination of each possible exit. This also gives me much more flexibility in level design. In the above screenshot, you can see that the tile ahead of you has exits north, south, east, west, and up. Not pictured: Down can also be an exit. This also allows me to implement “space station-shaped maps”—if you image the classic spinning space station design, walking straight forward will lead you in a circle, and climbing a ladder “up” will bring you to the opposite side of the circle. These kinds of designs aren’t possible with a flat grid.
Which brings me back to the point I keep reiterating: As a programmer, you can do anything you want…but you have to do it yourself. When I say that I use a multi-linked list to implement my dungeon’s tile map, my dear readers must understand that there is no such thing as a linked list, dungeon, tile, or map. There are only commands and data. It’s up to me to write the commands that parse the data and use it in a way that causes the NES to show something the player will interpret as “showing the exits of the tile ahead”. It’s also up to me to write an entire level editor (separately coded using C#) that allows the me to load, edit, and save the same data the NES game will use.
Makes perfect sense, right? Maybe there’s a reason I’m a software engineer and not a UX designer.
While I hate to leave my readers with a cliffhanger, I’ll have to leave the inner workings of this system to your imagination for the moment. If the miracle of NES development in the modern era excites you, you’ll either have to wait for the next installment of this column—or join us on the GameCola Discord!
