Category: Game Programming

Planitia Update 1

Welcome to Planitia.

Planitia

I know, it doesn’t look like much. That’s a heightfield with the height slightly jiggered so it’s not perfectly flat. It’s textured with the grass texture from Ultima VI. And there’s no lighting, which is the worst part. That’s why there’s no good definition on how the terrain actually changes.

But I wanted to post this anyway, because I met an important goal – I now have a 3D RTS-style camera control system working. You can move along the terrain using the arrow keys or WASD cluster, rotate the map about the viewpoint using Q and E, and zoom in and out using R and F.

The next step is to get units into the game, make them selectable by the player (which will require raypicking), make it so you can click on the terrain to give them movement orders (which will require an even more difficult version of raypicking) and have them move across the terrain in the proper manner.

No matter what kind of game Planitia ends up being it will needs these technologies, so I can go ahead and implement them while I’m still thinking about the design.


Video Blog 3, 10-01-06

Video Blog 3 successful!

In this blog I talk about how game development and game publishing work, tell two stories about game development, and even have a guest star at the end!

Edit: Google Video version is here. Gamespot’s player doesn’t seem to work well for non-Usanians. I’ll be uploading the Google Video version more promptly in the future.

Okay, let’s test something here…

Woohoo!

Well…

Except that the quality on the Google Video version is MUCH worse than the Gamespot one. Crud!

Edit: Direct download link for this video blog is here.


Video Blog 2, 09-24-06

And here it is.

If the above video doesn’t work well for you, here’s a Google Video version.

And if neither of those work, here’s the direct download link.


Video Blog 1, 09-16-06

Surprise!

I’d been meaning to do something like this for a while, and since Gamespot will kindly host them (since I’m a subscriber), why not? Enjoy!

Edit: Here’s an embedded Google video version:

And here’s a direct download link.


New Game Development Articles

Well, new to me, anyway.

While I’ve been working on Sandworm (my One-Page Game) I’ve been learning more about the Windows console application functions. While these aren’t really hard to use, example code is always helpful and Microsoft provides very little. So I’d been searching both the internet and Google Groups for more information on the assumption that I can’t be the only person using this stuff. But I hadn’t really found anything.

So Sandworm was almost finished when a Google search on the WriteConsoleOutput() function pointed me to an article I really really wish I’d found before I started coding. The code this article provides is much better than what I’d written, so I’m incorporating it. And anyone else who wants to write a console application should read it. It even includes an ASCII table!

And Sol has written a set of tutorials on immediate-mode GUIs. If you’ve used his SDL tutorials you know he’s an excellent writer, and immediate-mode GUIs look better to me every day (you’ll recall I used one for my combat prototype).


Yesterday

And then something strange happened…I describe it as “the best week’s work I’ve ever done in my life”. It was something I started on a Monday morning and finished on a Sunday afternoon; it was a game that was written in a week start-to-finish. And that was what was so nice about the industry back then – you could just do that. You could sit down and bang out a game; 3.5k of code didn’t take a lot of time to fill.

And I wrote this game. I was very fond of Centipede, but Centipede was too cutesy for me, with its flower gardens and little centipedes – I wanted something more hard-edged for this game.

I actually had the name of the game before I wrote the game; I’d been up at a computer show in London and they had posters for this new Harrison Ford film that was out called Blade Runner. So I saw the posters and they had this very distinctive font that said ‘Blade Runner’ at the top. But I didn’t want to use ‘Blade Runner’ because my game wasn’t anything like Blade Runner; it was a game based on this grid so I thought, “Hey, I’ll call it Gridrunner.”

So I wrote it and I thought it was a very nice little game, but I didn’t think that much more of it, really. And I sent a copy out to my friends in the States who were distributing my games, and one night I remember the phone going at about four o’clock in the morning. I crawled out of bed and answered the phone and it was this guy from Human Engineered Software, and he was ranting! He said they loved this game and had been playing it for hours and I should stand by to make quite a lot of money, and I thought, well, it’s just this silly little game I made in a week, but okay, fair enough, and I put the phone down and went back to bed and went to sleep. Got up the next day and thought I’d had a weird dream where I was sure they’d said that this game was so good I was going to make loads of money! But it turned out he was actually quite serious and they turned it into a cartridge and it did turn out to do really well! It was the first major success for Llamasoft. It was number one on the VIC-20 charts in the States which was really surprising, and made me enough money to keep me going for several years.

