Flux RSS

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...


1. On Wednesday, September 5 2012, 03:53 by Monte

There's been quite a bit of talk about this.

One interesting "manifesto" and project that came out of the Ruby community:


2. On Wednesday, September 5 2012, 09:53 by biou

I am sorry Nicolas but I really don't agree with you. Your point is that 20 years ago you were in a special context that was favorable to your learning and it does not exist anymore, so it is not possible to the kids of now to become great coders, like you. The concepts and languages are more complex now and the learning curve is too steep.
But if you read your own article, you will see that it is filled with nostalgia, and you are not objective. I am really not a big fan of the good old days, it is often a perception bias and has been shown as such by lots of studies in psychology (for example: http://www.springerlink.com/content... , http://onlinelibrary.wiley.com/doi/... , this one is not scientific and in french, sorry google translate is your friend http://psychologiejeuxvideo.com/201... )
Sure the young people will not learn as you did but they will learn differently. In my team, we have now MsC degree trainees, that were born 10 years after us. And I am sure that in their generation there will be very good coders, and certainly one of them will become a brilliant coder like you. What you have learned, you did not learn it at school. You are self-taught and self-made, and the school did not help because they were late at trying to teach computer science. We probably need to change education paradigms (a great talk of Ken Robinson on this topic at TED http://www.ted.com/talks/ken_robins... ), it was the case 20 years ago and it certainly is the case today.
One of your other points is that back in the days, it was simpler to code something that looked like the games of that time. This seems greatly exaggerated. When you were 12 years old, it was 1991, and the MegaDrive was already there since 1990 in Europe, so your text-mode game was probably not so good-looking compared to console games. It was not amazing per se, but only because *you* built it.
The IT landscape of now seems more complex, but we have build lots of abstractions, you have lots of prior knowledge you can build upon without reinventing the wheel, and I think that this can be considered as a real progress. How can you say that knowledge dissemination like wikipedia is a bad thing? It reminds me of what I heard when I made my first steps in IRC and Usenet in 1997, the Elite was there and they complained relentlessly about all these noobz. Back in 1991, PCs were expensive, I did not have one before I could personally afford it in 1996 (I learned to code in basic on a very old 8bit french (ph34r!) computer in 1988). Now lots of kids have computers! They have the knowledge and the hardware at hand. Last week, I discussed with a good friend of mine that work for the European Space Agency as an electronics engineer. He is very talented like you and for a living he designs the brains of lots of satellites. I was waiting for his opinion about Arduino (yes I know what you think about that) and he said that if he had such things when he was a kid, he would have been very happy!
In IT, if you want to learn now, you don't start with complex languages (in 1991, you learned with GWbasic, not x86 assembly or C). There are lots of simple languages out there like python, processing, etc. that you can begin with. I am sure you can find toy languages for kids, before they begin writing real code.
The only sentence that gives me hope in your article is your last one. Perhaps all this article was only written in order to justify one of your secret new project for the kids? So if there is really a problem, where is your patch? :P

3. On Tuesday, September 11 2012, 11:49 by karthik raja

Though i agree with biou's insights, the view of Nicholas view should be seen in a positive light.
i'm as a student and i seriously aware of the metality of students around me are scared to experiment and also resorted to readymade packages for everything.....
i think that's the point Nicholas wants to emphasize.