These are some technical references, some related to DH, some just written during the development of DH.
The Software Dilemma (thoughts on why software is forever “behind” in capturing the true potential of the hardware)
NOTES on PET 40 vs 80 column mode…
The “standard” dhunterpet.prg can be loaded and ran on an 80-column PET (8032). However, the maps are not displayed properly making the game largely unplayable. There are ways to “convert” an 80-column PET into a 40-column, however most 80-column PETs use a “business” instead of “graphics” keyboard.
6/3/2021: an 8032 w/ business keyboard build of DH was prepared. Here is a sample of “before” and “after.
Having started DH from void main() {} empty problem, I had no third-party library or reference to consult for strategies on doing “flicker-free” animation. Even in the TEXT-SCREEN environment this is an issue. I took a break and thought about it for a couple of days, and then produced the PowerPoint presentation here to describe my approach. It may not be the most optimal, but it is robust to scale to larger projects, and is a completely original approach. The performance is still somewhat sluggish, but I still consider it playable.
Here is the Microsoft Word version of the manual, in the fashion of the original computer games that came in boxes and had manuals. As a teaser, I thought about adding a “copy-protection” by asking “enter word 5 on page 6 of the manual” (with the joking being that any answer would be accepted)
In design the maps, I first did sketched by hand, thinking of what items would be needed, and the general flow of the game. I then mocked up these maps in PowerPoint, and refined additional details (where water would be, form of rocks). I also kept some screenshot records of the game now and then during the development, to refer to in case the game wasn’t runnable for some reason while in the middle of other development.
The PET has two character sets and a “text” vs “graphic” mode (non-gap), and so does the C64. It became very helpful to have a visual record AND corresponding code for these symbols as an easy to find reference. So I wrote a program to generate these tables, and I use VICE to run all the variations of equipment. Then screenshot those results and archived in this PowerPoint for reference throughout the development.
I’ve been programming for a very long time, and I think I’m fairly decent at it — not supreme, just above average. I say this because there is no code that I’m afraid of. Some peers I’ve had did shrink away from a task, not willing to “get their hands dirty” and study code they hadn’t written themselves. To me, all code is like putting on a different jacket, I’m comfortable around it. All programs are just shoveling bits around, here to there. But I’ve pondered often if there is a “better” or more insightful way to write software, beyond what has been created with High Level Languages. Typically the answer is “if there was a better way, someone would have thought of it” — as every year, there are routinely young energetic people passing through universities, with plenty of time to ponder such things. Anyhow, below is a presentation I put together on some thoughts on what might be a helpful way to do certain types of programming — IOB (Intentional Oriented Programming). I don’t know if it will ever get any traction, but I think it would be a fun thing to try to build someday.
PDF version:
This Excel worksheet contain various notes related to DH, like the set of rules, the RLE encodings for the maps and blockers, and just some interesting things I kept track of throughout the development. Mostly it started as a “memory audit” of the program that I would do once in awhile, but it grew into a larger repository of information.
D
Destiny Hunter 