I guess it is about time for another little update. I don't have a lot of info that I'm ready to share, so I guess I'll have to share some code for the Fahrfall fans to fondle... :-)
Beta 1 doesn't have any sounds (annoying or otherwise) that the Alphas didn't have. I'm still working on some things in that department -- I think Fahrfall's fans will be pleased! I'm know that I'm excited...
I'm not sure which direction I will go this weekend. I'm definitely having some fun with audio, but there is the physical part of this project to cover as well. Which to cover next? Well, I guess you'll have to stay tuned... :-)
Well, July continues apace...I guess it is time for another update on Fahrfall's progress. Things are looking up! After getting my feet wet with some low hanging fruit, I moved-on to some slightly more difficult features. For the most part, these are inspired by the past couple of years of playtesting at public events...
Pick Up The Pace
I think that Fahrfall's biggest weakness in the past has been its constant, somewhat...slow...pace. The most common question I get after someone has tried Fahrfall for a while is "does it get any faster?" I think that the steady pace actually leads to a lot of games ending due to the player losing mental focus...
The reason that Fahrfall has had a steady pace is because the timing of the platform movements has been driven by decrementing a counter until it hits zero. The value of that counter was fairly small, so any adjustment of it caused big changes in the speed. Therefore, changing the speed of the game during play was too jarring to seem reasonable.
In order to change that, I reimplemented the platform movement timer to increment by a variable value. The movement happens when that timer count overflows. Since it takes a reasonably big value to overflow a counter in a small number of increments, that value can be adjusted a lot more easily for a wider range of possible movement speeds. This technique allows me to make small increases in the platform movement speed as each new platform is introduced, causing the game to gradually speed-up over time!
As the game speeds-up, playing gets a bit more difficult. It doesn't seem fair to still award the same number of points per unit of play when the game runs a lot faster! So, I used the same "overflow timer" technique to modify the timing for the scorekeeping. Now the scoring becomes visibly faster as the game progresses until it tops-out at a blinding pace! :-) Change Of Scenery
I always wanted the platforms to change as a game of Fahrfall progressed, but I had trouble determining what algorithm should drive that change. I did modify the alpha releases to change the platforms from one solid color to the next every 64 platforms or so, but that was still a bit boring and a good player would have little trouble "wrapping" the color cycle.
The mechansm for changing the platform colors and patterns was built into Fahrfall long ago, with each platform's data structure holding pairs of graphics data representing the tops and bottoms of a platform section. The new algorithm implemented an 8-bit LFSR where 3 bits chose one color, 3 bits chose another color, and the last 2 bits chose a pattern. Patterns include solid parallel lines, segmented lines in alternating colors, a "checker board" pattern, and a fourth pattern that throws-in some black blocks to look a bit "twisted". Any of the first three patterns might also look like a solid color if both color choices match.
With the new color/pattern algorithm in place, I made Fahrfall choose a new platform color/pattern every 32 platforms. This gives a nice (albeit minor) reward to the succeeding player and helps the player to keep track of the game's progress.
Can You Hear Me?
One thing that I have always wanted to have in Fahrfall is in-game music. Very few games for the CoCo have in-game music, and even the sound effects tend to stop the action while the sound is played. The CoCo audio hardware completely depends on the CPU to do the heavy lifting either of feeding audio samples to the DAC or of flipping the 1-bit "beeper" output. Realizing these facts had convinced me to put in-game audio on the "nice to have" list for Fahrfall, but nothing more.
Still, the desire was there. Fahrfall is timed around the vertical sync output from the VDG, which is used to do most of the graphics work while no image is displayed. There is some work done during the active display, but there are a lot of cycles still free. I decided to experiment with playing tones _only_ during that free CPU time. The segmented audio wave that resulted sounded a lot rougher than a constant pure tone, but it was good enough to make me explore some possibilities...
One option that I am considering is to play some sort of sound effect to add to the game's ambiance. I was able to put together a little sample of one idea after some experimentation yesterday. I like it, but I'll probably do something a bit different in the final version. Nevertheless, I thought you might enjoy a taste of my thumping beat. :-)
Several people seem a bit apprehensive over that beat! I think they might get used to it, but it doesn't really matter. Like I said, I'll probably do something at least a bit different in the final version. Still, I do like how that audio makes me feel when I play Fahrfall -- it is like playing Fahrfall at a rave!
Anyway, this is getting a bit long...I'll keep working on some audio options and I may have another gameplay item up my sleeve. Plus, there is still the "arts & crafts" aspect of this project to explore...I guess you'll just have to stay tuned! :-)
We are now a few days into the Retrochallenge 2014 Summer Challenge, and I have been having a little fun with Fahrfall. Nothing too dramatic so far, but enough has happened that it is probably time for an update... Retool & Regroup
In earlier blog posts I had mentioned that I used an assembler called mamou. That assembler was derived from the assembler which Motorola originally provided on their long gone Freeware BBS. My friend Boisy Pitre took those sources some time ago and added a variety of features for targeting the BASIC environment of the Tandy Color Computer (CoCo), and the OS-9 operating system. FWIW, Boisy named mamou after a town near his home with a connection to his family and childhood.
The mamou assembler is relatively simple, but it has done the job for me. Nevertheless, Boisy has wanted to retire mamou for some time -- I may be the last user! Another CoCo user named William Astle has developed an assembler toolchain called LWTOOLS. Some time ago I promised Boisy that I would try using lwasm, the assembler from the LWTOOLS package. I am now making good on that promise. Along with the switch to lwasm, I have also done some Makefile clean-ups and some other housekeeping.
Some readers probably know that I am a Fedora contributor, and that Fedora is my preferred computing environment for day-to-day use. Given that, I have taken the opportunity to package LWTOOLS in Fedora. So, any budding CoCo software developers out there can now install LWTOOLS with a simple yum (or dnf) command. Let the retro-coding begin! :-)
Bugs & Low Fruit
The "random" number generation in Fahrfall is done with a software Linear Feedback Shift Register (LFSR). This is a mathematical construct that generates a distribution of numbers that can be used to create the illusion of random numbers. This code was simple and effective, and I had reused it when I created Sluzzle. Later, I discovered a bug in the LFSR code in Sluzzle. I fixed the code there, and this week I checked-in the equivalent fix in the Fahrfall code.
When a game of Fahrfall starts, there is an interstitial screen that gives some simple instructions before the game begins. That screen shows for about three seconds, but that seems to be too long for the most impatient players. As a first new feature for Fahrfall, I wanted to add a check for a button press to cut that timeout short. But at first, it didn't work -- the keyboard input routine always reported a button press. It turns-out that the keyboard routine was not properly reinitializing a variable -- it only worked previously because of luck!
One other simple feature actually changes the scoring. Until now, the scoring in Fahrfall essentially had been just a timer -- the score accumulated based on the length of the game and nothing else. Fahrfall already keeps track of when you are falling versus when you are riding a platform. So, I modified the scoring code to double the points accumulated while falling. Hopefully this provides some incentive for more daring play... :-)
Prototype Package
For some time, I've been toying with the idea of releasing Fahrfall as a ROM cartridge. A number of other retro platforms have had homebrew cartridge releases, and they seem to be a rallying point for the various retrocomputing and retrogaming communities. It would be great to do a homebrew cartridge release for the CoCo, and I plan to do some experimenting toward that end as part of the Summer Challenge. I'll do a post or two about that later...
Beyond the cartridge itself, people seem to appreciate a nice package for such things. It turns out that the CoCo cartridge width is a good match for a VHS case, and such cases are still available relatively cheaply -- make sure to get the ones that don't have hubs! The length is way too long for a cart, but a piece of foam board can be used as a spacer to keep the cart from sliding around. Also, many VHS cases can hold an insert to add instant graphics for a good looking game package.
So, there is a little sneak preview of the goal...looks cool, eh? Now I just have to whip Fahrfall into release-worthy shape, and figure-out how many cartridges I can make. If you want to see how that turns-out, then you'll just have to stay tuned!
A bit more than two years ago, Fahrfall was a winner in the Retrochallenge 2012 Winter Warmup. Since then, I have shown Fahrfall at three VCF events, four mini Maker Faire events, three CoCoFEST! events, and a number of other small events here and there. Many people like the game, and some people absolutely love it. Still, I've always felt that Fahrfall remains unfinished.
The Retrochallenge 2014 Summer Challenge starts tomorrow. I already intended to participate, and I even had a few other good ideas brewing this time around. Still, at some point I got a couple of brainstorms about some possible improvements that I could make to Fahrfall. I don't think that I will necessarily be able to have exactly the features that I envisioned two years ago. But, I do think that I can make some significant improvements and have a better game than what we have now. So, I've decided to return to Fahrfall for this summer's Retrochallenge competition.
In the meantime, I've also been putting some thought into how to produce Fahrfall game cartridges. Writing the code and even producing circuit boards never seemed like big problems. But, shaping plastic has been a bit of a mystery to me. However, I have recently learned a bit on that topic and I hope to share some of that over the coming weeks. I like the results I've been getting quite a bit -- I think you will be impressed!
So, improvements to Fahrfall combined with some arts & craft work -- fun for the whole family. There might even be more surprises along the way. If you want to see how it turns out, then you'll have to stay tuned... :-)
Wow! It's been a long time. I guess I got a little burnt-out after all my Fahrfall-related activities last year. But, at least I could have posted the updates that I actually made!
I assure you that with this version, great fun was had by all... :-) Coder's Block
I still maintain that I am not yet done with Fahrfall. I have a few minor improvements in mind here and there, but mostly I want to add some in-game music. I even have a few tunes in my head! The problem I originally had was that I knew that playing music would require some precise timing, and that inserting code to do that would make it difficult to make further changes to the game. Now there are few changes that I really want to make, so I guess that excuse is no longer valid.
I am not sure when I will get back to Fahrfall either for adding music or for any other new features. By now I already have a few other projects in mind or in progress. Maybe I should add support for my rotary controller to Fahrfall? :-)
In any case, I still think that I will be back to Fahrfall before too long...do stay tuned!
When it came time for this years Retrochallenge Summer event, I hadn't managed to come-up with a good idea for a project. So, I punted -- I said I'd just work some more on Fahrfall. Unfortunately, I didn't get around to that either. But, I did finally come-up with something good to do!
I have opened a new blog to describe that project. Please check-out my new Stupid VDG Tricks blog for details!
Whoa -- it's been a while...sorry about that! I can offer the typical excuses about life getting in the way and all that, but things really have been a bit busy lately around here lately. Along with the usual work and family stuff, I had a big deadline at work and I did a little work-related travel. Also, I've spent some of my free time in activities related to our upcoming Burlington Mini Maker Faire. Part of that includes time spent towards making an arcade-style joystick intended for use in my Fahrfall display -- I intend to blog a bit more about that later, when it gets finished. Anyway, what really matters is that I am back here now! :-)
Keyboard Control
I had always intended for Fahrfall to have keyboard controls. I had even added them at one point, but I had some problems working-out how to handle having the choice between a joystick or the keyboard. So, I backed that code out of the original Alpha 1 release. No one seems to have minded that, although it did cause a little confusion for someone on the CoCo mailing list while he tried to figure-out how the emulator handled joystick inputs. :-)
I think I mentioned earlier that we have been trying to work towards having a "makerspace" in my local area. As part of that, we have been having regular "maker club" meetings for the Alamance Makers Guild. I have taken Fahrfall as a "show-n-tell" to a couple of those meetings. The first time I did that was great, but the second time I forgot to bring a joystick! Fahrfall just isn't the same when you can't get past the title screen...
The CoCo keyboard is composed of a keyboard matrix circuit formed from the pins on a couple of PIA ports. Keyboard input is scanned by activating one column of switches at a time with one port and looking for certain input patterns on the other port. For Fahrfall, this is simplified by the fact that the CoCo designers cleverly put the spacebar and the arrow keys on the same row. The Dragon designers also did the same thing, albeit on a different row than what the CoCo used. These facts not only allowed me to use a simple routine to check all the required keyboard inputs but also allowed me to select between the CoCo or the Dragon keyboard based on whichever layout was used to start the game.
Selection
The joystick inputs on the CoCo will "float high" if no joystick is connected to them. This means that if there is no joystick plugged into the CoCo, they read as if the joystick is pointed into one of the corner positions. So, what? Well, that means that if we allow both joystick and keyboard input at the same time and someone tries to play without a joystick plugged-in at all, then the joystick input will force Fahrve over to one side of the screen, making the game unplayable. :-(
For now, my solution is to differentiate between whether the game is started using the joystick button or using the keyboard. If the user hits the spacebar to start the game, then that game will only use the keyboard. If the users starts a game with the joystick, then the keyboard will be disabled while that game is being played. This isn't my ideal solution, but I think it is workable. In the future I may find a good algorithm to simply detect when the joystick is missing and then to ignore it.
More To Come!
I've still got a lot in mind for Fahrfall, and time is ticking for my planned events. I had hoped to be further along than I am, but I think this will still work. Besides, it might be better to give Fahrfall some public play testing before moving much further in order to have a better game in the long run? Anyway, I do have in mind a few embellishments to make in the next few weeks...as always, stay tuned!
