Well I simply answered some of my own questions from the prior post and continued developing my attempted recode of "Dojin" based on Mr. Suzuki's sketch and the descriptions provided by John Szczepaniak who interviewed a bunch of Japanese programmers for his book "The Untold History of Japanese Game Developers." Vol 1. First I got a BASIC only version running, but it was a little pokey, so I compiled it using Greg Dionne's MCBASIC compiler. Here's the BASIC version:
Here is the compiled version:
If you are seeing this post without reading the prior ones, Mr. Suzuki's "Dojin" is a lost program. It was inspired by one his earlier groundbreaking game programs "Shoplifting Boy" aka "Manbiki Shounen." Dojin then helped inspire the groundbreaking game "Uchuu Yusousen Nostromo," by Akira Takiguchi (Masakuni Mitsuhashi did a NEC PC-6001 port that I used for my port), which is considered a very early example of the survival horror game genre. This project was suggested to me by John Szczepaniak. His book provides the only substantive information that I am aware of about this missing game.
I plan to have my son Charlie to play test Dojin and make final suggestions for refining the speed and timing, and possibly code some slightly more musical elements than the bleeps and bloops I'm only capable of. So there will be further updates. Until then the current version can be downloaded from the Internet Archive (but not played. The Archive emulator doesn't like compiled games):
But I have played the game a little (as you can see in the above video) and the player really has to work hard to avoid the enemies, so much that I wonder if "Dojin" is a Japanese play on words for the English word "dodging" (the title I will give it if I get word that it is not a good representation of the original). But according to Szczepaniak it means something like "native" or "aboriginal" in Japanese. The light green objects are meant to be trees of the forest. So the vibe is that you are some kind of colonialist (probably wearing a pith helmet) being chased by locals around their pastoral home. Not sure what the obstacle is. Either a rolling log, which is how my son and I thought of it, or a "car" of some kind (or possibly a bulldozer bringing "progress" to the local population and landscape."
I have been working on my implementation of the first variation of the rough sketch of the game provided by Mr. Suzuki. I now have a working group of four enemies ("Y"s) and a player ("X") moving in the maze. The enemies track whenever they reach a corner junction. They can get pushed along by the orange obstacle. If conditions are right they get crushed at the ends. I haven't put in detection of whether they hit the player or the player gets hit by the obstacle or new screens if you kill all 4 enemies. Using pure BASIC it is a little bit slow. Adding more refinements will probably make it a little slower again, although I can probably make the code a little faster with the application of speedup techniques, but I think I'm just going to have to compile it using Greg Dionne's MCBASIC compiler. Then I'll probably have to add delay loops to keep it playable. So I can't tell yet whether it will be a playable/enjoyable game. So many questions remain unanswered:
How many enemies? [I've chosen 4]
Do their numbers increase with each screen cleared? Their speed? [Mine: speed increases every screen cleared]
Levels of play? [none]
Does the player have lives? How many? [4] Can they earn new ones? [no] Where do they respawn? [bottom left]
Splash screen?
Points awarded for enemies eliminated? [1]
Scored displayed? Lives? Where? [bottom left and right]
Instruction screen? [none: Use WASD keys]
High Score displayed? Where? [bottom centre]
Thanks to John Szczepaniak for the project idea and doing the interview with Suzuki, which is the only real source of detailed information about this lost game, and my son Charlie for his coding suggestions and discussion.
John Szczepaniak emailed me with a suggestion for a possible "recoding" project (He'd noticed I do such projects) regarding a lost game from the early period of Japanese Game development. The game "Dojin" was inspired by Manbiki Shounen. It then helped inspire the game Nostromo. Here are some notes of my discussion of the program with my son Charlie, who watched the video transcript of Szczpaniak's interview and was able to use his knowledge of Japanese to provide some further context about the conversation going on.
From the descriptions Charlie heard in the interview and from the transcript and from the two diagrams, one by the Hiroshi Suzuki on the top left and another by a fellow programmer, Masakuni Mitsuhashi. Both were youthful programmers and game enthusiasts who had been contracted by Taito to create games and show them to the company as a kind of game idea incubator/computing club. Mitsuhashi had also played the game. I was able to rough together two MC-10 variations of the game screens based on their different sketches and descriptions:
Mr. Suzuki's Sketch
Mr. Masakuni Mitsuhashi's sketch (Thanks Charlie for helping create this one):
As John Szczepaniak pointed out in his email the two sketches and two descriptions suggest quite different games. The first one would involve what I felt was a fairly straightforward 8-bit BASIC text game using standard tracking algorithm for the enemies moving along the cyan colored hallways. The orange item/obstacle moves from top to bottom (or bottom to top, or both) and the player must lure the enemies via manipulation of their tracking behaviour to "cross the road" and be crushed by the orange moving obstacle (like a "car" on a road is mentioned, or a "piston" or pendulum). There is also an object in Masakuni's version but it is not shown in the screenshot above. In Masakuni's description the player navigates between closed rooms or cells (both descriptions mention a "forest" or "trees") by breaking the walls between them. Masakuni suggests that the enemies have a harder time breaking the walls and so move slower than the player. But the overall goal is the same: Lure the enemies onto the "road" and time it so that they are crushed by the orange object as it moves up and down.
According Szcepaniak, Dojin was a forerunner (inspiration of) Nostromo:
JS: Nostromo was also inspired by Mr Suzuki's unreleased game, called Dojin?
AT: Yes, certainly. I created Nostromo on a PET CBM. Later Mitsuhashi-san ported it to PC-6001. My idea was different from Dojin - actually, Dojin was a very interesting and playable game. But the enemy was always viewable by the player. So because I loved [the film] Alien, as well as Star Wars, I wanted the enemy invisible to the player. Visible only when it is viewable by your character. So that's the idea of Nostromo.
MC-10 Nostromo based on NEC PC-6001 version
In terms of game dynamic Nostromo has a large red "niche" in which the player can shelter from the Alien (the Alien will often pace back and forth in front of it before randomly veering off down another hallway). That niche reminds me of the little "randomly distributed" niches in Mr. Suzuki's diagram. But Nostromo also has a dynamic of breaking the walls of the 8 "lockers" that the player must access to retrieve the randomly distributed items needed to clear screens. So I'm in a real quandary about what the game was actually like. I am pretty sure I can make a game similar to another Japanese game called Heiankyo Alien, which also has enemies that track you through a linear grid (the programmers discuss this game on page on p. 400). That game inspired the game Space Panic (mother of all platform games) and involves digging holes and luring the aliens into them, then quickly refilling the holes before they can escape. I could see using Suzuki's map to do a very similar thing, except you lure the enemies to the central road area to be crushed. Here is a video of Heiankyo Alien:
The main problem I can see would be in how the enemies react when they reach the road. My thought is that they should always proceed across to the other side. That way they won't just end up wandering in to the central road zone and wandering around to be killed. The player would then have to use careful timing and reading of the enemies' tracking behaviour to lure them onto the road for a sure death.
But that suggests that there might be something to the "walls and wall breaking" of the second sketch. Perhaps the dynamic that prevents the aliens from simply wandering to their deaths on the road as they track the player is that they are compartmentalized. If they break walls at at a slower pace, then that might give the player time to create paths to lure specific ones to an exit to the road that the player creates. That dynamic would have aspects like the wall breaking in Nostromo, which requires 2 or 3 shots before the player can blast through the outside wall of the 8 lockers/rooms.
Szczepaniak seems to agree that the wall breaking dynamic has some advantages. In his email he says:
"I probably won't attempt [to recode] Suzuki's description, since the way he described the random forest, and hiding in the gaps, sounds difficult to implement."
I'm not sure it is difficult so much as it is unclear how the tracking enemies will interact with the road and its continuously moving obstacle and whether the resulting dynamic would provide an interesting game or just a exercise in temporary avoidance until the enemies wander to their deaths. But the second variation also has unknow dynamics. If the aliens are randomly placed then they will begin tracking towards to the player. Perhaps they need several attempts before walls breach for them, but will there really be enough time for the player to create trails and lure specific ones into following to the road? Should the player move slightly faster? Once on the road how quick (what rate) should the obstacle move?
As Charlie pointed out the obstacle's movement rate (the ratio of obstacle's movement rate from top to bottom or vice versa and the player's movement rate) can't be so quick that the player can't make it across or up or down and back into the "forest". And for both variations, can the enemies get swept before the obstacle (as it moves either up or down) but still move right and left to possibly escape back into the forest before being "crushed" at top or bottom wall edge (mentioned in the interview transcript)? That would certainly increase the need for timing one's luring.
And for an MC-10 re-code (same screen as the NEC-PC6001) would the reduction from the 40 by 25 screen of the PET to a 32 by 16 screen disrupt the original dynamic regarding these relative rates? So many unknowns... In the end, I will simply have to code each dynamic, do some tweaking of the relative movement rates and see if some kind of playable game "emerges." And then perhaps send some video to the original author and players to see if either variation comes close.
Here is an actual page from S's book with part of the transcript:
Any comments or suggestions would be much appreciated.
SPOILER ALERT! The above is a complete walkthrough of the game.
This program is from the July/August 1980 issue of Recreational Computing Magazine. I have made a port to the TRS-80 MC-10 using Microsoft Color BASIC. It is a simple text adventure designed to introduce children to text adventure games. My version of the game can be played online here:
I used Commodore 64 source code. There doesn't seem to be any easily available original TRS-80 Model I/III code out there.
It is a very gentle and forgiving text adventure. Hints are provided at the beginning to familiarize players with the basics of two-word parser text adventuring. However, this does not mean it is without its challenges. There are some subtle puzzles that need to be figured out, which will challenge neophyte players.
I have made a few edits to the text messages of the game. Some are just for clarification (perhaps simply my own). Others are indulgent. I changed the name of a university mentioned. I wonder if Dr. Furman taught at that university? It's in Texas, but the game otherwise has a distinctly British vibe to it. Perhaps it is simply its "Alice in Wonderland" style, or its the name "Nellan," which seems quintessentially English to me.
But I can't see much about Smith there, but the magazine original article supplies these details:
Furman Smith received a Ph.D. in Probability and Statistics from the Florida State University in 1972, taught three years at the University of Kentucky, and has since been at the University of Houston Victoria Campus. He is currently an Associate Professor of Mathematical Sciences teaching four courses, Chairperson of the UHUC Faculty Council, and a member of numerous committees including an eight faculty member group that is advisory to the President of the University of Houston System. He has a marvelous wife, two marvelous kids, one good home computer, a garden, and backlog of work.
Nice. From one academic with a backlog of work (who is doing this project during Winter reading week) to another, thanks for a wonderful game Dr. Smith!
I ran across a neat post on the Atari Archives Site that discusses very early computer versions of Checkers. Kevin Bunch mentioned a version of the game on the Bally Astrocade system that was by John Collins. I've converted other programs by Collins and other programs for the Astrocade system.
The system had limited memory, about 4K. It was one of the first early video game systems to also include a version of BASIC (a reasonably good one for a machine without a keyboard). Those limits seem to have inspired high levels of programming cleverness among coders. In the late 70s these pioneers created very memory efficient games with AI features within the extreme limits of 4K. Their skill can be easily leveraged to obtain programs that can run on the 4K MC-10 as well. I converted a very powerful Othello game with a strong AI by Clyde Perkins called O-Jello, which works in only 4K. And Collins made a very clever but fairly extensive text adventure Bally's Alley in only 4K.
Collins' Checkers source code is preserved on the Archive as a printout listing from the Arcadian newsletter:
Bally BASIC is not that hard to work with. It has a few differences from the Microsoft variation provided with the MC-10, but they are not hard to adjust to-- Semicolons for separating commands on the same line. No OR or AND Boolean operators. It uses # for "not equals" instead of <>. The biggest challenge is that it uses a cartesian graphic coordinate system which starts at the centre of screen, instead of the upper left corner and therefore uses negative numbers. I'll put my version up on the Internet Archive, so if people want to play the game, it might be a little easier than using a Bally emulator, since input for that system was only by controllers with numeric keypads and overlays for functions and alpha input (as with the old telephone key pads).
I also have been making a few graphic fixes to some of my old programs. I rejigged the splash screen (see just above) and the menu operations of my Micro Color Trek. This version is from some Coco version I acquired back in the day. I think I typed it in from an old BBS. Since the MC-10 Micro Color Compact didn't have download capabilities, I had to list the file from the screen buffer to my thermal printer and then type it back in by hand while I also converted it to MC-10 BASIC. Then I modified it further. It survived the years on tape and I converted it to a WAV sound file early in the 2000s and then converted it to an emulator C10 file. So I thought I would give it a little bit of a touch up. I discovered some unused musical note data typed in, but not accessed, probably for a Coco PLAY command. I had obviously simply ignored this data in my original conversion. I was able to convert the data for use with the SOUND command instead, and added back in some musical refrains at key points in the program's operation.
I also finally liberated from another one of my old tapes a "Crap" game demo program from the MC-10 User Manual. Like Trek, I had added some simple SG4 graphic dice, instead of just displaying numbers for the dice rolls. Back in the day these kinds of edits felt like monumental "computer hacking" to the teen me.
In the spirit of such hacking, I decided to modify a version of a Santa Claus graphic program from Family Computing magazine. I never liked the version of the chimney presented in that program, so I decided to make something better. I used the SG4 graphic editor to come up with something that I felt looked more like a brick chimney. Here is the original version:
Here is my updated version:
I also updated my port of the classic game "Switchbox" from the March 1986 issue of Compute! Magazine. I used the Atari ST source code for my original port. But inspired by a recent Youtube video discussing the program I changed the animation of the switches and added some more speedups to the code (e.g. converting to single character variables, using periods instead of 0s, combining lines): https://youtu.be/nZTqwJLJo-Y?si=A2of9-eoOkXpfBQI
Finally, I made some edits to Family Computing's New Years Eve program. It was originally limited to the year it was published (1984, if I recall). I thought it would be nice to update it so a date for any year (at least up to 9999) could be input. That way, the program will be functional for many years to come. Who knows, people might need their MC-10 to function in the year 2100...
Enjoy!
Addendum
I made some updates to Checkers. I added graphics for king pieces and the ability to hit N for a new game. I also streamlined the board display. Turns out, everything in terms of squares get placed by the piece placement routine, so I didn't need a separate graphic routine to display the board. I tested the game against the AI of a online checkers program on Medium difficulty and Collins' program beat it. But it lost when I set the level to Difficult. I just turned my phone upside down and input the computer's moves as my moves in Collin' game. Then I input the moves played by Collins' AI on the phone. If you take all the computer's pieces, it will sense the game is over and prompt you for a new game. Otherwise, if the computer takes all your pieces, you can hit N for a new game (or any other time you want to give up).
You have to set the modern game below to "force jumps" and to let you move first. Here is the site I used to test Collins' game:
This is a recode of a game from the NEC PC-6001 computer to the TRS-80 MC-10 using Micro Color BASIC. The original game, published in Mycom BASIC magazine in September 1989, used machine language to move the meteorites, but I just use a large string array, which I scroll through using variables and the MID$ command to create the effect of falling meteorites. Then I use VARPTR to POKE those meteorites out of existence if hit by an explosion.
The keys used to position your explosions are the following:
2 3 4 5 6 7
W E R T Y U
S D F G H J
Z X C V B N
As you can see, the programmer chose (no pun intended) to use a slightly staggered arrangement rather than simply following the diagonal left line of a QWERTY keyboard. I think this makes more tactile sense as it fits better with the actual up and down orientation of the grid of shots.
I have played the game a little now. It is easy to settle in to using only the bottom row with 3 fingers from each hand. I suspect the original game plays a little differently. It might be faster, but you also seem to have the ability to launch multiple explosions at the same time, a byproduct of the use of machine language and the ability of the NEC to run sound in the background. So I think my program is not a completely accurate rendition of the original gameplay. But I think it does present some of its challenge within the limitations of a fully BASIC variation of the game. My version has only 2 levels of ground above the three bases you are trying to protect, rather that the 3 from the original: _ - =
This decrease perhaps makes up (somewhat) for the lack of speed of my version. And of course, since you can have only one explosion going at time, it requires the player to (perhaps) be more selective when choosing targets.
The original programmer Kenta Cho seems like a really interesting fellow. He is described as an "indie programmer" and he has been responsible for some recent game hits like "Paku Paku." Here is some information on the original programmer: https://blog.gingerbeardman.com/2024/02/10/interview-kenta-cho-indie-game-developer/. But his programming career began back in the early 80s on the NEC PC-6001 home computer and using BASIC. From the interview, he credits some of his earliest inspiration as a programmer to playing games originally programmed in BASIC, like Heiankyo Alien, which I have also ported, and their creative game techniques and narrative premises.
If you want to see the original being played, look here:
I think I have found another bug in a commercial BASIC game distributed for a computer equipped with the Motorola MC6847 Video Display Generator. I recently ported the code for "Super Mind" for the Sanyo PHC-25 to the TRS-80 MC-10. Like my last project from that machine, "Fire War," there was a bug in the code that I think would have prevented the game from functioning as the designers intended. In Supermind the problem would only have occurred on the last of your 10 guesses. For that guess there was no need for the computer to print a report about how many of your guesses were right colors and rightly placed, since it was your last turn, so the programmer had created a special routine for your last guess. But I think that guess would never be able to be judged correct.
The following routine calls the input your guess routine (3000). Then if the number of the guess you are on is 10 it will jump to the last move routine (5000). Otherwise, it goes to the check the guess against the hidden code (4000), which counts up the absolutely right guesses (O) or right color wrong places. If the number of absolutely correct guesses is 4 (O=4), then it jumps to the end of game routine (6000) to print the appropriate congratulatory message. Otherwise, it keeps getting guesses (2510).
The following analysis applies to the code block listed here, which is the routine jumped to for your final guess (5000).
5000 REM Reponse dernier coup
5010 IF Z=1 THEN 5050
5020 FOR I=1 TO 4:LOCATE2*I+2,1:PRINT" ";CHR$(C(X(I)+1));" ":NEXTI:GOTO5090
5050 LOCATE4,1:PRINT " "
5060 FOR I=1 TO 4:LINE(42+(I-1)*16,18)-(45+(I-1)*16,23),X(I)+1,BF:NEXTI:GOTO5090
5090 IF O=5 THEN 5100 ELSE 5110
5100 LOCATE0,13:PRINT "Í° Gagne en 10 coups De justesse !!! ":GOTO5120
5110 LOCATE0,13:PRINT " Vous avez perdu... "
The problem is that the check routine (4000) is not run anywhere in this last guess routine. Line 2510 of the calling input routine either runs that check routine or jumps to this final guess routine. The final guess routine simply prints the last guess input (5000-5020) and then prints the hidden code (5050-5060). Then a check is made whether the number of exact correct answers (O=5) equals five (5090). If it does, then it prints a game won message, otherwise it prints a game lost message. This is very strange, since the guess check routine (4000) which determines how many absolutely correct selections (O) have been made has not been run. It is unclear why O would contain any number other than what it contained from the 9th turn guess. And it is unclear why O equaling 5 would be an indication of a correct guess of a 4 digit code. It might have made sense to do a simpler kind of check, perhaps to compare whether the guess perfectly matched the hidden code, but that does not appear to be done anywhere in the above.
Now it is somehow possible I have misinterpreted some aspect of the program or some nuance of the type of BASIC used on the PHC-25, but I really don't think so. The BASICs are very similar and conversion is not particularly difficult. There are no obvious nuances that I think could overcome this problem. The code certainly had the effect of always saying you lose in the MC-10 version I made. I had added a simple cheat for testing, which printed the hidden code at the start of the game. So I could see the right answer. But no matter what I input on the last try, correct or not, I would always be told that I had lost.
I can make a few guesses about why the code might have ended up like it did. The programmers might not have applied my cheating technique to do bug testing. It was an easy thing for me to add when I work with a modern text editor and can easily create subroutines and add and subtract lines in a temporary fashion. But when you were coding with the clunky line editing back in the day, these things were tougher. Also, it is possible that the authors intended to add a routine or line that did the simple test I mentioned, which would return a 5 if the two codes matched perfectly, but then forgot to add it.
I made some changes to fix the lack of a comparison check of the guess and the hidden code to fix the problem. My experience with the software made for the PHC-25 has left me very unimpressed. Another game I converted Labyrinth also had an error in it.
I was able to bug fix that error:
But along with the problems in Fire War, it's a pretty poor record of software reliability. This perhaps helps explain why the PHC-25 computer was a market failure. If you are interested in trying the game in my modified form, it can be played here:
