This article was originally posted on my blog.
Lets start with a bit of history. Before Windows, PCs ran on MS-DOS, and in the late 80s and early 90s DOS reigned supreme.
Some of the greatest games of all time were written for DOS. In order to capture the feel of games from this era I decided the best way to do so was to make a game the same way games were made then, so I wrote Chuck Jones: Space Cop of the Future for 16-bit DOS. However DOS had some serious limitations, a maximum of 640k ram, low-res low color graphics and often running on slow CPUs.
I've recently been getting some questions about my process such what tools I use or how I work. Seeing as I haven't written a super technical article in a while I figured that this month I would dive in and explain all that, step by step. So buckle up and lets go. How does one make a game for DOS?
Step 1: Decide on what kind of game you want to make
This is extra important to do first for a game that will run on DOS as hardware choice will impose some limitations on you, for example a cutting edge first person with a big complex open world and multiplayer is probably not a realistic choice for MS-DOS. I decided I wanted to make an adventure game, seeing as there were countless examples of excellent adventure games for DOS, I decided it would be a feasible idea.
Step 2: Choose a Programming Language
There is probably no issue among programmers that is more contentious than ones choice of programming language. However if you are intent on making a game for DOS your choice of language is incredibly important. You will need to be doing lots of hardware level programming, and as such JAVA, Python, C# or Ruby are probably not going to be suitable. Unsurprisingly to anyone who knows me, the language I chose was C++. Although C is also a good choice and many people swear by Pascal. Depending on the type of game you choose, pure Assembly Language could also be the right choice, this will require a lot more time to write, however for a fast paced action game with simple rules where performance is key, this might be the best choice. Any game for DOS will require probably at least some Assembly Language even if you choose another as you main language, this comes down to performance, high level languages simply cannot express what is needed for optimal performance on older hardware.
Step 3: Get some tools
Although Chuck Jones is written for DOS, I must confess it is not developed on DOS. It is 2017 after all and I take advantage of that by using a modern Windows 10 PC for development. As I was intent on using a modern OS for development I had to ask myself, is there a C++ compiler that runs on Windows 10 and produces code that runs on 16-bit DOS? Well there is, OpenWatcom! Watcom was highly successful in the 1990's and is still being developed under the Open-Source project OpenWatcom V2. While I can't say enough positive things about OpenWatcom, there are some other options such as Digital Mars which I have not tried yet and then there are a few that run on DOS, such as DJGPP (32 bit only) or Borland Turbo C++ if you wanna go old school.
Now you're gonna need an IDE, OpenWatcom comes with one but I prefer something more modern. My choice is Visual Studio 2017 but any IDE of your choice will work.
Of course there's more to a game than just code. One necessity is a good image editor for making sprites and backgrounds and a game for DOS needs some special attention here. DOS games are usually limited in terms of colors and often use a 256 color palette. Naturally you will need a program that gives you control over this, I use Pro-Motion NG which has some excellent tools for working with indexed images and it's dithered gradients. Tools like Photoshop or GIMP are also useful for a great deal of the work, but I always bring the image into Pro-Motion for finishing touches. If you want to go the DOS route you can also use good ol' Deluxe Paint, which was used for many classic games in the 90s.
There's one more aspect that needs special attention and that is music. Making music for obsolete sound chips is a bit too involved for this post and will probably be the subject of my next post. So see you then!