Like I said, the best week’s work I ever did in my life. I wish I could have another week like that!

– Jeff Minter, from his “History of Llamasoft” presentation at Assembly ’04

Now, I could go into a rant here about how games were better in the old days, but I don’t really believe that. True, there were some fantastic games made back then, but there was also a bunch of crap that nobody remembers any more.

What I will say is that modern software development has become very abstract, with layers upon layers upon layers upon layers, and this is simply the worst possible thing that could have happened for game development which really has to go straight to the hardware in order to be fast. So we get APIs that do touch the hardware directly, but because they have to play nice with these abstracted operating systems we have to jump through all these hoops and do things like raw memory writes just to put a damn pixel on the screen. And God help you if you forget to set your pitch and your width correctly…

This is why I like making and playing little text-mode games. I’m honestly fascinated by things like Roguelikes, even though most Roguelikes frustrate me because they are too damn hard.

And of course, the company that could have given us a very straightforward game development API because they control both the hardware and the OS refuses to do so because they hate gamers. Well, screw you too, Apple…see if I ever buy an iPod.

And this is just the Price that Must Be Paid in order to do modern game development (at least on the PC). It’s difficult, and it’s going to stay difficult for a good long while. But in the end, we do it because we are compelled. And it’s not like there aren’t any rewards…


A New Challenge: The One-Page Game

(Because I didn’t have enough projects going on at once…)

Basically, I’ve been working out of my book for about two weeks now, and I’ve written very little code. That bugs me. But I can’t really start on Planitia yet, can I?

So I began to think about doing a little game on the side in the meantime. A very little game – one that would scratch my game development itch but not take a bunch of time away from the book.

And then I remembered a little something I read in The Rainbow back in high school.

The Rainbow was a magazine for the Color Computer, which was Radio Shack’s competitor for the Apple II/Commodore 64/Timex Sinclair 1000 market. The Color Computer ran on a Motorola 6809 processor and came with 4k of RAM (later models came with 16k and there were expansion systems designed to bump it up to the “magic” 64k). It was hampered a bit by its weak display system, but overall it was a good little computer and lots of hobbyists used it for lots of different things.

And of course support magazines sprung up for it. The Rainbow was the biggest and most successful of these, and it was an old-school support magazine in that it included source listings that users could type in themselves. It covered just about every application you could put a computer to, which included games. Indeed, their annual game issue was always their biggest seller. During its heyday issues of The Rainbow ran over 300 pages and looked like phone books because of all the included source code.

I read a whole bunch of issues in high school. I borrowed them from a friend and thoroughly enjoyed them despite not having a Color Computer of my own. (Back then I would read anything about computers I could get my hands on.) And I recalled reading a small article in one issue that presented a version of Centipede a reader had written and submitted. This game was unique because the source code only took up a little more than one page. I remembered being very impressed when I saw that.

And I decided that writing a complete game in one page of source would be a unique challenge that wouldn’t take too much time away from learning DirectX.

So here comes a new challenger!

The One-Page Game

What does it mean to write a game in one page? Well, after trying it myself and having some of my friends try it, we’ve come up with a couple different interpretations.

Challenge 1: The True One-Page Game

To complete this challenge, write a game whose source is fully contained in one page of text that is eighty characters wide and sixty lines long. No external data files are permitted; this source file must contain everything your game needs to run. You may only use the base libraries that come with your compiler.

Of course, in order to complete this challenge, you’ll have to write source code that looks like this:

#include <windows.h>
HANDLE h;SetCur(bool b){CONSOLE_CURSOR_INFO c = {1, b};SetConsoleCursorInfo(h,
&c);}Init(){h = GetStdHandle(STD_OUTPUT_HANDLE);SetCur(false);}SetPos(int x,
int y){COORD c = {x, y};SetConsoleCursorPosition(h,c);}SetColor(int f, int b){
SetConsoleTextAttribute(h,f|b);}Print(char* i){DWORD r;WriteConsole(h,i,
strlen(i),&r,NULL);}

If this bothers you, you can try Challenge 2.

Challenge 2: The 4800-Byte Game

