Sunday, 30 April 2017

Teach Yourself Game Programming in 21 Days - Day 3

"Painting the Screen with the VGA Card", the first chapter with whole programs.

First, a bit of hardware history. The PC, being general-purpose, did not originally have a dedicated video card. The need for this became evident quickly, but there were many competing standards available.  VGA started to be used in 1987 (almost as old as I am), and the interface was so useful and easy to implement that almost every video card manufacturer conformed to it. Even cards today support it, I believe. Super VGA was a later improvement which added larger resolutions, but was otherwise quite similar architecturally.

VGA provides for a number of display 'modes'. The most important modes are:
  • Mode 12h: 640x480 with 16 colours, 1 page
  • Mode 13h: 320x200 with 256 colours, 1 page
  • "Mode X": 320x240 with 256 colours, 3 pages
There are a huge number of auxiliary modes with sliding scales of resolution, colour bit depth and refresh rate. If you don't mind being limited to the EGA palette, for example, you can run at 800x600 if your monitor supports it.

You might be asking why anybody would ever use Mode 13h when Mode X is available; the difference is in how the memory is laid out. Mode X (which is really just one of a family of unchained versions of other modes) uses a planar memory layout. This means that the bits for each pixel on screen are split between different parts of memory, requiring a command to be sent to the VGA controller for each plane. By contrast, Mode 13h simply has one byte per pixel, so it's easy to write code for.

The first code listing in the book is presented in its entirety below:
This gives some insight into both how André lays out his code and how lengthy this stuff gets. All this code does is change the video mode then back again. The next example shows how to actually draw stuff. I'll be uploading the code I write to a public repository so that I'm the only one who has to break their fingers. If you look in the repository, you'll notice I've worked ahead slightly. This is mostly because I'm not sure how much time I'll have each day to do this work.

About the code; as mentioned before, the author is using Microsoft C. I'm using Turbo C, which has different syntax and names. I'll make note when I find these out. I'll also be formatting my code differently because I'm not insane. Still, if you want to follow along then grab my code, run it through your favourite 16-bit compiler and run it in DOSBox for a blast from the past.

There are three more listings in this chapter:
  • colorrot: Showing how to do 'colour animation' by changing the palette contents instead of drawing new pixels. This is used in pretty much every DOS game I can think of, so it's a useful technique to know
  • strfield: A parallax, three-plane starfield. I remember recreating this effect about a zillion times while messing with The Games Factory. Also shows off text writing with the built-in font.
  • dots: Drawing random dots on the screen! Not very exciting, but a demonstration of what you can do with essentially one line of active code.
There are quite a few hardware details in this chapter, and a brief treatment of how to create a code library which all the later examples will link against. Of course, the details depend on your linker, but I'll be providing the scripts I've been using in each case. He also mentions the Mode X, but mainly to clarify that all the examples in this book will be using Mode 13h because of its simplicity. Mode X is "probably the best", though.

Let me know if there are any more details you want me to add.

Saturday, 29 April 2017

Teach Yourself Game Programming in 21 Days - Day 2

This second chapter is titled "The Components of a Complete Game: Mech War". It's a decent overall look at how complicated game development is, and how much hard work it takes to get there. André lists 20 steps that he had to work through. The game 'Mech War' is essentially a Space Invaders clone.

His paragraph about design is interesting, because it is quite the opposite from my own experience:

"Much of what a game programmer does boils down to being creative. Writing games isn't too terribly complex once the fundamentals have been grasped. The hard part about making games is thinking them up! I can't count the number of times I've sat at my desk and tried to think up the ultimate video game. Many times I'd find myself creating games that had already been done. This is the problem: there are so many games out there (literally, thousands) that coming up with a completely new one is hard to do. There are still about 50,000,000,000 good games to be written—they're just harder to come up with."

I think of game ideas all the time. Often I will think of quite detailed systems and worlds while I sleep; my main barrier is not being able to make these concepts a reality. I think of myself as a fairly competent programmer, but the large-scale planning needed to create a game on the scales I can imagine often eludes me. Not to mention the huge amount of hours needed to create all the content needed to fill games; I'm no artist, though I used to dabble in musical composition, so I usually abandon the majority of my ideas.

