What I am up to these days instead of fixing Walkabout

I suppose I have some explaining to do after that deck. I'll start with the relevant stuff: my latest attempt at stripping T3D down to its bare minimum. Which was, as you will read below, mildly successful.

t3d-bones

I suppose it's a bit of an odd title, but it comes out of the good old 'barebones' ideology: nothing but what is absolutely necessary. It's been the goal of the Empty template for a while now, I guess, but I felt it really didn't quite get right down to the marrow. There were still some ligaments attached, a bit of meat hanging around.

Nothing serious, of course. A good example is the mission structure. All the templates, Empty included, assume that your server will host a game, load up a mission file, then a client will connect, download some datablocks, receive ghosts, and be displaying a UI while doing so.

Which is entirely sensible. But still an assumption, and still a lot of code to get rid of. I'm not kidding. Stripping all that out was a lot of work. And it made me appreciate what a lot of work had gone into the thing. I said it back when I announced I was done, but I'll say it again: if you really want to learn in-depth how the template scripts work, getting rid of them is a great way to do that. It forces you to understand the processes they're implementing, so that you can simplify them.

Anyway, without further ado, this is what I ended up with:


This, my friends, is progress.
It... looks kind of like... the Empty level. With no player.

YES!

But get this, all the scripts and assets are 1.45MB large. And 1.06MB of that is graphics configuration that I'm way too scared to play with, but I'm sure could be mostly picked off if you knew you really weren't going to need them. This simple app will do nothing more than load up a local server, which you can then add objects to to your heart's content. The whole affair is completely transparent to you - the only script file (aside from the aforementioned graphics config) is main.cs. It's all there.

I'm sure it's incredibly geeky to be excited by this.

While I'm talking about this, I should not forget to give a massive thanks to Mike Hall, whose legwork made it possible for me to get this far. In working on a revised template for MIT3D (which sadly didn't make it into the 3.0 release), he took the important step of merging the core/ folder with the game/ folder, which made my job so much easier.

And it looks like he's got even more exciting stuff up his sleeve, too, though I'm sure we'll hear more about that soon.

Now, I guess the question is... how long will it take to write up a tutorial explaining this new template? (I flatter myself in referring to it that way, but I genuinely hope this is something people will want to use - the more code-inclined like me, who have no problem creating objects by hand).

Oh yeah. You can get it on GitHub here. In the immortal words of Neil Buchanan: try it yourself!

Canvas shenanigans

It's no secret that I'm a large fan of Bret Victor. He's a UX designer, coder, artist, and general all-round stand-up guy. He has some really interesting ideas about programming languages that made me rethink a lot of what I thought I knew about them.

If you haven't read it on any of the numerous occasions I've linked to it, well:

Here's another chance

Seriously, it's long, but a fantastic essay on how we can better teach programming*. It's something I've taken to heart so much that for a uni course investigating different image processing algorithms I've decided to write my own graphics framework. They told us we could use any language we like...

* I will admit that most of the cool stuff in that essay is about the environment - ways of visualising code and its execution. I've focused on his tips about language design, which are closer to the less exciting end of the piece.

It started as a simple reaction - ugh, I don't want to use Processing. My thought process then looked something like this: Right, I'll use OpenCV in Python... oh wait, that's a bit nasty too. Okay, so I'll write a more functional wrapper around OpenCV's Python interface... no, that's almost as insane as just using the library as it was intended. Right, the next most reasonable option is to write my own.*

*I should note that I ignored most of the existing HTML5 Canvas libraries out there.

And before I go any further, here's a pretty picture I made using my new library:


Look carefully - the pixels get bigger the further they are from her face.
And here's the code that makes it happen.

What I set out to do was resolve some of Bret's complaints with Processing, complaints that I've taken to heart. For example: Processing functions typically look like this:

ellipse(200, 100, 300, 400);

And Bret asks the very simple question: what do those numbers mean? The language is exactly as expressive as assembly:

push 100; push 100; push 50; push 50; call _ellipse

But it's more efficient - less characters to type, I'm sure I hear some people say. I've come to believe that efficiency isn't just about code size. That certainly plays a part, and I think code size is often a good indicator of overly complex code (or language) - but what really makes code efficient at expressing an idea is how readable it is to the untrained eye - to someone looking at your code for the first time.

To get an idea of this, compare the line above to this:

@drawEllipse
   x: 20
   y: 50
   width: 10
   height: 5

More stuff to type, but it's much quicker to understand, even if you just cast your eye over it. That last example was syntax from Processee*, by the way - my experimental wrapper over Processing. Processing.js, actually - it's a JavaScript port of Processing that runs in the browser using the same syntax. Then I wrote lots of my own functions that call their functions, with nicer syntax.

*It's actually CoffeeScript syntax, I shouldn't boast - but I thought CoffeeScript would make a very nice image-drawing DSL. And so did someone else.

And then I wrote a lot of my own functions for stuff like image handling. Because of this:

Quote:We often think of a programming environment or language in terms of its features -- this one has code folding, that one has type inference. This is like thinking about a book in terms of its words -- this book has a fortuitous, that one has a munificent. What matters is not individual words, but how the words together convey a message.

Likewise, a well-designed system is not simply a bag of features. A good system is designed to encourage particular ways of thinking, with all features carefully and cohesively designed around that purpose.

I kind of want to leave it there. That's basically my mission statement for Processee - if it can live up to that quote, I'll be happy.

Also, if it has enough features for me to write this assignment that's due in two weeks...