To complete this challenge, write a game whose source is fully contained in one file that does not exceed 4800 bytes in length. The actual file can be as long as you want it. While you may think you’re getting a little extra room with this method, I think with the extra whitespace it’s a wash, so this is mostly an aesthetic decision. Again, no data files or libraries except what came with your compiler.

And if that just isn’t enough room for you (or you abhor writing text-based games) you can try Challenge 3.

Challenge 3: The Two-File Game

To complete this challenge, write a game whose source is fully contained in two files, one header and one source, which are less than 4800 bytes each (9600 bytes total). Again, no data files or libraries except what comes with your compiler, but under Windows this includes DirectX and D3DX so this version opens up the option of using 3D rather than making a text-based game. Tom has already created an incredible-looking game that fits this challenge. Hopefully he’ll post it soon.

As for me, my game will fulfill Challenge 1. It’s going to be a Centipede clone in honor of that article I read in The Rainbow. And it would be done by now if I hadn’t spent so much time figuring out how to get the mouse to work with a console application…


Quick Planitia Update

In the wake of my article on getting started in game programming, I have been taking my own advice and doing some learning. In particular I am getting more familiar with Direct3D. While I’ve known the basics for a while, I want to become a more advanced 3D programmer and I also need to learn vertex and pixel shaders. So I’m working my way through Frank Luna’s Introduction to 3D Game Programming with DirectX 9.0. I mentioned this book earlier but I really can’t say enough about it. As far as I’m concerned this is the book to get if you want to learn Direct3D.

Plus, with sections on terrain rendering, particle systems and picking, this book could have been subtitled “How to Program Planitia”.

So, no work will be done on Planitia for a bit while I work my way through this book. I’m currently on page 60 of 376. I am hoping to get through the book by the end of this week, though that will take some serious work.


Getting Started in Game Programming

I’ve thought for a long time about writing an article on how to become a game programmer on your own. The problem is that everybody and their kid sister has written an article on this subject, and most of them are better than anything I could write.

But there is one thing I can do to help the budding game developer, and that’s point out which books he probably should be reading (and which ones he probably should avoid).

There are a couple steps on the path to becoming a game programmer. First, you have to pick your language. Your language is C++. There, wasn’t that easy?

Yeah, I’m being a little facetious. If you’re just writing games for yourself and don’t want to get an industry job or ever work on a team, you can write your games using whatever language, libraries and helper programs you want.

But if you want to become a professional, you’re going to have to learn C++. End of story. Oh sure, other languages might be helpful, but the vast majority of game development (both on PCs and on consoles) is done in C++. Why? Because it works, and more libraries have been written for it than any other language. There are free C++ compilers for almost every operating system on the planet. And there are more books on C++ than any other programming language.

Let’s talk about what to avoid. Avoid books that promise to teach you how to program a game in a short amount of time. What most of these books teach is how to use a scripting language or a gamemaker program to make games. This won’t be useful to you if you want to become a professional game developer. Specifically avoid the book 3D Game Programming All in One, as this book is basically just a tutorial for the Torque game engine and teaches you nothing about programming. Also take careful note of any book that promises to teach you DirectX; some of them actually use Visual Basic instead of C++, which makes them darn near useless.

So here’s what I suggest.

First, get a compiler. You cannot learn C++ without a compiler. If you’re on Windows, get Visual C++ Express and be done with it; there’s no sense in messing around with anything else. If you’re on another operating system you’ll probably end up with some version of GCC, which I don’t know much about, but it’s in widespread use so research shouldn’t be that hard.

Second, you need to learn basic C++ syntax. There are a lot of books on this subject. Tons and tons of them. Most of them are crap, but even a crappy book can suffice here if it does actually cover the basics. Now, back when I learned C++ I did it from a book that included a floppy disk with a copy of Borland’s Turbo C++ on it…that’s how long ago it was. So I’m not that familiar with the current crop of books, but the one I keep hearing about is Accelerated C++. You probably won’t go wrong with it (but this is the only book I will recommend that I haven’t actually read).

Once you’ve learned basic C++ and are familiar with your compiler, it’s time to get a more thorough overview of the language, and the best book for that is none other than Stroustrup’s The C++ Programming Language. Now, this book covers the entire language and most of the Standard Template Library and it’s not particularly difficult to read. But it should not be your first C++ book, because it isn’t a tutorial. I would recommend going straight through the book, reading each section and writing little programs in your compiler to demonstrate to yourself that you understand each concept – this is exactly how I learned C++ on my own. I would also recommend making double sure that you understand how classes work, how inheritance works, and how pointers work before you proceed to the next level. If you can’t tell me what a reference to a pointer is and why you would want to use one, you probably shouldn’t go on yet.

Now you know how to do pretty much everything in C++. But there’s more to learn, because there are a lot of things in C++ that you shouldn’t do even though you can. The next two books I would recommend are Meyers’ Effective C++ and McConnell’s Code Complete. Both of these are outstanding books that will make you a much better programmer practically overnight if you take the time to read and understand everything they say. Effective C++ will tell you about all the common traps C++ programmers fall into and explain how to avoid them. Code Complete is a bit higher level – it will teach you how to design your programs before you start coding so that your code doesn’t get so tangled you can’t deal with it any more. Code Complete is especially important if you plan to become part of a programming team.

Now, during the course of reading Effective C++ and Code Complete, you will probably encounter information that contradicts what you read in earlier books. In this case, these two books win.

Now you’re a hardcore C++ developer, but you still don’t know anything about game development. Therefore, your next book should be Llopis’ C++ For Game Programmers. This book is going to directly contradict things you’ve previously read; in this case, this book wins. You’ll be doing lots of stuff in game development that would make your average OOPmeister wince; that’s just the way game development is. Some of the content in the book will be stuff you already know. That’s okay, because the rest of it is pure gold. Pay special attention to the section on memory management; this is a vital concept that most game development books ignore because it can be quite difficult.

I’m also going to recommend that you read McShaffry’s Game Coding Complete at this point. Make sure you get the latest edition, which at the time of this writing is the fourth edition. This is the only book I’ve ever seen to cover how to design and write an overall game engine, as well as how to create a resource handling system. Again, these are both topics that most game development books ignore because of their difficulty. This book will also cover the basics of just about every aspect of game development, including graphics, sound, physics and networking.

If you’ve been reading and coding dilligently then you should now have a solid understanding of the basics of professional-level game development. Now there isn’t so much a progression as just a list of books I’d recommend.

The Graphics Gems series – if you’re doing 3D programming, and especially if you’re doing 3D programming on a platform that does not have hardware acceleration, then you must have at least the first book in this series. Yes, it is terribly expensive, but it’s worth it.

The Game Programming Gems series – this was an attempt to create a series like Graphics Gems, but for general game development. As they progressed the information presented became more specialized and less vital – but again, you should definitely own at least the first book.

If you are just starting out with Direct3D, then the book I’d recommend is Introduction to 3D Game Programming with DirectX 9.0 by Frank Luna. This book actually lives up to its name and will take you in baby steps from initializing Direct3D to particle systems, multitexturing, shadows, landscape rendering, picking, and pixel and vertex shaders. Make sure you get the first edition of this book, as the second edition will focus on DirectX 10 and will do everything with shaders. That’ll be interesting, but it won’t be a “for beginners” book like the first edition is.

Hope this helps!


The Dragon’s Lair

This post on the Rampant Coyote’s blog got me thinking about the Bluth/Dyer games in general, all of which I loved despite their frustrating gameplay. So I typed “Dragon’s Lair” into YouTube.

Boy was I surprised.

All of that footage was cut from Dragon’s Lair (except the dragon fight at the end). The most intriguing to me were the scenes where there were several different possible exits from certain rooms. This footage got all the way through the animation process before being cut.

I think with that footage, a very good case can be made that Rick Dyer originally had a very different design in mind for Dragon’s Lair.

The Dragon’s Lair we got is a tightly linear game, where rooms are thrown at the player in random sequence and the player must memorize the moves necessary to beat them by rote. But the animated sequences that show Dirk leaving some scenes through alternate exits strongly suggest that the castle was originally designed to be coherent, not random. Which would have given the game an aspect of exploration and required the player to not only figure out the correct sequence of moves to get through each room, but also to figure out the best path through the castle to the dragon.

This, frankly, would have been fantastic and would have given the game much-needed depth. It also would have paved the way for future games to do the same. It’s a shame that the feature had to be cut.