|
My brain is built of paths and slides and ladders and lasers and I have invited all of you to enter its pavilion. My brain, as you enter, will smell of tangerines and brand-new running shoes.
  Motivation time! | 
Posted - 4/28/2006 9:07:31 AM | I hereby issue myself a challenge.
It is shortly after 9 AM on Friday, April 28th, 2006. I have a list of mini-milestones that I wanted to have done this week in order to get the cutscene engine mostly implemented. I have thus far not done such a great job of keeping up with things, mostly due to having apparently developed a light dose of narcolepsy in the last three days. (I'm sure my rampant caffeine abuse and maniacally inconsistent schedule has nothing to do with it.)
So... here's what I want to get done today. My goal is to finish all of this by around 7 PM so that I can go out to dinner and a movie with some friends of mine.
Finish linear interpolation wrapper code (trivial) (Finished 9:14 AM)
Stub out spline interpolation code (Finished 9:15 AM)
Finish remaining special non-interpolation modes (Finished 9:16 AM)
Build and pass unit tests for interpolation system, sans spline interpolation (Finished 12:56 PM)
Codify the remaining elements of the system as a set of class interfaces (Finished 3:53 PM)
Implement skeletal outlines of the system in code, stub in pseudocode for algorithms where possible (Finished 4:31 PM)
Implement the core of the data flow model for managing timing and interdependent timing events (See Final Update below)
Implement validation/sanity logic for timing dependency system (See Final Update below)
Implement a dummy playback system that shows a real-time log of what a cutscene does as it plays (without actual rendering) - this is optional for tonight, but needs to be done this weekend at the latest. (See Final Update below)
Once those goals are done, the next big thing is to start integrating the logic with actual rendering code, so that we can actually see what's going on. From there, I need to build a veneer layer in XML so that certain special cases (Mission Briefing screens) can be handled easily by the content creation team. And then it's pretty much just patching and polishing and the sucker is done and ready for prime-time - right on schedule, hopefully.
So... there's my goals for myself, and they're now public, so I can no longer succumb to the temptation to go sneakly reassign tasks to next week, and pretend that I'm still on track.
I'll update this post and strike off items as I finish them, followed by a recap tonight when I finish. I'm going to force myself to not go out tonight if I'm not done, which should serve as a nice incentive to actually work.
Gentlemen, start your brains. The cheese flow will arrive soon, and we must be ready.
Update 12:39PM
I'm very annoyed. The unit test thing is taking about a billion times longer than it should have - I've had the tests coded for ages but I can't run them because my build environment got borked someplace along the line.
I've tracked the issue down to a couple of script files that were built with an old version of the compiler, so I have to rebuild them - but to do that I need to update a couple of files from the master repository, and it's taking a bloody long time. Much longer than copying 120KB should take.
Eventually, I'll be able to strike off that item. With luck I'll have a finished, unit-tested module by 1PM, which will give me about 6 hours to tackle the remaining items. Should be doable.
Update 12:56PM
Finally got it all working. The unit test quickly nailed a boundary-condition bug that I probably wouldn't have found for months without the test in place. Score one for good development practices. Anyways, it's time for a hard-earned break I think... and some food.
2:54 PM
Man... I suck. I have no idea where the last hour and a half went. Oh well... four hours to get this stuff done; it'll be a hard push, but I'm armed with a Stewart's peach soda and DI.fm's Chillout channel, so I think I can pull it off. Crunch time.
3:53 PM
Alright, this is more like it. I've got the basics of the classes all stubbed out, and some detailed implementation plans for how to represent all of the necessary data. I even whipped up a couple of diagrams and a wiki page entry for the plans. Now I just need to fight the urge to take another "quick break" - hah, hah.
Final Update 4:35PM
I just realized that I got some things out of order with this task list. I can't really solve the timing stuff until the representation of the entire system is built up, so I'll finish fleshing out the skeleton framework first and go back and add in the timing logic as I go, organically. That should work a lot better.
I will continue on this until 7PM (or some close time where I feel satisfied with my progress). So... all things considered: Challenge Completed Successfully! I am The Man.
| |
| Reading material FTW | |
Posted - 4/27/2006 1:56:37 AM | My copy of Programming Language Pragmatics just arrived today. It's big, heavy, and features small print.
Perfect bedtime reading.
| |
| Wednesday, April 26, 2006 |
| Brain stretch | |
Posted - 4/26/2006 1:12:05 AM | I've had a sort of recurring idea several times over the last few years. It involves a way to avoid stagnation of knowledge and skills, and identifying gaps and holes in important knowledge.
My idea is to periodically patrol the technical forums (and maybe some other ones too, like Business of Game Development) and look for questions that I can't think of an answer to - or, worse, can't think of how I'd go about researching an answer. Once a few such questions are identified, the idea is to find out how to answer them. Maybe that would involve waiting for other answers; but usually it involves educating oneself about the problem domain and learning a few things.
This idea came to mind again tonight. I've learned something interesting about my ideas: if I deliberately ignore them and they persist in coming back at least once, it's extremely important that I pay attention to them. This is at least the sixth or seventh time I've had this idea, so it's time to start doing it.
But not tonight. Tonight I'm going to go to bed.
As soon as I finish this SICP video. It's interestingly pertinent to my current work (defining and manipulating complex data structures by creating them recursively out of trivial elements). And the "OMFG HEAD ASPLODE" expressions from the audience are just priceless.
| |
| Foobar. | |
Posted - 4/26/2006 12:14:40 AM | I am ridiculously tired.
I have a lot of work planned out for this week that I need to get done (deadlines before I go off and lose a week at E3 next month) but I'm slipping behind.
Bleh. Sleep first, care later.
| |
| Hilarity! | |
Posted - 4/24/2006 10:11:40 AM | At the recommendation of a commenter on one of my previous entries (thanks, btw, even though I'm too lazy to find out who you were  ) I've been watching the video lectures from Structure and Interpretation of Computer Programs.
It's very entertaining, because the poor HP employees are clearly getting a very concentrated dose of brain-rape. Interestingly, being so freshly converted to the True Way of Lisp, I can both completely understand all of the concepts being discussed in the lectures, and understand just how utterly mind-bendingly weird all of this stuff is to a group of people who had (presumably) been doing everything in FORTRAN or whatever.
There's one guy in particular who occasionally gets shown during the lectures, and every time his face shows up, I imagine his brain overheating and his entire head exploding right there in the lecture hall.
Classic entertainment. If you're a total geek.
| |
| Short Journal Entry! Anathema! | |
Posted - 4/22/2006 9:21:02 PM | Alright, fine, I just can't do it. I can't post a short journal entry 
Actually, this is really just a half post-script. I have a feeling it won't make for anything long, but usually, the stronger I get that feeling, the more wrong I am - and the longer my posts get. Oh well.
Anyways, I just realized something about myself. I was working on putting together a mathematical model for balancing the rewards issued to the player when they complete missions in the game, based on a few input factors. I solved the problem the way I normally do: sat down, scribbled out some core observations and goals for the system, and then proceeded to stare vacantly into my lap for about 30 minutes. At one point I nearly fell asleep.
Then, after a while, I sort of popped "awake" and just spilled out a fully-formed, completely solved model, including ways to handle all the input factors (I even concluded that one of the proposed factors would have no beneficial effect and could be rolled into another factor). I wrote a 15KB email, entirely off the top of my head, in a single sitting. Didn't pause to think through anything, stop and reword anything, or whatever - it was basically fully formed in my brain already.
I probably would never have noticed that at all, except that I then proceeded to take a quick visit to the Lounge, and came across a thread on meditation. I read through the description of one of the meditative techniques, and realized that it pretty much identically matches what I do when I think about hard problems. That got me into Navel-Gazing Turbo Gear.
Looking back, I've been solving problems that way for as long as I can remember. I don't consciously sit there and think out-loud thoughts about whatever I'm working on - I sort of zone out, and after a while I just know the answer. Most of the time I can't even really express what I did to get the answer - which got me into a hell of a lot of hot water when I took Algebra in high school, let me tell you.
In fact, even then, I didn't really see what was going on; I just solved the problem, and never really was clear on why everyone seemed so obsessed with how I'd solved it. I knew I wasn't cheating, so it wasn't that - right? Bugged the heck out of me for quite a while, too; eventually I learned to suppress it, thanks to the carrot/stick of partial credit.
But left to my own devices, that's just how I do things. I think maybe that's why everyone at my Old Day Job had trouble realizing I was working on stuff - I probably look like I'm high or something.
That, of course, raises an interesting question: am I just insane for doing that, or is that how everyone works on hard problems? Is this some kind of weird psychological quirk that only appears among INTJ type people, or do I just do it more "strongly" than most people?
Inquiring hypochondriacs want to know
| |
| Noes! | |
Posted - 4/22/2006 9:06:55 PM | A new Books-A-Million just opened up about a mile from my apartment.
They also do not have any good books. In fact, the store is tiny, and barely has any computer-related books at all.
Alas.
| |
| Brain HUNGRY! | |
Posted - 4/21/2006 2:44:10 AM | I'm looking for a book. (For those not inclined to suffer through my tomes, you may skip to the end  )
In today's society, that's not really a remarkable thing. Just pop down to your local Borders, grab a double caramel latte with whipped cream and cinnamon, and bum around scanning shelves for a couple of hours. If you absolutely must get all hurried and technical and such, haul your coffee over to the little self-service info kiosk and search for the book by hand.
Heck, if you're going to be that lazy, just stay at home and use Amazon.
All of that works great... if you know what book you're looking for. Sure, for some categories of books, a good old-fashioned browse session in a brick-and-mortar store will probably get what you need. Maybe I'm just a sentimental, old-fashioned fart, but I really enjoy browsing like that. Grab a coffee, sit down in a nice spongy lounge chair, and blow an entire afternoon. Maybe take a short nap, walk around, talk to other people who are similarly browsing.
There comes a point, though, where brick and mortar stores have to make a trade-off. They have to stock stuff that they're likely to sell, or they'll never sell it. (I've had the grand good fortune to find a store specializing in obscure books precisely once in my life. Sadly, I was far too young and foolish to appreciate what I'd found at the time, and have long since forgotten where it even was.)
The practical upshot of this is that every now and then one comes across a need for a book that is very hard to satisfy by browsing - because the store doesn't stock such books. Sure, you can request specific books to be brought in, but that requires knowing the book you want beforehand - which again defeats the point of browsing.
The Internet was supposed to solve this. The dream was that oneday, mankind could feel this deep, ineffable need to find Some Book, about Some Thing. Man would then open up his Internet browser, do some searches, and find the Book. If the book sellers get to have their happy dream, too, then man finds several Books at the same time, many of which he wasn't actually looking for, and spends several hundred dollars stocking up shredded dead trees so he can curl up with lattes in the comfort of his own spongy lounge chair, without having to drive across town.
This is a wonderful dream. I hope it comes true someday.
For now, though, the dream is broken. Search technology sucks. Searching is useless on the Internet unless you already know what you are looking for (and even then sometimes it isn't all that useful). In fact, I think an interesting thing has happened, something that most people haven't quite cottoned on to yet.
Automated computerized searching is bad for learning things you know nothing about. If you can't express what you want to find in a couple of keywords, you're screwed. Often, you can come up with a couple of keywords, but unless they're precisely the same keywords that were thought of by everyone else, you probably won't find it, even though you know it's out there. Anyone who (like me) has been hanging around on the Internet for more than a few years knows the frustration of not being able to find something you know exists.
The fact is, people are far better at searching than computers, even the massive farms of computers at Google. (Because, face it, in the IT realm, Google is the de facto king of search.) People can talk to each other, discuss things, compare notes; even the mere act of describing to some other person what you are looking for often helps crystallize your own perceptions. People can say "I need Foo." Then some other person says "Well, I dunno about Foo, but I've got Bar, and it's pretty darn close." Then the first person says "Aha! Bar is indeed close, but not exactly it. Maybe what I'm really after is Baz. You got any Baz?" And then wham, Baz is found.
I think that's why, despite the near cliche of "Google first, post questions later," we still get a massive amount of people asking questions here (and on any Internet community, really). Because Google is only good for searching if you already know what you want to find. If you don't know what you're trying to find, you need people. People are far better at searching than Google - and it's likely to stay that way for at least a few more years. Maybe a lot of years. I don't know.
In the old days, this search problem was called "education." Since then we've totally perverted the concept of education and turned it into a brainwashing, here-beleive-these-facts sort of system. "Education" today means cramming the wealth of human knowledge down the uninterested throats of innocent kids who'd rather be running around outside. Education has lost its meaning, and this is a terrible misfortune.
Education, mentoring, discipleship, apprenticeship - even parenting - used to revolve around the notion of helping people search. The idea used to be that you would help people understand their own questions first, then help them answer them. It was a beautiful and powerful system. A thin scrap of it still survives in the American masters/doctorate degree research system, but even that spark is fading and dying, because people no longer understand that education means searching.
Education shouldn't be about pushing knowledge from the Knowledge Repository down into the Empty Young Minds. Education should be about the Older and Wiser coming alongside the Young, helping them to ask questions, and then helping to answer them.
I had a practical point here, but, as is my habit, I turned it into a rather long-winded rant - again. The practical point was that, in working on this Epoch project, I've realized just how unable I am to express my own questions.
What I really want is to be able to look at examples. I never really did care much for sterile, surgical history; but I'm absolutely fascinated by first-hand, personal, in-depth accounts of what people experience in the process of expressing questions, and then looking for answers. What I want is a book (maybe several books) that do this for programming languages. What struggles, annoyances, frustrations, and challenges were out there that drove people to create new languages? What motivated people to solve problems in certain ways rather than in others? To what extent are such solutions measurably "good" or "bad" and to what extent are they purely subjective?
I can't express that search in a way that Google or Amazon understands. I hope that maybe I can find someone sympathetic here, who knows better how to express the questions I want to ask - and maybe even knows how to answer them.
| |
| The right place for objects | |
Posted - 4/20/2006 4:16:38 AM | During my usual bouts of procrastination, I dug back up Paul Graham's essays, thinking that I might find some useful stuff in there since my Lisp conversion. Specifically, I started reading Why Arc Isn't Especially Object Oriented, looking to compare notes with Paul's work on the Arc language (a Lisp dialect, for those not familiar with it) with my own dabblings in the fledgling Epoch project.
I've read a lot of "OO considered harmful" type stuff in the past. I guess, like Lisp, it was one of those things that I shrugged off as crazy talk - because I didn't understand it, and because the writer didn't seem to explain it. Actually, I need to qualify that a bit, with some history of my own opinions on the matter of objects.
When I first started using objects extensively (around the time I got ahold of VB5 with its "new" Classes support) I thought objects were kind of handy for certain kinds of data modelling, but really didn't see what all the fuss was about writing entire programs based on objects interacting. As far as I was concerned, the Logical Thing To Do was to use objects to model, well, object-like stuff, and use good-ol' procedural style code to model logic and high-level operations involving objects.
However, I was very much a novice and unaware programmer at the time, so I figured there was a good chance I didn't know what I was talking about. While the attitude was good, I made a terrible mistake, which I now (in retrospect) kind of regret - I moved off into Java land. A lot of people were saying that Java was gonna be Really Big, and you'd better learn it if you want to have relevant skills in the real world.
I tried - really, really tried - for about a month to like Java. It had some of the niceness of VB's "get it done and screw the details" philosophy, and at least by comparison to C was kind of handy in that regard. But one thing just pissed me off about it: Java seemed to have some kind of weird, almost erotic fixation on objects. I ditched Java permanently, which (frankly) I think was a good move on my part. I've hated it ever since.
At that point, I'd been doing parallel work in VB and C for several years. I loved VB for doing "GUI stuff" and maybe the occasional rapid throwaway utility or whatever. For anything heavy-duty, I used C. (Actually, what I used was C++'s flavor of C-style programming - it was trivially isomorphic to C code, but exploited litte gimmicks like omitting struct everywhere. It wasn't legal C in the sense that you could compile it in a C compiler straight, but it was for all intents and purposes C code.) It worked great - I had a potent tag-team of languages that could solve most of my problems. I could even write MS-DOS 6 compatible batch files if I needed to.
However, I felt like I had some kind of gap in my knowledge still, because I didn't quite get this whole "objects" thing. I was still a student looking for a teacher, and sadly, at that point in time, the easiest teacher to find was the OO fanatic camp. I wish I could have found a different teacher instead (like, say, Lisp). But in any case, what happened happened - and I decided to try to learn "real C++" in order to get a handle on this objects stuff.
In the course of learning C++'s flavor of OO, I realized that OO was a vacuous (or, at best, nebulous) term. Every single language had a different notion of how OO should work, and nobody agreed that anyone else's was better (except maybe Smalltalk's). Nobody seemed to agree what OO really was - it just seemed to involve a lot of objects.
Even more unfortunate for me, I chose MFC as my entry point to the C++ land of OO. It permanently warped my opinion of the entire objects notion, although eventually I think the experience will prove beneficial, all things considered - if for nothing else than the fact that it has deeply broadened my experience. Call it an eye-opener, I guess.
I dabbled in this land for a while, doing a few little projects of my own, but never really liking it. I decided that my real problem was that I didn't have a good, hard problem to solve; I was just tooling around, and didn't have room to get a real solid feel for how Objects are supposed to be.
After a couple years of dabbling, I started the Day Job From Hell. (As a matter of fact, I'd "dabbled" a bit by writing a prototype version of what eventually became the product I worked on during that job. But that's another tale.) I figured it was my lucky break: the main thing I was to work on was - you guessed it - a C++, OO-heavy, MFC-encumbered mess. Of course, at that point, it was like some kind of vision from heaven; finally, I could get some clarity on all this OO stuff!
I wrestled, hard, with that project at first. I tried - really tried - to do everything in OO style, like Java. Except at every turn, I had this deep revulsion; I felt like I was going back into Java-land. Java was supposedly this great, highly OO language, but I hated it. Something wasn't adding up in my head.
Around that time I picked up a copy of The Pragmatic Programmer. Finally, things started to click, and it was the beginning of the fastest period of acceleration in my personal understanding of programming that has happened to date (in fact, I think I'm still on that upward trend, and possibly still accelerating a bit). Instead of trying to pursue this ghost, this OO, this object-worshiping nothingness that never seemed to materialize, I started using Pragmatic principles instead.
I rewrote the program, almost 100% from scratch, against very heavy protests from the management. I firmly believe that I made the right decision. Even now, I think the management is starting to grudgingly realize that it was the right thing to do; they've had a far more stable and reliable product even since I quit than they did when it was being actively maintained by the old developer.
After I got done rewriting the entire program, I noticed something funny: it deeply - and I mean very very deeply - resembled what I used to do in VB, all those years ago, when I first got my hands on "classes." Maybe a third of the "stuff" in the program was thought of as an object. The rest was basically procedural code, except with some of the nice trappings of C++ (STL, RAII, and such) to help smooth over the ugliness of doing applications in raw C.
For a while, I felt vaguely guilty about this. I felt like I'd betrayed my quest to Learn Objects, like I'd missed the mark somehow. I thought I had failed to understand the Grand Truth of OO, and that I was committing a deep sin by writing in the same style that I used to write VB code. I mean, hell, everyone knows VB is the worst language ever, right?
So I thought long and hard about this, in the back of my head, while other thoughts filled up my conscious effort. I realize now just how long this has been rolling around in my brain, but has only now attained clarity. The more I thought about it, the more I realized that I couldn't identify a "crime" in that code. Yeah, it wasn't Java-style OO, but it was exceptionally good code, compared to my previous stuff. Maybe it missed the mark of "the grand truth of OO" but it definitely lined up with what Pragmatic Programmer had to say. It wasn't object-laden, but I was still proud of that architecture.
I've been doing a lot of reading to back up my efforts on this Epoch thing. As a result, I've been finding out a lot about the real situation of OO. It seems that a lot of people have arrived at this conclusion long before me; and a lot of people seem to despise OO, at least in the sense of Java's "use objects or die" approach.
Now, though, I see a new perspective. I don't think the problem here is really objects per se - I think it's object orientation. And the more I read, the more I think that this is what all the anti-OO people have really been driving at all along; I just wasn't smart enough to understand it yet.
My problem was premature rejection. I read this stuff that, to me, seemed to be saying "objects are stupid! Use Lisp instead." And this bothered me. I had all kinds of cases where objects were exceptionally good representations of certain classes of problems. Today, I'd say that objects are probably the best method (for now at least) of modelling systems that are dominated by automata. A simulation game like X3 would be a damned nightmare to write without objects.
So, I would read these anti-OO discussions, and figure everyone out there was insane. I could see the benefits and power of objects plain as day, and these people seemed to be telling me that objects were, in fact, not useful. So I largely ignored the whole thing, assuming that once I found the Great Truth of OO, I'd be able to counter their arguments.
I did find the Great Truth of OO, but the truth isn't that the Emperor is also the Messiah. The truth is that the Emperor has had a catastrophic wardrobe malfunction.
Objects are awesome tools of abstraction. I think they should stick around, and here's what I think the term should mean:
- An object has some state, also called attributes or properties.
- An object knows how to do interesting things with its own state.
That's all. No more, no less. Encapsulation, implementation hiding, data hiding, all these things are good - but they are not inherent properties of objects, nor do objects hold a monopoly on those notions. In this sense, I think, objects are still very good tools.
Where we get into evil trouble is when we try to write all of our logic as objects. The presence of "manager" or "handler" objects is a tell-tale sign of this. Steve Yegge posted a humorous caricature of this kind of programming in Execution in the Kingdom of Nouns. I think, to a large degree, this kind of stuff is what "object-orientation" is all about: if you have code to write, find a way to cram it into an "object," a noun.
I think that we now have enough history (thanks to Java) to prove that this is a Bad Way To Do Things.
Inevitably, the question of objects is going to come up in the Epoch project. Up until now, I've been basically planning on declaring Epoch to support object-orientation. Now, though, I've changed my mind. Epoch will revile object-orientation. Epoch will spit upon it, deface it, shame it, and tell it to go back to Java land where it belongs, so that we can get work done in peace.
Epoch will have a new perspective. Well, I don't think the perspective itself is really all that new; I just don't think anyone has codified it before. I think a lot of people have become disillusioned with OO (if they were ever "illusioned" to begin with), and already have this perspective. But I've never seen a name for it, or even a really concise description of what it entails - just rhetoric about why OO is bad.
I've started thinking about it as "object awareness." Objects exist, and they're very useful tools in certain areas. As such, I think it's important to allow for them. Epoch will definitely "believe in" objects in that it won't be object-agnostic, the way, say, BASIC or C is. Objects themselves will be welcome citizens. Heck, at this point, I'm moving in the direction of modelling Epoch's language within itself, using self-referential, recursive objects.
Where the line is drawn, though, is in idolizing objects. Some things just shouldn't be objects. I think the term "object oriented" carries a sort of connotation of bending everything in the direction of objects. Objects aren't merely first-class citizens; they're aristocrats, maybe even dictators. That, I think, is the essence of all that is wrong with OO.
Here's to Object-Aware Programming. May our code be more concise, our abstractions more clean, and our modules less cluttered with FooManagers.
| |
| Wednesday, April 19, 2006 |
| Oooh bandwagon! | |
Posted - 4/19/2006 5:13:30 PM | I just joined LinkedIn. I don't know why, as usually I avoid those kinds of things as a rule, but for some reason it sounded good. Or maybe I was just bored. Maybe I thought I'd get on this bandwagon "early" while there's still leg room. I dunno.
In any case, if you add me, make sure you get the Mike Lewis that works for Egosoft - because there's a shedload of us out there, and most of them aren't me. (I did find another Mike Lewis in the Atlanta area who works in IT, which is kind of weird. I wonder how he'd respond if I came to work and started yelling at him about identity theft.)
Righty-o then... back to work for moi.
| |
| Some useless pondering | |
Posted - 4/19/2006 12:00:26 AM | Bill Amend is the smartest person in the universe.
Hang on... maybe I need to back up a bit and explain this properly.
So I was sitting around doing whatever, and suddenly, unbidden, something came to mind: an old Foxtrot comic strip where Jason writes a multimedia book report for school. At one point he's shown with a pile of thick, technical-looking tomes heaped on his desk. One of the titles there was "Binary Search Trees in C."
For some reason, this bugged me. My first reaction was that binary search trees aren't that complicated, and shouldn't deserve an entire thick book - maybe a 20 or 30 page chapter in a book on general algorithms and data structures.
My next thought was a sort of rebuttal to this (my mind like to debate itself). If you need to describe the notion of a binary search tree to an absolute initiate, it could well take an entire book: examination of representations for data, comparisons of alternate search methods, some guidelines for identifying areas where a binary search tree is a good solution, explanation of tree structures in general, examinations of various traversal methods and their inherent tradeoffs... maybe, just maybe, you could get an entire book out of it.
But, I countered to myself, does that even make sense? Would such a book really be titled Binary Search Trees in C? Don't you think it would have a better title, like, say, "Searching with Tree-Based Structures" or something? The phrase "in C" really seems to indicate that this is focused specifically on implementing binary tree related stuff in the C language. So to me, at least, that sort of implies that the reader is expected to have at least passing familiarity with the concept. And in that case, describing how to implement various tree-related things in C shouldn't take an entire book - again, maybe 20 or 30 pages, tops.
So, to me, this title is a miniature paradox. It doesn't make sense. It is inconsistent with the book's apparent mass. So what gives?
Then it occurred to me that maybe the secret here is simple: maybe it's just that the title sounds good. I mean, really - the vast bulk of Foxtrot's audience probably isn't comprised of veteran C hackers. So, by extension, it's quite likely that they don't know anything about binary search trees. In fact, for most people, seeing a book titled "Searching with Tree-Based Structures" will probably elicit a definite "WTF Mate?" reaction.
So, the phrase "binary tree" is important - because it has the word "binary" in it, and "binary" sounds, y'know, technical and stuff. Obviously then the phrase "binary tree" is technical too. So even if people do get weird mental images about oak trees made out of green glowing 1's and 0's, they'll be thinking technical. In fact, such an absurd mental image probably heightens the sense that this is a dense, specialized, genius-kids-only tome. Clearly, the notion of digitized flora is pretty strange, so a reader who gets such an impression on hearing the phrase "binary tree" is probably going to be more awed by Jason's mystical technological powers.
What of the "in C" clause, though? Again, to a totally non-technical reader, this gibberish is probably going to serve nicely to further confuse them. This isn't a bad confusion - in fact, it's a very good confusion, because it yet again reinforces the reader's impression that Jason is some kind of genius whiz kid computer magician. It also serves another, more insidious purpose: to the initiates, who will recognize the C language being referred to in the title, it's a sign of authenticity. You know who I mean: the CS dropouts who switched over to Creative Writing or something, heard about the C language once (and maybe have even seen a few lines of code). Those people now read this strip, and think to themselves, "Aha! I know about C. Clearly, this Bill Amend guy has done his homework. Clearly, Jason has teh überskillz. I am deeply impressed by his wizardry."
This title, then, is not just a paradox - it's a masterful work of mental manipulation. It's nothing less than art. Because even veteran programmers are likely to see the title, and think to themselves, "Hmmm... binary search trees. Useful things, them binary trees. And C, too - Jason's no weenie. He uses a Real Programming Language. This kid must be some pretty sharp stuff."
So really, this title is brilliant on Bill Amend's part - he's masterfully impressed the vast bulk of his readership, and drawn them deeper into the immersion of his comic-strip world. Pretty much everyone comes away from seeing that book title with a sort of sense that Jason's character is just sickeningly smart. And that's a very solid win for Amend.
He only made one miscalculation, though: the few, the proud, the skeptical and bored - well, me, anyways. He didn't count on someone analyzing the brilliance of his fictional book title. He left a little hole by which a critically-thinking programmer could rip a huge chunk out of the fabricated world of Foxtrot.
Uh oh, wait a second - this book is fictional, right? I suddenly realize that maybe my argument is baloney, because maybe it's a real book! However, a quick search of Amazon indicates that this is just a false alarm. The book is indeed an invention.
Except now another thought hits me, slowly and painfully: I've just spent a good twenty minutes dismantling the implications of a fake book title in a fricken comic strip.
What's worse, I didn't come away concluding that the author is a faker trying to twist our minds. I came away concluding that the title, while bogus, is actually brilliant in its effectiveness. To rub salt in the gaping wounds, I actually wrote a journal entry about it. Eek.
Bill Amend is truly smarter than me. There's no way that anyone can analyze his book title and find a problem with it (as far as I know), so chances are he's also smarter than everyone else in the world.
All hail the new Overlord of the Human Race.
| |
| Back in the swing o' things | |
Posted - 4/17/2006 6:53:27 PM | Well, it seems I've finally found my productivity gland again (after a three hour nap this afternoon, of course).
Stuff is flowing nicely and I should be able to get the plans for this cutscene system totally done here soon. I ran into a fun challenge today with controlling fine-grained timings for different events in a scene. My previous model was barfing terribly for a particular common case:
- Event A happens absolutely 5 seconds into playback (hardcode 5 second offset)
- A 2 second audio clip needs to be played just before the start of event A
- BUT the clip may be 3 seconds in another language
- The clip duration has to be computed automatically!
- Solution: start the audio clip at offset: (event a offset) - (clip duration)
The problem was, in the first incarnation of my timing model, the solution couldn't be expressed - at all. So I redid the timing system and came up with a far more potent solution.
Now I have a very nice framework that lets us build sophisticated and powerful timing interdependencies, with simple and easy-to-implement XML and code.
The secret? Recursion.
I have two recursive data elements: timing attributes (attributes of XML nodes), and manual timing nodes. A timing attribute is a simple XML attribute field that is allowed to take on multiple values depending on what it needs to represent:
- An integer evaluated as an absolute quantity of milliseconds
- A string that refers to a manual timing node's ID tag; the manual node's value is copied (lazily) and used as the value
- A string of the form start:foo that yields the starting time offset of foo (usually a shot displayed in the cutscene, or some other similar event)
- A string of the form end:foo that's similar to start:foo
- A string of the form duration:foo that yields the duration of foo
Any place where a node needs to talk about timing, it uses a timing attribute.
This leaves us to define what a manual timing node is. That's simple:
- A string giving the node's ID tag
- A base value, which is a timing attribute
- An optional offset attribute which adds or subtracts from the base value. Both addition and subtraction are permitted in the same timing node (trust me, this will be useful in a few special cases - but I don't have time to explain right now). The offset attributes are themselves timing attributes.
So if I want to cue a sound effect at some specific point in time, I just do thusly:
<bazaudio offset="specialtimingnode" />
...
<timing ref="specialtimingnode"
basevalue="end:QuuxShotNode"
offset_subtract="duration:QuuxSoundEffect"
/>
I can now express any timing relationship I want with the correct combination of manual timing nodes and automatically computed timing attributes. Cool stuff.
The other interesting problem that I've come up against is a little more abstract. Basically, the system I've designed is a kitchen-sink cutscene generation and rendering engine. It handles camera movement, flying all the little ships around and blowing them up, showing people talk, overlaying text and graphics onto the screen, etc. etc.
This makes the system ideal for displaying mission briefing sequences, where some talking head gives you some instructions, shows you some cool file footage of stuff exploding, etc.
Both systems are really designed, ultimately, for easy implementation. Everything is done with such recursive structures. The idea is that I can define a few simple pieces of code that handle those recursive elements, instead of writing a huge amount of special-case code to handle all the little variations and gimmicks that the content development team will need to be able to use.
Unfortunately, recursive data construction seems to be something that I understand just fine (and most of the other programmers as well) but just isn't something you use in the art/content realm too often. So the artists are at this point kind of worried that A) my system won't do what they need and B) even if it does they'll never figure it out.
Personally, I think that as soon as I get a couple of concrete examples done for everyone to look at, it'll get a lot more clear. To be fair, I've been thinking about these problems for a couple of months virtually non-stop, whereas everyone else hasn't. So it's only natural that the solution is obviously fine in my mind, but looks a bit iffy to everyone else.
For instance, most mission briefings will look pretty much alike. So from the artists' point of view, the most logical solution is to have a special-case XML and code system that handles those particular variations that they need. To them, it's better to add a special case when they need one. To me, that means code bloat, nasty bugs, and some terribly poor code longevity (as soon as the next project starts and we need different layouts, the code is useless). So I've been doing this other thing instead.
For a while, I was just planning on saying "here's an example, let me know if you need some pointers in getting any particular effects/results you need, I promise it all works and this is the best deal for everyone involved." I think that would have been a perfectly reasonable way to handle it.
Then I had an idea.
I'm constantly raving about building layers of abstraction in code. For some stupid reason, it took me until now to realize that I should also be building layers of abstraction in data.
The solution here is to build a veneer layer that lets the content creation team express notions abstractly and in simple data. Some kind of transformation layer then expands that into the lower-level data, which is pumped into the rest of the code. Since the code understands all this recursive, emergent gibberish, and the artists don't, all I need is a translation bridge between them.
It's really pretty similar to doing something like using XSLT to generate renderable markup from XML data, for instance. Except I'm moving from one abstraction of XML to another, and the actual translation mechanism will probably be a bit of manual code wizardry.
I still need to decide when this will be done. Doing it at design time has the advantage of needing less code and data to be shipped into production, but also requires the content team to "export" from abstract to concrete data formats every time they want to see their work in action. That sucks. So at the moment I'm leaning towards having the transformation be done "on the fly" when the game first loads the data.
This way, we can do things like abstract off the common briefing layouts/formats into one layer. The content developers generate content that targets that layer. Then, the translation code magically turns that into the raw cutscene data, which is much more stable and powerful. Everyone wins.
My brain is now dangerously close to self-combustion, so it's time to go do something Else for a while. With luck I'll have a bunch of this stuff documented (and maybe even implemented) very soon now.
It feels good to get back into things.
| |
| God Wills It! | |
Posted - 4/16/2006 3:38:39 AM | Well, if there's one thing every new Spiritual Convert needs, it's a good Crusade to fight for.
As a Newly Reformed Smug Lisp Weenie, I feel it is my deep responsibility to the Faith to join a Crusade. The thing is, I'm too lazy to see what Crusades are currently being fought, and I justify my laziness by telling myself I probably wouldn't want to fight for those Crusades anyways. So it's easier just to start my own. This also happens to dovetail nicely with my Ulterior Motives, i.e. the Epoch language project.
I've been reading up some more on what people are thinking The Next Big Language will be. It seems there's a generally widespread opinion that The Next Big Language is going to have to come from a major corporation like Microsoft or Sun. Maybe there's some dissent, but the only really well-argued stuff I've seen (so far) basically agrees that grassroots language revolutions will just take too long to gather critical mass. They might have great languages, but they won't be The Next Big One because they lack massive support and hype.
Hype and push from a Very Wealthy Corporation can take even a miserably poor language (read: Java) and turn it into a phenomenon. Conversely, really good languages (like the Lisp family, the ML family, and so on) are not going anywhere, even though they blow away other languages by a huge margin.
It seems that there's this sort of pervasive argument going on here. The argument basically observes that Lisp hasn't taken over the world, and Java (the language, not the platform) sucks and has more or less taken over the world because of marketing from Sun (and, to a lesser degree, Microsoft). The argument then concludes that, in light of these observations, The Next Big Language will have to come from A Really Big Company. Or maybe it will be Ruby, but probably it'll come from A Really Big Company.
I think this is bogus.
In fact, I think the Next Big Language will come from somewhere else. I think it will appear in a very grassroots way, and blindside the traditional Language Creation/Adoption Pipeline. I think that a highly pragmatic approach just might change the way we think of how programming languages grow.
I kind of waxed rhetorical at the end, but you can read my schemes (hehe, a Lisp pun! I'm such a clever little disciple) over in the Epoch thread, specifically at this post.
| |
| *Cue angelic beam of light* | |
Posted - 4/15/2006 4:12:19 AM | A funny thing happened today.
Actually, it happened a couple of days ago, but the effects have taken a bit of time to fully hit home. I was reading around in Steve Yegge's blog archives, Lambda the Ultimate, and a few other places that I forget at the moment. The other important bit of background was that I was fooling around with some concepts for the syntax of the emerging Epoch language. Somewhere in all this, something deep in my brain snapped.
I want to use the word "sudden" to describe what happened, but that isn't really quite accurate. It was a slow thing, building over a couple of hours (and in fact is still building a bit even now). There was no one trigger, not even in the sense of a "straw that broke the camel's back." Somewhere, though, a pile of thoughts, peeves, and old questions sort of congealed, and the half-formed answers in the back of my mind passed some ineffable threshold.
Once that marker was passed, my entire view on programming - and, more importantly, programming languages - changed profoundly. As cheesy as it may sound, it honestly has given me an almost giddy sense of euphoria. There is really something verging on the spiritual about reaching such a deep mental clarity. One could almost say that I've found religion.
I've found Lisp.
You have no idea how weird it is to type those words seriously. Heck, it wasn't but a few months ago that I was casually dismissing the world of "smug Lisp weenies" (brownie points to whoever I stole that phrase from) and probing the land of imperative languages for the answer to All My Programming Problems. I've been pondering for years the need for better abstraction facilities in programming languages - although admittedly for much of that time I only knew that I was annoyed at the deficiencies of languages like Java, without being able to really clearly express why I felt them to be so crippled. In fact, a fair bit of my journey along that road is recorded here in this very journal.
Over time, things added up. Then came Tim Sweeney's presentation on programming language needs for next-generation games. That whole thing spurred off a thought in my mind that had been brewing for some time: existing languages suck. So let's build a new one! The results of that particular epiphany are still doing interesting things off in this thread.
Yet even during that discussion, I've mostly (until now) been kind of stand-offish with respect to Lisp. When the language was still called Foo, I wanted to steal some of the "nifty" Lisp features without falling off the deep end into all that crazy talk about sexprs and macros. As things evolved into Epoch, I wanted to steal Lisp's power without looking like Lisp.
I've known for quite some time now of the need for a richer language than what I'm normally stuck with using. In fact, I've often looked at functional languages like Lisp, ML, and Haskell with a sort of wistful longing - I wanted to get into all that awesome potency, but without the scary shapes and incantations that didn't really make sense to my C-addled brain. I could appreciate the need for expressivity, extensible languages, and clean methods for building abstractions. I just hated the syntax.
I think I might have stayed in precisely that position for a very long time - maybe forever - if the Epoch discussion hadn't happened. The Epoch thing got me thinking really hard about syntax, and about clean ways of expressing a very rich and self-extending set of notions. I had started slowly down the trap of making a Really Convoluted Syntax, when something I read (I wish I could recall what) brought me back to reality: a simple, elegant syntax will serve much better.
Actually, I think one other thing contributed powerfully to my Conversion - my work at Egosoft. I've been working on defining a lot of new data formats for some of the features I'm building. In the process, I've had a bit of a struggle - the artists and content creation folks basically want the data to be a huge blob of special-case stuff, with lots of truly disgusting edge-cases, magic symbols, and so on. I've been fighting to take a totally different approach: define all of the data recursively, building complex content in a sort of emergent way from a lot of tiny and similar building blocks. I've played with a huge number of alternatives, and this recursive approach just makes this incredibly better all around. It's more powerful, more robust, and more reliable - it doesn't need a lot of special-case code to back it up, meaning that it decreases (in the long run) the chance of stupid bugs creeping in at edge cases.
So anyways, while I was reading whatever it was that I was reading, the Big Light Bulb Over My Head clicked on. Obviously, this recursive-definition thing isn't just a good idea for game data. It's a good idea for any data. Now I can see clearly why I'm so drawn to the idea of XML but find it to be so annoying and icky at the core - it's almost this recursive thing, but not quite.
Now I can see why Lisp is such an effective language family. Now I can appreciate the syntax and the philosophy behind it. Before, it struck me as just this weird, otherworldly, almost arbitrary thing. Some lunatic had a parenthesis-fetish, and built a language around it. Thanks but no thanks, I prefer the curly braces and four-billion-page specs that can only begin to cover the silly little nuances of syntax.
Unlike any other time before, I can really appreciate the effectiveness of Lisp's syntactical approach. It's not just a random thing - it's a truly beautiful and elegant solution to some very hard problems in language design. I'm not nearly smart enough to solve those problems. Every time I try to hack out a little start at a solution, I look over at Lisp and find out that it's already done a better job, and has been for decades.
At this point, I'm in a weird position. I want a language that has the Lisp-nature, but is not Lisp. It seems like some sort of bizarre Zen mind-rape. Maybe this is the last vestiges of my long history in the C-syntax family still clinging on to my soul for dear life. Maybe I've loaded my bloodstream so thick with curly braces that I need time to be purged.
Or maybe I have this sort of niggling feeling like Lisp just isn't quite it yet. (Eww... I almost feel like a heretic for even suggesting that, when even a few days ago I would have been proud to announce it.) Frankly, I think there's some truth there. Lisp is a brilliant concept. It does a lot of things in very nice ways. And yet I can't help but wonder why it has never taken off, why stupid messy compost heap languages like C++, Perl, and Java still exist.
I've heard a lot of theories as to why Lisp has failed to take over the world. Most of them strike me as total garbage. I think the reality is that Lisp, while Well and Truly Awesome, is still a step short of optimal.
It's funny, really. Two days ago I would have had no reservations about implying that Lisp isn't The Best Thing Forever and Ever. Yet now, as a newly reborn Smug Lisp Weenie, I feel kind of dirty for even bringing it up. I haven't even written any nontrivial software in Lisp yet. Now I can truly sympathize with those who found the Truth before me; you really honestly can't explain it succinctly.
To reach enlightenment requires one to travel down a long, hard road. It takes experience and acute awareness of the deficiencies of other tools. It takes a lot of hard thinking about deep principles of programming. You really can't be led to Lisp Enlightenment by means of a clever article or book. Like nirvana, Lisp Enlightenment must be attained by each individual, walking on his own path.
I doubt I'm smart enough to invent something that is closer to optimal than Lisp, at least not by itself. But maybe there's hope in learning from Lisp. Maybe we can take the pragmatic road, look long and hard at the realities of Lisp's station in life, and see if there just might be some room for improvement. Maybe we can stand upon the shoulders of giants, and just maybe, in so doing, we can see farther.
So now I am a Smug Lisp Weenie in Training. And damned if there isn't a heck of a lot to be smug about.
| |
| Procrastination and such | |
Posted - 4/14/2006 3:24:00 PM | Well, I ended up falling asleep last night instead of working. Story of my life. I'm going to make a quick effort at making up for it today, but I have four challenges that will defy that:
- My parents left Florida today and will by stopping by in the area on their way to Indiana. So my weekend will pretty much be consumed by bumming free meals off my sister (with whom they are staying).
- It's Friday, and Fridays always suck for getting work done. Worse, I'd be working on a Friday night, which is just shameful, and I wouldn't at all be surprised if I get "coerced" into going out someplace tonight instead of working.
- My nephew has a soccer game tomorrow morning at 11 AM. So I have to be conscious by then, since I don't want to miss it, and since there's food afterwards.
- I have an aunt who is notorious for giving incredibly awesome gifts. This year for my birthday she gave me a little DIY robotics kit, where you assemble a little robot mouse that can follow a path using optical sensors. Unfortunately the manufacturer's site is a total mess, so I have no links, but I'll be posting a documentary of my assembly efforts.
So... my high-minded, noble attempts at productivity just got their collective butt kicked, and hard.
But robotic thingies are fun, so I really don't care
| |
Page: 1 2 »»
All times are ET (US) |
In locus hic, omnes res dementes sunt.
|
OPTIONS
Track this Journal
ARCHIVES
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
