It has been a while since I have written one of my blog entries about the technical challenges of making my RPG "Penult" for the Atari 2600. By far my biggest challenge has been making the game with the extreme memory constraints of the console, so this entry will discuss how I dealt with those issues.
RPGs tend to be very memory-hungry. You need to keep track of a character's name, stats, inventory, experience, location, current state, etc. If there are multiple party members, these
It's my blog, so I can whine if I want to, right?
Anyway, my 5-year-old MacBook Pro died suddenly in the middle of using it, and nothing would revive it. I figured I could extract the drive to retrieve my data from it, but apparently 2017 MacBooks and later have the drive chips soldered onto the motherboard, and cannot be removed. I took it to a Mac shop to see if they could save the data, and they were unable to power the board to read the data off of the chips. So, my data is proba
Death in RPG-style videogames is handled many different ways, depending on the game. If there's not a reasonable chance of death in the game, then players may lose interest because the game is not challenging enough. If the penalty for death is too great, then it may be too discouraging to players, and they may give up on the game.
Here are a few possible approaches to handling in-game death:
Permadeath
This is the most hard-core option. If the characte
There are not a lot of Atari 2600 games that make use of a large amount of text. There are various reasons for this, including ROM size, as well as the fact that many implementations of a text display on the Atari use up a good deal of the limited RAM on the system. Penult has a large ROM size (128K), and makes use of a text display that builds the text lines on the fly to save on RAM (props to @RevEng for help with the initial design from which the Penult implementation had evolved).
Motivation for projects can come and go, and is hard to predict much less control. One odd thing I noticed is that there was a feature I had been meaning to add to my WIP Atari 2600 game, and when I realized that it would actually be a pain in the rear to implement it, I suddenly had the motivation get it done. Unfortunately, that doesn't work with everything else in my life, however.
When I was with my ex wife, I did the cooking, and she tried a lot of different diets. I noticed tha
I've been writing a few blog entries with semi-technical notes about the innards of my WIP Ultima-style game. In this one, I talk about keeping track of state in dungeons with extremely limited RAM.
I've been working on implementing dungeons in Penult, starting with original data from Ultima 3 for testing purposes. Dungeons in Ultima 3 consist of 8 levels each, and each level is a 16x16 square of tiles. Since there are less than 16 unique tiles, two tiles can be stored in 1 byte of R
I've been writing a few blog entries with semi-technical notes about the innards of my WIP Ultima-style game. In this one, I describe how I handle all of the game's tasks without running out of CPU time.
With many Atari games, especially ones that do not make use of a coprocessor like the ARM, limited CPU time for game logic can be a challenge. Since Penult is a turn-based game, timing isn't as critical for many of the game's tasks.
I have divided all of the game's tasks
While I have aimed to keep my WIP 2600 homebrew Penult within 64K, I've always known there was a possibility that it could go to 128K. Maps and text strings take up a lot of this space, and I'm going to need a good amount more of both to finish the game. What made me make the choice to switch to 128K was sitting down and doing the math comparing what I have planned with what space I have left. I'm looking at dungeons now, and those maps alone will use up much of my remaining space.
T
I have enjoyed @SpiceWare's blog entries about the making of his games, so I thought I'd try my hand at it for my upcoming game Penult.
My first demo was pretty much just a map viewer for the Ultima 3 world map. I chose Ultima 3 because it actually has the smallest world map: only 64x64 tiles. Converting the Ultima 3 map to data I could use in my initial demo wasn't difficult, but the first problem was that it was still too big: 64x64 bytes equals 4096 bytes, or exactly the size of o
I've recently started playing the PC version Ultima III: Exodus via DOSBox with an upgrade patch to allow for EGA graphics and midi music to more closely match the colors and music of the original on other platforms. The PC version out of the box uses CGA graphics and has no music.
This was my introduction to the series, but I didn't play it on a computer when it came out initially, but rather on the NES many years later. I hadn't heard of the game, and I was blown away. The NES
I am working on a small subset of Space Game in assembly that will be 2K in size. Why? I figure it will be good optimization practise for me as well as a way to strengthen my assembly language development skills. Also, I'm fascinated by the idea of an Atari game small enough to be loaded from a QR code, so I thought I'd try my hand at making one myself. The released version of Space Game is 32K, and almost every byte of that is used. Is it realistic to make something 1/16th that size, and
Now that we have a minikernel that can display a life icon for each player and be positioned correctly, we need to display the correct number of lives for each player. We will do this by setting the NUSIZx register for each player to a value that displays the correct number of copies of the player object that corresponds to their remaining number of lives. Before we do that, we need to talk about minikernel variables. Minikernel Variables Most minikernels will need some variables that will
Up until now, I've avoided talking about timing and cycles in too much detail, but now we will take a closer look, as it will be needed to understand horizontal positioning of objects. Imagine for a moment that you are decorating a house, and you are trying to position a picture on a wall. You ask a friend to hold up the picture against the wall, then walk from the left side to the right as you watch. When it is where you want it, you ask him to stop, and then maybe ask him to adjust it a fe
As I've been shuffling around routines to make room for an AtariAge splash screen and "Have you played Atari Today?" melody to Space Game, it occurred to me that it feels like defragmenting a drive by hand.
79 bytes of ROM space left in bank 1 45 bytes of ROM space left in bank 2 0 bytes of ROM space left in bank 3 8 bytes of ROM space left in bank 4 0 bytes of ROM space left in bank 5 26 bytes of ROM space left in bank 6 61 bytes of ROM space left in bank 7
At this point, we have engaged in enough yak shaving - that is, we have covered some assembly coding and made a minikernel do different things, but haven't made visible progress towards our ultimate goal: a minikernel that will display separate life icons for two players. In this lesson, that will change: we will cover drawing player graphics, and use that in our minikernel. Before we get to that, there's a couple more simple assembly commands I want to cover that I didn't get to in the last
6502 assembly code may look a bit intimidating for those who are unfamiliar, with all of the cryptic-seeming three-letter commands (opcodes). In reality, the language is pretty simple, if a bit tedious in places. There is no need to memorize the whole list of commands - you will use a subset of the available commands most frequently, and you can look up the others as you need them. Many people recommend the Easy 6502 tutorial to learn the language. It's a well-done tutorial with a built-in
Traditionally, when learning a new computer language, it is common to make one's first program in that language be a simple program that displays the message "Hello, world!". Displaying text on the Atari 2600 is a bit more complicated, so instead a simple example that is commonly used is a demo that changes the background color on each line to fill the screen. Here is an example from SpiceWare's Collect Tutorial: At the end of this lesson, we will make a very simple minikernel in a simila
Who This is For Batari basic minikernels are bits of display code, written in assembly, that appears below the main screen of an Atari game made with batari Basic. They can be used to show lives, timers, and many other things. Are you an batari Basic programmer who wants to know how to customize your games by making your own minikernels? Or maybe you just want to learn how to create games in assembly, but want to start by building off of what you have learned with batari Basic? If so,
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord