We get a lot of mail at Synthetic Reality. We enjoy reading your letters, so please keep sending them. Sometimes people give us great ideas (thanks!) and sometimes people ask questions. Some of these questions are answered here... sort of.
Very likely you can! But since it takes me 18 months from starting a project before it is testable, don't hold your breath. As a Beta Tester, you don't really get anything but maybe a free copy of the program (very extremely probably, but I don't want to make any blanket promises in advance!) and maybe a mention in a help file somewhere. But you get one other thing - my sincere gratitude! (Try taking THAT to the bank!)
WoS has been in beta for a year or two already, which sort of underscores the extreme sense of urgency I feel to roll out product :-) Basically, any Internet game I write will probably be called "beta" forever, unless I really tire of making upgrades. I suppose it's a little game I play to keep you from hating me. If it's FREE and it's BETA and it DOESN'T WORK, then you wouldn't think of complaining, would you?
Warpath and NetSpades were written in 'c', using the Microsoft "Quick C for Windows" compiler. Unfortunately, after upgrading from windows 3.1 to windows 95 that compiler stopped working for me and I lost the ability to work on those programs. This is why I stopped making new versions of them. In the case of Warpath I went on to make a sequel (Warpath 97, released in 98 as part of my sense of humour about it all). But NetSpades is a permanent orphan and I can't even make a 'free' version (as I was able to do with Warpath Classic).
Currently, I am using Microsoft Visual C++ 4.2b for all new projects. Warpath was basically my first program for Windows (though by no means my first program). I enjoyed the year I spent with Quick C, but I haven't looked back since switching to Visual C++.
So, Warpath 97 was written with Visual C++ 4.2b, as was Well of Souls, and as is Arcadia and even Rocket Club. Eventually I will probably upgrade to version 6.0, but then you'd all have to download several megabytes of microsoft support DLLs.
As the years go by, I am progressively more aware of the speed and memory penalty I pay for using the Microsoft Foundation Classes (MFC). Perhaps someday I will stop using that. Perhaps when Java settles down as a reliable language. Java is the language of the 21st century (and as I write this I still have a few months before then :-)
Well, first off, set your expectations appropriately. In general, any program which you think looks really cool was probably a whole lot of work to write, and required many years of training and experience before its author was able to write it. So don't expect anything to be too easy. That said, it's really pretty easy! Lots of successful programmers had no formal education at all (at least no formal education writing programs, I mean). Of course even more successful programmers did have a formal education. I'll let you draw your own conclusions about that.
Basically you need a computer (which means you probably need money) and you need a programming language/environment. I usually recommend Microsoft Visual Basic as a starter language. It's really just about the coolest development environment around for simple programs, and since you can embed ActiveX controls in a Visual Basic form, you can actually write some powerful programs, as well. But it's terribly expensive, and I find it a bit frustrating to use for my 'real' work. (not that Visual C++ is free by any means!) And, no offense intended, VB programs tend to be a teensy bit slow and clunky.... That's an unfair generalization, but somewhat true. The real reason I only use VB for 'quicky' applications and test protoypes is because I find that after programming in Basic for awhile, I get contaminated and start making errors in my 'c' coding.
VB is a great way to get yourself started along the object-oriented path, but VC++ lets you have more direct control over things (and hence can generally create higher-performance applications), but you have to take care of more of the details on your own. If you are just getting into programming now, you might want to think about specializing in web page authoring (HTML, and scripting languages) and the relatively new language: Java. Java is a bit over-hyped at the moment, but it really might end up being the Next Big Thing and you could be there at the start.
A couple years after I wrote that, I think Java is ready for you, and there are several free Java development packages available now. Add to that the availability of free web site hosting and you might really consider letting java be your first language.
Here are some links:
Let's face it, on their own computers are pretty dumb. You have to tell them every little thing to do. With luck, someone else has already told them to do something you need. Computer programming consists of learning all the little details and then typing them in over and over and over again until they do something you think is cool.
Well, first of all, I do recommend books highly. And I am excited by the possibility of the web providing the world's largest free library to all citizens of the earth [music swells], and I am disappointed when people poo poo that ("oh, I only like the feel of REAL BOOKS"). I think that misses the point. You are either into books for their information content, or it is some sort of trendy style thing and you might just as well be saying how cool fur feels. That being said, I prefer the feel of real books, too, and I hope we can come up with some better laptop/PDA designs which give us the best of both worlds.
While not a book per se, I highly recommend budding programmers sign up with the Microsoft Developer Network and get the lowest level subscription, which comes with the MSDN library CD-ROM. This has an amazing amount of good stuff on it (by which I mean, appropriate books (like Petzold's classic text on Windows programming), help files, and examples.) It's a couple hundred bucks, though. In any case, Microsoft is going to continue owning the world for the foreseeable future and you might as well be clued in to what they have in mind.
Also not a book, the Microsoft Visual C++ Developer Studio An integrated development environment is a wonderful thing. It is very wonderful to be able to click in a word you don't understand, press F1, and suddenly receive illumination. Plus the various wizards make it trivial to build the shell of an application, after which adding the fiddly bits is considerably easier. And over time you will begin to understand what all those magical things the wizard did for you are all about -- especially if you push F1 a lot.
While not about programming, I can heartily recommend the Discworld books by Terry Pratchett (start with the first one - The Colour of Magic) They're truly hilarious, and actually just a little bit philosophical at moments, but not preachingly so. I have the honor of having made TP mad at me once. He's techno-literate and will often answer email from fans. I abused the privilege and in an effort to make him like me, I said something wrong and got him mad. Sigh. While I'm name-dropping, I got to go out to dinner with Douglas Adams once. He was very very nice (and very tall <-- a small inside joke). I also got to touch Gillian Anderson's shoulder pad. And Charles Fleischer leered at me (don't get me wrong, he was nice as well). Robert Redford was too important to pay any attention to me. Let's see, is that it? Oh, I spoke with Steve Ballmer on the phone once. He sounded nice. Back to our story in progress...
For getting your toes wet programming Windows 95/98/Me in MFC, I recommend Jeff Prosise's Programming Windows 95 MFC. MFC brings a lot of mystery with it and this book is pretty clean in its focus on getting you through the basic points without a lot of digression.
For a foundation in programming for Windows in general (without which you are doomed to years of superstition), I have to recommend the classic: Petzold's Programming Windows 3.1 (since upgraded for windows 95)
For moving from a knowledge of C programming to C++ programming, I can recommend just about anything from SAMS publishing. The SAMS books are extremely good for people with my sort of short attention span. They really hold your hand and repeat things a lot. Bless you, SAMS.
For learning the C language itself, well there is always the K&R book. Pardon me for not knowing the proper spelling of their names: Kernighan and Ritchie (?). It's a fairly dry description of the language and assumes you already know the basics of programming. It's how I learned C. And probably why I only used about 10% of the language for my first 10 years of programming in it.
For a decent presentation of a lot of short-cuts which yield impressive results, I can recommend Tricks of the Game Programming Gurus. It's really about DOS programming (well, it's NOT about windows programming), but the tricks are re-usable even if the code examples are not. Specifically their description of texture-mapping surfaces will open your eyes to how a cheap hack can generate extremely impressive results.
If you're into math, you might enjoy Computer Graphics: Principles and Practice by Foley, Van Dam, et al. It covers most of the math you need to do 3D programming. If you're into 3D games, you should DEFINITELY take a Linear Algebra class or two in college. I notice my kids' gradeschool math books are much better than what I had. Pay attention to the stuff about matrices. It might seem boring at the time, but it underlies most of the cooler things done in game programming. And, oddly enough, eventually it doesn't even seem boring any more?
I went out and bought a few hundred dollars worth of CGI, PERL, and Java books. But really you should check the web first when you have a question. You can find the same info and not pay hundreds of dollars for it. I like the google search engine, by the way.
On The Nature Of Programming
People generally believe you need to know a lot of math to be a programmer. This is not strictly speaking true. The number one thing you need (in my humble opinion) is a deep understanding of what the problem is that you are trying to solve, and how to break that up into the proper subset of smaller problems, and the flexibilty to change your mind and do it all over again. You should think about your problem for a little while before beginning to write code, but then you should just jump in an thrash around a little. Usually painting yourself into a corner is a good way to discover what the thing you were trying to do in the first place really was all about.
Some people like to think things out completely before they even begin. This doesn't work for me as I start to focus on some insoluble little piece which turns out in retrospect to have not even been important. Some people like to just start coding without thinking about it at all. This doesn't work for me because frankly programming is a lot of work, and if you can't draw a picture of what you want (with pencil and paper) it is not going to be EASIER to make it appear when you have to micro-program every little detail of it.
So I recommend moderation. Think about it a little, scribble some crude diagrams. Think about the pieces involved. Pick a piece you think would be fun to work on, and start work on that piece, accepting that as things go along you will probably discard that work in favor of a better idea that occurs to you while working on it. Over the years you will get better at picking the right pieces in the first place and just knowing what the right way is to approach the problem. You will begin to see the patterns underlying the problems. And then you will be stuck in a rut! Heh heh.
Another thing I like to do is keep the program 'runnable' at all times. So I start by making a very quick shell program which doesn't actually do anything. Then I start fleshing in the major blocks with calls to dummy functions which don't actually do anything. I try to establish the overall 'flow' of the program at this stage, with the display stepping between the various modal displays I feel the program requires (for example, a logon screen, followed by a character selection screen, followed by the in-game screen, then a mission de-brief screen and then back to the character selection screen). I just have the individual screens paint large colored blocks (red for one, green for another) so I know the transition has taken place. Most programs end up being state machines anyway, so it's nice to block out the major states as soon as possible.
Then I can flesh out one particular screen/state while ignoring the others. In this way, I can always work on the part which interests me at the time, deferring those parts I consider 'necessary evils' until I either feel up to the drudgery, or think of a way to avoid them completely. But I can compile at any time and have a program which semi-works, instead of having to defer all gratification until I have implemented everything in its entirety.
If I feel motivated to work on a very tiny piece several layers down from any existing screen/state, then I quickly put in dummy routines representing the overall structure of the screen state and which ultimately call into the functionality which I am interested in working on at the time. This way I still get to have fun, but I am forced to think a little about the interfaces between those layers right up front. I may have to change them later, but the situation would be much worse if I just developed the fun piece in a vacuum.
Another side effect of this, is that you end up testing the outer layers many many times as you fly through them on your way to test the code you have just written for some inner layer. These means you end up with better tested code, and encourages you to fix problems and irritating UI problems in the outer layers, since you have to traverse them so frequently.
At least that's what works for me. Getting back to the math stuff. Most everyone says you need lots of math to work with computers. I majored in math in college, but only because they didn't have an undergraduate degree in computer science at the time and I had to do math to qualify for the masters degree in Computer Engineering that I wanted. I hated math. I specifically hated Linear Algebra. I was a professional programmer for over a decade without having to really use my vaunted math skills (most of programming is about moving stuff around, not number crunching). It wasn't until I got into game programming that suddenly math was very valuable. And for world-simulation sorts of things (especially 3D) that Linear Algebra was suddenly amazingly important (and oddly enough, it was suddenly fascinating as well. As soon as I realized it was the "math of flight simulation" I was hooked).
I still hate statistics, though. And modern algebra. Regular algebra and geometry are both fabulous, of course, as is trigonometry and physics in general. Another investment you can make in yourself is to memorize the multiplication tables for 1-12. It will just save you SO MUCH TIME later on. I still have to do 6x7 by saying in my head "oh, that's twice 3*7 which is 21, so it's 42" and I probably have a measurable percentage of my brain hardwired to reciting that phrase now.
This is where I get a little cranky. OBVIOUSLY, you should avoid re-inventing the wheel (unless it gives you pleasure, of course) and try to make your bits and pieces of code as reusable as possible. My cranky assertion is that the only code which is 100% reusable is boring code. Anything truly interesting is in some way unique. People who spend the majority of their programming career focused on reusability bug me. Mainly because their articles always start with a sentence like this: "We felt the world would benefit from a reusable WhackHammer and rather than use one of the seven existing reusable WhackHammer classes we decided to write our own from scratch." That is to say, what is important to them is that YOU re-use THEIR code, not that they re-use anything themselves. I think that's a bit hypocritical. Usually such articles are filled with style over substance, as well.
But I shouldn't generalize. In fact, I re-use code all the time.. specifically the Windows Operating system and the common control classes :-) But I pay for that by being locked into various limitations (can't make scroll bar look much different, for example, so it never blends in with your game UI). Still, I don't mind the trade-off. The Windows List Control is a fabulous object.
Anyway, so as your mentor, I advise you to try to think ahead to simplify re-use. It's really really hard sometimes, but it's often worth it.
|Copyright 1997-2005 (c) Synthetic Reality Co. All rights reserved|