I do agree with his assessment that there are essentially no 'new' games left. Even today, games can quite easily be described in terms of "older game X with extra mechanic Y". Or "like X but with better graphics". This is largely the result of the gaming industry becoming big business; many companies are simply not willing to throw the giant sacks of cash that AAA game development requires without guaranteeing a return on investment. Thankfully, indie development has a great role in filling these unfilled niches.

The author notes that even this simple game, copied from another existing game, took 5 days to write. Interestingly, he indicates that 50 days should be enough to write a game "of shareware quality" which you could probably sell. In my own attempts at game development, I can't really endorse this figure, but it does sound reasonable with a concerted effort and using the latest tools.

Even though Mech War is simple, he structures its development in a way that would make sense for a much larger game; he provides for a configuration system (here used simply to store sound card settings), splits up his code into modules, writes a separate library to handle sound playback (a very annoying issue back in the DOS era) and so on.

All the sounds in the game are processed samples of his own voice. I remember doing this too, back when I played around with The Game Factory; nothing beats going 'tsh' or 'oof' into a microphone then hearing them in-game. André also claims that many professional games use the same method; I don't think this is as true today, with the amount of commercial sound-banks available.

There are many, many more details here about what was involved in Mech War's creation, but I don't want to give everything away here. This is another one of those chapters that doesn't involve any actual programming, so I mostly skimmed over it on this fifteen-hundredth reading. It's still useful, though. At the end the author mentions a 'challenge' to send him an improved version of the game; he'll pick a winner and send them a cheque for $100! Golly!

I think perhaps that challenge might have ended some time ago. However, it might be amusing if I can find the time to send him my own improvement at the end of this little project of mine.

One of the exercises for this chapter is "Think up an entire game. Write down a list of all the elements in your game, and all their interactions." Way ahead of you, André.

Friday, 28 April 2017

Teach Yourself Game Programming in 21 Days - Day 1

Welcome to Teach Yourself Game Programming in 21 Days! You're about to embark upon one of the most exciting and rewarding learning experiences you've ever had. Game programming is, without a doubt, one of the most difficult areas of computing to understand. However, it's also one of the most satisfyingand, with determination and patience, you will conquer it.

So begins this great book. The first chapter talks about video gaming history on home computers, going from those heady days when owning an Atari 800 made you the coolest kid on the block, right up to the cutting edge of the Intel 486. It's fun to look back into the past this way; it's particularly amusing to see the almost breathless way that André explains things that are considered mundane or even trite now, like the way "most PCs today have sound cards" or that games aim to hit "15-30 frames per second".

The book lists the basic genres of games as such:

  • First-Person, Three-Dimensional Walkthroughs like Doom, Blake Stone, etc.
  • Flying, Driving, or Spaceflight Simulations like Microsoft's Flight Simulator, Wing Commander, etc. "These games try to simulate something we can do in reality." I wonder how André would feel about the preponderance of Farming Simulator stuff these days.
  • Sports Games in 2- or 3-D; he doesn't name any here, but he does mention that "the most popular games are football and basketball."
  • Scrolling Adventure Games like Mario Brothers. 'Adventure' games! It still amazes me how much this word has changed in meaning over time.
  • Sideview Combat Games by which he means Street Fighter et al. "The factor that attracts most players to these kinds of games is the ability to project themselves into virtual warriors with super strength and abilities."
  • Role-Playing Fantasy Games in 2- or 3-D, again not naming any, only 'admitting' that he used to play Dungeons and Dragons back in the day.
I guess the largest missing genre here is Puzzle; a segment which has exploded through so-called 'casual gaming', something that would have been difficult to predict back in the 90s. The focus back then was on bigger and better - pushing the boundaries of tech, upgrading your PC every 6 months. The very idea of large parts of the industry jumping onto a low-powered portable machine is kind of weird, but it definitely worked.

Next is a fairly lengthy discussion about the architecture of a video game. It notes that everything happens in a big loop, so it's really important to make that loop run as fast as possible. I remember there being quite a few optimisation tips spread throughout the book, and plenty of advice to make you stay on the path. I think this really stuck with me; even though I mostly write websites and non-critical things these days, I still make notes about what could be improved and like to use profilers to get a feel of how fast my code actually runs.

