20 years later...
A bit more than 20 years ago was when I started programming. I was a kid back then, about 12 years old. My first computer was a 286 running at 12Mhz with 640KB of memory, 40MB of harddrive, and MS-Dos 3.30. I was programming in GWBasic, mostly. My very first big program was a small game. I decided to re-write the game today. Here is the result: Daedalus. There is very minimal explanation, let's see how you guys will fare.
Follow me after the break for some discussion about it, and the state of programming in general.
20 years ago, MS-Dos 3.30 wasn't really an operating system. In fact, it was just a collection of tools and various API to slightly help the programmers. There was no such thing as multi-threading, or multi-tasking. So the notion of "event loop" wasn't really necessary back then. Moreover, the hardware was extremely simple, and you had to be very ingenious to get something done.
To make the same game I just showed you, I took a lot more shortcuts than I did here. The biggest shortcut is that I didn't have any maze generator. In fact, the game I wrote as a kid had only one, hardcoded maze. Best of all, this was only using plain text mode. If you look at an extended ascii table, you'll notice that there are some weird characters that look like you can use to draw tables and whatnot. In fact, my hardcoded maze was using a grand total of 12 different characters. The two straight lines, the four corners, the four lines with a notch in it, the cross, and the space. With it, I could draw anything. The main drawback was that the lines were occupying one square, as they were in the middle of the character space. Meaning that the actual maze had fewer spaces than the number of characters on the screen. But still. The textmode was fully predictable, all the characters were identically spaced, and drawing something like a maze was very easy, even for a kid. Now, just to draw a simple square, things are quite complicated. In my case, I choose to use an HTML table, with a bunch of CSS classes. In that case, the lines are on the right, and the bottom part of each cell, meaning I have more space to do things.
Of course, since I wrote a maze generator, I had to create a solver, to make sure that the generated maze is sound. It's true I could've stayed with a hardcoded maze, and not worry about this kind of detail, but still. In that latest version, I implemented a generator algorithm found on wikipedia. That, too, is a very big thing compared with what I had as a kid. Most of the time, I was ending up re-inventing the wheel, because I didn't really have access to that kind of knowledge. But today, almost everything's available without too much hassle. Well, really almost. But anyway, since back then I couldn't come up with a method to generate mazes, I just used a hardcoded one. As for the solver, this is the very typical recursive algorithm. A bit expensive in terms of stack space, but efficient.
Now, in terms of techniques, the version I wrote 20 years ago was cheating a lot about things. The way it worked was the following. It first would draw the maze, then "blacken" it by reading the screen's contents (minus the border), and would rewrite each character with a black color. So a black character on a black background would look like a space. From there, since each character that isn't a space is an occupied square one way or another, when the player was trying to move, I would simply read the destination character. If it was a space, the move was authorized. If it wasn't, the character was re-drawn using a white color. Doesn't matter what actual character it was. It simply revealed the maze. Here, I kind of reproduced the same trick, by re-reading the table cell's class, to know what edges have been already revealed in a given cell. So, as I did 20 years ago, I am using the screen as a kind of storage for the progress of the game.
A gimmick of the technique was that the "notches" of the other sides of the walls were visible, as well on the outer border. These would serve as a hint to the players about where walls were. With the new technique here, this would be way more difficult to do, and therefore the current game is kind of more complicated. But the maze generator makes quite simple mazes to solve.
I also choose to keep the same AI for the lion (yes, it's a lion...). You'll notice it can cheat: it can go in diagonals. This was the result of a simplification in the "if" statements that control it. I liked what it produced, so I've kept it this way. Also, the very dummy AI kind of dampens the difficulty of the game.
A very important thing to note is the fact that back in the days, the main loop could afford to freeze, waiting for a keyboard input. Here, this is completely out of question. So the new version of the game is event-based, which definitely obfuscate the flow of the program. Before, you could simply read the code sequentially, and not have to go back and forth. Here, you need to grasp the fact that when the game starts, the code is registering a callback for keyboard presses, and this breaks the flow. In fact, events, callbacks and event loops are an absolute essential part of "modern" programming (and by modern, I mean anything younger than maybe 18 years). This most definitely complicates the comprehension of programming. I don't think that I would come up with the design I wrote today if I was still the 13 years old kid trying to write this. And since modern games are multi-millions blockbusters, I probably wouldn't even lose my time with a black'n'white, turn-based, soundless, scoreless game.
The point of that article isn't to resurrect my 20 years old game concept. This is to show that the programmers of tomorrow will never have the same background as my generation did. Modern programming, as well as the quality expectation from the public, is so different, so much evolved, and so much complex that the future programmers of tomorrow don't spend the time learning how to do it. And that is a shame because while kind of useless today, the slow, learning curve was very much necessary to bring me to the programmer I am today. I had to learn and understand event-based programming, object-oriented programming, and multi-threaded programming, step by step, year after year. And by doing so, I acquired a priceless experience. This, plus the lack of wikipedia, forcing me to reinvent the wheel almost every time, meaning that I re-discovered these concepts, refined them, and perfected them with time. I very sadly believe that my generation was the last of "programming kids". And I am very proud and happy as an adult that I was part of these kids. This defines me as who am I today. I really wish there was a way to go back to this state of things, somehow, so we can teach our next generation of programmers the same way we learned.
But maybe something can be done...