As I am now going into year 8 of creating my vintage CRPG, It’s time to take a look back at things and share what I’ve learned from the experience of having a hobby programming project. Or, you know, I’m just looking to write something in my blog today.
Know your Platform and Resources
Before you start out, you need to know what you can do, and what kind of tools you have.
Programming on your ACTUAL vintage computer sounds like fun at first. But the truth is, nostalgia has made you forget some of the little problems with that old hardware…
For one thing, old computers ran HOT. Even modern computers can warm the room, but your old computer would get hot enough to make that funny heated plastic smell. Could be a little alarming after all these years to smell it, it starts you thinking about whether or not you should keep a fire extinguisher close by.
On that note, old hardware is old hardware, after all. You don’t know how much longer you have on a given chip or device before it dies on you. Fixing it or finding replacements could prove time-consuming and costly; vintage hardware is not that much cheaper than modern-day due to rarity. And finally, old computers lock up a lot. My old TI was particularly sensitive around the side-port, one bump and goodbye to hours of work.
Obviously, an emulator is the way to go. There are a large variety of emulators available nowadays that do a great job of emulating the original hardware. Plus you have the added bonus of being able to write up your code in a text editor on your PC and just paste it into the emulator. AND emulators can usually be ran at much higher speeds for compiling purposes.
Some other useful tools:
- Microsoft Excel. Spreadsheets are excellent to use to track data structures, graphics, and other aspects of your work
- Hex Editor. You can find a number of commercial and freeware hex editing software which will let you directly alter your emulator’s data files
- Paint Programs. Useful for creating graphics for your game
Engine First, Content Later
This particular issue happens a lot with game design. Namely, you get so excited about the end product that you start doing the content work before you’ve even written a single line of code.
For myself, I’ve wasted a LOT of 8-10 square per inch graph paper designing maps for my CRPG that was, in the end, a lot of wasted effort. I got so caught up in the story ideas I had that I just had to design the maps for it. I told myself it was important research work for the game engine of course… I had to know how much flexibility the engine needed, after all.
Of course, while you’re doing all this, you’re not actually doing any work on getting the game engine done. If you did things in the reverse manner, then at least you could update your story to match what the engine can do, and you have something substantial to keep working on.
Funny enough, I’ve seen the opposite as well. I read an interview of a programmer for an arcade clone on the TRS-80 Color Computer. He showed a remarkable degree of coding awareness and understanding of the platform and how to get the best performance out of it. But when he was asked about game design or what he thought of other games, he seemed lost and confused. He knew how to copy the game rules to an existing game and make it work on the platform, but creating his OWN rules or game was completely beyond him.
Commit to a Design and Stick With It
There is no way I would have finished this game as a teenager. The amount of compiling, debugging, and hunting down bugs would have bored me to tears. Plus, my disk drives would have burned out with all the compiling work I was doing.
The truth, though, is that any sizable programming project should be planned out WELL in advance, and almost written away from the computer entirely. With modern tools, it’s too easy to fall into the pattern of cowboy coding: Put something together and see if it works.
This also helps with another issue: Redesign. Software is never a step-by-step process. You often end up going back and changing something later, which affects your current work, which requires redesign and recoding, and so forth.
But the problem is made even worse when you change your mind about fundamental aspects of the project itself. For myself, I’ve altered the design of the game engine (as in, the rules by which the game is played) four times. Each time required a massive reorganization and updating of data, code changes, and even design alterations.
I could have avoided this problem had I sat down with a pad of paper or two and just wrote out my design and made sure it worked on paper first. Some redesign was inevitable; since I was discovering the capabilities of my computer in the process, some ideas proved to be too burdensome or grandiose to follow through on. But it’s almost better to finish something sooner than get stuck in a constant cycle of redesign.
Use Source Control
This one is a major requirement of modern-day software engineering. Source Control lets you maintain version history of your files, lock files so that multiple programmers can edit the same files but not overwrite one another, etc. You read stories about companies and teams who refused to jump on this bandwagon for years, but sorry, this is totally necessary.
But why for vintage game programming? And when you’re the only one on the team?
Well, the main value is the version history. If you have data sheets that are undergoing a lot of changes, it’s good to be able to refer to a past one. It also helps you consolidate changes easier. Truthfully, I still don’t have a source control system going for my CRPG, and I really should get one so it’s easier to sync up files between locations.
Comment Your Code
Yeah, you’re the only one writing it, right? And real programmers don’t need comments, they just figure out what the code does at a glance right?
No. Comment your code. Trust me.
If you’re working on a hobby project, you’re going to have a lot of other things that are going to interfere with it and make you stop it for long periods of time. Commenting your code will save you a lot of grief and time trying to figure out what you were doing.
Also, commenting can help you lay out the logic path of your code. Often in assembly language, you don’t have a lot of context as to what register is storing what value. Using comments to remind yourself of what this code is intended to do can help you find bugs later when you look at the logic and say “Hey, wait, that’s not right.”
Document Your Progress
Creating and maintaining a blog or website on your hobby project is very good to keep you motivated. You often create in a vacuum with no feedback on what you’re doing. Having a forum to share your work and experiences can do a lot to encourage you to keep going.
Take caution, though. If you’re the type to start and stop your project a lot, your support group may end up going into a “put up or shut up” mode of thinking. They will be waiting for you to deliver something rather than offer praise and encouragement with no return.
In my experience, prototype approach is best option, also for big projects.
I have build a 8 years/man project (according with function point analisys) step-by step with prototype approach and released 400 version of program… and finished in 4 years… using Access,vba and java…
Difference is tool/programming language…
assembler is good for little routines, the truth is this….
Glad to see you’ve resumed work on the game! It’s looking good.
Even though my game compiled into a 35K binary, I had several megabytes of source code files, excel spread sheets. As for source control, all I did was copy-paste the source code files on a daily basis. It was very helpful, especially when I had to revert to something that had worked previously.
Its all about the journey 🙂