Game Law: Don't mix game logic and graphics unless absolutely necessary. Try to keep rendering and computation separate.

This separation of concerns is a rather important part of programming in general. The separation of code into individually testable units means that it is possible to reason about their correctness. It also helps guarantee that later changes don't break any old code. This is something I've only really got into recently - although I've known about unit testing for a long time, I had no idea how good the tools for code coverage and static analysis had got. I think it's a fascinating way of learning more.

What Does the PC Offer as a Game Machine?
Today the PC is a formidable computer. You can bank on the following minimum hardware configuration as your base platform:
  • CPU: A 386 with two megabytes of RAM (with 486s being common)
  • Video Card: The VGA card is standard, with many PCs having a Super VGA card
  • Sound Card: A Sound Blaster- or Adlib-compatible sound card
  • Input Devices: All PCs have keyboards; many have mice, and—if the owner is a gamer—you can count on a joystick
What an amazing snapshot! It still blows my mind that these clever 90s programmers managed to wrest so much power out of a general-purpose machine, managing also to create some of the most memorable masterpieces in gaming history. The book also notes that you can also write games with this same level of hardware; this is something that is difficult to achieve today. Most Windows programming requires a powerful computer so you can load memory-hogging beasts like Visual Studio. Game programming with the latest engines is similarly demanding. Still, a commodity PC is enough to write indie games, and there are plenty of those around (lauded ones, too).

There is a worrying requirement in André's list, however. "You need a C compiler. I use Microsoft's C/C++ 7.0; if you have that one, we're completely in sync. Also, it would be to your advantage to have MASM 5.0 or higher." I've used Visual C, but this is older still, and it might be a pain to get hold of. Also, I'm using a 64-bit PC, so there could be further problems there.

The next line offers a potential way out. "If you're a Borland user, you'll have to make slight changes here and there. However, there shouldn't be a problem with code compiling under Borland's products." Ah, Borland (now Embarcadero)! My first experience with C programming was with Borland's venerable Turbo C package, also in the 90s. I also went on to use C++Builder once I got into visual stuff. I might still be able to find a copy of that lying around.

Lastly, there's a section about 'Being Creative'. This largely boils down to watching random fantasy and sci-fi movies for ideas. "If there's one game designer on Earth who hasn't seen all the Star Trek episodes, the Alien movies, and Real Genius a thousand times, I'd be surprised! So go out there and use other people's ideas as the seed of your own new idea." Probably decent advice for a programmer, we tend to be quite boring people.

So, there's no code in this chapter. However, each chapter does end with a list of quiz questions, some answered in the text, others requiring research. I won't bother to answer the questions (one is a bizarrely specific question about Real Genius) but I will attempt to do the exercises. One of them this time is "Play the game DOOM for a couple hours and see what can be done with a PC", so... see you later.

Thursday, 27 April 2017

Teach Yourself Game Programming in 21 Days - Intro

Holy crap, I haven't posted here since January!

I was reminiscing about coding in the olden days with a colleague when I realised I still have lots of coding books lying around. One sprang to mind immediately; Teach Yourself Game Programming in 21 Days by André LaMothe. It's an excellent book, full of practical tips (for the time, anyway) and reasonably structured code. Its language of choice is C, though there are occasional bits of Assembly to speed things up.

After I dug it out of the pile, I was slightly saddened to find that the CD with all the supporting material is gone. That means I'll have a lot of typing to do, not to mention some graphics and sound files to create. My second problem is that, this being a book from 1994, it creates programs that are designed to be run in DOS. Not only will I need to use DOSBox (which I'm familiar with), I'll also need to find a C compiler that can create these olde binaries.

Despite all this, I've decided to go through the book and get as much of it running as I can. I'm not sure I'll be able to do it over three weeks like the title suggests, but I plan to document my journey on this blog and release all the code I end up writing in a public repository somewhere.

Note: the games contained therein use PCX and VOC files. When was the last time you saw one of those?