As I start to reflect on participation in my first retrochallenge, it has been a really fun and challenging experience that has inspired me to create a program I have been thinking about since I saw the movie “Field of Dreams” in 1989, so 26 years later I have finally written the program for the baseball board game I loved and spent many hours playing a kid, “Sports Illustrated Superstar Baseball”. I would not have accomplished this if I hadn’t set my mind to participating in the challenge, and the challenge provided the time boxing to stay focused on this effort. Also having acquired the actual Times Sinclair 2068 that I never had but wanted as a Timex Sinclair 100 owner, provided additional motivation. Fellow participants and social media did provide good entertainment and inspiration as well.
So as I complete the project I wanted to reflect on the guiding principles I outlined at the onset of this adventure. Having these did really provide the “gutter guards” I needed to keep the project on track, here’s my thoughts.
1. Get the game to work, optimize later if there is time or required to fit in available RAM
Many times I stuck to this approach which kept me on track and making progress on functionality of the game. I would not have finished everything on time if I did not. This did come at the price of many subroutines that perhaps are not as efficient as they could be and screen display routines such as the roster change screen that are slow, even for the hardware on which they are intended to run.
Three things I did implement to save some RAM: (a) recoded all of the outcomes from the player and pitcher cards from two character codes to one character codes, this saved close to 2k of RAM; (b) remove extra spaces when using “:” on multiple statement lines; (c) my REM statements were shortened – so they may be a bit short but I think still meaningful enough to help debug.
- Data from Player cards will be hard coded, if time permits after the game is complete allow loading player data dynamically from “tape”
I stuck to this and did reduce the player data to only those that are needed for the two teams AL and NL for this version of the game. I do have the data for other player cards if I decide to take this further.
- In July stick to this computer project – stay focused
I did pretty well here, if I hadn’t set this principle I would not have completed the project. The big risk to this was when I scored a TI 99/4A, cassette recorder, speech synthesizer and program cartridges on eBay for $40, and downloading and playing with Free Pascal / Lazarus (cross platform GUI develop) which did take a few hours of my time that could have been devoted to this project. That said I have two future project in mind with this two new “toys”.
- Goal is to have final program run both on TS 2068 computer and in emulators on Windows 7, and Raspbian on Raspberry Pi
This goal has been achieved, as the ZX-Modules tools have made this very easy. Also the Eighty-One emulator’s ability to create .wav files allows for easy loading onto the Timex Sinclair 2068. My Laptop runs Windows 8 and all the tools and emulators are working well on it.
- Keep Game play as close to the board game as possible
As far as game logic goes the only notable exception is the assigning a -5 defensive rating for a player put in at a position he is not rated. The rules of the game to not address this situation, but a kid playing the game I had “invented” my own rules to accommodate the gaps I had found, this approach is in alignment with my rules modifications.
- Keep a parking lot for ideas for future enhancements to manage the urge of scope creep
I have kept a notebook with many ideas, which I may post time permitting, and having the parking lot allowed me to track and move forward without having to put in every idea. I did implement a couple of things I thought were really needed, such as picking who is the home team, and the “*” to denote current batter or current pitcher in the change roster screens.
- Utilize subroutines for repeated tasks
I would have to give myself an A+ on this one, which really sped development of many similar features as I went along. The subroutine for handling Manager Decision Outcomes came in very handy here at the end of the development cycle for the half dozen batting outcomes that allowed for this option. By simply setting a couple of variables I could use it for all cases. One can get a sense of the nature of the approach by seeing my post “PROGRAM DOCUMENTATION” where there is a brief explanation of each block of code and a downloadable version of the source code.
- Document in this blog as code is written, to keep up and provide frequent updates
I give myself mixed reviews on this one. I did a fair job of providing frequent updates, utilizing pictures and a video (more to come). As typical I might have sped up the program documentation if I had done more along the way. On the other hand, code does change and would have required updates to the documentation, which is not the fun.